해커는 '첫 번째 원칙'으로 돌아갑니다. 곡선 위기는 일반적인 공격이 아닙니다.
원저자:Jaleel，BlockBeats
원저자:Jack，BlockBeats
원본 편집자:
취약점 악용 사건이 발생하면서 DeFi 업계는 혼란에 빠졌습니다. DeFi 업계의 거대 기업인 Curve Finance는 심각한 공격의 대상이 되었으며 alETH/msETH/pETH와 같은 여러 스테이블코인 풀이 위험에 처해 있습니다. 불완전한 통계에 따르면 취약점 악용 이벤트로 인해 Alchemix, JPEG'd, MetronomeDAO, deBridge, Ellipsis 및 CRV/ETH 풀에서 총 5,200만 달러의 손실이 발생했으며 전체 시장의 신뢰가 심각하게 흔들렸습니다.
Vyper 0.2.15, 0.2.16 및 0.3.0 버전의 재진입 잠금은 유효하지 않으며 Vyper 공식 문서 설치 인터페이스는 잘못된 버전을 권장합니다. Vyper 컴파일러를 사용하는 다른 프로젝트 당사자들도 다음 피해자가 되지 않도록 서둘러 자체 조사를 실시했습니다. 취약점 익스플로잇 사건의 출처가 점차 밝혀지면서 시장은 이번 위기가 단순한 해커 익스플로잇 사건을 의미할 뿐만 아니라 전체 DeFi 산업에 대한 전체 기반 스택의 잠재적인 막대한 위험을 드러내는 것임을 점차 깨닫고 있습니다.
과거에 비해 이전 기간의 해킹 사고 건수는 점점 줄어들고 있으며 이는 시장의 번영과 불가분의 관계입니다. DeFi 여름과 NFT 여름 동안 매주 새로운 10억 달러 규모의 계약이 출시되었지만 오늘날의 시장은 매우 축소되었습니다. 동시에 해커가 익스플로잇을 찾거나 대규모 공격을 수행할 수 있는 시장 기회는 점차 줄어들고 있습니다. 이는 해커가 탐색할 새로운 미개척 진입점이 필요하다는 것을 의미합니다.@BoxMrChen) 및 BTX 연구원 Derek (@begas_btxcap）。
첫 번째 수준 제목
커브 이벤트는 어떻게 발생하나요?@StaniKulechovAave와 Lens의 창립자인 Stani(
)는 소셜 미디어를 통해 이번 사건에 대해 다음과 같이 견해를 밝혔습니다. 이것은 Curve와 DeFi에 있어서 불행한 차질입니다. DeFi는 기여할 수 있는 열린 공간이지만 절대적으로 정확하기는 어렵고 위험이 높습니다. In Curve's 경우에는 프로토콜 수준에서 올바르게 처리했습니다.”
Curve가 겪은 악용은 Ethereum 스마트 계약에 대한 가장 오래되고 아마도 가장 일반적인 공격 형태 중 하나인 재진입 공격입니다. 재진입 공격을 통해 공격자는 해당 함수에 대한 이전 호출이 완료될 때까지 기다리지 않고 스마트 계약의 함수를 반복적으로 호출할 수 있습니다. 이런 식으로 그들은 피해자 계약의 자금이 소진될 때까지 계속해서 허점을 이용해 자금을 인출할 수 있습니다.
재진입 잠금 및 CEI 원칙
재진입 공격을 설명하는 간단한 예를 들어 보겠습니다. 은행에는 총 100,000개의 현금이 있습니다. 하지만 이 은행에는 큰 허점이 있습니다. 사람들이 돈을 인출할 때마다 은행 직원은 계좌 잔액을 즉시 업데이트하지 않고 하루가 끝날 때까지 기다렸다가 확인하고 업데이트한다는 것입니다. 이때 누군가 이 허점을 발견하고 은행에 계좌를 개설해 먼저 1000위안을 입금한 뒤 1000위안을 인출했다가 5분 만에 1000위안을 인출했다. 은행이 실시간으로 잔액을 업데이트하지 않기 때문에 시스템은 확인하고 업데이트하기 전에 그의 계좌에 아직 1,000위안이 남아 있는 것으로 간주합니다. 반복적인 작업을 통해 사용자는 마침내 은행에 있던 현금 10만 달러를 모두 인출했습니다. 은행은 허점이 악용되었음을 발견한 것은 하루가 끝날 때까지였습니다.
재진입 공격의 복잡성은 계약 간의 상호 호출과 계약 자체의 논리적 허점을 활용하고 의도적으로 예외 및 롤백 기능을 트리거하여 사기 행위를 달성한다는 사실에 있습니다. 공격자는 자금을 훔치기 위해 계약의 논리적 허점을 반복적으로 악용할 수 있습니다. 재진입 공격을 방지하는 솔루션도 매우 일반적이며 보호를 위해 대상 특수 코드 내용을 미리 설정하고 이러한 보호 메커니즘을 사용하여 자금의 보안을 보장하는데 이를 재진입 잠금이라고 합니다.Solidity는 CEI 원칙
(효과 상호 작용 확인)은 재진입 공격으로부터 기능을 잘 보호할 수 있습니다. CEI 원칙의 내용은 다음과 같습니다.
1. 함수 구성 요소의 호출 순서는 첫 번째, 검사, 두 번째, 상태 변수에 대한 영향, 마지막으로 외부 엔터티와의 상호 작용이어야 합니다.
2. 외부 엔터티와 상호 작용하기 전에 모든 상태 변수를 업데이트해야 합니다. 이를 낙관적 장부 관리라고 하며, 상호 작용이 실제로 발생하기 전에 효과가 기록됩니다.
3. 호출 엔터티가 함수를 호출할 권한이 있는지 확인하기 위해 함수 시작 부분에서 검사를 수행해야 합니다.
4. 재진입 공격을 방지하려면 외부 호출 전에 상태 변수를 업데이트해야 합니다.
5. 신뢰할 수 있는 외부 엔터티라도 악의적인 제3자에게 제어 흐름을 넘길 수 있으므로 CEI 패턴을 따라야 합니다.
문서에 따르면 CEI 원칙은 특히 재진입 공격을 방지하여 계약의 공격 표면을 제한하는 데 도움이 됩니다. CEI 원칙은 로직을 변경하지 않고도 주로 기능 코드 순서대로 쉽게 적용할 수 있습니다. 이더리움의 포크로 이어진 The DAO의 잘 알려진 익스플로잇 역시 'CEI 원칙'을 무시했고, 공격자는 재진입 공격을 성공시켜 파괴적인 결과를 초래했다.
그러나 공격을 받고 있는 Curve 풀은 Curve가 Vyper 컴파일러를 사용하기 때문에 이 CEI 원칙을 따르지 않았습니다. 컴파일러의 Vyper 코드 취약점으로 인해 재진입 잠금이 실패하여 해커의 재진입 공격이 성공하게 됩니다.
대부분의 사람들은 Solidity를 알고 있지만 Solidity가 스마트 계약 작성을 위한 유일한 언어는 아닙니다. Solidity의 인기 있는 대안은 Vyper입니다. Vyper는 Solidity만큼 강력하고 대중적이지는 않지만 Python에 익숙한 개발자에게 이상적입니다. Vyper는 Python과 유사한 코드를 Ethereum 스마트 계약 프로그래밍 언어로 변환할 수 있기 때문입니다.
github 정보에 따르면 Vyper의 github 코드 베이스에 처음으로 기여한 개발자는 Curve의 개발자이기도 합니다. Curve가 Solidity 대신 Vyper를 사용하는 이유를 설명하는 것은 어렵지 않습니다.
Vyper 재진입 잠금이 실패하는 이유는 무엇입니까?@BoxMrChen그렇다면 이번 공격에서 Vyper의 문제점은 무엇입니까? 재진입 잠금이 실패하는 이유는 무엇입니까? 시험이 없어서 그런가? BlockBeats가 스마트 계약 개발자 Box 826.eth를 인터뷰했습니다(
) 그에 따르면 Vyper 재진입 잠금 장치는 사용 사례를 통해 테스트되었습니다. 하지만 실패 이유는 테스트 케이스가 결과 지향적이기 때문, 즉 테스트 케이스도 틀렸다는 점이다.
간단히 말해서, Vyper 재진입 잠금이 실패하는 가장 큰 이유는 테스트 케이스를 작성한 사람이 설명할 수 없을 정도로 슬롯이 1을 건너뛰는 이유에 대해 생각하지 않고 결과를 기반으로 테스트 케이스를 작성했기 때문입니다.
Box가 공유하는 Vyper 코드의 다음 단락에서 문제를 명확하게 볼 수 있습니다. 두 번째로 잠금 이름이 나타나면 Storage_slots 개수를 덮어쓰게 됩니다. 즉, 다시 말하면 첫 번째 잠금 획득에 대한 슬롯은 0이지만 함수가 다시 잠금을 사용한 후에는 잠금 슬롯이 0만큼 증가합니다. 하나. 컴파일 후 잘못된 슬롯이 사용되어 재진입 잠금이 적용되지 않습니다.
왼쪽이 공격받은 코드, 오른쪽이 복구된 코드
잘못된 테스트 결과가 예상되며 당연히 오류를 확인할 수 없습니다. 간단한 예를 들자면 지금 계산 문제를 하고 있는데 1+ 1 = 2인데 주어진 표준 답은 1+ 1 = 3이라고 틀렸습니다. 그리고 이 문제를 하던 동급생이 틀린 답을 내서 1+1 = 3이라고 대답했는데, 미리 주어진 표준 답안과 같았기 때문에 프로그램에서는 당연히 시험 결과가 옳다고 판단할 방법이 없었다. 틀렸어요. Box는 BlockBeats와의 인터뷰에서 말했습니다.
2년 동안 매달린 '다모클레스의 검'사상 최초로 기록된 재진입 공격에서,WETH 공격 와이즈 공격
공격자는 더 많은 프로젝트를 재진입 공격 가능성으로부터 면역시키기 위해 개발자가 재진입 공격에 더 많은 주의를 기울이도록 의도적으로 공격을 만드는 해커일 뿐입니다. 스마트 계약의 맥락에서 개발자는 보호를 달성하기 위해 상태 변경 기능을 호출하는 등 다양한 트리거 메커니즘을 사용해야 합니다. 이를 위해서는 개발자가 계약을 설계할 때 가능한 공격 시나리오를 충분히 고려하고 적절한 예방 조치를 취해야 합니다.
Vyper 편집기에 대한 심층적인 이해를 얻기 위해 BlockBeats는 BTX 연구원 Derek(@begas_btxcap)을 인터뷰했습니다. 그는 Python에 익숙한 개발자에게 Vyper는 더 편안한 UI 인터페이스와 더 빠른 속도를 갖춘 Solidity보다 더 이상적인 선택이라고 말했습니다. 학습. 그러나 Vyper 편집기 코드의 일부 버전은 신뢰할 수 있는 제3자에 의해 감사되지 않은 것으로 보입니다. 일부 감사 작업도 개발자가 직접 수행할 수 있습니다. 이런 일은 전통적인 IT 산업에서는 일어나지 않을 것입니다. 왜냐하면 새로운 언어가 나온 후에는 허점을 찾는 수많은 감사 회사가 있을 것이기 때문입니다.
말할 것도 없이, 버그가 2년 동안 공개적으로 존재하도록 허용합니다. fubuloubu 바이퍼 기여자
또한 다음과 같이 말했습니다. 컴파일러는 모든 사람이 생각하는 것만큼 심사나 감사를 받지 않습니다. 대부분의 컴파일러는 중요하고 자주 변경되므로 감사가 불리합니다. 전체 코드베이스 감사를 수행하더라도 이후에 더 많은 버전이 추가되면 구식이 됩니다. 컴파일러를 감사하는 것은 좋은 생각이 아닙니다. 왜냐하면 도구를 사용하여 최종 사용자가 생성한 최종 제품(예: 원시 EVM 코드)을 감사하는 것이 더 합리적이기 때문입니다.
이 모든 것은 마지막 문제인 동기 부여를 가리킵니다. 그렇긴 하지만, 누구도 컴파일러, 특히 이전 버전에서 심각한 버그를 발견할 동기가 없습니다. fubuloubu는 이전에 사용자가 공동 후원하는 현상금 프로그램을 추가하여 Vyper를 개선하는 데 도움이 되는 제안을 했지만 통과되지 않았습니다.
해커들은 첫 번째 원칙으로 돌아가고 있습니다.
이는 프로토콜 및 프로젝트 개발자를 위한 계약에 안전한 개발 관행의 또 다른 살아있는 예입니다. 그러나 가장 중요한 것은 Curve 사건이 우리 모두에게 기본 컴파일러의 보안이 심각하게 무시되었다는 경고를 줬고, 첫 번째 원칙으로 돌아간 해커들이 하위 컴파일러에서 완벽한 원칙을 찾아 입구를 끊었다는 것입니다.@StaniKulechov그 후 Aave와 Lens의 창립자인 Stani(
)도 자신의 감정을 표현하기 위해 소셜 미디어에 장문의 글을 올렸습니다: Curve 공격은 DeFi의 위험이 항상 전체 기본 스택, 프로그래밍 언어, EVM 등을 포함한다는 것을 의미합니다. 이는 특히 향후 맞춤형 EVM 및 애플리케이션 체인을 사용할 때 더욱 주의하고 민감해야 함을 경고합니다.
낮은 레벨에서의 공격
컴파일러 취약점의 경우 계약 소스 코드의 로직을 감사하는 것만으로는 알아내기 어렵습니다. 버전과 버전의 차이점을 연구하는 것만으로도 큰 프로젝트입니다. 스마트 계약이 컴파일러 취약점의 영향을 받는지 여부를 확인하려면 특정 컴파일러 버전과 특정 코드 패턴을 결합해야 합니다.
현재 단 두 개의 컴파일러만이 최고이며 Vyper의 코드 베이스는 더 작고 읽기 쉽고 기록을 분석하기 위한 변경 사항이 적습니다. 이것이 아마도 해커가 여기서 시작하는 이유일 것입니다. Solidity의 코드 베이스는 조금 더 큽니다. fubuloubu는 심지어 다음과 같은 상태를 의심합니다. 지원을 받는 해커가 이번 Curve 공격에 연루되었을 수 있습니다. “취약점을 찾는 데는 몇 주에서 몇 달이 걸릴 것이며, 투자된 리소스를 고려하면 소규모 그룹이나 팀에서 수행할 수 있습니다.”
암호화 업계에서 가장 널리 사용되는 컴파일 언어인 Solidity의 보안에 대한 사용자의 우려는 더욱 큽니다.결국 이번에 Solidity 컴파일러에 재진입 잠금 실패 문제가 발생한다면 DeFi 산업 전체의 역사는 다시 작성됩니다.Solidity 개발팀의 정기 릴리스에 따르면보안 경고
, Solidity 컴파일러의 다양한 버전에서 보안 취약점이 발견되었습니다.
가장 최근에 기록된 컴파일러 버그는 abi.error 사용과 관련된 보안 보고서를 조사할 때인 6월 26일이었습니다. 이전 코드 생성기는 할당, 함수 호출 또는 .selector가 액세스되는 조건과 같은 복잡한 표현식을 평가하지 않았습니다. 이로 인해 해당 표현식이 실행되지 않는 부작용이 발생하므로 이전 파이프라인으로 컴파일된 계약이 잘못 작동할 수 있습니다.우리는 또한 Solidity의 것을 볼 수 있습니다Github 저장소bugs_by_version.jsonSolidity 컴파일러의 일부 알려진 보안 관련 버그를 나열하는 파일이 에 배치됩니다. 목록은 버전 0.3.0으로 돌아가며, 이 버전 이전에만 존재했던 버그는 나열되지 않습니다. 여기 또 있어요
문서. 이 파일은 특정 컴파일러 버전이 영향을 받는 버그를 쿼리하는 데 사용할 수 있습니다.
다행스럽게도 Solidity 언어의 광범위한 적용과 Ethereum Foundation의 지원 덕분에 배포 프로세스 중에 프로젝트와 프로토콜에서 기존의 많은 문제가 지적되었습니다. 따라서 Solidity는 Vyper보다 몇 단계 더 빠르게 수정 및 개선을 완료했으며, 이러한 관점에서 볼 때 Solidity가 더 표준화되고 안전한 이유 중 하나입니다.
Solidity 개발자가 더 나은 테스트를 수행하고 동일한 일이 발생하지 않도록 돕기 위해. UnitasProtocol 공동 창업자 SunSec(@ 1 nf 0 s 3 cpt)은 Curve 공격 이후 DeFiVulnLabs Solidity 보안 테스트 가이드를 발표하여 취약점 설명, 시나리오, 방어, 취약점 코드, 완화 조치 및 테스트 방법을 포함하여 47가지 유형의 취약점을 지원했습니다. .
낮은 수준의 공격을 최대한 피하는 방법은 무엇입니까?
이번 Curve 사건에서 Box는 모든 개발자를 위한 깨달음은 기술 동향을 따르려고 하지 말고 미성숙한 솔루션을 선택하지 말고 테스트 사례를 작성하지 않고 자신의 코드를 승인하지 말라는 것이라고 믿습니다(문제가 있는 여러 버전의 Vyper 심지어 테스트 사례가 잘못됨), 자신의 코드를 직접 승인하지 마십시오. 일부 행운은 발견하는 데 수년이 걸릴 수 있습니다. 업그레이드 불가는 자신에 대한 오만함과 다른 사람에 대한 경멸입니다.
일반적으로 개발자는 여기에 어떤 함정도 생각하지 않고 마음대로 컴파일할 버전을 선택하는데, 이는 버전 간의 차이로 인해 발생하는 위험을 무시할 수 있습니다. 마이너 버전 업그레이드라도 주요 변경 사항이 발생할 수 있으며 이는 분산형 애플리케이션을 개발할 때 특히 중요합니다.
이 곡선 이벤트에서 개발자에게 경고하는 내용은 다음과 같습니다. 최신 버전의 컴파일러 언어를 사용하십시오. 코드베이스, 애플리케이션, 운영 체제를 최신 상태로 유지하고 모든 측면에서 자체 보안 방어 수단을 구축하는 것이 중요합니다. 최신 버전에서는 새로운 보안 문제가 발생할 수 있지만 일반적으로 이전 버전보다 알려진 보안 문제가 적습니다. 물론, 커뮤니티와 공식 버전 업데이트 공지에도 시기 맞춰 주목해야 합니다. 각 버전에 따른 변경 사항을 이해하고 필요에 따라 자체 코드 베이스와 운영 환경을 업데이트하세요. 이러한 단계를 수행하면 컴파일러 버그로 인한 보안 사고를 크게 줄일 수 있습니다.
또한 코드를 완성하기 위한 단위 테스트 케이스도 있습니다. 대부분의 컴파일러 수준 오류는 일관되지 않은 코드 실행 결과로 이어지며, 이는 코드 검토를 통해서만 찾기 어렵지만 테스트에서 노출될 수 있습니다. 코드 적용 범위를 개선하면 이러한 문제를 방지하는 데 도움이 될 수 있습니다. 그리고 명확한 필요가 없는 한 인라인 어셈블리, 다차원 배열 인코딩 및 디코딩과 같은 복잡한 언어 기능을 사용하지 마십시오. 역사적으로 대부분의 Solidity 언어 취약점은 이러한 고급 기능과 관련되어 있었습니다. 개발자는 특별한 필요 없이 자랑하기 위해 실험적인 언어 기능을 사용하는 것을 피해야 합니다.
물론 기본 인프라의 위험에 대해 너무 당황할 필요는 없습니다. 현재 대부분의 컴파일러 버그는 특정 코드 패턴에서만 발생하며 프로젝트 상황에 따라 실제 영향을 평가해야 합니다. 정기적으로 컴파일러 버전을 업그레이드하고 적절한 단위 테스트를 수행하면 위험을 예방하는 데 도움이 될 수 있습니다.
참고 내용:
2.https://github.com/pcaversaccio/reentrancy-attacks/issues/1
3.https://nipunp.medium.com/5-8-21-rari-capital-exploit-timeline-analysis-8beda31cbc1a
4.https://docs.Soliditylang.org/en/v0.8.21/
