주간 Web3 보안 사고 요약 | 2026년 2월 2일 – 2월 8일

지난 한 주(2026년 2월 2일~2월 8일) 동안 BlockSec은 총 6건의 공격 사건을 탐지 및 분석하였으며, 총 추정 피해액은 약 $3.8M입니다. 아래 표는 각 사건을 요약한 것이며, 세부 분석은 이후 소절에서 제공됩니다.

1. CrossCurve 사건

간략한 요약

2026년 2월 2일, CrossCurve 프로토콜이 공격받아 약 $2.8M의 손실이 발생하였습니다. 근본 원인은 ReceiverAxelar 컨트랙트가 권한 없이 누구나 호출 가능한 expressExecute() 함수를 노출하여 표준 Axelar Gateway 검증 프로세스를 우회할 수 있었기 때문입니다. 수신자는 외부에서 제공된 데이터를 기반으로 피어 주소 확인만 수행하였습니다. 그 결과 공격자는 악의적인 크로스체인 호출을 구성하여 소각 및 잠금 해제 메커니즘을 트리거함으로써, 공격자에게 999,787,453e18 EYWA 토큰이 무단으로 방출되었습니다.

배경

CrossCurve는 Eywa.Fi가 개발한 크로스체인 브릿지 프로토콜로, Axelar 크로스체인 메시징 프레임워크 위에 구축되었습니다.

Axelar의 의도된 보안 모델에서 크로스체인 메시지는 Axelar Gateway에 의해 중계되며, 목적지 체인에서 validateContractCall()을 통해 명시적으로 검증되어야 합니다. Gateway에 의해 암호학적으로 승인된 메시지만 실행으로 진행될 수 있습니다.

지연 시간을 줄이기 위해 Axelar는 익스프레스 실행 메커니즘도 제공합니다. 이 메커니즘에서는 수신자 컨트랙트가 Gateway가 검증을 완료하기 전에 낙관적으로 메시지를 실행할 수 있습니다. 이 설계는 신뢰할 수 있는 실행자만이 익스프레스 실행 경로를 호출할 수 있도록 엄격한 접근 제어가 필요합니다. 그렇지 않으면 검증되지 않은 크로스체인 메시지가 조기에 처리될 수 있습니다.

취약점 분석

근본 원인은 ReceiverAxelar가 Axelar Gateway 인가 없이 권한이 부여된 _execute() 경로에 직접 도달할 수 있는 권한 없이 누구나 호출 가능한 expressExecute() 함수를 노출했다는 것입니다.

Axelar의 올바른 보안 모델에서 크로스체인 메시지는 먼저 증명 기반 실행을 통해 Gateway의 승인을 받은 후, validateContractCall()을 통해 목적지 체인에서 검증되어야 합니다. 이는 (commandId, sourceChain, sourceAddress, contractAddress, payloadHash)를 단일 인가된 실행에 바인딩합니다.

그러나 expressExecute() 경로는 이 검증을 완전히 건너뛰었습니다. 이는 공격자가 제어할 수 있는 sourceChain과 sourceAddress만을 이용한 피어 확인에만 의존하였으므로 실질적인 보안을 제공하지 못하였습니다. 이로 인해 공격자는 위조된 메시지를 전달하고, receiveData 분기를 강제 실행하며, 궁극적으로 Eywa CLP Portal의 unlock()을 트리거하는 임의의 페이로드를 실행하여 크로스체인 자산이 무단으로 방출되었습니다.

공격 분석

• 1단계: 공격자는 expressExecute()를 직접 호출하여 sourceChain, sourceAddress, payload를 위조하였습니다. expressExecute()는 Gateway 검증을 우회하고 _execute()로 직접 진행하기 때문에, 남은 유일한 보안 조치는 피어 주소 화이트리스트 확인인 require(peers[sourceChain] == sourceAddress.toAddress())뿐이었습니다. sourceChain과 sourceAddress 모두 외부에서 제공되었기 때문에 이 확인은 불충분하였습니다. 공격자는 올바른 화이트리스트 피어 주소를 제공함으로써 이를 우회하였습니다.

