Binance의 63억 달러 규모 사고: 발생 경위와 위험을 줄이는 방법

Binance의 예비 조사에 따르면 6월과 9월에 직원 기기가 침해됐고, 10월 20일에는 내부 AI 도구를 통해 침입 범위가 확대됐습니다. 공격자는 동료 두 명의 컴퓨터에 접근해 컨테이너 배포용 토큰을 발견했습니다. 10월 29일에는 그 토큰으로 악성 코드를 배포해 지갑 서명 시스템에 접근하고 무단 이체를 시작했습니다.

공격자는 서명 서비스를 이용해 EIP-7702 위임도 생성했습니다. 이는 공격자가 제어하는 코드에 Ethereum 지갑을 대신해 동작할 권한을 부여하는 것입니다. 그 권한은 Binance의 출금 시스템과 독립적으로 블록체인에 존재했습니다. 출금을 중단해도 제거되지 않았기 때문에 Binance는 별도의 온체인 철회를 수행해야 했습니다.

중요한 차이는 활동을 중단하는 것과 그 활동의 바탕이 되는 권한을 제거하는 것 사이에 있습니다. 기기 교체, 배포 자격 증명 폐기, 다른 시스템 내부의 권한 철회는 각각 침입의 다른 부분에 대응합니다.

노트북, 배포 시스템, 민감한 서비스는 서로 다른 일을 합니다. 하나에 대한 접근이 다음 시스템의 접근으로 자동 연결되면 위험이 커집니다. 도난당한 토큰으로 공격자가 소프트웨어를 교체할 수 있고, 그 소프트웨어는 직원 본인이 직접 보유하지 않았던 권한으로 동작할 수 있습니다.

다음 네 가지 질문은 이 확산을 어디서 차단할지 파악하는 데 도움이 됩니다.

1. 자격 증명 노출. 공격자가 직원 한 명의 기기에서 어떤 프로덕션 접근 권한을 얻을 수 있습니까?
2. 배포 권한. 그 접근 권한으로 실행되는 코드를 누가 변경할 수 있습니까?
3. 서비스 권한 검증. 민감한 서비스는 그 코드의 어떤 작업 요청을 받아들입니까?
4. 지속되는 접근 권한. 원래 계정을 비활성화한 뒤에도 어떤 새로운 권한이 남을 수 있습니까?

목표는 시스템 사이에서 권한이 전달되는 범위를 제한하고, 침입 중에 생성된 추가 접근 권한을 식별해 철회하는 것입니다. 다음 절에서는 이 목표를 뒷받침하는 네 가지 통제를 살펴봅니다.

통제 1. 노트북에서 노출될 수 있는 자격 증명 줄이기

자격 증명이 공격자에게 유용한 이유는 다른 시스템이 이를 권한의 증거로 받아들이기 때문입니다. 직원 기기에 두는 프로덕션 자격 증명을 줄이면 도구, 저장소 또는 브라우저 세션이 침해됐을 때 도난당할 수 있는 항목도 줄어듭니다.

일상 업무에서 직원에게 필요한 것은 서비스 재시작과 같은 작업을 요청할 권한인 경우가 많습니다. 실제 수행에 사용하는 자격 증명은 별도의 실행 ID가 보유할 수 있습니다. 따라서 노출을 줄이려면 불필요한 사본을 제거하는 동시에 남아 있는 자격 증명을 관리해야 합니다.

• 가능한 경우 일상적인 직접 접근을 범위가 명확히 제한된 작업으로 대체합니다.
• 업무별로 별도의 ID를 사용하고 권한 범위와 유효 기간을 제한합니다.
• 자격 증명과 소유자, 폐기 방법을 목록으로 관리합니다.

이는 OWASP의 시크릿 관리 지침에 제시된 원칙, 즉 사람이 시크릿을 직접 다루는 일을 줄이고 각 ID에 필요한 접근 권한만 부여하는 방식을 적용한 것입니다. 워크스테이션이 도난당하거나 침해돼도 재사용 가능한 자격 증명이 덜 노출되고, 대응 담당자는 여전히 폐기해야 할 자격 증명의 소유자가 누구인지 알 수 있습니다.

통제 2. 배포 권한을 프로덕션 특권으로 취급하기

시크릿을 사람에게 숨겨도 그 사람이 배포하는 코드에서는 사용할 수 있습니다. 그 코드를 변경할 수 있는 사람은 시크릿을 읽거나 내부 API를 호출하거나 애플리케이션 서비스 계정으로 동작할 수 있습니다. 따라서 배포 접근 권한은 결과적으로 실행되는 워크로드의 권한을 기준으로 평가해야 합니다.

