Xbox 해킹이 하드웨어 보안 모델에 주는 교훈

Microsoft는 Xbox One의 보안 아키텍처를 뚫을 수 없도록 설계했습니다. 하드웨어 신뢰 루트(root of trust), 커스텀 하이퍼바이저, 콘솔별 키로 암호화된 스토리지, 그리고 각 단계가 다음 단계를 검증하는 서명된 부팅 체인까지 갖췄습니다. 이것은 보안 연출이 아니라, 업계 최고 수준의 보안 엔지니어링 팀이 설계한 정교한 다층 방어였습니다. 그들은 이 시스템을 '해킹 불가능'하다고 불렀습니다.

그런데 이제 해킹당했습니다. 'Bliss'라는 그룹이 Xbox One에서 전체 코드 실행 권한을 얻었고, 하이퍼바이저, 부팅 체인 검증, 하드웨어 보안 프로세서를 모두 우회했습니다. 익스플로잇의 세부 내용도 흥미롭지만, 더 흥미로운 것은 하드웨어 보안의 근본적인 한계가 무엇인지 드러낸다는 점, 그리고 왜 '해킹 불가능'이라는 말이 늘 위험한지를 보여준다는 점입니다.

Xbox 보안 아키텍처

이 해킹이 왜 중요한지 이해하려면, 무엇이 뚫렸는지부터 알아야 합니다. Xbox One의 보안 모델은 소비자용 하드웨어에 탑재된 보안 구현 중 가장 철저한 사례 중 하나입니다.

부팅 과정은 하드웨어 신뢰 루트에서 시작합니다. SoC에 새겨져 있어 수정할 수 없는 코드입니다. 이 코드가 다음 단계인 부트로더를 검증하고 로드하며, 부트로더는 하이퍼바이저를, 하이퍼바이저는 OS를 검증하고 로드합니다. 각 단계는 Microsoft의 키로 서명되어 있고, 하나라도 검증에 실패하면 콘솔은 부팅되지 않습니다. ARM TrustZone이나 Intel Boot Guard가 제공하는 것과 비슷한 전형적인 보안 부팅 체인입니다.

하이퍼바이저는 운영체제보다 높은 권한 수준에서 동작하는 자체 개발 소프트웨어로, 메모리 격리를 강제하고 하드웨어 접근을 통제하며, OS가 핵심 시스템 상태를 바꾸지 못하게 막습니다. 게임과 앱은 서로의 메모리를 보거나 수정할 수 없는 가상 머신에서 실행됩니다. 따라서 Xbox OS에서 커널 익스플로잇을 찾아도, 여전히 하이퍼바이저라는 샌드박스 안에 갇히게 됩니다.

여기에 더해, 콘솔의 스토리지는 하드웨어 보안 프로세서에서 파생된 키로 암호화됩니다. 하드 드라이브를 떼어 다른 기기에서 읽어봐야 쓸 만한 것은 아무것도 꺼낼 수 없습니다. 암호화 키는 특정 하드웨어에 묶여 있는데, 이는 기기 고유 봉인(device-specific sealing)이라 불리는 설계로, TPM이나 Apple의 Secure Enclave에서도 사용됩니다.

방어막이 갈라진 지점

모든 보안 시스템에는 가정이 있습니다. Xbox의 가정들은 합리적이었습니다. 하드웨어 신뢰 루트는 변경 불가능하고, 암호화가 견고하니 부팅 체인은 깨질 수 없으며, 하이퍼바이저는 작고 감사를 거친 코드베이스이니 악용 가능한 버그가 없다는 것입니다. 각 가정은 개별적으로는 충분히 방어 가능합니다. 문제는 보안 체인이 가장 약한 고리에서 끊어지고, 그 고리를 찾으려면 무차별 대입이 아니라 창의성이 필요하다는 점입니다.

Bliss 익스플로잇은 암호화를 공격하지 않았습니다(AES와 RSA는 멀쩡합니다). 신뢰 루트 ROM의 버그를 찾지도 않았습니다(코드가 작고 검증이 잘 되어 있습니다). 키를 무차별 대입으로 알아내지도 않았습니다. 대신 보안 도메인 사이의 인터페이스, 즉 신뢰된 영역과 신뢰되지 않은 영역이 소통하는 좁은 통로를 노렸습니다.

