~$1억 460만 달러 손실: Verus, RetoSwap 외 다수

지난 한 주(2026/05/18 - 2026/05/24) 동안 BlockSec은 여러 블록체인 생태계에서 다수의 공격 사건을 식별했습니다. 아래 표는 총 예상 손실액이 약 $104.6M에 달하는 5건의 주요 사건을 정리한 것입니다.

날짜	사건	유형	예상 손실
2026/05/18	Verus 사건	비즈니스 로직 결함	~$11.7M
2026/05/18	EchoProtocol 사건	개인 키 탈취	~$76.7M
2026/05/20	RetoSwap 사건	비즈니스 로직 결함	~$2.7M
2026/05/22	Polymarket 사건	개인 키 탈취	~$700K
2026/05/24	StablR 사건	개인 키 탈취	~$12.8M

두 건의 사건이 심층 분석을 위해 선정되었습니다:

Verus: 공격자는 Verus-Ethereum 브리지의 유형 검증 실패를 악용하여, 브리지가 유효한 기본 익스포트로 잘못 분류한 조작된 보조 익스포트 출력값을 제출했습니다. 크로스체인 메시지 시맨틱은 공격 표면의 일부입니다.
RetoSwap: P2P 거래 흐름의 프로토콜 수준 인증 결함으로 인해 공격자가 위조된 ACK 메시지를 전송하여 중재자 역할을 탈취할 수 있었습니다. 공격자는 완전히 오프체인에서 멀티시그 지갑 생성을 장악했습니다.

주간 하이라이트: Verus

이 사건이 하이라이트로 선정된 이유는 공격자가 특수한 크로스체인 익스포트 유형을 의도적으로 악용했으며, 이는 Verus 체인의 내부 설계에 대한 깊은 이해를 보여주기 때문입니다. 이번 익스플로잇은 보조 데이터 필드와 인코딩 경계를 포함한 크로스체인 메시지 형식이 공격 표면의 일부이며, 암호학적 증명 검증과 동일한 수준의 엄격함이 요구됨을 보여줍니다.

2026년 5월 18일, Verus L1 체인과 이더리움을 연결하는 크로스체인 브리지인 Verus-Ethereum 브리지가 약 $11.7M의 ETH, tBTC, USDC 피해를 입었습니다 [1][2]. 근본 원인은 이더리움 측 임포트 경로의 유형 검증 실패였습니다. 브리지 컨트랙트가 조작된 보조 익스포트 출력값을 수락하고 이를 유효한 기본 익스포트로 잘못 분류함으로써, 공격자가 일치하는 전송 데이터를 제공하고 자금을 탈취할 수 있었습니다. 5월 23일 기준으로 도난 자금의 약 75%가 반환되었습니다.

배경

Verus-Ethereum 브리지는 누군가가 공증된 Verus 상태 하에 적합한 Verus 측 익스포트가 존재함을 증명한 후 이더리움에서 자산을 해제합니다. 이더리움은 Verus 트랜잭션을 직접 관찰하지 않으며, 제출된 증명 데이터와 신뢰할 수 있는 Verus 상태를 고정하는 공증에 의존합니다.

이번 사건과 관련된 세 가지 브리지 객체가 있습니다: 기본 익스포트는 이더리움이 임포트하여 지불에 사용하는 객체이고, 보조 익스포트 출력값은 기본 익스포트에 첨부된 추가 데이터로 지불 목적의 독립적인 활성 익스포트로 취급되어서는 안 되며, 공증은 이더리움이 특정 Verus 측 객체가 확정된 브리지 상태에 존재했음을 증명할 수 있게 해줍니다.

취약점 분석

버그가 있는 이더리움 측 브리지 컨트랙트는 0xa045...6fc87f와 0x08f0...d0107d에 배포되어 있습니다.

근본 원인은 이더리움 임포트 경로의 유형 검증 실패였습니다. 브리지는 실제 Verus 측 객체의 존재를 증명했지만, 자금을 해제하기 전에 해당 증명된 객체가 유효한 기본 익스포트인지 확인하지 않았습니다. 대신 조작된 보조 출력값을 수락하고 이를 일반 활성 익스포트처럼 파싱했습니다.

높은 수준에서 보면, 취약한 흐름은 다음과 같습니다:

proveImports(...)
    -> 증명 검증
    -> keccak256(serializedTransfers) == 커밋된 전송 해시 검증

processTransactions(...)
    -> 이더리움에서 지불 실행