• 2단계: 위조된 payload는 이후 Receiver.receiveData() 분기로 전달되었습니다. resume() 함수는 악의적인 페이로드를 기반으로 크로스체인 작업인 PortalV2.unlock()을 실행하여 공격자에게 자금이 무단으로 잠금 해제되었습니다.

결론

이 사건은 근본적으로 크로스체인 수신자 컨트랙트 내 가속 실행 경로에 대한 불충분한 접근 제어로 인해 발생하였습니다. expressExecute()를 권한 없이 누구나 호출 가능한 함수로 노출하고, 외부에서 제공된 피어 정보에만 의존함으로써 CrossCurve는 사실상 공격자가 Axelar Gateway의 보안 보장을 우회하고 임의의 크로스체인 페이로드를 실행할 수 있도록 허용하였습니다.

향후 유사한 위험을 완화하기 위해, 익스프레스 또는 낙관적 실행 메커니즘을 통합하는 크로스체인 프로토콜은 다음을 수행해야 합니다:

• 신뢰할 수 있는 릴레이어 또는 게이트웨이만이 호출할 수 있도록 빠른 경로 실행 함수에 엄격한 호출자 인증을 적용합니다.

• 인가의 유일한 기준으로 공격자가 제어하는 메타데이터(예: 소스 체인 또는 주소)에 의존하는 것을 피합니다.

• 익스프레스 실행을 권한이 부여된 작업으로 취급하고, 표준 검증 실행 경로와 동등한 심층 방어 검사를 적용합니다.

이러한 원칙을 신중하게 준수하는 것은 단일 검증 우회가 여러 네트워크에 걸쳐 시스템적 자산 손실로 이어질 수 있는 크로스체인 시스템을 설계할 때 매우 중요합니다.

2. GYD 사건

간략한 요약

2026년 2월 3일, GYD 프로토콜이 공격받아 약 $700K의 손실이 발생하였습니다. 근본 원인은 CCIP 수신자가 공격자가 제어하는 메시지 데이터를 실행 컨텍스트로 신뢰하였기 때문입니다. 이 공격은 Arbitrum에서 전송된 CCIP 메시지로 트리거되었으며, 메시징 계층에서는 올바르게 인증되었지만 디코딩된 페이로드가 이후 _ccipReceive()에서 임의의 외부 호출을 수행하는 데 사용되었습니다. 디코딩된 수신자를 GYD 토큰 컨트랙트로 설정하고 approve(attacker, type(uint256).max) calldata를 제공함으로써, 에스크로는 의도치 않게 GYD 잔액에 대한 무제한 허용량을 부여하였습니다. 공격자는 이후 transferFrom()을 통해 자금을 빼냈습니다.

배경

GydL1CCipEscrow 컨트랙트는 Chainlink CCIP 표준을 기반으로 구축된 크로스체인 자산 에스크로 컨트랙트입니다. 사용자는 L1의 이 컨트랙트에 GYD 토큰을 잠금 처리하면, 이후 CCIP를 통해 목적지 체인으로 크로스체인 메시지가 전송됩니다. 반대로, 크로스체인 메시지가 에스크로에 도달하면 CCIP가 진위를 검증하고 _ccipReceive()를 트리거합니다. 이 함수는 수신된 calldata를 파싱하여 tx.recipient와 data를 추출하고, 파싱된 매개변수(금액 및 수신자)를 기반으로 GYD 전송 또는 잠금 해제 로직을 실행하며, data가 비어 있지 않은 경우 recipient.functionCall(data)를 통해 임의의 외부 호출을 수행합니다.

취약점 분석

핵심 취약점은 GydL1CCipEscrow가 크로스체인 메시지에서 디코딩된 tx.recipient 주소를 검증하지 않는다는 것입니다. 공격자는 tx.recipient를 GYD 토큰 컨트랙트 주소로 설정하고 data를 approve(attacker, type(uint256).max)로 구성할 수 있습니다. 에스크로 컨트랙트는 많은 양의 잠금된 GYD 토큰을 보유하고 있기 때문에, 이 무제한 외부 호출로 인해 에스크로가 공격자에게 GYD 토큰의 전체 허용량을 부여하게 되고, 공격자는 transferFrom()을 통해 모든 자금을 빼낼 수 있습니다.

