사태 반전, Bybit가 도난당한 15억 달러는 사실 Safe 프로토콜 개발자가 해킹당한 것이었다

저자: 우설 블록체인

외부에서 Bybit가 어떻게 여러 서명자를 뚫렸는지에 대한 의문이 제기되는 가운데, 2월 26일 저녁 Bybit와 Safe가 동시에 공지를 발표했다.

Safe는 Lazarus Group이 Bybit에 대해 시작한 표적 공격에 대한 포렌식 검토 결과, 이번 Bybit Safe에 대한 공격은 해킹된 Safe{Wallet} 개발자 머신을 통해 이루어졌으며, 이로 인해 위장된 악성 거래가 발생했다고 밝혔다. Lazarus는 정부 지원을 받는 북한 해커 조직으로, 개발자 자격 증명에 대한 복잡한 사회 공학 공격으로 유명하며, 때때로 제로데이 취약점을 결합하기도 한다.

외부 보안 연구자들의 포렌식 검토 결과 Safe 스마트 계약이나 프론트엔드 및 서비스의 소스 코드에 취약점이 존재하지 않는 것으로 나타났다. 최근 사건 발생 후, Safe{Wallet} 팀은 철저한 조사를 실시했으며, 단계적으로 이더리움 메인넷에서 Safe{Wallet}을 복구했다. Safe{Wallet} 팀은 모든 인프라를 완전히 재구성하고 재구성했으며, 모든 자격 증명을 교체하여 공격 매개체를 완전히 제거했다. 조사 최종 결과를 기다린 후, Safe{Wallet} 팀은 전체 사후 분석을 발표할 예정이다.

Safe{Wallet} 프론트엔드는 여전히 운영 중이며, 추가적인 보안 조치를 취하고 있다. 그러나 사용자는 거래 서명 시 각별히 주의하고 경계를 유지해야 한다.

Bybit는 다음과 같이 밝혔다:

공격 시간: 악성 코드는 2025년 2월 19일 Safe{Wallet}의 AWS S3 버킷에 주입되었으며, 2025년 2월 21일 Bybit가 멀티시그 거래를 실행할 때 트리거되어 자금이 도난당했다.

공격 방법: 공격자는 Safe{Wallet}의 프론트엔드 JavaScript 파일을 변조하여 악성 코드를 주입하고, Bybit의 멀티시그 거래를 수정하여 자금을 공격자 주소로 리디렉션했다.

공격 목표: 악성 코드는 Bybit의 멀티시그 콜드 월렛 주소 및 특정 조건에서만 활성화되는 테스트 주소를 겨냥했다. 공격 후 조치: 악성 거래가 실행된 후 약 2분 후, 공격자는 AWS S3 버킷에서 악성 코드를 제거하여 흔적을 감추었다.

조사 결론: 공격은 Safe{Wallet}의 AWS 인프라에서 발생했으며(아마도 S3 CloudFront 계정/API 키 유출 또는 해킹), Bybit 자체 인프라는 공격받지 않았다.

Safe 다중 서명 지갑은 블록체인 스마트 계약 기반의 암호화폐 지갑으로, 다중 서명(Multisig) 메커니즘을 통해 자산을 관리한다. 그 핵심은 여러 사전 정의된 서명자(예: 3명 중 2명, 또는 5명 중 3명, 즉 M/N 메커니즘)가 공동으로 승인해야 거래를 실행할 수 있도록 요구하는 것이다. 지갑 자체는 블록체인에 배포된 계약으로, 소유자 주소와 서명 임계값을 기록하며, 거래는 충분한 서명을 수집한 후 계약에 의해 검증되고 실행된다. 그 기술 원리는 타원 곡선 디지털 서명 알고리즘(ECDSA)에 의존하며, 서명자는 개인 키로 거래에 서명하고, 계약은 공개 키로 검증한다. 거래 제안은 먼저 계약에 저장되고, 서명을 수집한 후 블록체인에 제출되어 실행되며, 계정 복구 기능과 같은 유연한 확장을 지원한다.

Polygon의 Mudit Gupta는 왜 한 개발자가 처음부터 Safe 생산 웹사이트의 내용을 변경할 권한을 가졌는지 의문을 제기했다. 또한 왜 변경 사항에 대한 모니터링이 없었는지도 질문했다.