이 흐름에서 FLAG_SUPPLEMENTAL이 설정된 객체를 거부하는 검사가 없습니다. 수정 사항은 이 플래그를 명시적으로 확인하고 증명된 객체가 보조 객체일 경우 되돌립니다:

공격 분석

다음 분석은 이더리움 트랜잭션 0x6990f0...87eb321과 Verus 트랜잭션 f899e698...b9f5a733을 기반으로 합니다.

1단계: 5월 17일, 공격자는 Tornado Cash를 통해 이더리움 주소 0x5aBb...9D5777에 1 ETH를 입금했습니다. 5월 18일, 공격자는 Verus 주소 RW9vEW...B3g6zd에 대해 Verus 수도꼭지(faucet)에서 0.02 VRSC를 획득했습니다.
2단계: 공격자는 Verus에서 이더리움을 목적지로 하는 네 건의 익스포트 트랜잭션을 제출하며, 조작된 보조 익스포트 출력값을 포함시켰습니다. 이 보조 출력값들은 오류 없이 파싱 가능하도록 인코딩되었으며, 공격자가 나중에 실행하려는 사기성 지불과 일치하는 hashReserveTransfers 커밋을 포함했습니다.
3단계: 이더리움에서 크로스체인 공증이 충분히 진행된 후, 공격자는 이더리움에서 위조된 임포트 트랜잭션을 제출했습니다. 증명된 Verus 측 객체는 위의 Verus 트랜잭션에서 나온 보조 출력값이었습니다.
4단계: 이더리움 브리지는 증명을 수락했지만 증명된 객체를 보조 데이터로 거부하지 않았습니다. 대신 조작된 출력값을 유효한 활성 익스포트인 것처럼 파싱했습니다. 공격자가 커밋된 hashReserveTransfers 값과 일치하는 해시를 가진 serializedTransfers도 함께 제공했기 때문에, 브리지는 임포트 흐름을 계속 진행했습니다.
5단계: 보조 출력값이 유효한 익스포트로 잘못 해석되면서 사기성 전송이 이더리움 측 검사를 통과했습니다. 공격자는 약 $11.7M의 ETH, tBTC, USDC를 탈취했습니다.
6단계: 악의적인 임포트가 성공한 직후, Verus 노드는 사기성 익스포트 스레드와 실제 익스포트 스레드의 공존으로 인한 잘못된 상태 어설션(assertion)을 만나 브리지의 추가 진행이 중단되었고, 후속 공격이 제한되었습니다.

결론

이번 사건은 Verus-Ethereum 브리지의 유형 검증 실패로 인해 발생했습니다. 이더리움 컨트랙트는 실제 암호학적 증명을 수락했지만, 증명된 객체는 지불을 위한 유효한 기본 익스포트가 아닌 보조 익스포트 출력값이었습니다.

크로스체인 메시지 형식은 공격 표면의 일부입니다. 보조 데이터, 선택적 필드, 압축 인코딩, 파서 오프셋은 서명이나 머클 증명 검사와 동일한 수준의 엄격함으로 다루어야 합니다. 객체가 실행 중인 액션에 대해 예상되는 유형과 일치하지 않을 경우, 브리지는 파싱을 시도하는 대신 즉시 거부해야 합니다.

참고 자료

[1] BlockSec Phalcon 알림
[2] Verus 공식 사후 분석

이번 주 추가 사건

RetoSwap

2026년 5월 20일, Haveno Protocol에서 포크된 Monero 기반 탈중앙화 P2P 거래소 RetoSwap이 약 $2.7M(7,000 XMR)의 피해를 입었습니다 [1]. 근본 원인은 프로토콜 수준의 인증 결함이었습니다. 클라이언트가 위조되고 순서가 뒤바뀐 ACK 메시지를 수락하고, 발신자를 중재자의 알려진 공개 키와 대조 검증하지 않은 채 중재자의 저장된 Tor 주소를 공격자가 제어하는 주소로 덮어썼습니다. 이로 인해 공격자는 멀티시그 지갑 생성을 탈취하고, 자금이 입금되는 즉시 탈취할 수 있었습니다.

배경

RetoSwap은 Haveno Protocol에서 포크된 Monero 기반 탈중앙화 P2P 거래소입니다. 거래 프로토콜은 거래를 보호하기 위해 2-of-3 중재자 멀티시그 모델에 의존하며, Tor를 통해 오프체인으로 거래를 조율합니다.

