이벤트 리뷰
2025년 2월 21일 오후 2시 16분 11초 UTC에 Bybit의 이더리움 콜드 월렛(0x1db92e2eebc8e0c075a02bea49a2935bcd2dfcf4)이 공격을 받아 약 401,346개 ETH, 15,000개 cmETH, 8,000개 mETH, 90,375개 stETH, 90개 USDT가 알려지지 않은 주소로 전송되었으며, 총 가치는 약 14억 6,000만 달러에 달했습니다.
공격자는 피싱 공격을 통해 Bybit의 다중 서명 지갑 서명자를 속여 악성 거래에 서명하도록 했습니다. 구체적인 단계는 다음과 같습니다.
공격자는 자금을 이체하기 위한 백도어 기능이 포함된 악성 계약을 사전에 배포했습니다.
Safe 프런트엔드 인터페이스를 조작하여 Safe에서 서명자가 보는 거래 정보가 Ledger 하드웨어 지갑에 실제로 전송된 데이터와 일치하지 않도록 합니다.
공격자는 위조된 인터페이스를 통해 성공적으로 3개의 유효한 서명을 획득하고 안전 다중 서명 지갑의 구현 계약을 악성 계약으로 바꿔서 콜드 지갑을 제어하고 자금을 이체했습니다.
Sygnia는 Bybit의 의뢰로 공격의 근본 원인을 파악하기 위한 법의학적 조사를 실시했습니다. 그 목표는 공격의 범위와 출처를 파악하고 현재 및 미래의 위험을 완화하는 것입니다. 최신 보고서는 Bybit 중간 조사 보고서 (https://docsend.com/view/rmdi832mpt8u93s7/d/rwecw3rumhqtgs6a)에서 확인하세요.
현재까지의 법의학적 조사에서는 다음과 같은 결과가 강조되었습니다.
거래를 시작하고 서명하는 데 사용된 모든 호스트에 대한 포렌식 조사 결과, Safe의 AWS S3 버킷에 있는 리소스에 악성 JavaScript 코드가 삽입된 것으로 밝혀졌습니다.
리소스 수정 시간과 공개적으로 사용 가능한 네트워크 기록 보관소는 악성 코드 주입이 Safe의 AWS S3 버킷에서 직접 수행되었음을 나타냅니다.
삽입된 JavaScript 코드를 처음 분석한 결과, 주요 목적은 거래를 조작하여 서명 과정에서 내용을 변경하는 것이었습니다.
또한, 주입된 JavaScript 코드 분석 결과, 거래 출처가 두 계약 주소 중 하나와 일치하는 경우에만 실행되는 활성화 조건이 밝혀졌습니다. 즉, Bybit의 계약 주소와 현재 식별되지 않은 계약 주소(위협 행위자가 제어하는 테스트 계약과 관련이 있을 가능성이 높음)입니다.
악성 거래가 실행되고 게시된 지 2분 후, JavaScript 리소스의 새로운 버전이 Safe의 AWS S3 버킷에 업로드되었습니다. 업데이트된 버전에서는 악성 코드가 제거되었습니다.
초기 조사 결과에 따르면 이 공격은 Safe의 AWS 인프라에서 시작된 것으로 나타났습니다.
지금까지 법의학적 조사에서 Bybit 인프라가 손상된 흔적은 발견되지 않았습니다.
세 개의 서명 호스트에 대한 법의학적 조사 결과, 공격의 근본 원인은 안전 인프라에서 유래된 악성 코드라는 사실이 밝혀졌습니다.
Bybit의 인프라에서는 손상의 징후가 발견되지 않았습니다.
이러한 결과를 더욱 확인하기 위한 조사가 계속 진행되고 있습니다.
현재 정보로 판단하면, 이번에는 프런트 엔드가 주요 문제가 아닙니다. 이 공격의 주요 원인은 AWS의 스토리지 서비스가 해킹되어 JavaScript가 변조되었고, 이로 인해 Safe 프런트 엔드에서 시작된 거래 내용이 수정된 것입니다. 하지만 프런트엔드에서 Safe 프런트엔드가 기본적인 SRI 검증을 수행했다면 JavaScript가 변경되었더라도 아무 문제가 발생하지 않았을 것입니다. 이런 식으로 프런트엔드에는 어느 정도 책임이 있어야 합니다. 물론 Bybit도 책임을 져야 합니다. 우선, 그들이 사용한 하드웨어 지갑이 구체적인 거래 정보를 표시하지 않았다는 것을 확인했습니다. Safe 프런트엔드 자체에 대한 신뢰가 신뢰할 수 없었습니다.
하드웨어 지갑은 복잡한 거래를 처리할 때 한계가 있으며, 다중 서명 지갑의 자세한 거래 데이터를 완전히 분석하고 표시할 수 없기 때문에 서명자는 거래 내용을 완전히 검증하지 않고 맹목적으로 서명하게 됩니다.
해커는 사용자의 자산을 사기하기 위해 상호작용 프로세스의 설계 결함을 악용하는 데 매우 능숙합니다. 예를 들어 UI 하이재킹을 사용하여 사용자를 속여 서명하게 하거나, 숨은 서명을 사용하여 사용자를 속여 서명하게 하거나, 허가 서명을 사용하여 사용자의 자산을 훔치거나, TransferFrom을 사용하여 사용자를 속여 피싱하게 하거나, 같은 마지막 숫자를 사용하여 숏 포지션을 사용하여 사기를 저지르거나, NFT를 낚거나 다른 일반적인 피싱 기술을 사용하는 경우가 있습니다.
Web3 기술의 급속한 발전으로 인해 프런트엔드 보안과 블록체인 보안 간의 경계가 점차 모호해지고 있습니다. XSS, CSRF와 같은 기존 프런트엔드 취약점은 Web3 시나리오에서 새로운 공격 차원을 부여받고 있으며, 스마트 계약 취약점 및 개인 키 관리 결함과 같은 문제는 위험을 더욱 증폭시킵니다.
다음으로, 두 가지 시나리오에서 프런트엔드 개발과 보안 문제 간의 관계를 분석해 보겠습니다.
시나리오 1: 거래 매개변수 변조 - 인터페이스는 전송을 표시하지만 실제로는 승인이 실행됩니다.
예: 프런트엔드 디스플레이와 온체인 실행 분리
사용자 관점:
✅ 지갑 팝업 창에 0x 사용자에게 1 ETH 전송...이라는 메시지가 표시됩니다.
실제 온체인 효과:
⚠️ 언제든지 자산을 전송하려면 approve(attacker, unlimited)를 실행하세요.
어떻게 해야 하나요? EIP-712 구조화된 서명 검증
1. 프런트엔드는 검증 가능한 데이터를 생성합니다.
2. 스마트 계약 검증 서명
효과: 프런트엔드 매개변수를 조작하면 서명 불일치가 발생하고 거래는 자동으로 롤백됩니다.
시나리오 2: 블라인드 서명 하이재킹 - 하드웨어 지갑이 해킹된 이유
예: Ledger 구문 분석 규칙 변조
1. 공격자는 프런트엔드 코드를 하이재킹하고 가짜 콜데이터를 하드웨어 지갑으로 전송합니다.
2. 원장 화면 표시:
실제 실행 : approv(attacker, unlimited)
어떻게 해야 하나요? 하드웨어 지갑 의미 분석 + 온체인 2차 검증
1. EIP-712를 지원하도록 하드웨어 지갑 펌웨어 업그레이드
2. 온체인 필수 의미 매칭
결론
프런트엔드 보안과 Web3 보안을 통합하는 것은 과제이자 기회입니다. Bybit 도난 사건은 암호화폐 산업의 보안 관리와 기술 아키텍처에 심각한 문제가 있음을 드러냈습니다. 해커의 공격 기술이 계속 발전함에 따라 업계에서는 점점 더 복잡해지는 위협에 대처하기 위해 기기 보안, 거래 검증, 위험 제어 메커니즘을 포함한 여러 측면에서 보호 역량을 종합적으로 강화해야 합니다. 프런트엔드 개발자가 해야 하는 일은 DApp에 대한 접근, 지갑 연결, 메시지 서명, 거래 서명, 거래 후 처리 및 기타 링크를 반복적으로 검증하는 것입니다. 수동적 수리에서 능동적 면역으로의 도약을 실현하세요. 이런 방법으로만 우리는 Web3의 개방된 세계에서 모든 거래의 가치와 신뢰를 보호할 수 있습니다.
물론, 온체인 계약의 보안 감사도 모든 Dapp에 필수적입니다. ZAN AI Scan (https://zan.top/cn/home/ai-scan?chInfo=ch_WZ)은 형식적 검증 및 AI 지원 보안 사양 생성을 통해 코드 정확성을 보장하고, 수백만 개의 배포된 계약에 대한 코드 유사성 및 지적 재산 위험 분석을 제공하며, 배포된 프로젝트에 영향을 미칠 수 있는 제로데이 취약성 및 보안 사고와 관련하여 24시간 연중무휴 모니터링 및 즉각적인 알림을 제공합니다. 또한, 스마트 계약의 다양한 실제 취약성을 감지하기 위해 방대한 취약성 데이터베이스를 기반으로 최적화된 GPT 모델도 갖추고 있습니다.
이 글은 ZAN Team(X 계정 @zan_team )의 KenLee가 작성했습니다.
