프로젝트가 실제로 운영되기 전에 전문적인 제3자 감사 기관에서 스마트 계약 감사 실시해야 합니다.
저자: SharkTeam
표지: Unsplash 의 Markus Spiske 사진
2024년 4월 19일, 헤지 파이낸스는 여러 건의 공격 거래를 당했으며, 이로 인해 200만 달러 이상의 손실을 입었습니다.
샤크팀은 즉시 해당 사건에 대한 기술적 분석을 실시하고 보안 예방 조치를 정리했으며, 향후 프로젝트들이 이 경험을 통해 배우고 블록체인 산업을 위한 보안 방어선을 공동으로 구축할 수 있기를 희망합니다.
I. 거래 에 대한 공격
헤지 파이낸스는 여러 공격자로부터 토큰 승인 취약점을 악용하여 클레임캠페인(ClaimCampaigns) 계약에서 대량 의 토큰을 탈취하는 공격을 여러 차례 받았습니다.
예를 들어, 가장 큰 거래는 약 130만 달러 규모였습니다.
공격 거래: 0x2606d459a50ca4920722a111745c2eeced1d8a01ff25ee762e22d5d4b1595739
공격자: 0xded2b1a426e1b7d415a40bcad44e98f47181dda2
공격 계약: 0xc793113f1548b97e37c409f39244ee44241bf2b3
대상 계약: 0xbc452fdc8f851d7c5b72e1fe74dfb63bb793d511 (ClaimCampaigns)
이번 거래를 통해 ClaimCampaigns 계약에서 1,303,910.12 USDC가 직접 이체되었습니다. 거래 내역은 다음과 같습니다.
공격을 촉발한 실제 거래는 다음과 같습니다.
0xa17fdb804728f226fcd10e78eae5247abd984e0f03301312315b89cae25aa517 (약칭 0xa17f)
공격 과정은 다음과 같습니다.
1. Balancer에서 130만 5천 USDC 플래시 론(Flash loan).
2. `ClaimCampaigns` 컨트랙트의 `createLockedCampaign` 함수를 호출합니다. 이 함수에서 공격 컨트랙트는 130만 5천 USDC를 `ClaimCampaigns` 컨트랙트에 예치하고, `ClaimCampaigns` 컨트랙트는 공격 컨트랙트가 사용할 수 있도록 이체된 130만 5천 USDC를 승인합니다.
3. `ClaimCampaigns` 컨트랙트의 `cancelCampaign` 함수가 호출됩니다. 이 함수에서 공격 컨트랙트는 예치된 130만 5천 USDC를 클레임 하지만, `createLockedCampaign` 함수에서 공격 컨트랙트에 대해 승인된 USDC는 취소되지 않습니다.
4. Balancer의 플래시 론(Flash loan) 상환하기 위해 계약을 공격하십시오.
이 거래에서 공격 계약이 ClaimCampaigns 계약에서 130만 5천 USDC를 클레임 후에도 ClaimCampaigns 계약이 공격 계약에 대해 승인한 130만 5천 USDC는 취소되지 않습니다. 따라서 공격 계약은 USDC transferFrom 함수를 직접 호출하여 ClaimCampaigns 계약에서 또 다른 130만 5천 USDC를 이체할 수 있습니다. 이것이 거래 0xa17fdb804728f226fcd10e78eae5247abd984e0f03301312315b89cae25aa517을 통해 구현된 기능입니다.
이 두 건의 거래를 통해 공격자는 ClaimCampaigns 계약에서 130만 5천 USDC를 훔쳤습니다.
공격자는 USDC 외에도 이 취약점을 이용해 ClaimCampaigns 계약에서 대량 의 NOBL 토큰을 탈취했으며, USDC를 포함한 총 가치는 200만 달러가 넘습니다.
II. 취약성 분석
이번 사건의 근본 원인은 프로젝트 스마트 계약의 구현 로직에 있는 토큰 승인 취약점으로, 공격자가 대상 계약에서 승인된 토큰을 msg.sender로 반복적으로 전송할 수 있도록 허용합니다.
ClaimCampaigns 스마트 컨트랙트의 createLockedCampaign 함수는 msg.sender의 토큰을 대상 컨트랙트에 저장하고 msg.sender에 대해 해당 토큰을 승인합니다.
cancelCampaign 함수는 입금된 토큰을 클레임 하지만 토큰 승인을 취소하지는 않습니다.
공격자는 이 취약점을 악용하여 토큰의 transferFrom 함수를 직접 호출하여 승인된 토큰을 대상 계약에서 다시 전송할 수 있습니다.
III. 안전 권고사항
이러한 공격에 대응하여 개발 과정에서 다음과 같은 예방 조치를 취해야 합니다.
(1) 프로젝트의 설계 및 개발 과정에서 논리의 완전성과 엄격성이 유지되어야 합니다. 특히 자산을 이전할 때에는 토큰이 이전되었으나 승인이 취소되지 않은 상황을 방지하기 위해 동시에 승인된 토큰의 수를 보장해야 합니다.
(2) 프로젝트가 시작되기 전에 제3자 전문 감사 회사가 스마트 계약 감사 실시해야 합니다.
면책 조항: 본 사이트는 블록체인 정보 플랫폼으로서, 사이트에 게시된 글은 필자 및 초청 연사의 개인적인 관점 일 뿐이며 Web3Caff의 공식적인 입장을 반영하는 것은 아닙니다. 본 글에 포함된 정보는 참고용일 뿐이며 투자 자문 또는 투자 제안으로 간주될 수 없습니다. 각 국가 또는 지역의 관련 법률 및 규정을 준수하시기 바랍니다.
