~$1590만 달러 손실: 신뢰받던 볼륨, 와사비 등 | BlockSec 주간 뉴스

지난 2주간(2026/04/27 - 2026/05/10), BlockSec는 여러 블록체인 생태계에 걸쳐 다수의 공격 사건을 식별했습니다. 아래 표는 총 약 $15.9M의 피해가 발생한 11건의 주요 사건을 나열합니다.

공격의 참신성, 재정적 영향 및 보안적 시사점을 기준으로 세 가지 사건을 심층 분석 대상으로 선정했습니다:

• Aftermath Finance: 퍼페추얼 DEX에서 발생한 실제 익스플로잇으로, 수수료 검증 로직의 미묘한 부호 있는/부호 없는 의미론적 불일치가 프로토콜 자금의 완전한 유출로 이어졌습니다.
• Trusted Volumes: 큰 재정적 피해(~$5.87M)와 RFQ 정산 로직에서의 권한 불일치를 명확히 보여주는 사례입니다.
• Wasabi Protocol: 인프라에서 컨트랙트 제어권까지 이어진 침해 사례로, 점점 더 흔해지고 있지만 감사 범위에서는 충분히 다뤄지지 않는 공격 유형입니다.

주간 하이라이트: Aftermath Finance

이 사건이 주목받는 이유는 부호 있는/부호 없는 의미론적 불일치가 단일 프로토콜을 넘어 광범위하게 적용되는 미묘한 취약점 유형이기 때문입니다. 부호 없는 수수료 또는 가격 값을 검증하기 위해 부호 있는 고정소수점 라이브러리를 사용하는 모든 DeFi 프로토콜은 동일한 공격 패턴에 취약하므로, 이 익스플로잇은 개발자와 감사자 모두에게 폭넓은 교훈을 제공합니다.

2026년 4월 29일, Sui 기반의 온체인 퍼페추얼 선물 거래소인 Aftermath Perpetuals가 약 $1.14M USDC 규모의 익스플로잇 피해를 입었습니다 [1]. 근본 원인은 프로토콜의 빌더 수수료 검증 로직에서 발생한 부호 있는/부호 없는 의미론적 불일치였습니다. 수수료 비교 함수가 부호 없는 값에 대해 부호 있는 산술 연산을 수행하여, 공격자가 부호 있는 해석 하에 음수로 보이는 수수료 값을 제출할 수 있었습니다. 정산 과정에서 음수 수수료는 양수 담보 크레딧으로 변환되어, 공격자가 프로토콜 볼트에서 부풀려진 자금을 인출할 수 있게 되었습니다.

배경

Aftermath Perpetuals는 Sui 기반의 온체인 퍼페추얼 선물 거래소입니다 [2]. 이 프로토콜은 외부 통합자(integrator)가 프론트엔드 인터페이스를 구축하여 거래 수수료를 수익으로 얻을 수 있도록 허용합니다. 각 통합자는 자신의 인터페이스를 사용하는 트레이더에게 부과되는 수수료율(taker_fee)을 설정합니다 [3]. 안전장치로서, 트레이더는 통합자가 청구할 수 있는 최대 수수료를 제한하는 사전 설정 수수료 상한(maxTakerFee)을 구성하여 통합자를 승인할 수 있습니다.

시장가 주문을 실행할 때, 프로토콜은 먼저 taker_fee와 maxTakerFee를 비교하여 수수료가 트레이더가 승인한 범위 내에 있는지 확인한 후, 계산된 수수료를 테이커의 담보에서 차감하고 통합자의 기록에 적립합니다.

