배경

Blast는 블러의 창립자인 팩맨(일명 티에쉰 로커레, Tieshun)이 출시했습니다. 이더리움 레이어2 네트워크이며, 2월 29일 메인 네트워크를 출시했고 현재 약 19,500개의 이더리움과 640,000개의 스테이블코인이 블라스트 메인 네트워크에 서약되어 있습니다.

공격을 받은 프로젝트인 뭉쳐블은 블라스트가 주최한 빅뱅 대회에서 우승한 프리미엄 프로젝트입니다.

Blast는 공식적으로 Blast 메인넷에서 이더리움을 서약하는 사용자에게 정기적으로 포인트를 지급합니다:

이용자들의 블라스트 생태계 내 디파이 프로젝트 참여를 독려하기 위해 블라스트 관계자는 양질의 프로젝트를 선별하여 추천하고, 골드 포인트뿐만 아니라 포인트 증가율도 빠르게 얻을 수 있는 디파이에 ETH를 2회 서약할 것을 권장할 것입니다. 그 결과, 많은 사용자가 블라스트 메인 네트워크에서 보유하고 있는 이더리움을 새로 생성된 디파이 프로젝트에 스테이킹했습니다.

그러나 이러한 디파이 프로젝트가 얼마나 성숙하고 안전한지, 그리고 이러한 계약이 수천만 달러 또는 수억 달러의 사용자 자금을 보관할 수 있을 만큼 안전한지는 아직 지켜봐야 할 문제입니다.

사건 개요

Blast의 메인 웹사이트가 오픈한 지 한 달도 채 되지 않은 2024년 3월 21일, 토큰 계약의 전송 로직에 오류가 발생하여 공격자가 갑자기 SSS 토큰(슈퍼 스시 사무라이)에 대한 공격이 발생했습니다. 특정 계정의 SSS 토큰 잔액을 증가시켰으며,그 결과 프로젝트에 1310 ETH(약 460만 달러) 이상의 손실을 입혔습니다.

그리고 SSS 토큰 공격이 발생한 지 일주일도 채 되지 않아 Blast에서 더 큰 공격이 발생하여 공격자들이 17,413.96 ETH, 총 6250만 달러에 달하는 금액을 Munchables 프로젝트에 빼앗아갔습니다. strong>.

이 공격 거래 30분 후, 프로젝트의 컨트랙트에 있는 73.49 WETH도 해커에 의해 다른 주소로 도난당했습니다.

이 시점에서 프로젝트 측의 컨트랙트 주소에는 여전히 7276 WETH, 7758267 USDB, 4 ETH가 있으며 언제든지 해커의 손에 넘어갈 수 있으며 해커는 전체 프로젝트의 모든 자금, 총 약 9700만 달러를 위험에 노출시킬 수 있는 권한을 가지고 있습니다! .

사건 발생 직후 유명 체인 추리꾼인 X의 zachXBT(트위터)는 이 공격의 근본 원인이 특정 국가의 해커를 고용했기 때문이라고 지적했습니다.

'특정 국가의 해커'가 어떻게 1억 달러에 가까운 공격을 감행했는지 자세히 살펴봅시다.

장면 복원

. strong>

• 피해자 발성

[UTC+0]2024년 3월 26일 21시 37분(공격 발생 5분 후), 뭉쳐블 관계자는 X(트위터)에 공격을 받았다는 메시지를 올렸습니다.



체인 탐정 ZachXBT의 조사에 따르면. 개발자 중 한 명이 '특정 국가의 해커'이며, 아브고치의 설립자인 코드단(coderdannn)도 트위터를 통해 "아브고치의 개발팀인 픽셀크래프트 스튜디오가 2022년 당시 MMS에 단기 고용된 적이 있다"고 밝혔습니다. 픽셀크래프트 스튜디오는 2022년에 게임 개발 작업을 위해 뭉쳐블 어택커를 단기간 고용했는데, 그는 매우 비열하고 특정 국가의 해커처럼 느껴져 한 달 만에 해고했습니다. 그는 또한 해커일 가능성이 있는 자신의 친구를 고용하도록 유도하기도 했습니다."

이 공격으로 인해 커뮤니티에 막대한 피해가 발생하자 즉시 온체인 조사를 시작했으며, 이제 이 "특정 국가의 해커"에 의한 공격의 세부 사항을 자세히 살펴보겠습니다.

• 첫 번째 장면

[ UTC+0]2024년 3월 26일 21:32에 17413.96 ETH와 관련된 공격이 발생했습니다.

