2024년 4월 19일, Hedgey Finance는 여러 번의 공격 거래를 겪었고 그 결과 200만 달러 이상의 손실이 발생했습니다.
SharkTeam은 이 사건에 대해 즉시 기술적 분석을 수행하고 보안 예방 조치를 요약했습니다. 후속 프로젝트가 이로부터 교훈을 얻어 블록체인 산업을 위한 보안 방어선을 공동으로 구축할 수 있기를 바랍니다.
Hedgey Finance는 ClaimCampaigns 계약에서 대량의 토큰을 훔치기 위해 토큰 승인 취약점을 악용한 공격자로부터 여러 차례 공격을 받았습니다.
약 130만 달러 규모의 가장 큰 거래를 예로 들어보겠습니다.
공격 트랜잭션: 0x2606d459a50ca4920722a111745c2eeced1d8a01ff25ee762e22d5d4b1595739
공격자: 0xded2b1a426e1b7d415a40bcad44e98f47181dda2
공격 계약: 0xc793113f1548b97e37c409f39244ee44241bf2b3
대상 계약: 0xbc452fdc8f851d7c5b72e1fe74dfb63bb793d511(ClaimCampaigns)
해당 거래는 ClaimCampaigns 계약에서 직접 1,303,910.12 USDC를 이체했습니다. 거래내역은 다음과 같습니다.
실제로 공격을 시작한 트랜잭션은 다음과 같습니다.
0xa17fdb804728f226fcd10e78eae5247abd984e0f03301312315b89cae25aa517 (약어로 0xa17f)
공격 과정은 다음과 같습니다.
0xa17fdb804728f226fcd10e78eae5247abd984e0f03301312315b89cae25aa517 (약어로 0xa17f)
공격 과정은 다음과 같습니다.
Balancer로부터 1개의 플래시 대출 1305M USDC.
2. ClaimCampaigns 계약에서 createLockedCampaign 함수를 호출합니다. 이 기능에서 공격 계약은 ClaimCampaigns 계약에 1.305M USDC를 입금한 다음 laimCampaigns 계약은 공격 계약에서 사용할 전송된 1.305M USDC를 승인합니다.
3. ClaimCampaigns 계약에서 cancelCampaign 함수를 호출합니다. 이 함수에서는 공격 계약이 예치된 1305만 USDC를 출금하지만, createLockedCampaign 함수에서 공격 계약에 승인된 USDC는 취소되지 않습니다.
4 Balancer의 플래시 대출을 상환하기 위해 계약을 공격합니다.
이번 거래에서는 공격 계약이 ClaimCampaigns 계약에 저장된 1305M USDC를 인출한 후 공격 계약에 대해 ClaimCampaigns 계약에서 승인한 1305M USDC가 취소되지 않았습니다. 따라서 공격 계약에서는 USDC의 transferFrom 함수를 직접 호출할 수 있습니다. ClaimCampaigns 계약에서 자금을 다시 인출하세요. 1305M USDC를 다시 이체하세요. 이는 트랜잭션 0xa17fdb804728f226fcd10e78eae5247abd984e0f03301312315b89cae25aa517에 의해 구현된 기능이기도 합니다.
위의 두 거래를 통해 공격자는 ClaimCampaigns 계약에서 1305만 USDC를 훔쳤습니다.
USDC 외에도 공격자는 이 취약점을 이용하여 ClaimCampaigns 계약에서 대량의 NOBL 토큰을 훔쳤습니다. USDC와 함께 총 가치는 200만 달러를 초과합니다.
이번 사건의 근본 원인은 프로젝트의 스마트 계약 구현 로직에 토큰 승인 취약점이 있어 공격자가 대상 계약 승인을 msg.sender의 토큰으로 반복적으로 전송할 수 있다는 것입니다.
스마트 계약 ClaimCampaigns의 createLockedCamaign 기능은 msg.sender의 토큰을 대상 계약에 저장하고 이러한 토큰을 msg.sender에 승인합니다.
cancelCampaign 기능은 예치된 토큰을 철회하지만 토큰 승인을 취소하지는 않습니다.
공격자는 이 취약점을 이용하여 Token의 transferFrom 함수를 직접 호출하여 대상 계약에서 승인된 토큰을 다시 전송합니다.
이 공격에 대응하여 우리는 개발 과정에서 다음과 같은 예방 조치를 따라야 합니다.
공격자는 이 취약점을 이용하여 Token의 transferFrom 함수를 직접 호출하여 대상 계약에서 승인된 토큰을 다시 전송합니다.
이 공격에 대응하여 우리는 개발 과정에서 다음과 같은 예방 조치를 따라야 합니다.
(1) 프로젝트의 설계 및 개발 과정에서 특히 자산 양도와 관련하여 논리의 무결성과 엄격함이 유지되어야 합니다. 토큰 양도 시 승인된 토큰 수를 동기화하여 양도를 방지하십시오. 토큰은 있지만 승인 취소는 없습니다.
(2) 프로젝트가 온라인으로 진행되기 전에 제3자 전문 감사 회사를 통해 스마트 계약 감사를 수행해야 합니다.
SharkTeam의 비전은 Web3 세계를 보호하는 것입니다. 이 팀은 블록체인 및 스마트 계약의 기본 이론에 능숙한 전 세계의 숙련된 보안 전문가와 수석 연구원으로 구성되어 있습니다. 위험 식별 및 차단, 스마트 계약 감사, KYT/AML, 온체인 분석 등을 포함한 서비스를 제공하며 지능형 지속 위협(Advanced Persistant Threat, Advanced Persistant Threat)에 효과적으로 대처할 수 있는 온체인 지능형 위험 식별 및 차단 플랫폼 ChainAegis를 만들었습니다. 지속적인 위협), APT). Polkadot, Moonbeam, Polygon, Sui, OKX, imToken, Collab.Land, TinTinLand 등 Web3 생태계의 다양한 분야의 주요 플레이어와 장기적인 협력 관계를 구축했습니다.
공식 홈페이지: https://www.sharkteam.org
트위터: https://twitter.com/sharkteamorg
모든 댓글