배경

Blast는 Blur의 창립자인 Pacman(Tieshun Roquerre, 일명 Tieshun)이 출시한 이더리움 레이어 2 네트워크로, 지난 2월 29일 메인넷을 출시했으며, 현재 Blast 메인넷에는 약 19,500 ETH와 640,000 stETH가 약속되어 있습니다.

공격을 받은 프로젝트 Munchables는 Blast가 주최한 빅뱅 대회에서 우승한 수준 높은 프로젝트였습니다.

Blast 관계자는 Blast 메인넷에서 ETH를 약속한 사용자에게 일반 포인트를 발급합니다.

사용자가 Blast 생태계의 DeFi 프로젝트에 참여하도록 장려하기 위해 Blast 관계자는 추천을 위해 고품질 프로젝트를 선택하고 사용자가 더 빠른 포인트 증가 및 골드 포인트를 얻기 위해 DeFi에 두 번째로 ETH를 약속하도록 권장할 것입니다. 몇몇 사용자는 Blast 메인 네트워크에서 약속된 ETH를 새로 생성된 DeFi 프로젝트에 약속했습니다.

이러한 DeFi 프로젝트의 성숙도와 보안은 아직 조사되지 않았으며 이러한 계약에 사용자의 수천만 달러, 심지어 수억 달러를 보호할 수 있는 충분한 보안 고려 사항이 있는지 여부도 조사되지 않았습니다.

이벤트 개요

Blast 메인넷이 온라인에 접속한 지 한 달도 채 되지 않아 2024년 3월 21일 SSS 토큰(Super Sushi Samurai)에 대한 공격이 발생했습니다. 토큰 계약에 전송 논리 오류가 있어 공격자가 SSS 토큰을 늘릴 수 있었습니다. 특정 계정의 잔액이 부족해 프로젝트는 결국 1,310 ETH(약 460만 달러) 이상을 잃었습니다.

SSS 토큰 공격이 발생한 지 일주일도 채 되지 않아 Blast에서 또 다른 대규모 공격이 발생했는데, Munchables 프로젝트는 17413.96 ETH, 총 약 6250만 달러에 달하는 공격자들에 의해 휩쓸려갔습니다.

공격 거래가 발생한 지 30분 만에 프로젝트 계약의 73.49 WETH도 해킹당한 다른 주소로 도난당했습니다.

현재 프로젝트 당사자의 컨트랙트 주소에는 여전히 7,276 WETH, 7,758,267 USDB, 4 ETH가 저장되어 있어 언제든지 해커의 손에 넘어갈 수 있으며, 해커는 프로젝트 당사자의 모든 자금을 탈취할 수 있는 권한을 가지고 있습니다. 전체 프로젝트 규모는 약 9,700만 달러에 이르며 위험에 노출되어 있습니다.

사건 직후 X(트위터)의 유명 온체인 탐정 zachXBT는 이번 공격의 근본 원인이 특정 국가 출신의 해커를 고용한 것이라고 지적했다.

"특정 국가의 해커"가 어떻게 1억 달러에 가까운 공격을 완료했는지 자세히 살펴보겠습니다.

현장 복원

[UTC+0] 2024년 3월 26일 21시 37분(공격 후 5분), Munchables는 공식적으로 X(트위터)에 공격을 받고 있음을 게시했습니다.

온체인 형사 Zach의 조사에 따르면 공격자는 게임 개발 작업을 하러 왔습니다. 그는 매우 거칠고 정말 중국 해커처럼 보였습니다. 우리는 그를 한 달 만에 해고했습니다. 그는 또한 우리에게 자신의 직원을 고용하려고 했습니다. 아마 해커이기도 했던 친구들. 해커."

이번 공격으로 인해 커뮤니티 내 사용자들에게 큰 손실이 발생했기 때문에 우리는 즉시 온체인 조사에 착수했습니다.이 “특정 국가의 해커”의 공격 세부 내용을 심층적으로 살펴보겠습니다.

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

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

손상된 컨트랙트(0x29..1F)는 사용자가 담보한 자금을 저장하는 대리 컨트랙트이며, 공격자가 담보 컨트랙트의 Unlock 기능을 호출하고 모든 권한 확인을 통과한 후 컨트랙트 내 자금을 이체한 것을 확인할 수 있습니다. 모든 ETH는 공격자 주소 1(0x6E..c5)로 보내집니다.

공격자는 출금 동작과 유사한 잠금 해제 기능을 호출해 손상된 계약(0x29..1F)의 ETH를 대부분 빼앗은 것으로 보입니다.

프로젝트 당사자가 금고를 잠그는 것을 잊었나요?

손상된 컨트랙트(0x29..1F)에는 Unlock 관련 체크가 2개 있는데, 하나씩 살펴보겠습니다.