Blastscan을 통해 이 공격 트랜잭션을 확인할 수 있습니다: https://blastscan.io/tx/ 0x9a7e4d16ed15b0367b8ad677eaf1db6a2a54663610696d69e1b4aa1a08f55c95



탈취된 컨트랙트(0x29..1F)는 사용자의 담보 자금을 보유하고 있는 프록시 컨트랙트로, 공격자가 담보 컨트랙트의 잠금 해제 기능을 호출하고 모든 권한 확인을 통과하여 컨트랙트의 모든 이더리움을 공격자의 주소 1(0x6E..c5)로 전송합니다.



공격자는 이와 유사한 형태의 잠금 해제 기능의 인출 동작을 호출하여 손상된 컨트랙트(0x29..1F)에 있는 대부분의 이더리움을 가져간 것으로 보입니다.

볼트의 프로젝트 측에서 잠그는 것을 잊은 것일까요?

손상된 컨트랙트(0x29..1F)에는 잠금 해제와 관련된 체크섬 이 두 개 있으므로 하나씩 살펴봅시다.

먼저, 권한을 확인하는 과정에서 컨트랙트의 isRegistered 메서드(0x16..A0)가 호출되어 해커 주소 1(0x6E..c5)인 현재 msg.sender가 등록되어 있는지 확인합니다."





답변: 검증을 통과했습니다.



여기에 관련된 계약이 있습니다(0x16..A0 A0)

[UTC+0]2024년 3월 24일 08:39(공격 2일 전), 컨트랙트(0x16..A0)에 해당하는 논리적 컨트랙트가 업그레이드되었습니다.



논리적 컨트랙트 업그레이드 트랜잭션:

https://blastscan.io/tx/0x9c431e09a80d2942319853ccfdaae24c5de23cedfcef0022815fdae42a7e2ab6

논리적 컨트랙트가 0xe7..f1.

초기 논리적 컨트랙트 주소는 0x9e..CD.

https:/. /blastscan.io/tx/0x7ad050d84c89833aa1398fb8e5d179ddfae6d48e8ce964f6d5b71484cc06d003



이 시점에서 해커는 프록시 컨트랙트의 로직을 업데이트하여 0x9e.CD를 악성 0xe7..f1으로 바꾸고 인증 권한 우회를 완료하는 것으로 의심됩니다.

정말요?

웹 3.0에서는 다른 사람의 말을 듣고 추측할 필요 없이 기술을 습득하여 스스로 답을 찾으면 됩니다.

오픈소스 컨트랙트가 아닌 두 컨트랙트를 비교해 보면, 원래 0x9e..CD 컨트랙트와 업데이트된 0xe7..f1 사이에는 몇 가지 분명한 차이점이 있습니다:

0xe7..f1 초기화 함수는 부분적으로 다음과 같이 구현됩니다:



0x9e. ">0x9e...CD의 초기화 기능은 부분적으로 다음과 같이 구현됩니다.



공격자는 초기 논리적 컨트랙트(0x9e..CD)에서 공격자 주소(0x6e..c5)를 REGISTER로 설정하고, 다른 두 개의 공격자 주소인 0xc5..0d와 0xbf..87도 REGISTER로 설정하고 필드0을 초기화 상태로 설정한 것을 볼 수 있습니다. 로 설정되어 있으며, 필드0은 나중에 설명합니다.

사실, 우리가 의심했던 것과는 달리 실제 백도어 로직 컨트랙트는 애초에 존재했던 것이고 나중에 업데이트된 것은 정상적인 컨트랙트입니다!

잠깐, 이 업데이트는 2024년 3월 24일 08:39 [UTC+0] (공격 이틀 전), 즉 이 이벤트 이전에 이미 로직 컨트랙트가 백도어가 없는 것으로 바뀌었는데 공격자가 나중에 공격을 완료할 수 있었던 이유는 무엇이었을까요?

그 이유는 델리게이트 호출로 인해 실제 상태 저장소 업데이트가 컨트랙트(0x16..A0)에 있기 때문에 백도어가 없는 논리 컨트랙트 0xe7..f1로 업데이트되더라도 컨트랙트(0x16..A0)의 Changed ss가 변경되었다는 사실로 이어지기 때문입니다. strong> 변경된 슬롯은 여전히 복원되지 않습니다.

확인해 봅시다:



해당 컨트랙트(0x16.... .A0)에 값이 있음을 알 수 있습니다.