프로토콜의 산술 연산은 부호 있는 고정소수점 라이브러리(ifixed)를 기반으로 구축되어 있으며, 이 라이브러리는 값을 u256 정수로 표현하지만 비교 및 산술 연산 시 2의 보수(two's-complement) 의미론으로 해석합니다.

취약점 분석

버그가 있는 컨트랙트는 인터페이스 모듈(0x9e2080...25d136)과 클리어링 하우스 모듈(0x21d001...7c5068)입니다.

취약점은 calculate_taker_fees() 함수에 있으며, 이 함수는 ifixed::less_than_eq()를 사용하여 통합자의 taker_fee를 트레이더의 maxTakerFee와 비교합니다:

assert!(
    ifixed::less_than_eq(
        v5.taker_fee,
        account::get_integrator_max_taker_fee(
            account::get_integrator_config(arg1, v5.integrator_address)
        )
    ),
    errors::invalid_integrator_taker_fee()
);

taker_fee와 maxTakerFee는 의미론적으로 음수가 될 수 없는 수수료율입니다. 그러나 ifixed::less_than_eq()는 u256에 대해 부호 있는 비교를 수행합니다. maxTakerFee가 0으로 설정된 경우, 2^256 - 10^16과 같은 값은 부호 있는 의미론 하에 -10^16으로 해석됩니다. -10^16 <= 0이 성립하므로 검사를 통과하게 됩니다.

또한 create_integrator_info()가 공개적으로 호출 가능하며 제공된 taker_fee에 대한 권한 또는 수수료 범위 검증을 강제하지 않기 때문에 익스플로잇 경로가 더욱 노출됩니다:

public fun create_integrator_info(arg0: address, arg1: u256): Option<IntegratorInfo> {
    let v0 = IntegratorInfo {
        integrator_address : arg0,
        taker_fee          : arg1,
    };
    option::some<IntegratorInfo>(v0)
}

음수 수수료는 단순히 허용되는 것에 그치지 않고, 정산 과정에서 직접적인 양수 담보 크레딧으로 변환됩니다. 정산 경로에서 담보는 collateral += pnl - taker_fee - builder_fee로 갱신됩니다. builder_fee가 음수이면 이를 빼는 것이 더하기가 됩니다:

position::add_to_collateral_usd(
    arg0,
    ifixed::sub(v6, ifixed::add(v7, v8)),
    arg2
);

수수료 검증과 정산 산술 연산 모두 수수료 값이 음수가 아니어야 한다는 것을 강제하지 않으므로, 두 가지 누락된 검사가 복합적으로 작용합니다. 부호 있는 비교가 음수 값을 허용하고, 부호 있는 산술 연산이 이를 담보 크레딧으로 변환합니다.

공격 분석

다음 분석은 트랜잭션 4pGQdf...wVD8을 기반으로 합니다.

• 1단계: 공격자는 100e6 USDC를 두 개의 새로운 퍼페추얼 계정 1227과 1228로 분할했습니다. 이를 통해 공격자가 메이커(계정 1227)와 테이커(계정 1228) 양쪽으로 활동할 수 있는 독립된 컨텍스트를 생성했습니다.

• 2단계: 공격자는 계정 1227에 100e6 USDC를 담보로 예치하고 시장가 포지션을 개설하여, 이후 테이커 주문의 카운터파티를 확보했습니다.

• 3단계: 공격자는 통합자 볼트를 생성한 후, 계정 1228에 maxTakerFee = 0인 설정을 추가했습니다. 상한을 0으로 설정하는 것이 핵심이었습니다. 이를 통해 부호 있는 비교 taker_fee <= 0이 2의 보수 하에 음수로 보이는 모든 값을 허용하게 되었습니다.

• 4단계: 공격자는 계정 1227에서 세션을 시작하고 order_size = 100e6인 지정가 주문을 제출하여, 계정 1228이 거래할 유동성을 공급했습니다.

• 5단계: 공격자는 taker_fee = 2^256 - 100e6으로 create_integrator_info()를 호출했습니다. 이 값은 부호 있는 ifixed 의미론 하에 -100e6을 나타냅니다. 이 함수는 공개적이고 검증을 수행하지 않으므로 호출이 성공했습니다.

• 6단계: 공격자는 악의적인 통합자 정보를 사용하여 계정 1228에서 시장가 주문을 실행했습니다. 부호 있는 수수료 비교가 통과되었고(-100e6 <= 0), 정산 과정에서 음수 수수료가 담보에서 차감되어 실질적으로 계정 1228에 100e6의 무료 담보가 추가되었습니다.

• 7단계: 공격자는 계정 1228에서 부풀려진 담보를 할당 해제하고 인출하여 79,610 USDC를 획득했습니다. 공격자는 여러 트랜잭션에 걸쳐 이 패턴을 반복하여 총 약 $1.14M을 축적했습니다.

결론

이 사건은 Aftermath Perpetuals의 빌더 수수료 검증 로직에서 발생한 부호 있는/부호 없는 의미론적 불일치로 인해 발생했습니다. 핵심 문제는 수수료 비교 함수(ifixed::less_than_eq)가 부호 없는 수수료 값을 부호 있는 의미론으로 해석한다는 점입니다. 경계 검증을 수행하지 않는 공개적으로 호출 가능한 수수료 설정 함수와 결합되어, 공격자는 부호 있는 비교에서 "음수"로 통과하고 정산 시 양수 담보로 변환되는 값을 주입할 수 있었습니다.

더 광범위한 패턴에 주목할 필요가 있습니다. 본질적으로 음수가 될 수 없는 값(수수료, 가격, 수량)을 검증하기 위해 부호 있는 고정소수점 라이브러리를 사용하는 모든 프로토콜은 동일한 유형의 공격에 취약합니다. 완화 방법으로는 다음을 포함해야 합니다: (1) 비교 전에 수수료 값이 음수가 아님을 강제하기(assert!(taker_fee >= 0)), (2) create_integrator_info()를 권한 있는 호출자만 사용하도록 제한하기, (3) 의미론적으로 부호 없는 값에 대해 부호 없는 비교 함수 사용하기.

참고 자료

• [1] Aftermath Finance 사후 성명
• [2] Aftermath Perpetuals 문서
• [3] 빌더 코드 / 프론트엔드 수수료

이번 기간 추가 사건

Trusted Volumes

2026년 5월 7일, 이더리움 상의 커스텀 RFQ(Request-For-Quote) 프록시 컨트랙트가 익스플로잇되어 마켓 메이커 TrustedVolumes로부터 약 $5.87M이 유출되었습니다. 근본 원인은 RFQ 구현 컨트랙트의 주문 체결 함수에서 발생한 권한 불일치였습니다. 서명자 권한 조회와 토큰 전송 작업이 주문의 서로 다른 필드를 참조하여, 권한 검사는 한 주소에 대해 통과되었지만 자금은 다른 주소에서 인출되었습니다. 공격자는 약 1,291 WETH, 206K USDT, 16.94 WBTC, 1.27M USDC를 탈취했습니다.

배경

TrustedVolumes는 이더리움에 배포된 RFQ 프로토콜에서 마켓 메이커로 운영됩니다. 마켓 메이커는 오프체인에서 서명된 가격 견적을 지속적으로 생성하고, 테이커(일반적으로 트레이더 또는 어그리게이터 라우터)는 온체인에서 선택한 견적을 제출하며, 프로토콜 컨트랙트는 서명을 검증하고 transferFrom을 통해 메이커와 테이커 사이에 토큰을 이동시켜 원자적으로 거래를 정산합니다. 이 프로토콜은 볼트 없는 설계를 따릅니다. 자금을 직접 보관하지 않으며, 각 메이커는 견적을 제공할 모든 토큰에 대해 프로토콜 컨트랙트에 ERC-20 허용량을 사전에 부여하고, 프로토콜은 체결 시 메이커의 지갑에서 직접 토큰을 인출합니다.

메이커가 서명 작업을 핫 월렛에 위임할 수 있도록, 프로토콜 컨트랙트는 메이커별 서명자 레지스트리를 유지합니다. 메이커는 registerAllowedOrderSigner(signer, allowed)를 호출하여 핫 키를 화이트리스트에 등록할 수 있으며, 해당 키로 서명된 이후 주문은 메이커가 직접 서명한 것으로 처리됩니다.

취약점 분석

RFQ 프록시 컨트랙트는 0xeEeEEe...051756에 배포되어 있으며, 구현 컨트랙트는 0x88eb28...2760d8에 있습니다.

RFQ 구현 컨트랙트의 주문 체결 함수 0x4112e1c2()는 ecrecover()를 통해 서명자를 복구하고 allowedOrderSigner 매핑을 확인하여 서명 수락 여부를 결정합니다. 이 검사의 조회 키는 주문의 테이커 측 주소인 varg4입니다. 그러나 자금을 인출하는 이후 transferFrom은 주문의 메이커 필드인 varg5를 사용합니다. varg4와 varg5는 주문 구조체의 독립적인 필드이므로, 권한 검사와 자금 흐름 작업이 서로 다른 주체를 참조합니다. 권한 있는 서명자 도메인이 실제로 토큰이 인출되는 주소와 일치하는지 확인하는 검사가 없습니다.

registerAllowedOrderSigner 함수는 외부 키로 msg.sender를 사용하여 화이트리스트를 기록하는 반면, 체결 경로는 외부 키로 varg4를 사용하여 읽습니다. varg4의 호출자가 이전에 registerAllowedOrderSigner를 통해 자신을 등록한 경우, varg5에 어떤 서드파티 메이커 주소가 있든 상관없이 권한 검사가 통과됩니다.

공격 분석

다음 분석은 트랜잭션 0xc5c61b...990513을 기반으로 합니다.

• 1단계: 공격자는 공격 컨트랙트를 배포하고 이를 통해 registerAllowedOrderSigner를 호출하여 공격자 EOA를 허용된 서명자 화이트리스트에 등록했습니다. 이를 통해 공격자가 서명한 주문이 프로토콜의 서명자 권한 검사를 통과할 수 있었습니다.

• 2단계: 공격 컨트랙트는 공격자 EOA로부터 4 wei의 USDC를 인출하고 RFQ 프로토콜에 4 wei를 승인하여, 테이커로 활동하기 위한 최소한의 대가를 공격 컨트랙트에 장착했습니다.

• 3단계: 공격자는 공격자 EOA가 서명하고 TrustedVolumes를 메이커로 지정한 네 개의 위조 주문을 생성했습니다. 서명자 검사가 varg4(공격자의 컨트랙트)를 조회하는 반면 transferFrom은 varg5(TrustedVolumes)에서 자금을 인출했기 때문에, 각 주문은 TrustedVolumes로부터 자금을 탈취했습니다. 네 개의 주문은 각각 1 wei의 USDC를 1,291 WETH, 206,282 USDT, 16.939 WBTC, 1,268,771 USDC와 교환하여 총 약 $5.87M의 이익을 얻었습니다.

결론

핵심 결함은 주문 체결 함수에서의 권한 불일치입니다. 서명자 권한 검사에 사용되는 주소와 실제로 지불하는 주소가 다릅니다. 구체적으로, registerAllowedOrderSigner는 msg.sender를 키로 화이트리스트를 기록하고, 체결 경로는 테이커 필드(varg4)를 키로 읽으며, transferFrom은 메이커 필드(varg5)에서 인출합니다. 이 세 가지 작업이 서로 다른 주체를 참조하므로, 자신의 서명자를 등록한 공격자는 서드파티 메이커의 자금을 탈취하는 주문을 위조할 수 있습니다. 자산 이동을 통제하는 권한 검사는 실제로 지불할 주소를 키로 사용해야 하며, 쓰기 경로와 읽기 경로는 동일한 키를 사용해야 합니다.

Wasabi Protocol

2026년 4월 30일, 여러 EVM 체인에 배포된 옵션 및 퍼페추얼 선물 프로토콜인 Wasabi Protocol이 약 $5.7M($4.8M 사용자 자금, $900K Wasabi 트레저리)의 피해를 입는 보안 사건이 발생했습니다 [1][2]. 공격은 인프라 침해에서 비롯되었습니다. 공개 서버의 노출된 분석 엔드포인트에서 자격 증명이 유출되었고, 이로 인해 결국 프로토콜의 EVM 스마트 컨트랙트를 제어하는 개인 키가 탈취되었습니다. 공격자는 해당 키를 이용하여 이더리움, Base, Blast, Berachain에 걸친 여러 Wasabi 볼트에서 무단 인출을 실행했습니다.

배경

Wasabi Protocol은 EVM 체인(이더리움, Base, Blast, Berachain)과 솔라나에 배포되어 운영됩니다. 이번 사건은 프로토콜의 EVM 측에 국한되었으며, 솔라나 배포본과 Prop AMM은 영향을 받지 않았습니다.

Wasabi의 EVM 컨트랙트(WasabiLongPool, WasabiShortPool, WasabiVault)는 권한 있는 키를 통해 관리됩니다. 프로토콜은 또한 Spring Boot 기반으로 구축된 분석 및 모니터링 서비스를 포함한 오프체인 인프라를 운영합니다.

공격 분석

이번 사건은 인프라에서 컨트랙트 제어권까지 이어지는 침해 연쇄 과정을 따랐습니다:

• 1단계: 공격자는 공개용 Wasabi 서버에 Spring Boot Actuator가 설치되어 있음을 발견했습니다. Actuator 힙 덤프는 일반적으로 비밀번호로 보호되지만, 이 서버는 표준 비밀번호 보호 메커니즘과 호환되지 않는 다른 Spring 프레임워크 변형을 사용하고 있어 힙 덤프 엔드포인트가 노출된 상태였습니다.

• 2단계: 공격자는 힙 덤프를 획득했으며, 여기에는 별도의 내부 서버에 대한 자격 증명이 포함되어 있었습니다.

• 3단계: 유출된 자격 증명을 이용하여 공격자는 내부 서버로 이동하고 Wasabi의 EVM 스마트 컨트랙트를 제어하는 개인 키를 획득했습니다.

• 4단계: 권한 있는 키를 손에 넣은 공격자는 이더리움, Base, Blast, Berachain에 걸친 WasabiLongPool, WasabiShortPool, WasabiVault 컨트랙트에 대해 무단 인출 흐름을 실행하여 총 약 $5.7M을 탈취했습니다.

결론

이번 사건은 스마트 컨트랙트 보안이 코드 수준에서 끝나지 않는다는 것을 보여줍니다. 이 익스플로잇은 온체인 취약점이 전혀 필요하지 않았으며, 공격자는 순전히 인프라 노출을 통해 제어권을 획득했습니다. 핵심 교훈은 다음과 같습니다: (1) 디버깅 및 분석 인터페이스(힙 덤프, 프로파일링 엔드포인트, 로그 익스포터)는 공개 인프라에서 절대 접근 가능해서는 안 됩니다. (2) 프로덕션 시스템의 자격 증명은 분석 및 모니터링 환경과 엄격하게 분리되어야 합니다. (3) 스마트 컨트랙트 관리 키는 멀티시그 보관, 하드웨어 기반 서명, 역할 분리, 실시간 모니터링, 긴급 일시정지 절차 등 심층 방어 제어로 보호되어야 합니다.

참고 자료

• [1] BlockSec Phalcon 알림
• [2] Wasabi Protocol 사후 성명

BlockSec 소개

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

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

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

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

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

• 🔗 Phalcon Security APP: 데모 예약

• 🔗 Phalcon Compliance