최근 Oasis 멀티시그를 사용하여 MakerDao Vault에서 자금을 이동시키는 "카운터 익스플로잇"에 대해 많은 관심이 집중되고 있습니다. 한편, 저희가 2월 18일 Platypus의 240만 달러 구제를 위한 카운터 익스플로잇에 참여했기 때문에 BlockSec이 이 작전의 "화이트햇"인지에 대한 몇 가지 문의를 받았습니다. 저희는 BlockSec이 Jump 사례의 어떠한 행동에도 관여하지 않았음을 명확히 밝힙니다. 자세한 분석(BlockWorks에서 Dan Smith가 발표한 훌륭한 분석에 경의를 표합니다) 후에, 저희는 Jump "카운터 익스플로잇"에 사용된 방식이 Platypus 사례와 근본적으로 다르다고 생각합니다.
또한, Oasis의 성명에 따르면, 카운터 익스플로잇은 관리자 멀티시그 접근의 취약점으로 인해 가능했습니다
그러나 저희의 분석에 따르면, 카운터 익스플로잇의 핵심 단계는 다음과 같습니다:
- 지연 실행 비활성화. 이는 Oasis 멀티시그 지갑인 Service Registry 컨트랙트의 소유자가 수행하도록 설계되어 있습니다.
- AutomationBot 컨트랙트의 AUTOMATION_EXECUTOR 및 CloseCommand 컨트랙트의 MCD_VIEW, MULTIPLY_PROXY_ACTIONS를 포함한 중요한 역할에 대해 등록된 컨트랙트 주소를 변경합니다. 이를 통해 Oasis 멀티시그 지갑은 AutomationBot을 직접 호출하여 클로즈 명령을 실행할 수 있으며, 실제 실행 작업은 익스플로이터의 Vault를 이동시키는 새로운 작업으로 대체됩니다.
저희의 분석에 따르면 이러한 핵심 단계들은 관리자 멀티시그 접근의 취약점으로 인한 것이 아닙니다.
면책 조항: 이 블로그는 온체인 트랜잭션과 공개 정보를 기반으로 작성되었습니다. 질문이나 의견이 있으시면 [email protected]으로 연락해 주세요.
전체 프로세스
이 작업에는 여러 주소가 관여되었습니다. 그 중 일부를 다음 구글 문서에 정리했습니다.
https://docs.google.com/spreadsheets/d/1k0PEci8wQ16X7JT7KRq9SvhaCA2yerJcqLn6EfAoPZs/edit?usp=sharing
구체적으로, Jump 카운터 익스플로잇의 고수준 개념은 다음과 같습니다.
-
익스플로이터가 Oasis에서 제공하는 자동화 매도 및 매수 서비스를 활성화했기 때문에, Oasis AutomationBot 스마트 컨트랙트로 익스플로이터의 Maker Vault를 관리할 수 있습니다.
-
AutomationBot은 AUTOMATION_EXECUTOR 역할을 가진 주소에서만 운영될 수 있습니다. 이 주소는 Oasis 멀티시그 지갑으로 업데이트할 수 있는 Oasis Service Registry 컨트랙트의 구성입니다. 그러나 Oasis Service Registry 컨트랙트의 구성 업데이트에는 지연 실행 메커니즘이 있으며, 이는 Oasis 멀티시그 지갑으로 비활성화할 수 있습니다.
-
AutomationBot이 실행하는 실제 컨트랙트와 함수도 Oasis Service Registry에서 구성 가능합니다.
따라서 Oasis 멀티시그 지갑은 먼저 Oasis Service Registry 컨트랙트의 지연 실행을 비활성화하고, Oasis Service Registry 컨트랙트의 구성을 변경하여 AUTOMATION_EXECUTOR 역할을 자신(멀티시그 지갑)으로 설정합니다. 변경은 즉시 적용됩니다. 그런 다음 멀티시그 지갑은 AutomationBot을 호출하여 익스플로이터의 Maker Vault를 인수할 수 있는 명령(shift 및 give)을 실행합니다. AutomationBot이 익스플로이터의 Vault를 관리할 수 있으므로 전체 작업이 성공할 수 있습니다.
저희는 이 과정이 공격자의 컨트랙트에서 취약점을 발견하고 Platypus와 공유한 Platypus 사례와 근본적으로 다르다고 생각합니다. 그런 다음 Platypus는 공격자의 컨트랙트를 익스플로잇하여 자신들의 자금을 이동시켰습니다. 그러나 Jump 사례에서는 Oasis 멀티시그가 지연 실행 메커니즘을 비활성화하고, 컨트랙트의 동작을 완전히 변경할 수 있는 중요한 구성을 업데이트하며, AutomationBot의 관리 역할을 활용하여 익스플로이터를 대신하여 Maker의 Vault를 조작합니다.
다음에서는 Jump "카운터 익스플로잇"의 전체 과정을 자세히 설명하겠습니다.
세부 단계
이 작업에는 Jump, Oasis, Wormhole 익스플로이터, Maker 등 여러 프로토콜과 당사자들이 관련되어 있습니다. Maker는 작업 중에 어떠한 조치도 취하지 않는다는 점에 유의하세요.
구체적으로, 익스플로이터는 Maker Vault(30100 및 30179)를 생성하고 ETH를 담보로 사용하며 Vault에서 DAI를 빌립니다. 익스플로이터는 또한 Oasis에서 제공하는 자동화 매도 및 매수 서비스를 활용하여 Maker Vault의 담보화 비율을 관리했습니다.
Oasis 자동화 서비스를 사용하려면 Oasis에서 제공하는 AutomationBot이라는 스마트 컨트랙트를 Vault의 관리 목록에 추가해야 합니다. 이는 AutomationBot이 익스플로이터가 생성한 Maker Vault를 제어할 수 있음을 의미합니다. 그 후, AutomationBot은 Vault를 조작하고 Vault의 담보 및 부채를 Jump가 제어하는 다른 Vault로 이전할 수 있습니다. 이것이 "카운터 익스플로잇"의 기본 프로세스입니다. AutomationBot을 호출하려면 ServiceRegistry 컨트랙트에 AUTOMATION_EXECUTOR로 등록된 주소에서 트랜잭션을 호출해야 합니다.
1단계: Oasis 멀티시그 지갑에 주소 04e1 추가
이 트랜잭션은 Oasis 멀티시그 지갑에 주소 04e1을 추가합니다. 이 지갑은 현재 12개의 주소를 가지고 있으며, 4명의 서명자 확인이 필요합니다.
2단계: Oasis Service Registry의 지연 실행 비활성화
이 트랜잭션은 changeRequiredDela(0)을 호출하여 Oasis Service Registry의 지연 실행을 비활성화합니다. Oasis Service Registry는 AutomationBot에서 사용될 중요한 구성 정보를 저장하는 스마트 컨트랙트입니다. 일반적으로 구성 변경에는 중요한 작업(예: "카운터 익스플로잇"에서 사용될 updateNamedService)에 대한 지연 실행 메커니즘이 있습니다. 일반적으로 지연 실행은 투명성을 위한 보안 메커니즘으로, 중요한 정보 업데이트가 즉시 적용되지 않으므로 다른 사람들이 다시 한번 검토할 수 있습니다.
changeRequiredDelay를 호출하는 실행은 지연 실행에 의해 제한된다는 점에 유의하세요(reqDelay 변경이 아직 적용되지 않았으므로).
3단계: 카운터 익스플로잇 수행
이 트랜잭션은 카운터 익스플로잇을 수행합니다. BlockSec이 개발한 트랜잭션 분석 도구인 Phalcon이 출력한 실행 추적을 살펴보겠습니다.
이 트랜잭션은 04e1 주소에서 초기화되어 Oasis 멀티시그 지갑을 통해 실행되며, 이는 작업이 최소 4명의 서명자에 의해 서명되었음을 의미합니다.
3.1단계: 지연 실행 비활성화
추적에서 볼 수 있듯이, 지연은 다시 0으로 설정됩니다. 이는 2단계에서 지연 실행을 비활성화하는 동작을 적용하기 위한 것입니다.
3.2단계: 두 개의 컨트랙트 생성 및 서비스 레지스트리 업데이트
MCD_VIEW 및 MULTIPLY_PROXY_ACTIONS 컨트랙트로 사용될 두 개의 새 컨트랙트가 생성됩니다.
- MCD_VIEW: 0xceca8d8410797bc6c575fd8ba957708d1e85ed36
- MULTIPLY_PROXY_ACTIONS: 0xcaef24016d0fba2c1a9427371e0d79c5781b6ea8
그런 다음 이 두 컨트랙트는 Oasis 서비스 레지스트리 컨트랙트에 업데이트됩니다.
3.3단계: 자동화 실행자 변경
Oasis 멀티시그는 ServiceRegistry 컨트랙트에서 AUTOMATION_EXECUTOR로 등록됩니다. 이 역할로 등록된 컨트랙트만 AutomationBot 컨트랙트를 호출할 수 있으므로 이 과정이 필요합니다.
3.4단계: AutomationBot에 익스플로이터의 Vault 종료 요청
핵심 프로세스는 AutomationBot의 execute 함수에서 시작됩니다. 상세한 실행 함수는 인수를 통해 전달됩니다.
전체 프로세스를 이해하기 위해 먼저 이 함수를 살펴보겠습니다.
고수준 로직은 봇이 먼저 Vault에서 DAI를 인출(268번 줄)하고, 그 다음 Vault(cdpId로 지정)에서 실행할 구체적인 명령 컨트랙트를 호출(274번 줄에서 278번 줄)하는 것입니다. 이 과정에서 명령 주소는 CloseCommand 컨트랙트입니다. 그 후 isExecutionCorrect 확인이 필요합니다.
다음은 CloseCommand 컨트랙트의 execute 함수를 보여줍니다. KEY MULTIPLY_PROXY_ACTIONS를 사용하여 서비스 레지스트리 컨트랙트에서 실제 실행자 컨트랙트 주소를 가져옵니다. MULTIPLY_PROXY_ACTIONS에 해당하는 컨트랙트 주소가 새 주소로 업데이트되었으므로, CloseCommand의 실제 실행은 새 컨트랙트에서 임의의 작업을 수행하도록 제어 가능합니다.
isExecutionCorrect가 CloseCommand에서 호출되어 실행 성공 여부를 확인한다는 점을 기억하세요(AutomationBot.sol의 278번 줄). 뷰 주소가 업데이트되었으므로 viewerContract.getVaultInfo(cdpId) 확인의 반환값은 CloseCommand.sol의 24번 줄에서 확인을 통과할 수 있는 임의의 값이 될 수 있습니다.
코드를 살펴본 후 실행 추적을 살펴보겠습니다. 추적에서 automationBot이 CloseCommand 컨트랙트를 호출하는 것을 볼 수 있습니다. CloseCommand 컨트랙트는 대체된 MULTIPLY_PROXY_ACTIONS 컨트랙트를 호출하여 새 Vault(30231)를 열고, Vault 30100(익스플로이터의 것)을 30231(새로 생성된 것)로 이동시키고, 새 Vault 30231을 Oasis 멀티시그 지갑에 줄 수 있습니다. 유사한 작업이 익스플로이터의 다른 Vault(30179)에도 수행됩니다.
3.5단계: 상태 복원
Service Registry에서 변경된 항목을 복원하고 지연 실행을 다시 활성화합니다.
3.6단계: 주소 1536에 Vault 양도
이제 새 Vault(30231 및 30232)는 Oasis 멀티시그 지갑이 제어합니다. 그런 다음 이 트랜잭션들[TX1 TX2]에서 Vault들이 0x15364305a06ba3ac6ba13dfe97ca0bad639adf41에 양도됩니다. 그러면 이 주소는 Vault의 부채를 갚고 담보(이더리움)를 인출할 수 있습니다. 담보화 비율이 높으므로(Vault 30100의 경우 약 293%), Vault 30100에서 약 7,600만 달러의 부채를 갚는 비용으로 약 12만 개의 이더리움을 돌려받을 수 있습니다. 이러한 작업에 대한 자세한 내용은 Maker 프로토콜 문서를 참조하세요.
BlockSec 소개
BlockSec은 전 세계적으로 저명한 보안 전문가 그룹이 2021년에 설립한 선도적인 블록체인 보안 회사입니다. 이 회사는 대중적 채택을 촉진하기 위해 새롭게 떠오르는 Web3 세계의 보안성과 사용성을 향상시키는 데 전념하고 있습니다. 이를 위해 BlockSec은 스마트 컨트랙트 및 EVM 체인 보안 감사 서비스, 보안 개발 및 위협 선제 차단을 위한 Phalcon 플랫폼, 자금 추적 및 조사를 위한 MetaSleuth 플랫폼, 그리고 크립토 세계에서 효율적으로 탐색하는 Web3 빌더를 위한 MetaSuites 확장 프로그램을 제공합니다.
현재까지 MetaMask, Uniswap Foundation, Compound, Forta, PancakeSwap 등 300개 이상의 저명한 클라이언트를 서비스했으며, Matrix Partners, Vitalbridge Capital, Fenbushi Capital 등 유명 투자자들로부터 두 차례의 자금 조달 라운드에서 수천만 달러를 유치했습니다.
공식 웹사이트: https://blocksec.com/
공식 트위터 계정: https://twitter.com/BlockSecTeam