이를 통해 공격자는 isRegistered 메서드의 체크섬을 전달할 수 있습니다.



그런 다음 공격자는 백도어 컨트랙트를 정상 컨트랙트로 대체하여 백도어가 이미 심어져 있다는 사실을 위장합니다.

또한 잠금 해제 과정에서 잠긴 자산이 만료되기 전에 전송되지 않도록 하는 두 번째 확인:

잠금 시간을 확인합니다. 만료되기 전에 전송되지 않도록 합니다.



공격자는 잠금 해제가 호출될 때 블록 시간이 필요한 값보다 큰지 확인해야 합니다. 잠금 해제가 호출될 때 차단 시간이 필수 잠금 만료 시간(필드3)보다 길어야 합니다.

이 점검 부분에는 손상된 컨트랙트(0x29..1F)와 해당 논리적 컨트랙트 0xf5..cd가 포함됩니다.

해제가 호출될 때 공격자의 블록 시간이 필수 잠금 만료 시간(필드3)보다 큽니다.

해제가 호출될 때 공격자는 블록 시간이 필수 잠금 만료 시간보다 크다는 것을 확인해야 합니다. 트랜잭션에서 공격 5일 전)

https://blastscan.io/tx/ 0x3d08f2fcfe51cf5758f4e9ba057c51543b0ff386ba53e0b4f267850871b88170



손상된 컨트랙트(0x29..1F) 컨트랙트는 처음에 0x91..11의 논리적 컨트랙트를 가지고 있으며, 4분 후

https://blastscan.io/tx/0xea1d9c0d8de4280b538b6fe6dbc3636602075184651dfeb837cb03f8a19ffc4f



0xf5..cd.

와 비슷하게 비교해 봅시다. 공격자가 이전과 마찬가지로 초기화 함수도 변조했음을 알 수 있습니다.

0xf5..cd의 초기화 함수 일부가 구현되어 있습니다.



0x91..11에 대한 초기화 함수의 일부가 구현되었습니다:



보시다시피, 동일한 기법이 다시 사용되어 보유 이더리움 수와 잠금 해제 시간이 변조된 것을 확인할 수 있습니다. 동일한 기술을 사용하여 보유 이더리움의 수와 잠금 해제 시간을 변경한 다음 이를 일반 계약으로 대체하여 대중에게 숨겼습니다. 프로젝트 팀과 보안 연구원이 디버깅할 때 논리적 계약은 모두 정상적이었고, 계약이 오픈 소스가 아니었기 때문에 문제의 핵심을 파악하기가 더 어려웠습니다.

지금까지는 공격자가 17,413개의 이더리움을 거래한 방법을 파악했지만, 이 사건의 배후에 있는 정보가 너무 많나요?

위 분석에서 실제로 해커가 컨트랙트 내에 3개의 주소를 내장한 것을 확인했습니다.

0x6e...c5 (공격자의 주소 1)

. style="text-align: 왼쪽;">0xc5...0d (공격자 주소 2)

0xbf...87 (공격자 주소 3)

그리고 위에서 발견한 공격은 다음과 같습니다. 트랜잭션에는 0x6e..c5만 보이는데, 다른 두 주소는 무엇을 했을까요? 그리고 주소(0), _dodoApproveAddress, _uniswapV3Factorty에는 어떤 다른 비밀이 숨겨져 있을까요?

• 사이트 2

동일한 기법을 통해 73.49 WETH를 탈취한 공격자 주소 3(0xbf..87)을 살펴보겠습니다:

https://blastscan.io/tx/ 0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233

그리고 가스(0x97..de) 소스 주소를 공격하는 동시에 0xc5. 0d(공격자 주소 2)와 0xbf...87(공격자 주소 3)에 수수료를 지불합니다.



그리고 가스 소스 주소(0x97..... DE)에 0.1 ETH의 자금을 owlto.finance(크로스체인 브리지)에서 조달했습니다.

0xc5..0d(공격자 주소 2)는 수수료를 받고 공격을 수행하지는 않았지만, 실제로는 숨겨진 의도를 가지고 있었습니다(계속 살펴보겠습니다).

실제로 사후 공식 구조 거래에 따르면 원래 피해 계약의 주소(0x29..1F)에는 73.49 WETH가 있었고 공격이 끝날 때까지도 7276.5 WETH & 7758267 USDB가 남아 있었습니다.

거래 구조:

https://blastscan.io/tx/ 0x1969f10af9d0d8f80ee3e3c88d358a6f668a7bf4da6e598e5be7a3407dc6d5bb



