BitDAO의 3.5억 달러가 거의 도난당할 뻔했다, 화이트 해커가 전하는 긴박한 구출 작전 전말

2021-08-18 11:13:43

수집

한 편의 가슴 뛰는 화이트 해커 구출 작전.

8월 17일, 블록체인 투자 기관 Paradigm의 연구 파트너이자 유명 화이트 해커인 samczsun이 SushiSwap IDO 플랫폼 MISO에서 진행된 BitDAO의 네덜란드 경매 스마트 계약에 보안 취약점이 존재한다고 밝혔습니다. 여러 화이트 해커들이 힘을 합쳐 크라우드 펀딩 자금 풀에서 10.9만 ETH(약 3.5억 달러)를 구출한 과정입니다.

원문 제목: 《정정득부》( Two Rights Might Make A Wrong )

저자: samczsun

번역: Kyle, 바비트

본 문서 목차:

만남
발견
공개
준비
구출
반성

소프트웨어를 구축할 때 자주 발생하는 일반적인 오해는 시스템의 모든 구성 요소가 개별적으로 안전하다고 검증되면 시스템 자체도 안전하다는 것입니다. 이러한 관념은 DeFi 프로젝트에서 더욱 두드러지게 나타납니다. DeFi 프로젝트 개발에서 조합 가능성은 개발자의 제2의 본능입니다.

불행히도, 두 개의 안전한 구성 요소를 결합하는 것이 대부분의 경우 안전할 수 있지만, 이는 단 하나의 취약점만으로 수백 또는 수천 명의 무고한 사용자에게 심각한 경제적 손실을 초래할 수 있음을 의미합니다.

오늘, 저는 109,000 ETH(오늘 환율로 약 3.5억 달러)가 도난 위험에 처한 심각한 취약점을 발견하고 이를 수정하는 데 도움을 준 방법을 말씀드리고자 합니다.

1. 만남

오전 9:42

제가 Telegram의 LobsterDAO 그룹 채팅을 무심코 스크롤하고 있을 때, Twitter에서 @ivangbi_와 @bantg 간의 SushiSwap의 MISO 플랫폼에서 진행되는 새로운 토큰 판매 프로젝트에 대한 논의를 주목했습니다. 저는 일반적으로 공공장소에서 극적인 행동을 피하려고 하지만, 도대체 무슨 일인지 궁금해져서 구글에서 빠르게 검색해 보았습니다.

제가 얻은 결과는 그리 흥미롭지 않았지만, 계속해서 검색을 이어갔습니다. 뭔가 흥미로운 것을 발견할 수 있을 것 같았기 때문입니다.

MISO 플랫폼은 두 가지 유형의 토큰 경매 모델을 지원합니다: 네덜란드식 경매와 배치 경매. 오늘 언급하는 이 토큰 판매는 네덜란드식 경매를 통해 진행됩니다. 물론, 제가 가장 먼저 한 일은 Etherscan에서 해당 프로젝트의 계약 주소를 여는 것이었습니다.

오전 9:44

저는 해당 프로젝트의 참여 계약을 통해 이 네덜란드식 경매의 계약을 빠르게 훑어보며 흥미로운 함수들을 확인했습니다. 계약의 제출 함수(commitEth, commitTokens 및 commitTokensFrom)는 모두 올바르게 구현된 것처럼 보였습니다. 경매 관리 함수(setDocument, setList 등)도 적절한 접근 제어를 갖추고 있었습니다.

그러나 하단 근처에서 initMarket 함수에 접근 제어가 없다는 점이 매우 우려스러웠습니다. 게다가 호출되는 initAuction 함수에도 접근 제어 검사가 포함되어 있지 않았습니다.

하지만 저는 이렇게 명백한 취약점을 발견할 것이라고는 생각하지 못했습니다. Sushi 팀이 이렇게 명백한 실수를 저지를 것이라고는 상상도 하지 못했습니다. 결국, initAccessControls 함수는 계약이 아직 초기화되지 않았음을 검증했습니다.

그런데 그때 또 다른 발견이 있었습니다. 모든 파일을 스크롤하면서 SafeTransfer와 BoringBatchable 라이브러리를 주목하게 되었습니다. 저는 이 두 가지 모두에 익숙하며, BoringBatchable 라이브러리의 잠재적 위험에 즉시 충격을 받았습니다.

여기서 설명하자면, BoringBatchable은 배치 호출을 쉽게 도입할 수 있도록 설계된 혼합 라이브러리입니다. 이는 입력으로 제공된 각 호출 데이터에 대해 현재 계약에서 위임 호출을 실행함으로써 이루어집니다.

function batch(bytes[] calldata calls, bool revertOnFail) external payable returns (bool[] memory successes, bytes[] memory results) {
successes = new bool[](calls.length);
results = new bytes[](calls.length);
for (uint256 i = 0; i < calls.length; i++) {
(bool success, bytes memory result) = address(this).delegatecall(calls[i]);
require(success || !revertOnFail, _getRevertMsg(result));
successes[i] = success;
results[i] = result;
}
}