하드웨어 보안 모델은 신뢰 수준 사이의 공격 표면이 최소일 때 가장 강합니다. 하지만 '최소'가 '0'을 의미하지는 않습니다. 하이퍼바이저는 게스트 OS에 메모리 관리, 장치 접근, 가상 머신 간 통신을 위한 시스템 호출 같은 인터페이스를 어느 정도 노출해야 합니다. 이 인터페이스 하나하나가 잠재적 공격 벡터입니다. Bliss 팀은 특정 순서로, 특정 파라미터와 함께 호출했을 때 하이퍼바이저의 내부 상태를 손상시켜 코드 실행 흐름을 바꿔버리는 호출 시퀀스를 찾아냈습니다.

더 넓은 패턴

Xbox 해킹은 하드웨어 보안 전반에서 반복되는 패턴을 따릅니다. 초기 보안 설계는 탄탄하고 구현도 신중하지만, 보안 도메인 사이의 인터페이스에 미묘한 버그가 숨어 있고, 이는 적대적인 환경에서 사용될 때만 드러난다는 것입니다.

• PS3 해킹(2010)은 Sony의 ECDSA 서명 생성에서 치명적인 구현 오류를 악용했습니다. 서명마다 새로운 난수를 써야 했는데 고정된 난수를 사용해서, 개인 키가 그대로 노출되었습니다. 수학은 옳았지만 구현이 그렇지 않았습니다.
• 닌텐도 스위치 해킹(2018)은 NVIDIA Tegra 부트 ROM의 버그를 노렸습니다. USB 복구 모드가 버퍼를 넘치게 하는 페이로드를 받아들였고, 소프트웨어 보안 검사가 실행되기 전에 코드 실행을 허용했습니다. 부팅 체인은 잘 설계되었지만, 복구 모드는 위협 모델에 포함되지 않았습니다.
• Intel SGX 공격은 격리 모델이 아키텍처상 올바른데도, 사이드 채널(Spectre, Meltdown 및 수많은 변종)을 통해 보안 enclave에서 데이터가 새어 나갈 수 있음을 반복해서 보여주었습니다. 논리는 옳지만, 마이크로아키텍처가 정보를 누출합니다.

패턴은 이렇습니다. 설계자는 한 추상화 수준(암호 프로토콜, 격리 경계, 신뢰 계층)에서 보안 모델을 생각하고, 공격자는 다른 수준(구현상의 특이점, 마이크로아키텍처 부작용, 인터페이스의 가장자리 사례)에서 움직입니다. 모델은 맞지만, 구현에는 모델이 고려하지 못한 틈이 있습니다.

'해킹 불가능'이라는 말이 항상 틀린 이유

무언가를 해킹 불가능하다고 부르는 것은 신뢰의 신호가 아니라 경고등입니다. 설계자가 가능한 모든 공격을 열거했고 그 모두를 막았다고 믿는다는 뜻이기 때문입니다. 하지만 보안의 역사는, 방어를 설계할 당시에는 존재하지 않았던 공격 유형들의 역사입니다.

Xbox One이 2013년에 출시됐을 때 Spectre와 Meltdown은 아직 발견되지 않았고, Rowhammer는 이론에 가까웠으며, 최신 SoC에 대한 전압 글리칭 공격도 잘 알려져 있지 않았습니다. 설계자들은 아직 발명되지도 않은 공격을 막을 수 없었습니다. 게다가 당시에는 비현실적이라고 여겨졌던 일부 예상 공격도, 도구와 기법이 발전하면서 실현 가능해졌습니다.

좋은 보안 엔지니어링은 완벽한 불침투성을 주장하지 않습니다. 침해는 일어날 수밖에 없음을 인정하고, 탐지, 격리, 복구를 위해 설계합니다. 성숙한 보안 사고와 미숙한 보안 사고의 차이는 '어떻게 하면 이것을 깨지지 않게 만들까?'와 '이것이 깨지면 어떻게 될까?'의 차이입니다.

소프트웨어 개발자에게 주는 시사점

대부분의 개발자는 콘솔 보안 아키텍처를 설계하지 않지만, 여기서 얻을 교훈은 넓게 적용됩니다.