일반적인 거래는 세 단계로 진행됩니다: 첫째, 구매자, 판매자, 중재자가 멀티시그 지갑을 생성하기 위한 오프체인 메시지 교환을 완료하고, 둘째, 멀티시그 지갑이 완전히 생성된 후에만 자금이 잠기며, 셋째, 구매자와 판매자가 지불 트랜잭션에 공동 서명하여 결제하거나 중재자가 분쟁 해결을 위해 개입합니다. 모든 통신은 Tor를 통해 이루어지며, 각 노드는 .onion 주소로만 식별됩니다.

취약점 분석

5월 20일, Haveno 프로젝트는 "core: refuse to update node address before multisig created(코어: 멀티시그 생성 전 노드 주소 업데이트 거부)"라는 제목의 풀 리퀘스트를 열었습니다 [2]. 그 시점에 RetoSwap은 이미 공격을 받고 있었습니다.

패치를 통해 TradeProtocol.java:onAckMessageAux(...)의 취약점이 드러났습니다. 클라이언트는 발신자가 예상되는 중재자의 공개 키와 일치하는지 암호학적으로 검증하지 않고, 메시지에 포함된 senderNodeAddress를 사용하여 피어를 식별했습니다. 공격자는 공격자가 제어하는 .onion 주소를 담은 위조된 ACK 메시지를 전송할 수 있었고, 클라이언트는 저장된 중재자 주소를 해당 주소로 덮어썼습니다.

이 일이 1단계(멀티시그 지갑 생성 전)에 발생했기 때문에, 공격자의 주소가 실제 중재자의 주소를 대체했습니다. 따라서 공격자는 멀티시그 지갑의 거래자 키와 중재자 키를 모두 보유하게 되어, 자금이 입금되는 즉시 전액을 탈취할 수 있었습니다.

수정 사항은 두 가지 방식으로 이를 해결합니다: 발신자를 피어의 알려진 공개 키와 대조 검증하여 미검증 피어의 메시지를 거부하고, trade.isDepositRequested()를 통해 주소 업데이트를 제한하여 멀티시그 지갑이 생성되기 전의 덮어쓰기를 방지합니다.

공격 분석

이번 사건에서 온체인 공격 트랜잭션은 확인되지 않았습니다. RetoSwap은 오프체인 메시지 처리와 함께 전적으로 Tor를 통해 운영되므로, 핵심 행위는 어떠한 공개 원장 밖에서 발생합니다. 다음 재구성은 공개된 패치와 공식 커뮤니케이션을 기반으로 합니다.

1단계: 공격자는 구매자 또는 판매자로서 기존 거래에 참여했습니다.
2단계: 공격자는 중재자로부터 온 것처럼 가장한 위조되고 순서가 뒤바뀐 ACK 메시지를 전송했으며, senderNodeAddress로 공격자가 제어하는 .onion 주소를 담았습니다.
3단계: 피해자의 클라이언트는 발신자를 중재자의 알려진 공개 키와 대조 검증하지 않고 메시지를 수락하여 중재자의 저장된 주소를 덮어썼습니다.
4단계: 중재자를 향한 이후의 모든 통신, 멀티시그 지갑 생성을 포함하여, 공격자에게 라우팅되었고 공격자는 세 번째 멀티시그 키를 획득했습니다.
5단계: 구매자와 판매자가 손상된 멀티시그 지갑에 자금을 입금하자, 공격자는 지갑의 전체 잔액을 탈취했습니다. 총 이익은 약 7,000 XMR(~$2.7M)에 달했습니다.

결론

이번 사건은 암호학적 실패가 아닌 프로토콜 수준의 인증 결함이었습니다. 메시지는 올바른 형식으로 검증되었지만, 주소 업데이트가 적용되기 전에 발신자가 알려진 공개 키에 암호학적으로 바인딩되지 않았습니다. 그 결과, 클라이언트는 멀티시그 지갑이 생성되기 전에 위조된 ACK 메시지의 미검증 senderNodeAddress를 중재자의 새로운 연락처로 취급하여, 공격자가 중재자 역할을 탈취할 수 있었습니다.

핵심 교훈은: (1) 피어 신원을 업데이트하는 모든 메시지는 업데이트가 적용되기 전에 피어의 알려진 공개 키와 대조하여 암호학적으로 검증되어야 하며, (2) 상대방 주소와 같이 신원에 중요한 상태는 보안에 민감한 단계(예: 멀티시그 지갑 생성)가 시작되면 변경 불가능해야 한다는 것입니다.

참고 자료

BlockSec 소개

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

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