위의 함수를 보면, 올바르게 구현된 것처럼 보입니다. 그러나 제 머리 속의 한 구석에서 무언가가 저를 경고하고 있었습니다. 그때 저는 과거에 매우 유사한 것을 본 적이 있다는 것을 깨달았습니다.

2. 발견

오전 9:47

오늘로부터 1년 이상 전, 저는 Opyn 팀과의 Zoom 비디오 통화에서 파괴적인 해킹 공격을 받은 후 사용자 자금을 복구하고 보호하는 방법을 알아내려고 했습니다.

해킹 기법 자체는 간단하지만 교묘했습니다: 하나의 ETH 지불을 사용하여 여러 옵션을 행사하는 것이었습니다. Opyn 계약이 루프 내에서 msg.value 변수를 사용했기 때문입니다.

토큰 지불을 처리하는 것은 각 루프 반복에 대해 개별 transferFrom 호출을 포함하지만, ETH 지불을 처리하는 것은 msg.value가 충분한지 확인하는 것뿐입니다. 이는 공격자가 동일한 ETH를 여러 번 재사용할 수 있게 합니다.

오늘로 돌아가서, 저는 지금 보고 있는 것이 두 개의 완전히 동일한 취약점이라는 것을 깨달았습니다. 단지 형태가 다를 뿐입니다. 위임 호출에서 msg.sender와 msg.value가 지속됩니다. 이는 제가 commitEth를 배치 호출하고 각 commitment에서 제 msg.value를 재사용할 수 있어야 함을 의미합니다. 이는 제가 경매에서 무료로 입찰할 수 있게 해줍니다.

오전 9:52

제 직감은 이것이 실제 거래라고 말하고 있었지만, 실제로 검증하지 않고는 확신할 수 없었습니다. 저는 신속하게 Remix를 열고 개념 증명을 작성했습니다.

안타깝게도, 제 메인넷 포크 환경은 얼마 전 완전히 손상되었습니다. 저는 런던 하드 포크 중에 실수로 그것을 망가뜨린 것 같습니다. 이렇게 많은 자금이 위험에 처해 있는데, 저는 충분한 시간이 없었습니다. 저는 명령줄에서 간단한 메인넷 포크를 조합하여 제 취약점을 테스트했습니다. 결과는 제가 생각한 대로였습니다.

오전 10:13

이 취약점 위험을 외부에 보고하기 전에, 저는 제 동료 Georgios Konstantopoulos에게 전화를 걸어 그들이 다시 한 번 확인해 보도록 했습니다. 응답을 기다리는 동안, 저는 계약에서 심각성을 확인할 방법을 찾기 위해 돌아갔습니다. 이 경우, 경매에 무료로 참여할 수 있는 것은 한 가지 일이지만, 모든 다른 참여자의 입찰을 훔칠 수 있는 것은 또 다른 일입니다.

저는 처음 스캔 과정에서 환불 로직이 있다는 것을 주목했지만, 그때는 별로 생각하지 않았습니다. 이제는 ETH를 계약에서 인출할 수 있는 방법이 되었습니다. 저는 계약이 저에게 환불을 제공하기 위해 충족해야 할 조건을 확인했습니다.

놀랍고(그리고 두려운) 것은, 경매의 하드 상한선을 초과하여 보내진 ETH는 모두 환불된다는 것이었습니다. 하드 상한선에 도달하더라도 적용되며, 이는 계약이 거래를 완전히 거부하는 것이 아니라 단순히 모든 ETH를 환불한다는 것을 의미합니다.

갑자기 제가 발견한 이 취약점은 거대해졌습니다. 저는 다른 참여자보다 더 많은 입찰을 할 수 있는 취약점을 다루고 있는 것이 아닙니다. 제가 보고 있는 것은 3.5억 달러의 가치가 있는 취약점입니다.

3. 공개

오전 10:38

Georgios와 이 취약점을 확인한 후, 저는 그와 Dan Robinson에게 Sushi CTO Joseph Delong에게 연락해 보도록 했습니다. 몇 분 후, Joseph이 응답했고, 그 후 저는 Georgios, Joseph, Mudit, Keno 및 Omakase와 함께 Zoom 통화를 진행했습니다. 저는 취약점에 대해 다른 참여자들에게 간단히 보고한 후, 그들은 응답을 조율하기 시작했습니다. 전체 통화는 몇 분밖에 걸리지 않았습니다.

4. 준비

오전 11:26

구출 작전실에서 Mudit, Keno, Georgios와 저는 간단한 구출 계약을 작성하는 데 바쁘고 있었습니다. 우리는 가장 깔끔한 방법은 플래시 론을 시작하여 하드 상한선에 직접 구매하고 경매를 종료한 후, 경매 자체의 수익으로 플래시 론을 상환하는 것이라고 결정했습니다. 이 방법은 사전 준비 자금이 필요하지 않으며 매우 효과적이었습니다.