원래 공격자는 이러한 자산을 탈취할 계획이었으며, 0xc5..0d(공격자 주소 2) 주소가 원래 USDB 탈취에 사용되었음을 알 수 있습니다.



여기서 _. https://img.jinse.cn/7200169_image3.png">

DB의 주소



0xbf..87 (공격자 주소 3) 이 주소는 웨스를 훔치는 데 사용되었습니다:



여기의 _uniswapV3Factory는 다음과 같습니다. 0x000000000000000000000000000000000000000000000000000000000000000000000000000004



weth 주소



그리고 0x6e..c5(공격자 주소 1)는 네이티브 자산인 ETH인 주소(0)를 훔칩니다.

공격자 는 다음 로직으로 필드0을 설정하여 해당 자산을 훔칠 수 있습니다.





질문

• 공격자가 모든 자산을 훔치지 않은 이유는 무엇인가요?

이론적으로 그는 모든 자산, 즉 나머지 WETH와 USDB를 훔칠 수 있었습니다.

0xbf..87 (공격자의 주소 3)은 다음만 훔쳤습니다. 73.49 WETH, 0xbf..87 (공격자 주소 3)은 실제로 0xc5..0d (공격자 주소 2)의 도움으로 7758267 USDB를 모두 가져갈 수 있으며, 왜 약간의 WETH 만 중지해야하는지, 우리는 내부 조사를 심화하기 위해 잘 알려진 형사 사슬이 필요할 수 있는지 모릅니다.

https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233



• 공격자들은 왜 17413 ETH를 메인 이더리움 네트워크로 전송하지 않았나요?

이 이더리움 메인넷이 이러한 이더를 중앙화하여 사용자에게 실질적인 비용을 지불하지 않도록 영구적으로 보관하는 것이 가능하다는 것은 잘 알려져 있지만, 일단 이더리움 메인넷에 들어오면 가로채는 것이 불가능합니다. 가로챌 방법이 없습니다.

현재 블라스트 크로스체인 브리지를 평가한 결과, 공식 크로스체인 브리지 수에는 제한이 없지만 14일의 옵트아웃 기간이 있어 블라스트 관계자가 차단 계획을 준비하기에 충분한 시간입니다.

서드파티 크로스 체인 브리지는 거의 실시간으로 사용할 수 있고 공격자의 수수료 출처와 마찬가지로 크로스 체인을 빠르게 완료하는데, 왜 공격자는 애초에 이를 수행하지 않았을까요?

실제로 공격자가 처음에 크로스체인을 만들었습니다(공격 후 2분 이내):

https://blastscan.io/tx/ 0x10cf2f2b884549979a3a1dd912287256229458ef40d56df61738d6ea7d9d198f



그리고 자금이 이더리움 메인넷에 도착하는 데 20초가 걸렸으므로 이론적으로 공격자는 계속해서 크로스체인을 진행할 수 있었고, 크로스체인 브리지가 수동으로 개입하기 전에 많은 양의 이더를 체인에 전송할 수 있었습니다.



한 번에 3 ETH만 가능한 이유에 대해서는 다음과 같은 이유가 있습니다. 블라스트에서 이더로 건너가는 크로스체인 브리지 유동성 제한 :



. 왼쪽;">Blast를 지원하는 또 다른 크로스 링크 브리지는 더 적게 지원합니다:



이 크로스 체인 거래 이후 공격자들은 알 수 없는 이유로 다른 크로스 체인 작업을 계속하지 않았지만, '특정 국가의 해커'가 블라스트에서 자금을 인출할 때 적절히 준비하지 못한 것으로 보입니다.

공격 후 전개 상황

커뮤니티 사용자 Nearisbuilding에 따르면, 그는 공격자의 신원에 대해 자세히 알아낼 수 있었고 공격자에게 자금을 반환하도록 유도하는 방법을 알아냈습니다.

https://twitter.com/Nearisbuilding/status/1772812190673756548





결국 암호화폐 커뮤니티의 관심과 노력 덕분에 '특정 국가의 해커'는 자신의 신원이 노출될 것을 우려한 탓인지 공격자 3명의 개인키를 프로젝트에 제공하고 모든 자금을 반환했으며 프로젝트는 구출될 수 있었습니다. 프로젝트는 또한 구출 계약을 체결하여 손상된 계약의 모든 자금을 다중 서명 계약으로 이체하여 안전하게 보관했습니다.