공격 분석

• 1단계: 공격자는 Arbitrum에서 악의적인 CCIP 메시지를 시작하여, Ethereum의 GYD 토큰 컨트랙트 주소를 tx.recipient로, approve(attacker, type(uint256).max)의 인코딩된 calldata를 tx.data로 지정하였습니다.

• 2단계: Ethereum에서 메시지가 처리될 때, GydL1CCipEscrow 컨트랙트의 _ccipReceive() 함수는 tx.recipient를 검증하지 않고 GYD 토큰 컨트랙트에서 승인을 실행하였습니다. 그런 다음 공격자는 GYD 토큰에서 transferFrom()을 호출하여 에스크로된 모든 자금을 빼냈습니다.

결론

이 사건의 근본 원인은 GydL1CCipEscrow 컨트랙트가 크로스체인 메시지를 처리할 때 디코딩된 페이로드를 검증하지 않아 공격자가 악의적인 크로스체인 호출을 구성할 수 있었다는 것입니다. 크로스체인 브릿지 메시징에서 개발자는 다음을 수행해야 합니다:

• 에스크로에서 토큰 컨트랙트로의 직접 호출 금지: 크로스체인 메시지 페이로드가 에스크로된 토큰 컨트랙트에 대한 호출을 트리거할 수 없도록 합니다.

• 실행 대상 화이트리스트 구현: tx.recipient(또는 tx.target)를 잘 정의된 신뢰할 수 있는 주소 집합으로 제한합니다.

3. SOFI 토큰 사건

간략한 요약

2026년 2월 5일, BNB 체인의 SOFI 토큰이 공격받아 약 $29.6K의 손실이 발생하였습니다.

근본 원인은 토큰의 오버라이드된 _transfer() 함수 내에 구현된 결함 있는 소각 메커니즘이었습니다. PancakeSwap 유동성 풀에서 직접 토큰을 제거하고 후속 sync()를 트리거하는 지연된 소각 로직을 악용함으로써, 공격자는 SOFI 가격을 인위적으로 부풀릴 수 있었습니다. 반복적인 전송과 스왑을 통해 공격자는 풀에서 과도한 USDT 유동성을 추출하고 플래시론을 수익과 함께 상환하였습니다.

배경

SOFI는 BNB 체인에 배포된 커스텀 ERC-20 토큰입니다. 표준 ERC-20 구현과 달리, SOFI 토큰은 내부 _transfer() 함수를 오버라이드하여 매도 작업 시 토큰 소각과 관련된 추가 로직을 내장합니다.

이 토큰은 PancakeSwap 스타일의 상수곱 AMM 풀(SOFI–USDT)에서 거래됩니다. 이러한 풀에서 토큰 가격은 토큰 준비금의 비율에서 파생됩니다. 스왑으로 인한 것이 아닌 풀 잔액의 예상치 못한 변화는 가격을 직접 조작할 수 있습니다.

이 설계에서 토큰 컨트랙트 자체가 전송 중에 유동성 풀과 상호작용하므로, 풀의 준비금 계산이 순수한 AMM 메커니즘이 아닌 토큰 측 로직에 의존하게 됩니다.

취약점 분석

취약점은 _transfer() 내부에서 풀 상호작용과 결합된 SOFI의 소각 메커니즘에 있습니다.

SOFI 토큰이 유동성 풀 주소로 전송될 때, 컨트랙트는 이를 매도로 해석하고 내부 누산기 변수 waitBurnTokenAmount를 증가시킵니다. 그러나 누적된 양은 즉시 소각되지 않습니다. 대신, 풀로의 후속 전송 시 풀의 잔액에서 소각된 후 풀의 sync() 함수가 호출됩니다.

이 설계는 두 가지 중요한 문제를 야기합니다:

1. 직접적인 풀 잔액 조작 풀에서 직접 토큰을 소각하면 해당하는 USDT 유출 없이 SOFI 준비금이 감소하여 AMM 불변량을 위반하고 SOFI 가격을 인위적으로 상승시킵니다.