바이낸스 창립자 CZ는 "나는 일반적으로 다른 산업 참여자를 비판하지 않지만, Safe가 문제를 감추기 위해 모호한 언어를 사용하고 있다"고 말했다. "Safe{Wallet} 개발자 머신을 해킹했다는 것은 무슨 뜻인가? 그 특정 머신은 어떻게 해킹되었는가? 사회 공학, 바이러스 등인가? 개발자 머신은 'Bybit가 운영하는 계정'에 어떻게 접근했는가? 일부 코드는 이 개발자 머신에서 직접 프로덕션 환경에 배포되었는가? 그들은 어떻게 여러 서명자의 Ledger 검증 단계를 속였는가? 블라인드 서명인가? 아니면 서명자가 올바르게 검증하지 않았는가? 14억 달러는 Safe로 관리되는 최대 주소인가? 그들은 왜 다른 사람을 목표로 하지 않았는가? 다른 '자체 관리, 다중 서명' 지갑 제공업체와 사용자는 무엇을 배울 수 있는가? 또한 CZ는 바이낸스도 Safe를 사용하여 자산을 보관하고 있지 않다고 부인했다.

SlowMist의余弦은 Safe의 스마트 계약 부분에는 문제가 없지만(체인에서 쉽게 검증 가능), 프론트엔드가 변조되어 위장 효과를 달성했다고 말했다. 왜 변조되었는지에 대한 이유는 Safe 공식의 세부 사항 공개를 기다려야 한다. Safe는 일종의 보안 인프라로 간주되며, 이 다중 서명 지갑을 사용하는 모든 사람은 Bybit와 유사하게 도난당할 수 있다. 심각하게 생각해보면, 모든 다른 프론트엔드, API 등 사용자 상호작용 서비스는 이러한 위험을 가질 수 있다. 이것은 고전적인 공급망 공격의 일종이다. 대규모 자산의 보안 관리 모델은 대규모 업그레이드가 필요하다. 만약 Safe 프론트엔드가 기본적인 SRI 검증을 수행했다면, 이 js가 변경되더라도 문제가 발생하지 않았을 것이다.余弦은 만약 그 Safe의 개발자가 북한 특공대원이라면, 그는 놀라지 않을 것이라고 말했다.

GCC의 주최자 콘스탄틴은 이것이 산업에 중대한 타격이라고 말했다. 이른바 탈중앙화된 공공재는 단일 지점 위험이 몇몇 일반 계약 프론트엔드 개발자에게도 거의 안전성이 없다는 것을 보여준다. Safe 외에도 많은 웹3 오픈 소스 의존성들이 유사한 공급망 공격의 위험을 가지고 있으며, 이들은 단지 리스크 관리가 약할 뿐만 아니라 전통적인 인터넷 인프라에 심각하게 의존하여 안전성을 보장하고 있다.

Hasu는 Safe 프론트엔드가 아닌 Bybit 인프라가 해킹당했지만, Bybit 인프라도 최종적으로 상당히 간단한 해커 공격을 막기에는 부족하다고 말했다. 10억 달러 이상의 자금을 이동할 때, 두 번째 격리된 머신에서 메시지 무결성을 검증하지 않는 이유가 없다.

Mingdao는 핵심은 대규모 자금 서명 거래는 영구적으로 오프라인 컴퓨터에서 생성되어야 한다고 말했다. 거래를 시작하는 쪽의 다중 서명자가 오프라인에서 서명한 후, 연결된 컴퓨터를 통해 방송하면, 다른 사람들이 어떻게 서명하든 문제가 발생하지 않는다. 모든 다중 서명자가 연결된 컴퓨터에서 거래를 생성하면, 이 콜드 월렛은 핫 월렛이 된다. 이것은 Safe의 잘못이 아니다. 결국 그들은 자금을 관리하지 않았다. 그들은 단지 불행히도 신뢰의 중심점이 되었다.

Vitalik은 개인 자산의 90%를 Safe 다중 서명으로 보관하고 있다고 언급한 바 있다.

Wintermute의 창립자는 Bybit의 보안 조치가 완벽하다고 말하는 것은 아니지만(그들은 아마도 SAF E 프로토콜의 최대 다중 서명 계좌를 사용하고 있을 가능성이 있다), Fireblocks 또는 Fordefi와 같은 솔루션을 사용하고 다른 조치를 결합하여 특히 간단한 자금 이동을 처리할 때 더 합리적일 수 있다고 말했다.