먼저, 권한 확인 과정에서 현재 msg.sender, 즉 해커 주소 1(0x6E..c5)이 등록되었는지 확인하기 위해 컨트랙트(0x16..A0)의 isRegistered 메소드를 호출한 것을 확인했습니다. :

대답은 다음과 같습니다. 검증을 통과했습니다.

여기에는 계약(0x16..A0) 및 해당 최신 논리 계약(0xe7..f1)이 포함됩니다.

[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로 변경하여 검증 권한 우회를 완료한 것으로 의심됩니다.

진짜야?

Web3.0에서는 다른 사람의 말을 추측하거나 들을 필요가 없으며 기술을 익히기만 하면 스스로 답을 얻을 수 있습니다.

두 계약(오픈 소스 계약 아님)을 비교하여 원래 0x9e..CD 계약과 업데이트된 0xe7..f1 계약 간에 몇 가지 명백한 차이점이 있음을 발견했습니다.

0xe7..f1의 초기화 기능 부분은 다음과 같이 구현됩니다.

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

공격자는 원래 논리 계약(0x9e..CD)에 레지스터로 공격자 주소(0x6e..c5)를 설정한 것을 볼 수 있으며, 다른 두 공격자 주소 0xc5..0d와 0xbf..87도 있음을 알 수 있습니다. 등록되어 있으며 field0은 초기화 시 블록 시간으로 설정됩니다. field0의 사용법은 나중에 설명합니다.

사실 우리가 추측한 것과는 달리 백도어를 이용한 실제 로직 컨트랙트는 처음부터 존재했고, 이후의 업데이트도 정상이었습니다!

잠깐, 이 업데이트는 2024년 3월 24일 [UTC+0] 08:39 (공격 2일 전)에 나타났습니다. 즉, 이번 사건 이전에는 논리 계약이 백도어 없는 계약이 되어 있었습니다. 왜일까요? 공격자는 완료할 수 있습니까? 공격은 나중에?

이는 델리게이트 콜 때문이므로 실제 상태 저장 업데이트는 컨트랙트(0x16..A0)에 있고, 이로 인해 나중에 로직 컨트랙트가 백도어 없이 로직 컨트랙트 0xe7..f1로 업데이트 되더라도, 계약(0x16..A0)은 여전히 ​​복원되지 않습니다.

확인해 봅시다:

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

이를 통해 공격자는 isRegistered 메소드 검사를 통과할 수 있습니다.

공격자는 나중에 백도어가 이미 설치되어 있다는 사실을 숨기기 위해 백도어 계약을 일반 계약으로 변경합니다.

또한 잠금 해제 프로세스에는 두 번째 확인도 포함됩니다.

잠금 시간 확인과 관련하여, 이 부분은 잠긴 자산이 만료되기 전에 이동되지 않도록 하기 위한 것입니다.

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

이 확인 부분에는 손상된 계약(0x29..1F)과 해당 논리적 계약 0xf5..cd가 포함됩니다.

2024년 3월 21일 [UTC+0](공격 5일 전) 11시 54분의 거래에서,

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

손상된 계약(0x29..1F) 계약의 원래 논리적 계약은 0x91..11이었고 불과 4분 후인 것을 알 수 있습니다.

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

0xf5..cd로 업그레이드되었습니다.

또한 두 계약을 비교한 결과 공격자가 이전과 마찬가지로 초기화 기능에도 트릭을 적용한 것을 확인할 수 있습니다.

0xf5..cd의 초기화 기능 부분 구현:

0xf5..cd로 업그레이드되었습니다.

또한 두 계약을 비교한 결과 공격자가 이전과 마찬가지로 초기화 기능에도 트릭을 적용한 것을 확인할 수 있습니다.

0xf5..cd의 초기화 기능 부분 구현:

0x91..11의 초기화 기능 부분 구현:

동일한 수법으로 다시 ETH 수량과 잠금 해제 시간을 조작한 후, 이를 일반 계약으로 대체하여 타인을 속이는 것을 볼 수 있습니다. 보이는 논리적 계약은 모두 정상이며, 해당 계약은 모두 오픈소스가 아닌 계약이기 때문에 문제의 핵심을 명확하게 보기는 더욱 어렵습니다.

지금까지 우리는 17413 ETH가 관련된 이 거래와 공격자가 어떻게 했는지 이해하고 있는데, 이 사건의 배후에는 이 정도의 정보만이 있는 걸까요?

위의 분석에서 실제로 해커가 계약서에 3개의 주소를 구축한 것을 확인했습니다.

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

0xc5..0d(공격자 주소 2)

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

그런데 위에서 찾은 공격 트랜잭션에서는 0x6e..c5만 보았는데, 나머지 두 주소는 무슨 역할을 하였나요? 그리고 address(0), _dodoApproveAddress 및 _uniswapV3Factorty에는 어떤 비밀이 숨겨져 있나요?

먼저 동일한 방법으로 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가 남아 있었습니다.

실제로 구조 후 공식 거래에 따르면 손상된 계약의 원래 주소(0x29..1F)는 73.49 WETH만이 아니라 공격이 끝날 때까지 여전히 7276.5 WETH 및 7758267 USDB가 남아 있었습니다.

구출 거래:

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

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

여기의 _dodoApproveAddress는 0x0000000000000000000000004300000000000000000000000000000000000003입니다.

usdb 주소입니다

0xbf..87(공격자 주소 3) 이 주소는 Weth를 훔치는 데 사용됩니다.

0xbf..87(공격자 주소 3) 이 주소는 Weth를 훔치는 데 사용됩니다.

여기서 _uniswapV3Factory는 0x000000000000000000000004300000000000000000000000000000000000004입니다.

웨스 주소예요

그리고 0x6e..c5(공격자 주소 1)는 네이티브 자산인 ETH인 주소(0)를 훔치는 역할을 담당합니다.

field0을 설정하면 공격자는 다음 논리를 통해 해당 자산을 훔칠 수 있습니다.

질문

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

0xbf..87(공격자 주소 3)은 73.49 WETH만 훔쳤습니다. 0xbf..87(공격자 주소 3)은 실제로 7350 WETH를 모두 가져갈 수 있습니다. 또한 0xc5..0d(공격자 주소 2)를 사용하여 7758267 USDB를 모두 가져갈 수도 있습니다. , 왜 약간의 WETH만 취하고 중지했는지는 알 수 없으며, 심층적인 내부 조사를 수행하려면 잘 알려진 연쇄 형사가 필요할 수도 있습니다.

0xbf..87(공격자 주소 3)은 73.49 WETH만 훔쳤습니다. 0xbf..87(공격자 주소 3)은 실제로 7350 WETH를 모두 가져갈 수 있습니다. 또한 0xc5..0d(공격자 주소 2)를 사용하여 7758267 USDB를 모두 가져갈 수도 있습니다. , 왜 약간의 WETH만 취하고 중지했는지는 알 수 없으며, 심층적인 내부 조사를 수행하려면 잘 알려진 연쇄 형사가 필요할 수도 있습니다.

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

우리 모두 알고 있듯이 Blast 메인 네트워크는 중앙 집중식 방법을 통해 이러한 ETH를 가로채어 사용자에게 큰 손실을 입히지 않고 영구적으로 여기에 머물게 하는 것이 가능합니다. 그러나 이러한 ETH가 이더리움 메인 네트워크에 들어가면 가로챌 수 있는 방법이 없습니다. 그것.

현재 Blast 교차교를 평가했는데, 공식 교차교량 수에는 제한이 없으나, 빠져나오는 데 14일이 소요되며, 이는 Blast 관계자가 차단 계획을 준비하는 데 충분합니다.

제3자 크로스체인 브리지는 공격자의 수수료 소스와 마찬가지로 거의 실시간으로 적립될 수 있으며 신속하게 크로스체인을 완료할 수 있습니다. 공격자는 왜 즉시 크로스체인을 수행하지 않았습니까?

실제로 공격자는 첫 순간(공격 후 2분 이내)에 크로스체인을 수행했습니다.

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

게다가 자금이 이더리움 메인 네트워크에 도착하는 데 20초가 걸렸습니다. 이론적으로 공격자는 크로스체인 브리지가 수동으로 개입하기 전에 계속해서 크로스체인을 수행하고 체인 간에 대량의 ETH를 전송할 수 있습니다.

한 번에 3 ETH만 가능한 이유는 Blast에서 ETH까지 크로스체인 브리지의 유동성 제한 때문입니다.

한 번에 3 ETH만 가능한 이유는 Blast에서 ETH까지 크로스체인 브리지의 유동성 제한 때문입니다.

Blast를 지원하는 또 다른 크로스체인 브리지는 다음보다 더 적은 지원도 지원합니다.

이번 크로스체인 거래 이후, 공격자는 다른 크로스체인 작업을 계속하지 않았으며, 그 이유는 알려지지 않았으며, '특정 국가의 해커'가 Blast 자금 인출에 대한 적절한 준비를 하지 않은 것으로 보입니다.

공격 후에 무슨 일이 일어났는가

커뮤니티 사용자 Nearisbuilding의 피드백을 바탕으로 그는 공격자의 더 많은 신원 정보를 발견하고 공격자가 자금을 반환하도록 유도하는 방법을 찾았습니다.

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

결국 암호화 커뮤니티의 관심과 노력으로 '특정 국가의 해커'는 자신의 신원이 노출될까 두려워 위 3개의 공격자 주소의 개인 키를 프로젝트 팀에 제공하고 모두 반환했습니다. 프로젝트 팀은 구제 거래도 진행했으며 손상된 계약서의 모든 자금을 다중 서명 계약서로 이체하여 보관했습니다.