2. 지연되고 공격자가 제어 가능한 실행 소각이 미래의 전송 시에만 발생하기 때문에, 공격자는 소각과 sync()가 발생하는 시점을 정밀하게 제어하여 가격 왜곡으로부터 이익을 얻을 수 있습니다.

결과적으로 풀 가격은 더 이상 진정한 수요-공급 역학을 반영하지 않게 되어 추출 가능한 차익 거래가 가능해집니다.

공격 분석

• 1단계: 플래시론을 통해 USDT를 빌립니다.

• 2단계: SOFI–USDT 풀에서 USDT를 SOFI로 스왑합니다.

• 3단계: SOFI를 풀에 전송하고 skim()을 호출하여 최소한의 손실로 waitBurnTokenAmount를 증가시킵니다.

• 4단계: SOFI를 다시 풀에 전송하여 소각 + sync()를 트리거하고 SOFI 가격을 올린 후 SOFI를 USDT로 스왑합니다.

• 5단계: 4단계를 반복합니다. 새로 누적된 waitBurnTokenAmount는 다음 전송 시에만 소각되므로 여러 번의 반복이 필요합니다.

• 6단계: 풀에서 USDT를 빼낸 후 플래시론을 상환합니다.

결론

이 사건은 궁극적으로 AMM 풀 잔액을 직접 조작하는 안전하지 않은 토큰 측 소각 메커니즘으로 인해 발생하였습니다. _transfer() 내부에 지연된 소각 로직을 내장하고 유동성 풀 자체에서 소각을 실행함으로써, SOFI 토큰은 상수곱 AMM의 근본적인 가정을 깨뜨리고 결정론적인 가격 조작을 가능하게 하였습니다.

_transfer()를 오버라이드하는 ERC-20 토큰의 경우, 개발자는 다음을 피하도록 특별히 주의해야 합니다:

• 유동성 풀에서 직접 토큰 소각

• 풀 준비금에 영향을 미치는 지연되거나 상태를 가진 메커니즘 도입

• AMM 내부와의 토큰 로직 과도한 결합

일반적으로 토큰노믹스 관련 로직이 임의로 풀 잔액을 변경할 수 없도록 해야 합니다. 작은 편차도 반복적으로 악용되어 유동성을 고갈시킬 수 있기 때문입니다.

4. 미상 스테이킹 프로토콜 사건 (2026년 2월 5일)

간략한 요약

2026년 2월 5일, Ethereum의 미상 스테이킹 프로토콜이 공격받아 약 $71.6K의 손실이 발생하였습니다.

근본 원인은 출금 시 프로토콜이 검증되지 않은 사용자 제공 입력 데이터에 의존하였기 때문입니다. 구체적으로, 프로토콜은 검증 없이 공격자가 제어하는 routerCalldata와 LP 양을 Pendle Router에 전달하였습니다. 프로토콜의 전체 LP 포지션을 제거하고 자신을 수신자로 설정하는 calldata를 구성함으로써, 공격자는 볼트가 보유한 모든 자산을 빼낼 수 있었습니다.

배경

미상 스테이킹 프로토콜은 Pendle Finance 위에 구축된 단순한 수익 볼트입니다. 사용자는 볼트에 자산을 예치하고, 볼트는 Pendle Router를 통해 해당 자산을 라우팅하여 수익 창출 포지션을 발행합니다. 내부적으로 예치금은 SY로 변환되고, PT와 YT로 분리된 후 Pendle LP 토큰을 형성하기 위해 결합됩니다.

프로토콜은 모든 LP 토큰을 보관하고 각 사용자의 예치된 기초 자산량에 대한 내부 계정을 유지합니다. 사용자가 출금할 때, 볼트는 Pendle Router를 통해 LP 토큰을 환매하고 해당 자산을 사용자에게 반환합니다.

취약점 분석