OWASP의 CI/CD 보안 지침은 저장소 변경, 파이프라인 구성, 실행 호스트를 하나의 보안 문제를 구성하는 요소로 다룹니다. 보호 범위는 배포 전 코드와 배포 후 권한을 모두 포함해야 합니다.

• 프로덕션 코드 검토를 의무화하고 자동화가 실행하는 저장소 브랜치를 보호합니다.
• 주요 스크립트뿐 아니라 작업 정의, 의존성, 실행 시 입력의 변경도 통제합니다.
• 워크로드에는 기능에 필요한 자격 증명과 네트워크 접근 권한만 부여합니다.

두 통제 집합은 함께 작동해야 합니다. 저장소와 배포 권한은 누가 코드를 변경할 수 있는지 결정합니다. 별도의 ID, 호스트, 네트워크 정책은 실행된 코드가 할 수 있는 일을 제한합니다. 중앙 시크릿 저장소는 노출을 줄이고, 이러한 정책은 시크릿을 사용하는 프로그램을 제약합니다.

통제 3. 호출자뿐 아니라 작업 자체의 권한 검증하기

서명 서비스는 개인 키를 숨긴 상태에서도 유해한 서명 요청을 받아들일 수 있습니다. 데이터베이스나 클라우드 API에도 같은 구분이 적용됩니다. 워크로드 인증은 호출자가 누구인지 식별하고, 권한 검증은 무엇을 해도 되는지 결정합니다.

OWASP는 모든 요청에서 권한을 검증하고 명시적으로 허용되지 않은 접근을 거부할 것을 권장합니다. 요청을 받는 서비스에서는 허용된 송금 대상과 금액, 데이터베이스 작업, 인프라 변경처럼 작업과 대상을 모두 확인해야 합니다.

호출자가 이미 신뢰할 수 있는 주체라도 요청된 작업을 평가하는 서비스가 되어야 합니다. 자동화는 업무 요청 방식을 관리하고, 요청을 받는 서비스는 어떤 작업을 받아들일지 관리합니다.

통제 4. 침입 중에 생성된 접근 권한 철회하기

공격자는 정상 ID를 사용해 다른 자격 증명을 추가하거나 더 많은 권한을 부여할 수 있습니다. MITRE ATT&CK는 계정 조작을 클라우드 자격 증명과 SSH 키 추가 등을 통해 접근을 유지하거나 확대하는 방법으로 설명합니다. 원래 세션을 비활성화해도 이러한 변경 사항이 반드시 제거되지는 않습니다.

Binance의 온체인 위임 사례는 대응 담당자가 영향을 받은 시스템 자체의 권한을 조사해야 하는 이유를 보여줍니다. 봉쇄에는 최초 침입 거점과 그 거점을 통해 생성된 권한을 모두 포함해야 합니다.

• 추가 자격 증명을 만들거나 권한을 부여할 수 있는 자동화 ID를 제한합니다.
• 새로 생성된 계정, 세션, 위임을 대응 계획에 포함합니다.
• 작업이 중단됐다는 이유로 봉쇄가 완료됐다고 판단하지 말고, 실제로 권한을 적용하는 시스템에서 철회를 검증합니다.

이 단계를 따르면 대응 담당자는 조사하고 철회해야 할 ID와 권한의 범위를 명확히 파악할 수 있습니다. 또한 봉쇄를 검증할 수 있습니다. 영향을 받은 서비스에 이르는 알려진 경로가 실제로 각각 차단됐는지 확인할 수 있기 때문입니다.

이 통제들은 직원 기기, 배포 시스템, 요청을 받는 서비스, 대응 프로세스라는 서로 다른 계층에서 작동합니다. 각 계층에는 담당자와 함께 다른 계층이 침해돼도 제약이 유지되는지 확인할 방법이 필요합니다.

자동화 관리 플랫폼은 직원의 요청에서 프로덕션 실행까지 이어지는 구간의 문제를 다룹니다. Semaphore UI에서는 팀이 정의된 작업을 준비하고, 실행하거나 변경할 수 있는 사람을 통제하며, 별도의 ID로 실행할 수 있습니다. 대상 서비스 내부의 권한 검증과 다른 곳에서 생성된 권한의 철회는 여전히 해당 시스템과 대응 팀의 책임입니다.