신뢰 경계 사이의 인터페이스가 가장 위험한 코드입니다. 백엔드와 공개 인터넷 사이, 애플리케이션과 서드파티 플러그인 사이, 데이터베이스와 사용자 입력 쿼리 사이의 경계가 그렇습니다. 실제로 문제가 되는 버그는 대개 여기에 있습니다. SQL 인젝션은 SQL이나 데이터베이스의 버그가 아니라, 신뢰된 영역(쿼리 로직)과 신뢰되지 않은 영역(사용자 입력) 사이의 인터페이스에서 생기는 버그입니다. 보안에 신경을 쓴다면 바로 이 경계에 집중해야 합니다.

심층 방어는 선택이 아닙니다. Xbox에는 하드웨어 신뢰 루트, 보안 부팅, 하이퍼바이저 격리, 스토리지 암호화 등 여러 겹의 방어가 있었습니다. 한 겹을 뚫는 것만으로는 충분하지 않았고, 공격자는 여러 익스플로잇을 연쇄적으로 조합해야 전체 제어권을 얻을 수 있었습니다. 시스템이 단일 보안 경계에만 의존했다면, 첫 번째 익스플로잇으로 게임은 그대로 끝났을 것입니다.

위협 모델은 언젠가 틀립니다. 설계가 허술해서가 아니라 위협 환경이 계속 변하기 때문입니다. 권한 상승의 역사는 방어를 설계할 당시에는 상상조차 할 수 없었던 공격들로 가득합니다. 재설계 없이도 업데이트, 패치, 강화가 가능한 시스템을 만드세요. 오늘의 '불가능한' 공격이 내일의 CVE가 된다고 가정하세요.

열린 보안의 역설

콘솔 보안은 비밀에 기대고 있습니다. 독점 하드웨어, 비공개 하이퍼바이저, 암호화된 펌웨어가 그렇습니다. 이는 보안 커뮤니티가 대체로 약한 접근으로 보는 '은닉을 통한 보안(security through obscurity)'입니다. 그렇다고 오픈소스 보안 하드웨어가 답이라고 하기도 어렵습니다. 공격자가 정확한 구현을 여유롭게 연구하며 취약점을 찾을 수 있기 때문입니다.

실용적인 답은, 두 접근 모두 결국 실패한다는 것입니다. 닫힌 시스템은 리버스 엔지니어링을 당합니다(Xbox 해킹이 바로 그 증거입니다). 열린 시스템은 연구되고 공격당합니다(끊임없이 나오는 Linux 커널 CVE가 그 증거입니다). 차이는 열린 시스템이 방어 측도 공격 측과 같은 시야를 갖기 때문에 더 빨리 고쳐진다는 점입니다. Xbox의 취약점은, 세부 내용이 무엇이든, 보안 모델이 현장에서 교체할 수 없는 하드웨어에 박혀 있기 때문에 패치하기가 훨씬 어려울 것입니다.

업데이트가 가능한 소프트웨어 시스템이라면, 이는 독점 구현보다 공개되고 충분히 감사된 보안 구현을 강하게 지지하는 근거가 됩니다. 열린 시스템이 공격하기 어려워서가 아니라, 피할 수 없는 공격이 성공했을 때 고치기가 더 쉽기 때문입니다.

앞으로의 전망

Xbox 해킹이 콘솔 보안의 종말을 가져오지는 않을 것입니다. Microsoft는 익스플로잇을 분석하고, 소프트웨어로 가능한 부분을 패치하며, 다음 세대 하드웨어에서 이런 종류의 취약점을 막도록 설계할 것입니다. 공격자는 또 다른 무언가를 찾아낼 것입니다. 이것이 사이클입니다. 방어와 공격이 함께 진화하고, 각 세대의 보안은 이전 세대의 실패에서 얻은 교훈을 담습니다.

여기서 얻을 유용한 교훈은 하드웨어 보안이 무의미하다는 것이 아니라, 하드웨어 보안은 이분법이 아니라 스펙트럼이라는 것입니다. Xbox의 보안은 해킹을 극적으로 어렵게 만들었고, 10년 넘게 버텼습니다. 완벽하지는 않더라도 엄청난 성과입니다. 목표는 해킹 불가능한 시스템이 아니라, 보호가 필요한 기간 동안 공격 비용이 목표물의 가치를 넘어서는 시스템을 만드는 것입니다. 그 기준으로 보면 Xbox One의 보안은 놀라울 만큼 효과적이었습니다. 다만 무한하지는 않았을 뿐입니다.