저자: 문빔(Moonbeam)
타임라인
2025년 2월 21일: 바이비트(Bybit) 다중 서명 지갑이 공격당해, 15억 달러가 '합법적' 서명 거래를 통해 유출되었습니다.
온체인 추적: 자금이 익명 주소로 이체되고 믹싱되었으며, 공격자와 일부 검증 노드 간에 잠재적인 연관성이 있습니다.
사후 분석: 보안 감사에서 공격자가 Safe 프론트엔드의 공급망 취약점을 이용해 악성 스크립트를 삽입했다는 것이 밝혀졌습니다.
공격이 발생한 이유
해커는 악의적인 프론트엔드 코드를 이용해 바이비트 다중 서명 지갑의 서명자들이 이것이 합법적인 거래(예: 일상적인 토큰 이체)라고 확신하게 만들었습니다. 실제로는 그들을 불법 거래에 서명하도록 유도했습니다. 서명자들이 다른 방법으로 거래 내용에 문제가 있음을 발견하는 것을 막기 위해, 해커는 이 공격을 '전송' 거래로 위장했습니다.
공격 방식을 요약하면 다음과 같습니다:
해커가 Safe 프론트엔드 개발자 권한을 얻어 코드를 수정하고 바이비트 공격을 위한 악성 스크립트를 삽입했습니다.
바이비트 다중 서명 멤버들이 오염된 웹페이지에 접속했습니다.
그들이 보게 된 페이지: "100 이더리움(ETH)을 주소 A로 전송"
실제로 서명을 요구받은 것: "콜드 월렛 로직 수정"
이는 ATM 기기의 화면을 바꿔치기한 것과 같아, 화면에는 100원 출금이 표시되지만 실제로는 100만원이 출금되는 것과 같습니다.
공식 앱 — 사용자의 신뢰 맹점
사용자들이 인식하는 다중 서명 거래 프로세스는 매우 간단합니다: 거래 확인 → 서명 → 체인에 제출. 그러나 실제로는 다음과 같은 핵심적인 분리가 존재합니다:
사용자가 보는 거래
실제로 서명되는 거래
공식 앱을 사용하면 사용자의 경계심이 크게 낮아져, 이러한 분리를 간과하게 됩니다. 공식 앱 페이지가 공격당하면, 사용자의 서명은 진짜이지만 자신이 무엇에 서명했는지 모르게 됩니다.
이때 독립적인 채널을 통해 서명 내용의 진실성을 검증할 수 있다면, 프론트엔드 공격으로 인한 위험을 크게 줄일 수 있습니다. 이것이 블록체인이 주장하는 "믿지 마, 검증하라(Don't trust it, VERIFY it)"의 핵심입니다.
「독립 채널 검증」의 이론적 기반
먼저 Safe 계약의 작동 원리를 살펴보겠습니다(현재까지 Safe 계약은 충분히 안전합니다):
거래 내용의 해시 값을 계산합니다(거래의 '지문'과 유사함)
이 해시 값에 개인 키로 서명합니다
충분한 수의 서명을 모으면 거래 원문과 서명을 체인에 제출합니다
체인에서 원문으로 다시 해시 값을 계산하고 서명의 유효성을 검증합니다. 충분한 유효 서명이 있으면 거래를 실행하고, 그렇지 않으면 거부합니다.
해시와 서명의 안전성과 위조 불가능성은 블록체인 작동의 두 가지 기반입니다.
따라서 거래가 체인에 제출되기 전에 독립 채널에서 거래 원문과 서명을 얻을 수 있다면, "사용자가 서명한 거래가 무엇인지"와 "사용자가 이 거래에 서명했는지"를 검증할 수 있습니다.
따라서 프론트엔드나 백엔드가 공격당해도 최악의 경우는 잘못된 데이터를 반환하는 것뿐이며, 이 경우 「독립 채널」에서는 다음과 같은 상황이 발생합니다:
잘못된 거래 원문, 잘못된 서명 — 사용자가 거래 전송을 거부
잘못된 거래 원문, 유효 서명 — 사용자가 거래 전송을 거부
잘못된 거래 원문, 잘못된 서명 — 사용자가 거래 전송을 거부
최악의 경우에도 이 거래가 체인에 전송되지 않을 뿐이며, 그 외에 어떤 체인 상의 손실도 발생하지 않습니다. 따라서 이러한 "표시 공격"에 대한 최선의 방법은 다중 채널 검증이며, 이는 블록체인의 정신인 "믿지 마, 검증하라"와도 부합합니다.
현재 가능한 해결책
다양한 다중 서명 제품 간 상호 검증
현재 시장에는 Safe와 호환되는 많은 다중 서명 제품이 있습니다. 예를 들어 Safe 자체에도 두 개의 독립적인 프론트엔드 페이지가 배포되어 있습니다:
https://eternalsafe.vercel.app/welcome/
https://eternalsafe.eth.limo/welcome/
사용자가 다중 서명 거래에 서명한 후, 자신이나 후속 서명자가 다른 다중 서명 제품의 페이지에 로그인하여 거래 원문을 다시 확인할 수 있습니다. 두 다중 서명 제품이 동일한 거래 내용을 표시한다면 "자신이 서명한 거래 내용"을 신뢰할 수 있습니다.
그러나 이를 위해서는 다른 다중 서명 제품들도 Safe의 백엔드를 사용하여 체인 외 거래 및 서명 데이터를 저장하고 서로 공유해야 하며, 이는 제품 간 협력에 매우 엄격한 요구사항을 부과합니다. 또한 Safe는 일부 비표준 거래의 원문 해석에 친화적이지 않아, 여러 Safe 프론트엔드가 동일한 calldata를 표시하더라도 그것이 의미 없는 0x abcdefsf일 경우 서명자들이 망설일 수 있습니다.
참고: 현재 Safe가 제공하는 두 개의 독립 대체 웹사이트는 사용자가 직접 RPC 링크를 제공해야 합니다:
독립적인 Safe 거래 검증 도구
Safe 프론트엔드 공격 사건에 대해 커뮤니티의 반응도 빨랐습니다. Safe 공식 텔레그램 그룹에서 독립적인 Safe 거래 분석 도구를 발견했는데, 이 방식이 더 간단하고 직접적인 것 같습니다.
우리도 이 도구를 테스트해 보았습니다. 그림과 같이 Safe 페이지의 거래 공유 링크를 붙여넣기만 하면 Safe 백엔드 데이터를 자동으로 읽어와 거래 원문의 해시 값과 서명의 유효성을 독립적으로 검증할 수 있습니다. 즉, 그림의 calldata 분석이 자신이 보내고자 하는 거래라고 확신하고 "SafeHash Check"와 "Signature Check"가 통과되면, 이것이 자신이 서명한 거래라고 믿을 수 있습니다.
물론 안전을 위해서는 Safe 주소, 서명자 주소, 상호작용 계약 주소 및 Call 또는 Delegatecall과 같은 작업 유형도 다시 한 번 주의 깊게 확인해야 합니다. 예를 들어 이번 바이비트 공격 거래에는 delegatecall과 transfer가 동시에 나타났는데, 이는 경험 있는 개발자라면 매우 이상한 조합이라는 것을 알 수 있습니다.
거래 정보를 읽을 수 없는 경우:
Decode 버튼을 클릭하고 해당 거래 메서드의 ABI를 제공하면:
읽을 수 있는 거래 정보를 확인할 수 있습니다:
