요약
북한 해커가 가짜 채용 면접으로 바이낸스 엔지니어의 컴퓨터를 뚫어 63억 달러를 빼돌렸습니다.
바이낸스가 11월 3일 공개한 사고 보고서를 더레지스터가 정리했습니다. 미국 연방수사국(FBI)은 이번 탈취를 라자루스 그룹과 연결된 북한 조직 트레이더트레이터(TraderTraitor)의 소행으로 지목했습니다.
왜 중요한가
- 단순한 피싱 한 번이 아니었습니다. 몇 달에 걸쳐 엔지니어들을 차례로 장악한 다단계 공격이었습니다.
- 개발자 컴퓨터에 남아 있던 배포 권한 토큰 하나가 거래소 지갑 시스템으로 들어가는 통로가 됐습니다.
- 사내 AI 도구도 공격 경로로 쓰였습니다. 바이낸스는 블록체인 환경의 AI 보안 연구를 지원하겠다고 밝혔습니다.
핵심 내용
- 9월 한 엔지니어가 구직 플랫폼에서 가짜 회사의 면접 제의를 받았고, CEO를 사칭한 면접관이 악성코드가 든 과제를 내려받게 했습니다.
- 악성코드는 pyenv 관련 개발 도구 구성 요소를 바꿔치기했고, 바이낸스의 보안 도구는 이를 바로 잡아내지 못했습니다.
- 공격자는 10월 20일 사내 AI 도구를 거쳐 지갑 담당 엔지니어 두 명의 컴퓨터에 들어가 컨테이너 배포 토큰을 찾아냈습니다.
- 10월 29일 공격자는 이 토큰으로 컨테이너를 배포해 탈취 스크립트를 실행했습니다.
- 6월의 첫 침입은 적발됐지만, 그때 지갑 인프라 팀의 구성과 역할이 공격자에게 이미 드러났습니다.
HN 반응
- 일부 이용자는 개발자 컴퓨터에 배포 토큰이 있었던 것이 더 큰 문제라며 배포는 CI(자동 빌드·배포 시스템)로만 해야 한다고 지적했습니다.
- 대규모 이체 제한은 소액 이체를 빠르게 반복하는 방식에 뚫렸고, 지갑을 스마트 계약으로 바꾸는 EIP-7702 거래에 서명한 것이 핵심 허점이었다는 분석도 나왔습니다.
많은 분이 엔지니어가 업무용 컴퓨터를 너무 무책임하게 썼다는 점에 주목하는데, 그것도 분명 문제지만 제가 보기에 더 큰 실패는 엔지니어 C의 컨테이너 배포 토큰입니다.
이건 아주 큰 위험 신호입니다. 이 정도 규모의 회사라면 배포는 CI로만 해야 합니다. CI는 배포의 속도와 안정성을 높이려고 쓰는 것만이 아니라, 소프트웨어를 깨끗한 환경에서 빌드하게 해 주는 장치이기도 하니까요. 잠깐 복사해서 붙여 넣는 토큰이라 해도, 시스템이 내 PC에서 1. 복사하고 2. 붙여 넣고 3. 토큰 지우는 걸 잊지 말라고 요구하는 구조여선 안 됩니다.
또 바이낸스는 침투 테스트에 돈을 썼어야 합니다. 믿을 만한 업체에 비용을 내고 맡기는 편이, 북한이 직접 시범을 보이게 두는 것보다 낫습니다. 이번과 똑같은 공격 경로를 찾아냈을 것 같진 않지만, 침투 테스트였다면 엔지니어 C의 토큰을 악용할 다른 방법은 분명 찾아냈을 거라고 생각합니다.
회사 전체를 통틀어 수십억 달러어치 암호화폐를 옮길 수 있는 사람은 아무도 없어야 합니다. 배포 과정에 참여하는 평범한 엔지니어라면 더더욱 그렇고요.
대량 이체를 막는 통제 장치는 있었어요. 그래서 공격자들이 아주 빠르게 소액 이체를 잔뜩 하는 식으로 쪼갰던 거죠.
그럼 "소액 이체가 아주 빠르게 반복되는 것"을 막는 통제도 따로 있어야겠네요.
"소액 이체를 아주 빠르게 처리하는 것"이 바이낸스가 하는 일의 핵심 아닌가요?
사후에 말하기는 참 쉽죠! 일이 터지기 전에 내놓을 수 있는 방안이라도 있나요?
그뿐만이 아니에요! EIP-7702 위임으로 지갑을 스마트 컨트랙트로 바꿔 버리는 바람에, 서명자에 걸어 둔 통제가 전부 우회됐거든요. 그 트랜잭션 유형은 서명 자체를 못 하게 막는 장치가 없었다는 게 어이가 없네요.
제가 대충 이해한 바로는 이게 핵심 공격 같습니다. 지갑 키에 접근할 수 있는 머신이 이상한 EIP-7702 트랜잭션을 받아 서명했고(그러면 트랜잭션 한 번으로 사실상 그 지갑이 넘어갑니다)[1]. 보안 모델을 알 수는 없지만, 가장 중요한 신뢰 경계는 그 서명 머신과 나머지 모든 것 사이에 있어야 할 것 같습니다.
[1] 경쟁 상태(race condition)를 풀려고 이런 트랜잭션에 50번이나 서명해야 했다는 건 구현상의 세부 사항으로 보입니다.
암호화폐에는 정족수 서명(quorum signing) 같은 게 없나요?
이더리움에서는 계정을 스마트 컨트랙트 코드에 연결한 다음 개인 키를 버려서, 스마트 컨트랙트를 통해서만 트랜잭션을 만들 수 있게 하는 식으로 구현합니다. 이번에 서명한 게 바로 그 스마트 컨트랙트 코드에 연결하는 승인이었습니다. 다만 멀티시그 스마트 컨트랙트가 아니라 악성 코드였다는 점이 다릅니다.
있긴 합니다. 그런데 그게 이 건과 어떻게 이어지는지는 모르겠네요.
불만을 품은 직원이라면 똑같은 짓을 못 하겠어요?
「뉴 오피스 스페이스」 줄거리가 딱 그거잖아요!
「슈퍼맨 3」도 그렇습니다. 그쪽이 먼저 나왔고, 각본가들도 아마 잘 알고 있었을 겁니다. 다만 이 수법과 악명은 훨씬 오래전으로 거슬러 올라갈 것 같다는 생각이 듭니다(귀금속 주화를 깎아 내거나 질을 떨어뜨리는 일 같은 것 말이죠). 가난한 사람이 빵을 훔치는 이야기 같은 윤리적 질문이나 "현실이 그저 꿈이라면?" 같은 사고 실험처럼, 대부분의 사람이 성장기에 한 번쯤 마주치는 주제입니다. 하지만 늘 그렇듯 이론과 실행 사이의 간극은 건너기 가장 어렵습니다(정작 중요한 때에 현실의 가능성을 알아보는 것조차 그렇고요).
영화에서도 그 얘기가 나와요.
https://en.wikipedia.org/wiki/Salami_slicing_tactics
60년대 피터 유스티노프 영화도 있어요.
이럴 때 밀턴은 어디 있는 거죠??
대부분의 직원은 자금에 아예 손댈 수 없어야 하고, 소수만 가능하되 그나마도 상사의 확인(이중 인증)이 필요해야 합니다.
그야 맞는 말인데, 직접 배포할 수 있는 한 공격자에게 권한 모델은 의미가 없지 않나요? 그냥 지워 버리면 되니까요.
저도 지난 직장에서 가장 먼저 한 일 중 하나가 이런 작업을 팀원들 컴퓨터에서 걷어 내는 것이었습니다. 보안 문제는 둘째치고, 멍청한 실수 한 번이면 됩니다. 위 화살표 키를 한 번 더 누르거나 한 줄을 끝까지 읽지 않으면, 어느새 실수로 프로덕션에 뭔가를 하고 있게 되니까요!
저도 그렇게 했습니다. 로컬에서 체인으로 스마트 컨트랙트를 배포하던 팀이었어요.
파이프라인을 팀원 노트북에서 빼내는 데 두어 달이 걸렸습니다.
그만한 가치가 있었죠. 그 안에서 흥미로운 것들이 나왔는데, 그 팀이 왜 업그레이드 배포를 그렇게 꺼렸는지가 설명되더군요.
...개발자가 CI에는 드러나지 않게 자기만의 익스플로잇을 배포할 수 있는 백도어였나요?
아뇨, 그보다는 라이브러리를 몽키 패치해 놓고, 컴파일러 여러 버전에 별칭을 걸고, 원하는 설정에서 되다 안 되다 하는 환경 변수가 수십 개 얽힌 특수한 환경이었습니다.
시크릿 저장과 관련된 어떤 작업을 팀 컴퓨터에서 빼낼 수 있었나요? 제 입장에서는 트위터에서 API 키를 받아 프로덕션 환경에 넣어야 한다면, 어쨌든 제 컴퓨터로 그 작업을 해야 하거든요. 사람 손으로 옮겨 줘야 하는 시크릿 종류가 아직도 수없이 많습니다.
맞습니다. 하지만 그 사람이 개발자여선 안 되고, 정해진 절차에 따라 일하는 관리자여야 합니다.
권한 분리는 가장 기본인데도 요즘은 완전히 무시되는 것 같습니다.
솔직히 CI가 이런 실수를 막아 주진 않아요. 엉뚱한 CI 파이프라인을 실행하는 사람도 봤거든요.
사람이 파이프라인을 실행한다는 것 자체가 이미 문제의 일부 아닐까요.
뭘 하든 결국 어딘가에서는 사람이 어떤 행동을 하고, 그게 몇 겹의 간접 단계를 거쳐 프로덕션 변경으로 이어집니다. 전설 속의 완전 자동화된 에이전트형 소프트웨어 공장이 아닌 이상은요.
기사에 따르면 소프트웨어 엔지니어 한 명이 북한 측과 면접을 봤고, 북한은 그 후 (배포 토큰이 있던) 엔지니어 A의 머신에 접근했습니다. 그런 다음 그 토큰을 (실제로 배포를 맡았던 것으로 보이는) 엔지니어 C의 머신에서 실행되도록 넘겼고요. 북한은 첫 번째 시도(적발됐던 것)를 통해 팀 구성을 이미 알고 있었습니다.
면접용 소프트웨어를 내려받아 자기 머신에서 실행한 그 어수룩한(미안하지만) 엔지니어가 여기서 사람이라는 약한 고리입니다. 그 사람을 엔지니어 F라고 부르죠. 개발팀에서 일부러 골라낸 사람 같습니다.