근본 원인은 검증되지 않은 입력 데이터입니다. withdrawWithCalldataMultiToken() 함수는 기초 토큰, 기초 자산 양, LP 양, routerCalldata의 네 가지 매개변수를 받습니다. 이 함수는 사용자의 기록된 기초 자산 잔액이 충분한지만 확인하고, LP 양이나 routerCalldata의 내용은 검증하지 않습니다. Pendle Router를 통해 유동성을 제거할 때, 컨트랙트는 routerCalldata에 내장된 매개변수에 완전히 의존합니다. 결과적으로 공격자는 프로토콜의 전체 LP 잔액을 전달하고 자신을 수신자로 설정하여 프로토콜이 보유한 모든 자산을 빼낼 수 있었습니다.

공격 분석

• 1단계: USDC 플래시론을 빌립니다.

• 2단계: 소량의 USDC를 프로토콜에 예치합니다. 프로토콜은 Pendle Router를 통해 자금을 라우팅하여 유동성을 추가하고 LP를 발행합니다.

• 3단계: receiver를 공격자로, lpAmount를 프로토콜의 전체 LP 잔액으로 설정하는 구성된 routerCalldata와 함께 withdrawWithCalldataMultiToken()을 호출합니다.

• 4단계: 프로토콜은 공격자가 제어하는 매개변수를 사용하여 Pendle Router를 통해 유동성을 제거하고 모든 자산을 공격자에게 전송합니다.

• 5단계: 받은 자산을 USDC로 스왑하고, 플래시론을 상환한 후 나머지를 수익으로 보유합니다.

결론

이 사건은 궁극적으로 중요한 출금 경로 내에서 공격자가 제어하는 외부 입력에 대한 맹목적인 신뢰로 인해 발생하였습니다. 검증 없이 임의의 calldata와 LP 양을 외부 라우터에 전달함으로써, 프로토콜은 사용자가 자신의 권리 있는 몫을 훨씬 초과하는 출금을 실행할 수 있도록 허용하여 볼트의 Pendle 포지션이 완전히 고갈되었습니다.

복잡한 외부 라우터를 통합하는 프로덕션 볼트 및 수익 전략의 경우, 개발자는 다음을 수행해야 합니다:

• calldata를 포함한 모든 사용자 제공 입력을 신뢰할 수 없는 것으로 취급하고 엄격하게 검증합니다.

• 민감한 매개변수(예: LP 양 및 수신자)를 사용자로부터 받는 것이 아닌 내부적으로 도출합니다.

• 내부 계정과 외부 실행 결과 간의 일관성을 강제하여 심층 방어를 적용합니다.

이를 이행하지 않으면 단일 출금 호출로도 프로토콜이 보유한 모든 자산이 손상될 수 있습니다.

5. LZMultiCall 프로토콜 사건

간략한 요약

2026년 2월 7일, LZMultiCall 사건으로 Ethereum에서 약 $142K의 손실이 발생하였습니다.

이 사건은 LZMultiCall 컨트랙트 자체의 취약점으로 인한 것이 아니라 사용자의 잘못된 사용으로 인한 것입니다. LZMultiCall은 자산을 보관하거나 ERC-20 허용량을 보유하도록 설계되지 않은 상태 없는 배치 실행 컨트랙트입니다. 그러나 일부 사용자가 실수로 컨트랙트에 토큰 허용량을 승인하였습니다. 공격자는 이후 이러한 남아있는 승인을 악용하여 execute()를 구성된 calldata로 호출해 transferFrom()을 실행함으로써, 피해를 입은 사용자들로부터 토큰을 빼냈습니다.

배경

LZMultiCall은 범용 배치 실행 유틸리티 컨트랙트입니다. 의도된 목적은 사용자가 여러 호출을 단일 트랜잭션으로 묶어 사용자 제공 calldata를 대상 컨트랙트에 전달할 수 있도록 하는 것입니다.

중요하게도, LZMultiCall은 상태 없는 비수탁형으로 설계되었습니다. 자산을 보유하거나 사용자가 ERC-20 허용량을 부여해서는 안 됩니다. LZMultiCall에 부여된 토큰 승인은 명시적인 사용 가정을 위반하며 사용자를 위험에 노출시킵니다. 컨트랙트가 호출자를 대신하여 임의의 호출을 전달할 수 있기 때문입니다.

취약점 분석