API 서비스를 재시작해야 하는 온콜 엔지니어를 예로 들어 보겠습니다. 유지보수 담당자는 대상 호스트와 재시작 방식을 고정한 플레이북과 Task Template을 준비합니다. 엔지니어는 프로덕션에 SSH 세션을 열지 않고 작업을 시작한 뒤 결과를 확인합니다. 아래 두 경로는 같은 재시작을 수행하지만 실행 자격 증명을 보유하는 주체가 다릅니다.

재시작 워크플로는 제한된 실행 ID 생성, 사용자의 실행 및 변경 범위 정의, 실행 환경 선택, 결과 가시화라는 네 가지 연결된 단계로 구성됩니다. 이 단계가 갖춰지면 같은 접근법을 배포에도 확장할 수 있습니다.

도난당한 운영자 세션으로도 해당 계정에 허용된 작업을 요청할 수 있습니다. 허용된 재시작도 반복적으로 실행되면 서비스를 방해할 수 있습니다. 스테이징 환경에서 실제에 가까운 운영자 계정으로 구성된 워크플로를 테스트하고, 가능한 작업과 악용에 대한 팀의 대응을 함께 확인합니다.

• 작업과 입력 권한. 다른 브랜치, 인벤토리, 인수를 포함해 실제 역할과 실행 시 옵션을 시험합니다.
• 의도한 작업 범위를 벗어난 접근. runner 프로세스가 접근할 수 있는 범위를 포함해 다른 템플릿, 자격 증명, 프로덕션 시스템에 대한 접근을 확인합니다.
• 탐지와 운영 영향. 결과를 받는 사람, 예상치 못한 활동을 조사하는 사람, 반복 실행이 허용할 수 없는 장애를 일으키는지 확인합니다.
• 권한 철회. 세션 및 토큰 폐기를 테스트하고 실행 ID가 다른 곳에 생성할 수 있는 권한을 파악합니다.

테스트 계정에 남아 있는 접근 권한을 문서화하고 작업 목적을 벗어나는 경로를 차단합니다. 훈련을 마치면 팀은 도난당한 세션으로 무엇을 할 수 있는지, 악용을 어떻게 탐지하고 봉쇄할지 모두 알고 있어야 합니다.

접근 통제는 엔드포인트 보호와 대응 방법을 아는 팀이 함께할 때 작동합니다. 준비된 워크플로를 충분히 편리하게 만들어 공유 키나 문서화되지 않은 우회 방법으로 돌아가지 않도록 합니다. 다음과 같은 일상적인 실천으로 이를 뒷받침합니다.

• 익숙하지 않은 설치 프로그램과 면접 과제는 기업 자격 증명, 호스트 마운트, 내부 네트워크 접근이 없는 일회용 격리 환경에서 실행합니다.
• 의심스러운 활동을 비난받을 걱정 없이 조기에 쉽게 신고할 수 있게 합니다. 명확한 연락 창구와 사고 대응 경로를 제공합니다.
• 업무가 바뀌면 접근 권한을 검토하고, 통제된 비상 접근 절차를 유지하며, 사고 전에 권한 철회 훈련을 합니다.

이러한 실천은 예방, 탐지, 복구를 일상 업무에 연결합니다. 책임이 바뀌어도 접근 모델을 정확히 유지하고, 의심스러운 사건이 발생했을 때 팀이 익숙한 절차로 대응하도록 돕습니다.

핵심 교훈은 침해된 하나의 ID가 축적할 수 있는 권한을 제한하는 것입니다. 노트북의 자격 증명 축소, 검토된 자동화, 제한된 실행 호스트, 프로덕션 서비스 내부의 권한 검증은 각각 공격자가 이용할 수 있는 경로를 줄입니다.

Semaphore는 준비된 작업, 실행과 편집 권한의 분리, 중앙에서 제공되는 자격 증명, 확인 가능한 실행 기록을 통해 이러한 통제 중 일부를 반복 가능한 워크플로로 만듭니다. 운영자는 업무에 필요한 작업을 수행하고, 유지보수 담당자는 그 뒤의 코드와 자격 증명을 계속 통제합니다.

자주 사용하는 프로덕션 작업 하나부터 시작합니다. 작업 템플릿을 준비하고 필요한 운영자 권한을 부여한 뒤, 대체할 직접 연결을 폐지하기 전에 실제 접근 범위를 테스트합니다. 유용한 진척 지표는 다음에 침해된 계정으로 공격자가 할 수 있는 일을 얼마나 줄였는가입니다.