원작자 : 문빔
타임라인
2025년 2월 21일: Bybit 다중 서명 지갑이 공격을 받았고, 합법적인 서명 거래를 통해 15억 달러가 유출되었습니다.
온체인 추적: 자금은 익명 주소로 이체되고 혼합된 코인으로 분할됩니다. 공격자는 일부 검증 노드와 잠재적으로 연결되어 있습니다.
사후 분석: 보안 감사를 통해 공격자가 안전 프런트엔드의 공급망 취약성을 이용해 악성 스크립트를 삽입한 사실이 발견되었습니다.
공격이 발생한 이유
해커는 악의적인 프런트엔드 코드를 사용하여 바이비트 멀티시그니처 지갑의 서명자들에게 이것이 합법적인 거래(예: 일상적인 토큰 전송)라고 확신시켰고, 이는 실제로 이들이 불법적인 거래에 서명하도록 유도했습니다. 서명자들이 다른 수단을 통해 거래 내용의 문제를 발견하지 못하도록 하기 위해 해커는 이 공격을 전송 거래로 위조하여 바이비트 서명자들이 다른 수단을 통해 거래 콜데이터를 확인하지 않도록 했습니다. (거래 내용은 일반적으로 콜데이터라고 함)
간단히 말하면 공격 방법은 다음과 같습니다.
해커는 Safe 프런트엔드의 개발자 권한을 얻어 프런트엔드 코드를 수정하고 바이비트 공격을 타겟으로 하는 악성 스크립트를 이식했습니다.
Bybit 다중 서명 회원이 오염된 웹페이지를 방문하여 가짜 거래 정보를 확인했습니다.
그들이 보는 페이지: 주소 A로 100 ETH 전송
실제로 서명이 필요한 것은 콜드 월렛 로직 수정입니다.
이것은 디스플레이 화면을 교체한 ATM기와 같습니다. 화면에는 100위안이 인출되었다고 표시되지만 실제 작동은 100만 위안을 인출하는 것입니다.
공식 APP - 사용자의 신뢰 사각지대
사용자의 인식에서 다중 서명 거래 프로세스는 매우 간단합니다. 거래 보기 → 서명 → 체인에 제출 하지만 실제로는 키 분리를 의미합니다.
사용자가 본 거래
실제로 서명된 거래
공식 앱을 사용하면 사용자의 각성이 크게 떨어져, 이러한 분리 단계를 무시하게 됩니다. 공식 앱 페이지가 해킹당하면 사용자의 서명은 진짜가 되지만, 지금은 자신이 무엇에 서명했는지 알 수 없습니다.
이때 서명 내용의 진위 여부를 검증할 수 있는 독립적인 채널이 있다면 프런트엔드 공격으로 인한 위험을 크게 줄일 수 있습니다. 블록체인이 옹호하는 바는 이것입니다: 믿지 말고 검증하세요.
독립채널검증의 이론적 기초
먼저 Safe 계약이 어떻게 작동하는지 살펴보겠습니다(지금까지 Safe 계약은 여전히 충분히 안전합니다).
먼저, 거래 내용에 대한 해시 값을 계산합니다(거래의 지문을 생성하는 것과 유사).
이 해시 값에 개인 키로 서명하세요
충분한 서명이 수집되면 원래 거래와 이 서명을 체인에 제출합니다.
체인은 원래 텍스트를 기반으로 해시 값을 다시 계산하고 서명이 유효한지 확인합니다. 충분한 유효한 거래가 수집되면 실행되고, 그렇지 않으면 거부됩니다.
해시와 서명의 보안성과 위조 불가능성이 블록체인 작업의 두 가지 초석이라는 점에는 의심의 여지가 없습니다.
따라서 거래가 체인에 제출되기 전에 원래 거래 텍스트와 서명을 얻을 수 있는 독립적인 채널이 있다면 사용자가 서명한 거래가 정확히 무엇인지와 사용자가 거래에 서명했는지 여부를 검증할 수 있습니다.
따라서 프런트엔드나 백엔드가 공격을 받더라도 최악의 시나리오는 잘못된 데이터가 반환되는 것입니다. 그러나 독립 채널의 잘못된 데이터는 다음과 같은 상황을 발생시킵니다.
잘못된 거래 텍스트, 잘못된 서명 - 사용자가 체인에 거래를 보내는 것을 거부합니다.
잘못된 거래 텍스트, 유효한 서명 - 사용자가 체인에 거래를 보내는 것을 거부합니다.
잘못된 거래 텍스트, 잘못된 서명 - 사용자가 체인에 거래를 보내는 것을 거부합니다.
최악의 시나리오는 거래가 체인으로 전송되지 않는다는 것을 알 수 있습니다. 그 외에는 체인상 손실이 발생하지 않습니다. 따라서 이러한 디스플레이 공격을 처리하는 가장 좋은 방법은 여러 채널을 통해 확인하는 것이며, 이는 블록체인의 정신, 즉 신뢰하지 말고 검증하라에 부합합니다.
기존 솔루션
여러 개의 다중 서명 제품이 서로를 검증합니다.
시중에는 많은 안전 호환 멀티서명 제품이 있습니다. 예를 들어, Safe 자체는 두 개의 독립적인 프런트엔드 페이지를 배포했습니다.
https://eternalsafe.vercel.app/welcome/
https://eternalsafe.eth.limo/welcome/
사용자가 다중 서명 거래에 서명한 후, 그 또는 그 이후의 서명자는 다른 다중 서명 상품의 페이지에 로그인하여 원래 거래를 다시 봅니다. 다른 다중 서명 상품이 정확히 동일한 거래 내용 분석을 표시하는 경우, 사용자는 자신이 서명하려는 거래 내용이 정확하다고 확신할 수 있습니다.
그러나 이를 위해서는 다양한 멀티서명 제품이 모두 {Safe}의 백엔드를 사용하여 오프체인 거래와 서명 데이터를 저장하고, 수집된 서명 데이터를 {Safe}의 백엔드로 전송해야 하므로 제품 간 협업에 매우 까다로운 요구 사항이 적용됩니다. 또한 Safe는 일부 비전통적 거래의 원본 텍스트 구문 분석에 친화적이지 않습니다. 여러 Safe 프런트엔드가 동일한 호출 데이터를 표시하더라도 0x abcdefsf의 무의미한 문자열일 뿐이라면 서명자를 낙담시킬 것입니다.
참고: 현재 Safe에서 제공하는 두 개의 독립적인 대체 웹사이트는 모두 사용자가 자신의 RPC 링크를 제공하도록 요구합니다.
독립적인 안전거래 검증 도구
커뮤니티는 Safe 프런트엔드 공격에 신속하게 대응했습니다. 우리는 공식 Safe 텔레그램 그룹에서 누군가가 더 간단하고 직접적이었던 독립적인 Safe 거래 분석 도구를 제공했다는 것을 발견했습니다.
우리는 또한 이 도구의 유효성을 검증했습니다. 그림에서 보듯이, 안전 페이지에 거래 공유 링크만 붙여넣으면, 안전 백엔드 데이터를 자동으로 읽고 원래 거래의 해시 값과 서명의 정확성을 독립적으로 검증할 수 있습니다. 간단히 말해서, 그림의 콜데이터 분석이 원하는 거래이고, SafeHash Check와 Signature Check 검증을 통과했다면, 이것이 당신이 보내려는 거래다라고 생각할 수 있고, 당신이 올바르게 서명했다고 생각할 수 있습니다.
물론 안전을 위해 Safe Address, 서명을 통해 구문 분석된 서명자 주소, 대화형 계약 주소 , 작업 유형 (Call인지 Delegatecall인지)도 주의 깊게 확인해야 합니다. 예를 들어, 이번에 bybit이 공격한 트랜잭션은 delegatecall과 transfer가 동시에 나타난 트랜잭션이었습니다. 약간의 경험이 있는 개발자라면 이런 조합이 매우 이상하다는 것을 알 것입니다.
읽을 수 없는 거래 정보가 있는 경우:
디코드를 클릭하면 다음과 같은 트랜잭션 메서드의 ABI를 제공할 수 있습니다.
읽을 수 있는 거래 정보를 표시할 수 있습니다.
안전을 유지하세요 - 확인, 신뢰하지 마세요
Bybit의 다중 서명 공격은 프런트엔드 신뢰가 거래 보안과 같지 않다는 점을 다시 한번 일깨워줍니다. 공식 앱을 사용하는 경우라도 거래 내용이 변조될 수 있으며, 서명자는 자신이 서명한 내용을 확인할 독립적인 방법이 필요합니다.
믿지 말고 , 검증하세요. 이것이 Web3 보안의 핵심 원칙입니다. 앞으로는 안전 생태계와 더 많은 다중 서명 제품을 통해 독립적인 서명 검증 메커니즘이 강화되어 유사한 공격이 다시 발생하지 않도록 방지할 수 있기를 기대합니다.