LZMultiCall은 설계대로 작동하였지만, 사용자가 실수로 ERC-20 허용량을 부여하면 권한 없이 누구나 호출 가능한 execute() 함수가 악용 가능해집니다. 컨트랙트가 임의의 calldata를 어느 대상에나 전달하기 때문에, 공격자는 토큰 컨트랙트에서 transferFrom(victim, attacker, amount)를 인코딩하는 calldata와 함께 execute()를 호출하여 미결 허용량을 효과적으로 빼낼 수 있었습니다.

공격 분석

• 공격자는 토큰 컨트랙트를 대상으로 하는 구성된 calldata와 함께 execute()를 호출하여, LZMultiCall에 실수로 허용량을 승인한 사용자들로부터 transferFrom()을 사용하여 토큰을 전송하였습니다.

결론

이 사건은 궁극적으로 상태 없는 배치 실행 컨트랙트의 명시적인 사용 가정을 위반함으로써 발생하였습니다. LZMultiCall은 자금을 보관하거나 ERC-20 허용량을 보유하도록 의도된 것이 아니었습니다. 사용자가 실수로 승인을 부여하면, 컨트랙트의 권한 없이 누구나 실행 가능한 모델로 인해 어느 호출자든 임의로 전달된 호출을 통해 해당 허용량을 빼낼 수 있습니다.

배치 실행 또는 멀티콜 스타일 컨트랙트와 상호작용하는 사용자 및 통합자의 경우:

• 자산을 보관하도록 명시적으로 설계되지 않은 컨트랙트에는 ERC-20 허용량을 부여하지 마십시오.

• 범용 호출 전달 컨트랙트를 신뢰할 수 없는 실행 표면으로 취급하십시오.

• 가능한 경우 트랜잭션별 승인 또는 허용량이 필요 없는 설계(예: permit)를 선호하십시오.

프로토콜 취약점이 없더라도, 컨트랙트의 신뢰 모델을 오해하면 상당하고 되돌릴 수 없는 손실이 발생할 수 있습니다.

6. 미상 프로토콜 사건 (2026년 2월 8일)

간략한 요약

2026년 2월 8일, Ethereum의 미상 프로토콜이 공격받아 약 $63K의 손실이 발생하였습니다.

근본 원인은 Gnosis Safe 모듈 실행 경로에서 공격자가 제어하는 입력 데이터가 검증되지 않았기 때문입니다. SafeModule로 등록된 유틸리티 컨트랙트(0xF5E4)가 플래시론 콜백을 노출하였는데, 이 콜백은 임의의 사용자 제공 데이터를 디코딩하여 GnosisSafe.execTransactionFromModule()을 직접 호출하였습니다. 모듈에서 발생한 호출은 설계상 서명 검증을 우회하기 때문에, 공격자는 임의의 Safe 인가 트랜잭션을 실행하고, Safe의 Aave V3 부채를 상환하며, 모든 담보물을 공격자가 제어하는 주소로 출금할 수 있었습니다.

배경

이 프로토콜 아키텍처는 Aave V3에서 레버리지 포지션을 관리하는 Gnosis Safe를 중심으로 구성되어 있습니다. Gnosis Safe는 모듈식 실행 모델을 지원하며, 지정된 SafeModules는 소유자 서명 없이 Safe를 대신하여 트랜잭션을 실행할 수 있습니다. 이 설계는 자동화, 통합 및 고급 전략을 지원하기 위한 것입니다.

이 설정에서 컨트랙트 0xF5E4는 Gnosis Safe의 SafeModule로 구성되었습니다. 이 컨트랙트는 플래시론 기반 포지션 관리를 지원하기 위해 설계된 헬퍼 유틸리티로 보입니다. 플래시론 콜백인 receiveFlashLoan()을 구현하며, 이는 플래시론 실행 중 외부 유동성 제공자에 의해 호출됩니다.

모듈 호출은 서명 검증을 우회하기 때문에, 모듈 로직의 정확성과 안전성이 매우 중요합니다. 어떠한 결함도 Safe에 대한 무제한 제어권을 효과적으로 부여합니다.

취약점 분석

SafeModule 0xF5E4는 외부에서 제공된 userData를 디코딩하고 이를 직접 GnosisSafe.execTransactionFromModule() 호출에 사용하는 플래시론 콜백 receiveFlashLoan()을 노출합니다. 0xF5E4는 SafeModule로 등록되어 있기 때문에 이를 통해 발생하는 호출은 서명 검증을 우회합니다. 그러나 receiveFlashLoan()은 호출자를 인증하거나 디코딩된 매개변수(예: 대상 주소, 값, calldata, 또는 작업 유형)를 검증하지 않습니다. 결과적으로 공격자는 구성된 userData를 제공하여 모듈이 Safe를 통해 임의의 트랜잭션을 실행하도록 만들 수 있으며, 이를 통해 Safe의 Aave V3 부채를 상환하고, 모든 담보물을 출금하며, 포지션을 수익으로 고갈시킬 수 있습니다.

공격 분석

• 1단계: 공격자는 Uniswap V4를 통해 플래시론을 빌려 GnosisSafe로 자금을 전송하였습니다.

• 2단계: 공격자는 구성된 userData와 함께 Balancer의 flashLoan()을 호출하였습니다. 실제 자산은 빌리지 않고, recipient를 0xF5E4로 설정하였습니다.

• 3단계: 0xF5E4.receiveFlashLoan()에서 컨트랙트는 공격자가 제공한 userData를 디코딩하였습니다. 0xF5E4는 Safe 모듈로 등록되어 있기 때문에 서명 확인을 우회하고, userData에 내장된 매개변수에 따라 임의의 호출을 실행하기 위해 execTransactionFromModule()을 호출하였습니다.

• 4단계: 이 기능을 사용하여 공격자는 Aave V3에서 GnosisSafe의 부채를 상환하고 모든 담보물을 출금하여 수익을 실현하였습니다.

결론

이 사건은 궁극적으로 모듈 기반 실행의 안전하지 않은 사용과 검증되지 않은 외부 입력의 결합으로 인해 발생하였습니다. 임의의 공격자 제공 userData를 execTransactionFromModule()에 전달함으로써, SafeModule 0xF5E4는 Gnosis Safe에 대한 무제한 제어를 효과적으로 노출하였습니다. Safe 모듈이 설계상 서명 확인을 우회하기 때문에 이 결함은 Safe의 Aave V3 포지션을 완전히 손상시킬 수 있었습니다.

Gnosis Safe 모듈 또는 유사한 권한이 부여된 실행 프레임워크에 의존하는 시스템의 경우, 개발자는 다음을 수행해야 합니다:

• 플래시론 userData를 포함한 모든 외부 입력을 신뢰할 수 없는 것으로 취급하고 엄격하게 검증합니다.

• 모듈 실행을 잘 정의된 일련의 작업, 대상 및 선택자로 제한합니다.

• 권한이 부여된 실행 함수에 임의의 calldata를 전달하는 범용 "유틸리티" 모듈을 피합니다.

이러한 안전 장치를 적용하지 않으면 단일 헬퍼 컨트랙트가 완전한 관리자 백도어로 변할 수 있습니다.

BlockSec 소개

BlockSec은 풀스택 블록체인 보안 및 암호화폐 컴플라이언스 제공업체입니다. 저희는 고객이 코드 감사(스마트 컨트랙트, 블록체인 및 지갑 포함), 실시간 공격 차단, 사건 분석, 불법 자금 추적 및 AML/CFT 의무 준수를 프로토콜과 플랫폼의 전체 생애주기에 걸쳐 수행할 수 있도록 돕는 제품과 서비스를 구축합니다.

BlockSec은 저명한 학술 컨퍼런스에서 다수의 블록체인 보안 논문을 발표하고, 여러 DeFi 애플리케이션의 제로데이 공격을 보고하였으며, 2,000만 달러 이상을 구제하기 위해 다수의 해킹을 차단하고 수십억 달러의 암호화폐를 보호하였습니다.

• 공식 웹사이트: https://blocksec.com/

• 공식 트위터 계정: https://twitter.com/BlockSecTeam

• 🔗 BlockSec 감사 서비스 : 요청 제출하기

• 🔗 Phalcon 보안 앱: 데모 예약하기

• 🔗 Phalcon 컴플라이언스