바이비트 공격
2025년 2월 21일, 바이비트는 Safe 멀티시그 콜드월렛에서 약 15억 달러를 잃었습니다. 업계 역사상 최대 규모의 절도이고, 꼼꼼히 읽을 가치가 있습니다. 딱 한 가지를 빼면 거의 모든 것이 정상이었기 때문입니다.
무슨 일이 있었나
공개된 사후 분석에서 뽑은 짧은 버전입니다.
- 공격자가
Safe{Wallet}개발자의 머신을 장악해,Safe{Wallet}프런트엔드를 서비스하던 AWS S3 버킷에 악성 자바스크립트를 주입했습니다. 코드는 2월 19일에 들어갔고, 2월 21일 바이비트의 특정 Safe를 겨냥해 작동했습니다. - 바이비트의 서명자들은 인터페이스를 열고, 평범해 보이는 거래를 검토했습니다.
- 실제로 그들의 하드웨어 지갑에 전달된 것은 그 거래가 아니었습니다. Safe 프록시의
masterCopy— 슬롯 0 — 을 덮어써 계정 구현 전체를 공격자의 것으로 바꾸는delegatecall이었습니다. - 서명자들은 승인했습니다. 서명은 유효했습니다. 컨트랙트는 지시받은 그대로 실행했습니다.
귀속은 북한과 연관된 활동으로 공개되었습니다(FBI는 TraderTraitor 클러스터를 지목했습니다).
뚫리지 않은 것
- Safe 컨트랙트가 아닙니다. 유효하게 서명된 명령을 실행했을 뿐입니다. Safe의 버그가 악용된 것이 아닙니다.
- 암호학도 아닙니다. 모든 서명은 진짜였습니다.
- 하드웨어 지갑도 아닙니다. Ledger 기기가 경로에 있었고, 그럼에도 서명했습니다.
하드웨어 지갑은 건네받은 것을 보여 줄 뿐이고, 건네받은 것이 악성 페이로드였기
때문입니다.
delegatecall을 사람이 판단할 수 있는 형태로 풀지 못하는 기기가 지키는 것은 키이지 결정이 아닙니다.
뚫린 것은 모든 지갑 인터페이스 밑에 깔린 가정입니다. 거래를 설명하는 화면과 서명되는 바이트가 같은 것이라는 가정 말입니다.
이것이 예외가 아니라 일반적인 경우인 이유
당신이 웹 지갑에서 만든 모든 서명은 그 가정 위에 있었습니다. 인터페이스가 페이로드를 만들고, 인터페이스가 요약을 그리며, 둘이 일치하는지 독립적으로 확인하는 것은 없습니다. 그 인터페이스를 서비스하는 코드가 교체되면 — 장악된 빌드 파이프라인, 탈취된 CDN, 악성 의존성, 훔친 배포 자격증명 — 요약은 공격자가 원하는 무엇이든 되고, 당신의 서명은 진짜가 됩니다.
이것이 Vela의 서명 설계가 겨냥하는 위험입니다. 피싱도, 유출된 키도 아니고, 당신에게 거짓말을 하는 서명 화면입니다.
Vela는 무엇을 하는가
calldata까지 가는 클리어 서명. 모든 거래는 승인 전에 사람이 읽을 수 있는 의도로
바뀝니다 — 금액, 받는 사람, 그 호출이 실제로 무엇을 하는지
(ERC-7730). 해독하지 못한 호출은 괜찮은 척 조용히 그려지는
대신 해독 불가로 표시됩니다. 바이비트의 페이로드는 구현 주소를 바꿔치기하는 delegatecall이었습니다. 바로 그런 것이 서명자를 멈춰 세워야 하고, 친절한 요약 뒤에
숨었기에 멈추지 못한 것입니다.
인터페이스를 검산할 수 있는 독립 경로. Vela는 빌드도 의존성도 없는 서명 페이지를 만들고 있습니다. 의도를 스스로 그리고 WebAuthn 서명도 스스로 수행하는, 처음부터 끝까지 읽을 수 있고 직접 서비스할 수 있으며 브라우저 확장으로도 돌아가는 정적 파일 폴더입니다. 존재 이유는 본 앱과 공급망을 공유하지 않는 두 번째 의견이 되는 것입니다. 상태: 제작과 테스트 완료, 아직 배포 전. 공개되면 선택 기능이고, 상황이 바뀌면 이 페이지에 그대로 적겠습니다.
우리가 업그레이드할 수 있는 컨트랙트는 없습니다. 바이비트의 페이로드는 계정의 구현을 바꿔치기해 작동했습니다. Vela의 계정은 수정하지 않은 Safe v1.4.1이고, Vela는 거기에 특권적 역할이 없습니다. 관리자 키도, 강요나 침해로 쓰일 수 있는 업그레이드 경로도 없습니다.
서명마다 생체 인증을 새로 합니다. 오래 사는 세션 키가 없으므로, 당신이 없는 사이 무언가가 대신 서명할 수 있는 창이 존재하지 않습니다.
최후의 보루로서의 셀프 호스팅. 앱과 모든 백엔드 서비스가 오픈소스입니다. 우리의 빌드 파이프라인을 전혀 신뢰하고 싶지 않다면 직접 돌리세요. 이런 부류의 공격에 대해 누구도 신뢰하지 않아도 되는 답은 그것뿐입니다.
Vela가 주장하지 않는 것
Vela의 프런트엔드도 Safe{Wallet}과 같은 방식으로 침해될 수 있습니다. 우리 코드는
감사받지 않았습니다. 그보다 더 듣기 좋게 말하는 것이야말로, 이 사건이 끝냈어야 할
종류의 보증입니다.
이 설계가 하려는 일은 경로를 좁히는 것입니다. 페이로드를 불투명한 덩어리가 아니라 읽을 수 있게 만들고, 공격이 기댄 업그레이드라는 수단을 없애고, 우리가 아닌 것으로 검증할 방법을 주는 것. 솔직한 요약은 이렇습니다. 이 부류의 공격은 설계로 약화되었을 뿐, 사라지지 않았습니다. 그리고 더 단단하게 만들 부분들은 미완성인 채로 감사와 알려진 문제에 적혀 있습니다.