오후 1:36

우리가 구출 계약 작업을 완료했을 때, 우리는 배치 경매의 후속 단계를 논의했습니다. Mudit는 경매가 진행되는 동안 포인트 목록을 설정할 수 있으며, 매번 ETH commitment 동안 호출된다고 지적했습니다. 우리는 즉시 이것이 우리가 찾고 있는 일시 중지 기능일 수 있다는 것을 깨달았습니다.

우리는 이 방법을 사용하기 위한 다양한 방법을 브레인스토밍했습니다. 즉각적인 복원은 명백한 해결책이었지만, 우리는 더 나은 솔루션을 원했습니다.

저는 각 소스가 각 블록에 대해 하나의 commitment만 할 수 있도록 검사를 추가하는 것을 고려했지만, 우리는 해당 함수가 뷰로 표시되어 있다는 것을 주목했습니다. 이는 Solidity 컴파일러가 정적 호출 작업 코드를 사용할 것임을 의미합니다. 우리의 방식은 상태 수정을 허용하지 않았습니다.

한참을 생각한 후, 우리는 포인트 목록을 사용하여 경매 계약이 수행된 commitment에 맞는 충분한 ETH를 보유하고 있는지 검증할 수 있다는 것을 깨달았습니다. 즉, 누군가 이 취약점을 이용하려고 한다면, commitment가 ETH보다 많을 것입니다. 우리는 이를 쉽게 감지하고 거래를 복원할 수 있습니다. Mudit와 Keno는 검증을 위한 테스트를 작성하기 시작했습니다.

5. 구출

오후 2:01

통신 돌파 팀과 구출 돌파 팀은 진행 상황을 동기화하기 위해 협력했습니다. 그들은 경매를 실행하는 팀(BitDAO)과 연락을 취했지만, 해당 팀은 수동으로 경매를 완료하기를 원했습니다. 우리는 위험에 대해 논의하고, 이 거래를 주목하거나 이에 대해 조치를 취할 수 있는 자동화된 로봇이 있을 가능성이 낮다고 판단했습니다.

오후 2:44

경매를 실행하는 팀이 경매를 완료하여 직접적인 위협을 제거했습니다. 우리는 서로 성공을 축하한 후 각자 해산했습니다. 이 배치 경매는 그날 늦게 조용히 종료될 예정입니다. 모르는 사람들은 방금 얼마나 심각한 재앙을 피했는지 알지 못할 것입니다.

6. 반성

오후 4:03

지난 몇 시간은 흐릿하게 느껴졌고, 시간이 정지한 것 같았습니다. 저는 이 프로젝트와의 만남에서부터 취약점을 발견하기까지 30분이 채 걸리지 않았고, 20분 내에 공개했으며, 30분 내에 작전실을 운영하고, 3시간 내에 취약점을 수정했습니다. 총 5시간 만에 3.5억 달러가 나쁜 사람의 손에 떨어지지 않도록 보호했습니다.

금전적 손실이 없었다 하더라도, 저는 이 과정에 참여한 모든 사람들이 처음부터 이 과정을 겪지 않았으면 더 좋았을 것이라고 믿습니다. 이번 사건에 대해 제가 드리고 싶은 두 가지 주요 요점이 있습니다.

첫째, 복잡한 시스템에서 msg.value를 사용하는 것은 매우 어렵습니다. 이는 전역 변수이며, 변경할 수 없고 위임 호출에서 불변으로 유지됩니다. 만약 msg.value를 사용하여 지불이 수신되었는지 확인하려면, 절대 그 논리를 루프 내에 두어서는 안 됩니다.

코드베이스의 복잡성이 증가함에 따라, 발생하는 위치를 잊고 실수로 잘못된 위치에서 어떤 것을 루프하는 것은 쉽습니다. ETH를 포장하고 해제하는 것은 번거롭고 추가 단계를 도입하지만, 이러한 일을 피하고 싶다면 WETH와 다른 ERC20 토큰 간의 통일된 인터페이스를 시도해 볼 가치가 있을 것입니다.

둘째, 두 개의 안전한 구성 요소가 결합되면 불안전한 것이 될 수 있습니다. 저는 이전에 조합 가능성과 DeFi 프로토콜의 맥락에서 이 점을 언급한 적이 있지만, 이번 사건은 안전한 계약 수준의 구성 요소조차도 불안전한 계약 수준의 행동을 생성하는 방식으로 혼합될 수 있음을 보여줍니다. 여기에는 "검사-효과-상호작용"과 같은 포괄적인 조언이 없으므로, 새로운 구성 요소가 도입하는 추가 상호작용을 이해하는 것이 중요합니다.

저는 Sushi의 기여자들, Joseph, Mudit, Keno 및 Omakase가 이 문제에 신속하게 대응해 준 것에 감사드리며, 제 동료 Georgios, Dan 및 Jim이 이 과정 전반에 걸쳐 제공한 도움, 특히 이 글을 검토해 준 것에 대해 감사드립니다.

위험 경고