중요한 이더리움 보안 가정은 스마트 계약 코드가 변경 불가능하므로 일단 블록체인에 배포되면 변경할 수 없다는 것입니다. 실제로 일부 스마트 계약은 변경 – 배포된 후에도. 몇 가지 영리한 트릭을 사용하여 "변형”를 다른 것으로 변환하고 무엇이 이를 가능하게 하는지 이해함으로써 이를 감지할 수 있습니다.
변형 스마트 계약은 변경 가능하므로 개발자가 내부 코드를 변경할 수 있습니다. 이러한 스마트 계약은 특히 악의적인 행위자가 이 형태 변경 능력을 악용할 수 있기 때문에 절대 일관성으로 실행될 것으로 기대하는 코드를 신뢰하는 web3 사용자에게 심각한 위험을 초래합니다. 공격자가 이 기술을 사용하여 스마트 계약에 토큰을 스테이킹하는 사람들이 변성이라는 사실을 깨닫지 못하는 사람들을 "덮개"한다고 상상해 보십시오. 이와 유사한 전제를 기반으로 한 공격은 사기꾼이 사람을 잡아먹도록 하고 일반적으로 분산 시스템의 완전한 약속에 대한 신뢰를 약화시킬 수 있습니다.
스마트 계약에 변성 속성이 포함되어 있는지 분석하려면, 간단하게 만들었어요 변성 계약 감지기 (원작에서 영감을 받아 구축함 제이슨 카버, 0 세및 다른 사람). 누구든지 이 도구를 사용하여 주어진 계약에 변형 가능성을 나타낼 수 있는 위험 신호가 표시되는지 확인할 수 있습니다. 이 방법은 완벽하지 않습니다. 스마트 계약이 플래그를 표시한다고 해서 반드시 변성적임을 의미하지는 않습니다. 안전하지 않다고 해서 안전한 것은 아닙니다. 검사원은 계약에 대한 빠른 초기 평가를 제공할 뿐입니다. 수도 가능한 지표에 따라 변태적이어야 합니다.
Web3 사용자는 변형 계약이 제기하는 위협에 대해 잘 알고 있어야 가능한 공격을 찾고 피할 수 있습니다. 지갑과 블록체인 인덱서는 사용자가 변성 속성을 포함할 수 있는 스마트 계약과 상호 작용하기 전에 경고함으로써 도움을 줄 수 있습니다. 이 도구는 사람들에게 이 잠재적 위협에 대해 교육하고 이를 방어하는 데 도움을 주기 위한 것입니다.
변성 스마트 계약 감지
XNUMXD덴탈의 변성 계약 감지기 스마트 계약이 변성인지 여부를 나타낼 수 있는 XNUMX가지 속성을 분석했습니다.
-
- 계약을 배포하는 데 알려진 변형 코드가 사용되었습니까? 알려진 변형 바이트 코드(일반적으로 Solidity로 작성된 Ethereum 스마트 계약이 컴파일된 후 변환되는 하위 수준의 가상 머신 판독 가능 코드)가 주어진 스마트 계약 배포에 대한 트랜잭션에 표시되는 경우 이는 주요 위험 신호입니다. 다음 섹션에서는 0age가 개발한 변형 바이트코드의 한 가지 예를 논의할 것입니다. 중요한 경고: 변성 바이트 코드에는 잠재적으로 수많은 변형이 있으므로 모든 종류를 감지하기 어렵습니다. 하지만 잘 알려진 인스턴스를 스캔함으로써 탐지기는 단순히 기존 예제를 복사하여 붙여넣는 공격자에 대한 낮은 행잉 과일을 제거합니다.
- 스마트 계약 코드가 스스로 파괴될 수 있습니까? 컨트랙트의 코드를 교체하려면(변형 컨트랙트 생성의 핵심 단계) 개발자는 먼저 기존 코드를 삭제해야 합니다. 이 작업을 수행하는 유일한 방법은 SELFDESTRUCT 연산 코드, 정확히 들리는 대로 수행하는 명령 - 주어진 계약 주소에서 모든 코드와 저장소를 지웁니다. 계약에 자체 파괴 코드가 있다고 해서 그것이 변성임을 증명하는 것은 아닙니다. 그러나 그것은 계약에 대한 단서를 제공합니다. 수도 변태적이어야 하고 어쨌든 당신이 의존하고 있는 계약이 스스로를 핵무장할 수 있는지 여부를 아는 것은 가치가 있습니다.
- 스마트 계약은 다른 곳에서 코드를 호출합니까? 문제의 스마트 계약이 직접 자체 파괴할 수 없는 경우에도 다음을 사용하여 스스로를 지울 수 있습니다. DELEGATECALL 연산 코드. 이 opcode를 사용하면 스마트 계약이 다른 스마트 계약 내부에 있는 코드를 동적으로 로드하고 실행할 수 있습니다. 스마트 계약에 SELFDESTRUCT opcode가 포함되어 있지 않더라도 DELEGATECALL을 사용하여 다른 곳에서 자체 파괴 코드를 로드할 수 있습니다. DELEGATECALL 기능이 스마트 계약이 변성인지 여부를 직접적으로 나타내지는 않지만, 이는 주목할 가치가 있는 가능한 단서이자 잠재적인 보안 문제입니다. 이 지표는 많은 오탐을 일으킬 가능성이 있음을 주의하십시오.
- 다른 계약에서 이 계약을 배포했습니까? 변형 계약을 배포할 수 있습니다. 만 다른 스마트 계약에 의해 이는 변형 계약이 CREATE2라는 다른 스마트 계약에서만 사용할 수 있는 다른 opcode에 의해 활성화되기 때문입니다. (우리는 CREATE2의 작동 방식과 중요한 이유에 대해 이후 섹션에서 더 자세히 논의할 것입니다.) 이 특성은 가능한 변형의 가장 눈에 띄지 않는 지표 중 하나입니다. 그것은 필요하지만 불충분한 전제조건이다. 이 특성을 검색하면 많은 오탐지가 발생할 수 있습니다. 그러나 특히 스마트 계약에 다음에 설명된 opcode가 포함된 경우 의심을 불러일으키고 계약을 더 자세히 조사해야 하는 이유를 제공할 수 있으므로 아는 것이 가치 있는 정보입니다.
- 배포자 계약에 CREATE2 opcode가 포함되어 있습니까? 위에서 언급했듯이 CREATE2를 통한 배포는 변형의 필수 전제 조건입니다. 배포자 계약에 CREATE2 opcode가 포함되어 있으면 CREATE2를 사용하여 해당 계약을 배포했음을 나타낼 수 있습니다. 배포자가 실제로 CREATE2를 사용하여 해당 계약을 배포한 경우 계약이 반드시 변성적이어야 한다는 의미는 아니지만 수도 변형될 수 있으므로 주의하여 진행하고 추가로 조사하는 것이 현명할 수 있습니다. 다시 말하지만 가양성(false positive)에 주의하십시오. 만들기2 많이있다 합법적인 사용, 강화를 포함하여 "레이어 2" 스케일링 솔루션 web3를 개선할 수 있는 스마트 계약 지갑을 더 쉽게 만들 수 있습니다. 사용자 온보딩 및 주요 복구 옵션.
- 코드가 바뀌었나요? 이것은 가장 분명한 텔이지만 메타모픽 계약이 이미 모핑된 후에만 나타납니다. 스마트 계약의 코드 해시(고유한 암호화 식별자)가 계약이 처음 배포되었을 때와 다른 경우 코드가 제거, 교체 또는 변경되었을 수 있습니다. 해시가 더 이상 일치하지 않으면 코드에 대한 내용이 변경되었으며 계약이 변형될 수 있습니다. 이 플래그는 변성 작용의 가장 확실한 표시기이지만 이미 발생했는지만 확인하기 때문에 변성을 예측하거나 선점하는 데 도움이 되지 않습니다.
Metamorphic Contract Detector를 위한 간단한 명령줄 도구를 구축하는 것 외에도 저는 다음 섹션에서 설명하는 사기 변형 계약 스테이킹 시나리오를 보여주는 몇 가지 예시 스마트 계약을 구축했습니다. 모든 코드는 여기에서 사용할 수 있습니다. GitHub 저장소.
악의적인 행위자가 변성 계약을 사용하여 사람들의 자금을 훔치는 방법
누군가가 사기의 일부로 변성 스마트 계약을 사용하는 방법은 다음과 같습니다.
먼저 설정 단계입니다. 공격자는 변성 바이트코드와 CREATE2 opcode라는 두 가지 도구를 사용하여 블록체인의 특정 주소에 스마트 계약을 배포합니다. (나중에 이 두 개념을 모두 확장할 것입니다.) 그런 다음 변성 바이트코드는 이름이 암시하는 대로 "모핑"합니다. 여기에서 로 바뀝니다. 스테이 킹 계약 사용자가 ERC-20 토큰을 스테이킹할 수 있는 곳입니다. (다시 말하지만, 이 모핑 트릭에 대한 자세한 내용은 나중에 논의하겠습니다. 약속합니다!)
다음은 미끼와 스위치입니다. 순진한 사용자는 이 계약에서 토큰을 스테이킹하여 수익 또는 기타 특혜를 얻을 가능성에 현혹됩니다. 그런 다음 공격자는 다음을 사용하여 이 스마트 계약 주소에서 모든 스테이킹 코드와 "상태"(블록체인 스토리지 또는 메모리)를 삭제합니다. SELFDESTRUCT 연산 코드 이전 섹션에서 논의. (별도의 ERC-20 계약의 일부로 존재하는 토큰은 자체 파괴된 계약의 영향을 받지 않고 지속됩니다.)
마지막으로 양탄자 당기기. 공격자는 새 계약을 "재배포"하기 위해 설정 단계에서 사용된 것과 동일한 변형 바이트코드를 재사용합니다. 이 새 계약은 최근에 자동 소멸 계약으로 비워진 동일한 주소에 배포됩니다. 그러나 이번에는 바이트코드가 계약 주소에 스테이킹된 모든 토큰을 훔칠 수 있는 악의적인 계약으로 "모핑"(다시 설명하겠습니다)합니다. 사기 완료.
변성적 스마트 계약이 제기하는 위험은 이제 명백하게 드러났습니다. 그러나 이 변형 트릭이 실제로 어떻게 작동하는지 여전히 궁금할 것입니다. 이를 이해하려면 바이트 코드 수준까지 더 깊이 조사해야 합니다.
CREATE2가 변형 가능성을 여는 방법
만들기2 opcode 업그레이드이며, 이더리움에 도입 2019년 XNUMX월에 스마트 계약을 배포하는 새로운 방법을 제공합니다.
CREATE2는 개발자에게 이전보다 스마트 계약 배포에 대한 더 많은 제어 권한을 제공합니다. 원래 CREATE opcode는 개발자가 배포할 스마트 계약의 대상 주소를 제어하기 어렵게 만듭니다. CREATE2를 사용하면 블록체인에 실제로 배포하기 전에 특정 스마트 계약의 주소를 미리 제어하고 알 수 있습니다. 이 예지와 몇 가지 영리한 트릭을 통해 사람들은 변성적인 스마트 계약을 만들 수 있습니다.
CREATE2는 어떻게 미래를 예측할 수 있습니까? opcode의 계산은 결정적입니다. 입력이 변경되지 않는 한 CREATE2에 의해 결정된 주소는 변경되지 않습니다. (아주 작은 변경이라도 배포가 다른 곳에서 발생하도록 합니다.)
더 세분화하면 CREATE2는 몇 가지 요소를 결합하고 함께 해시하는 함수입니다. 첫째, 배포자(또는 발신자)의 주소를 통합합니다. 생성할 스마트 계약의 부모 역할을 하는 스마트 계약을 시작합니다. 다음으로 발신자가 제공한 임의의 번호(또는 "솔트")를 추가하여 개발자가 동일한 코드를 다른 주소에 배포할 수 있도록 하고(솔트 변경을 통해) 기존의 동일한 계약을 덮어쓰는 것을 방지합니다. 마지막으로 일부 스마트 계약 초기화("초기화") 바이트코드의 keccak256 해시를 사용하며, 이는 새로운 스마트 계약으로 전환되는 시드입니다. 이 함께 해시된 조합은 이더리움 주소를 결정한 다음 해당 주소에 지정된 바이트 코드를 배포합니다. 하는 한 바이트 코드는 정확히 동일하게 유지되며 CREATE2는 항상 주어진 바이트 코드를 블록체인의 동일한 주소에 배포합니다.
CREATE2 수식은 다음과 같습니다. (참고: 아래 예에서 "0xFF"라는 또 다른 요소를 볼 수 있습니다. 이것은 CREATE2가 사용하는 상수일 뿐입니다. 충돌 방지 앞의 CREATE opcode와 함께).
이제 결정적 주소에 코드를 배포할 수 있는 방법이 생겼습니다. 이전 단계로 돌아가기 같은 주소에 있는 코드? 처음에는 이것이 불가능해 보일 수 있습니다. CREATE2를 사용하여 새 코드를 배포하려면 바이트 코드를 변경해야 하므로 CREATE2가 다른 주소에 배포됩니다. 그러나 개발자가 CREATE2가 스마트 계약을 배포할 때 다른 코드로 "모핑"할 수 있는 방식으로 바이트코드를 구성했다면 어떻게 될까요?
변성 계약이 실제로 작동하는 방식
스마트 계약을 변형 계약으로 전환하는 방법에는 각각 고유한 역할을 하는 총 XNUMX개의 스마트 계약이 필요합니다.
이러한 필수 구성 요소 중 하나는 작업의 두뇌인 변형 계약 공장입니다. 이 "팩토리"는 구현 계약이라고 하는 또 다른 스마트 계약뿐만 아니라 변형 계약을 배포하는 책임이 있습니다. 코드가 결국 변형 계약 내에서 구현되기 때문에 그렇게 명명되었습니다. 이 세 가지 계약 간의 미묘한 안무가 아래 다이어그램에 표시된 것처럼 변형을 초래합니다.
각 단계(1-7)에 대해 자세히 논의하여 직장에서의 작업을 조명해 보겠습니다.
1단계: 개발자가 모든 것을 움직이게 합니다.
코더는 일부 스마트 계약 코드(구현 계약 바이트코드)를 설계하여 결국 변형 계약으로 이어집니다. 개발자는 이 코드를 다른 스마트 계약을 배포하는 것이 주요 목적인 스마트 계약인 Metamorphic Contract Factory로 보냅니다. 이 작업은 전체 변형 계약 생성 프로세스를 시작합니다.
다음에 나오는 모든 것은 이 초기 단계의 결과입니다. 물론, 1~6단계는 블록체인의 하나의 원자적 트랜잭션에서 발생합니다. 이는 거의 모든 것을 동시에 의미합니다. 이러한 단계를 무한히 반복하여 변형 계약 내부의 코드를 교체하고 지속적으로 모핑할 수 있습니다.
2단계: 공장에서 구현 계약 배포
공장이 배포하는 첫 번째 계약은 구현 코드가 포함된 구현 계약입니다. (Creative, 우리는 알고 있습니다.) 구현 계약을 최종 목적지(이 경우 변형 계약 내부)로 배송하기 전에 일부 코드를 보유하는 로딩 도크 또는 웨이포인트로 생각하십시오.
3단계: 공장에서 구현 계약 주소 저장
블록체인에 배포한 후 구현 계약은 반드시 일부 블록체인 주소에 존재합니다. Factory는 이 계약 주소를 자체 메모리에 저장합니다(나중에 5단계에서 사용).
4단계: 공장에서 변형 계약 배포
Factory는 CREATE2 및 변형 바이트 코드를 사용하여 변형 계약을 배포합니다. 변성 바이트 코드가 작동하는 방식에 대한 기술적이고 심층적인 설명을 찾을 수 있습니다. 여기에서 지금 확인해 보세요.그러나 변형 바이트코드가 실행될 때 다른 온체인 위치(이 경우 구현 계약에서)에서 변형 계약으로 코드를 복사하는 것으로 충분합니다. 지난 섹션에서 이야기했듯이 CREATE2는 결정적이므로 동일한 발신자, 솔트 및 바이트 코드가 사용되는 한 이러한 단계를 몇 번이나 반복하더라도 변형 계약 주소는 동일하게 유지됩니다.
다음은 변성 바이트 코드가 어떻게 보이는지에 대한 예입니다. 변성 레포 0세까지. 이것은 변성 바이트 코드의 한 예일 뿐입니다. 잠재적으로 무수한 변형이 존재하여 변성 계약의 감지를 크게 복잡하게 만듭니다.
5단계: 변형 바이트코드는 구현 계약 주소를 위해 Factory에 쿼리합니다.
변형 바이트코드는 팩토리에 구현 계약 주소(3단계에 저장된 대로)를 요청합니다. 주소를 요청하는 변형 바이트코드가 동일하게 유지되는 한 구현 계약의 주소가 변경되는지 여부는 중요하지 않습니다. 실제로 개발자가 나중에 토큰을 훔치도록 설계된 악의적인 것과 같은 새로운 구현 계약을 배포하는 경우 2단계에 따라 반드시 다른 블록체인 주소에 배포해야 합니다. 이는 변형 계약의 생성에 영향을 미치지 않습니다.
6 단계 : 구현 계약 코드가 변형 계약에 복사됩니다.
5단계에서 학습한 블록체인 주소를 사용하여 변형 바이트코드는 구현 계약에서 코드를 찾고 해당 코드를 변형 계약의 로컬 저장소에 복사합니다. 구현 계약에서 코드를 복사하여 변형 계약의 형태가 이동하는 방식은 다음과 같습니다.
7단계: 헹구고 반복
개발자는 1~6단계를 계속해서 반복하고 새로운 구현 계약을 통해 변형 계약의 코드를 원하는 대로 바꿀 수 있습니다. 필요한 모든 것은 SELFDESTRUCT opcode를 사용하는 것입니다. 또는 궁극적으로 SELFDESTRUCT를 생성하는 DELEGATECALL opcode를 사용하여 변형 계약에서 기존 코드를 제거하는 것입니다. 새로운 구현 계약 바이트코드로 주기를 반복함으로써 변형 계약은 마술처럼, 모프!
변형 계약을 생성하기 위해 이 기술을 사용하여 영리한 개발자는 web3 사용자의 발 아래에서 지속적으로 기반을 이동할 수 있습니다. 예를 들어 사기 시나리오를 다시 생각해 보십시오. 개발자는 먼저 그래픽에 묘사되고 위의 단계에서 자세히 설명된 순환 경로를 통해 변형 계약으로 끝나는 토큰 스테이킹 코드로 구현 계약을 배포할 수 있습니다. 사기꾼은 나중에 이 코드를 자체 파괴하고 토큰을 포함하는 새 구현 계약을 배포하여 대체할 수 있습니다.훔침 암호.
구현 계약에 배포되는 모든 것은 궁극적으로 변형 계약으로 귀결됩니다. 그것이 트릭의 본질입니다.
***
변성적 스마트 계약은 보이는 것이 곧 얻는 것이라는 암묵적인 web3 사회 계약을 깨뜨립니다. 쉘 게임이 공을 숨기기 위해 3개의 움직이는 컵을 사용하는 방식과 유사하게, 변형 계약을 생성할 때 XNUMX개의 계약이 상호 작용하면 계약의 진정한 기능을 따르기가 어렵습니다. 셸 게임은 특히 적절한 비교입니다. 자신감 사기꾼은 종종 기만과 잘못된 방향을 사용하여 승리를 보장하기 때문입니다. webXNUMX 버전에서 변형 계약 작성자는 유사하게 구현 코드인 "ball"을 사라지게(읽기: 자체 파괴)할 수 있으며 원하는 대로 대체할 수 있습니다.
변형 계약의 존재는 web3 사용자가 마음대로 변경할 수 있는 계약을 체결할 수 있음을 의미합니다. 그렇기 때문에 이 위협을 이해하고 방어하는 것이 매우 중요합니다. 내 변성 계약 감지기 그들은 그들이 사용하는 교묘한 기술로 변성 계약을 식별하는 첫 번째 단계를 제공합니다. 검출기는 미래에 개선될 수 있는 몇 가지 방법이 있습니다. 예를 들어, 변형 계약을 생성한 팩토리(또는 배포자 계약)를 재귀적으로 확인하여 팩토리 자체가 변형인지 확인할 수 있습니다. 이 기능은 Detector의 업그레이드된 버전 2에 유용한 추가 기능입니다.
다시 한 번 반복할 가치가 있습니다. 이 탐지기 도구는 완벽하지 않습니다. 그것이 잡는 깃발은 모두 변성 잠재력의 명백한 징후는 아니지만 단서를 제공합니다. 이러한 플래그를 식별하는 것은 보다 철저한 조사를 위한 시작일 뿐입니다. 그렇기 때문에 CREATE2 또는 DELEGATECALL opcode의 존재와 같이 가양성을 쉽게 생성할 수 있는 플래그를 검색하도록 Detector를 확장했습니다. 도구 개선에 대한 제안이 있거나 이 초기 작업을 기반으로 하거나 추가하려는 경우 다음에서 저에게 연락하십시오. .
변성 특성에 대한 스마트 계약 분석 감지기 도구를 사용하여 방문 GitHub 레포 자세한
편집자: Robert Hackett @rhhackett
***
감사의 말: 이 게시물과 도구에 생명을 불어넣는 데 귀중한 피드백과 조언을 주신 Robert Hackett, Eddy Lazzarin, Sam Ragsdale, Riyaz Faizullabhoy, Noah Citron, Mason Hall 및 Daejun Park에게 큰 박수를 보내고 싶습니다.
***
여기에 표현된 견해는 인용된 개별 AH Capital Management, LLC("a16z") 직원의 견해이며 16z 또는 그 계열사의 견해가 아닙니다. 여기에 포함된 특정 정보는 16z가 관리하는 펀드의 포트폴리오 회사를 포함하여 제16자 출처에서 얻은 것입니다. 신뢰할 수 있다고 여겨지는 출처에서 가져왔지만 16z는 그러한 정보를 독립적으로 검증하지 않았으며 정보의 지속적인 정확성이나 주어진 상황에 대한 적절성에 대해 어떠한 진술도 하지 않습니다. 또한 이 콘텐츠에는 타사 광고가 포함될 수 있습니다. XNUMXz는 그러한 광고를 검토하지 않았으며 여기에 포함된 광고 콘텐츠를 보증하지 않습니다.
이 콘텐츠는 정보 제공의 목적으로만 제공되며 법률, 비즈니스, 투자 또는 세금 관련 조언에 의존해서는 안 됩니다. 그러한 문제에 관해서는 자신의 고문과 상의해야 합니다. 증권 또는 디지털 자산에 대한 언급은 설명을 위한 것일 뿐이며 투자 추천이나 투자 자문 서비스 제공을 의미하지 않습니다. 또한, 이 콘텐츠는 투자자 또는 예비 투자자를 대상으로 하거나 사용하도록 의도되지 않았으며, 어떤 상황에서도 a16z가 관리하는 펀드에 투자하기로 결정할 때 의존할 수 없습니다. (16z 펀드에 대한 투자 제안은 사모 투자 각서, 청약 계약서 및 해당 펀드의 기타 관련 문서에 의해서만 이루어지며 전체 내용을 읽어야 합니다.) 언급되거나 언급된 모든 투자 또는 포트폴리오 회사 설명된 내용은 16z가 관리하는 차량에 대한 모든 투자를 대표하는 것은 아니며 투자가 수익성이 있거나 미래에 수행되는 다른 투자가 유사한 특성 또는 결과를 가질 것이라는 보장이 없습니다. Andreessen Horowitz가 관리하는 펀드의 투자 목록(발행자가 16z가 공개적으로 공개하도록 허가하지 않은 투자 및 공개적으로 거래되는 디지털 자산에 대한 미고지 투자 제외)은 https://a16z.com/investments에서 볼 수 있습니다. /.
내부에 제공된 차트와 그래프는 정보 제공의 목적으로만 사용되며 투자 결정을 내릴 때 의존해서는 안 됩니다. 과거의 성과는 미래의 결과를 나타내지 않습니다. 내용은 표시된 날짜 현재만 말합니다. 이 자료에 표현된 모든 예측, 추정, 예측, 목표, 전망 및/또는 의견은 예고 없이 변경될 수 있으며 다른 사람이 표현한 의견과 다르거나 반대될 수 있습니다. 추가 중요 정보는 https://a16z.com/disclosures를 참조하십시오.
