Windows 11에서 메모리 덤프로 BitLocker 우회하기

 (noinitrd.github.io)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Windows 11 24H2 환경에서 Memory-Dump-UEFI로 RAM을 덤프해 전체 볼륨 암호화 키인 FVEK를 찾아내고 BitLocker 보호 볼륨에 접근하는 시연임
  • 공격자가 장치에 물리적으로 접근할 수 있으면 재시작 직후 RAM에 남은 키를 노릴 수 있지만, 전원 차단 시간이 길어질수록 RAM 내용 손상 위험이 커짐
  • 시연은 메인보드의 리셋 핀(reset pins) 을 쇼트해 전원 손실 없이 재시작하는 방식을 썼고, Secure Boot 우회 사례는 데모 범위 밖으로 둠
  • Windows 11 덤프에서는 과거 Windows 7의 FVEc, Windows 8.1/10의 Cngb 대신 dFVE 와 None 태그 아래에서 FVEK가 발견됨
  • Microsoft가 SymCryptSessionDestroy 같은 함수로 키를 파괴하려 해도 힙에 키가 남을 수 있어, BitLocker 구현 분석에는 커널 수준 디버깅이 가장 직접적인 접근임

Windows 11 BitLocker 우회 시연 범위

  • 대상은 Windows 11 version 24H2이며, BitLocker의 전체 볼륨 암호화 키인 FVEK를 메모리에서 추출하는 방식임
  • RAM 내용을 덤프하는 UEFI 애플리케이션 Memory-Dump-UEFI가 사용됨
  • 핵심 전제는 공격자가 장치에 물리적으로 접근할 수 있다는 점임

RAM 덤프가 성립하는 조건

  • 최근 실행 중이던 Windows 인스턴스의 RAM에는 FVEK 같은 민감 정보가 남아 있을 수 있음
  • 전원이 끊기면 RAM 내용이 빠르게 손상되므로, 재시작 과정에서 컴퓨터가 완전히 꺼져 있는 시간을 최소화해야 함
  • RAM 손상을 줄이는 방법으로는 물리적 냉각이나 외부 전원 공급 유지가 있으며, 시연에서는 메인보드의 리셋 핀을 쇼트해 전원 손실 없이 재시작함
  • Secure Boot는 장치 시작 시 실행 가능한 항목을 제한하는 보안 표준이지만, shim 등으로 우회된 사례가 있고 이 데모에서는 자세히 다루지 않음

부팅 USB 준비와 덤프 생성

  • 부팅 USB에는 대상 시스템의 RAM 용량보다 큰 저장장치가 필요함
  • flashimage.sh 스크립트로 부팅 가능한 애플리케이션 준비를 단순화함
  • 부팅 애플리케이션 생성과 사용 절차는 MemoryDumpUEFI에 정리돼 있음
  • Windows가 로딩 중이지만 로그인 화면이 나타나기 전 재시작했을 때 FVEK를 찾을 가능성이 가장 높았음
  • USB 장치에서 Memory-Dump-UEFI로 즉시 부팅한 뒤 UEFI shell에서 app.efi를 실행함
    • 실행 방식은 애플리케이션 README에 추가 절차가 있음
    • 덤프 시간은 RAM 용량과 USB 장치 속도에 따라 달라짐
    • 잘못된 드라이브에 기록되는 일을 피하려면 다른 USB 저장장치는 분리하는 편이 좋음

덤프 파일 처리와 검색 도구

  • Memory-Dump-UEFI는 여러 개의 덤프 파일을 만들 수 있음
  • UEFI 사양에 맞추려면 FAT32 파일시스템을 사용해야 하며, FAT32에는 4GB 파일 크기 제한이 있음
  • tools 디렉터리의 concatDumps는 여러 덤프를 시간 순서대로 하나로 합침
  • 덤프는 당시 메모리에 있던 원시 데이터이므로, xxd 같은 도구로 읽기 쉽게 확인할 수 있음
  • searchMem은 덤프 안에서 hex 패턴을 검색하고, 발견 위치의 오프셋으로 이동할 수 있게 함

풀 태그와 FVEK 위치

  • 풀 태그(pool tag) 는 Windows 커널 메모리 풀이 어디인지 나타내는 4글자 식별자임
  • Windows 커널이 할당한 메모리 풀은 민감 정보를 찾기 좋은 위치가 될 수 있음
  • pooltag.txt에는 풀 태그 목록과 각 목적에 대한 정보가 들어 있음
  • 과거 Windows 버전에서는 BitLocker 키 위치가 달랐음
    • Windows 7에서는 fvevol.sys의 암호화 할당에 해당하는 FVEc 풀 태그에서 키 복구가 가능했음
    • Windows 8.1과 Windows 10에서는 ksecdd.sys 모듈에 해당하는 Cngb 태그 메모리 풀에서 키를 찾을 수 있었음
  • Windows 11 덤프에서는 FVEc와 Cngb에서 키를 찾지 못했고, 대신 두 위치에서 FVEK가 발견됨
    • 첫 번째는 dumpfve.sys가 할당한 메모리를 나타내는 dFVE 풀 태그 아래임
    • dumpfve.sys는 BitLocker drive encryption의 full volume encryption crash dump filter와 관련됨
    • dFVE 위치는 키가 가장 쉽고 일관적으로 발견된 지점이었음
    • 이 위치의 키 앞에는 암호화 유형을 나타내는 0x0480이 붙어 있었고, 시연 환경에서는 XTS-AES-128을 의미함
    • 두 번째는 ExAllocatePool 호출과 관련된 None 태그 아래임
    • 이 위치에서는 키의 앞 절반이 두 번, 뒤 절반이 한 번 보였음

FVEK로 BitLocker 볼륨 접근하기

  • 얻은 키는 사용 중인 암호화 알고리듬 값을 앞에 붙여야 함
  • 예시에서는 키 앞에 알고리듬 값 0x8004를 little endian 형식인 0480으로 붙임
  • 이렇게 만든 값을 파일로 저장해 output.fvek 형태로 사용할 수 있음
  • dislocker 도구 모음은 필요한 알고리듬과 값을 확인하고, BitLocker 보호 파티션을 잠금 해제하는 데 권장됨
  • 절차가 맞으면 output.fvek로 BitLocker 보호 볼륨의 데이터에 접근할 수 있음

BitLocker 구현 분석과 힙에 남은 키

  • BitLocker 구현을 이해하는 가장 직접적인 방법은 windbg 를 이용한 커널 수준 디버깅임
  • 커널 디버깅은 가상머신이나 crossed over USB 3.0 A/A 케이블로 비교적 쉽게 할 수 있음
  • Windows 부팅 과정을 단계별로 따라가며 BitLocker 동작을 관찰한 것이 키를 찾는 데 도움이 됨
  • Microsoft는 SymCryptSessionDestroy 같은 함수로 키를 파괴하려 하지만, 힙에 키가 남아 모든 키를 제거하지는 못함

참고 링크

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • BitLocker는 TPM(PCR 7+11)+PIN을 쓸 때 가장 큰 이점이 있다고 봄
    PIN 없이는 FVEK를 읽지 못해야 하므로 이 공격을 완화할 수 있고, BitLocker가 제대로 구현했다면 PIN을 너무 많이 틀렸을 때 TPM이 사전 공격 잠금 모드로 들어감
    몇 달째 Linux에서도 같은 구성을 해보려 했지만, systemd-cryptsetup/cryptenroll은 LUKS용이고, 느린 내장 eMMC에서 fscrypt로 민감한 디렉터리 몇 개(secure boot 키와 /home)를 암호화하려는 상황임
    기본을 넘어가면 TPM 코딩이 극도로 어렵다고 느낌: PCR 7에 묶고, 커널/init/cmdline 업데이트마다 바뀌는 PCR 11에 묶고, AuthValue가 아닌 PIN을 쓰고, 로그인 시 DA 잠금 카운터 초기화에도 같은 승인 정책을 쓰면서 수동 초기화용 긴 비밀번호/AuthValue도 두고, systemd-stub이 제공하는 PCR 11 서명과 공개키까지 맞춰야 함
    기본 TPM 가이드 말고는 자료가 거의 없어서, 전문가가 있다면 도움을 받고 싶음. 개인 프로젝트지만 언젠가 완성하면 글로 정리할 생각임

    • LUKS에는 여러 키 슬롯이 있으니, 한 슬롯은 TPM 잠금 해제용으로 쓰고 다른 슬롯은 긴 비밀번호 복구용으로 쓸 수 있었던 것으로 기억함
      복구 메커니즘으로 그 방식을 고려해볼 만함
      취미로 오픈소스 TPM 쪽을 건드리는 사람이 적은 이유 중 하나는, 비슷한 욕구를 훨씬 쉽게 해결하는 대안이 많기 때문임
      중요한 암호화 키를 하드웨어에 묶고 싶으면 Yubikey를 사면 되고, 노트북 디스크 암호 비밀번호가 번거로우면 완전 종료 대신 덮개 닫을 때 대기 모드를 쓰면 됨
      로그인 비밀번호가 불편하면 지문 인식기나 생체 인증 Yubikey가 있고, 무인 키오스크나 학교 컴퓨터실처럼 비밀번호 없이 부팅해야 한다면 튼튼한 금속 상자에 넣고 벽에 체인으로 묶으면 됨
      데이터센터 서버가 무인 부팅해야 한다면 신뢰할 수 있는 물리 보안이 있는 데이터센터로 옮기고, 그래도 걱정되면 Dropbear나 Tang으로 올바른 네트워크에 있어야 부팅되게 하면 됨
      홈랩 취미로 TPM을 만지는 중이라면 정말 TPM 작업이 재미있는지 점검해보는 게 좋고, 아마 그렇지 않다는 걸 알게 될 가능성이 큼
    • Windows는 TPM이 처음 FVEK를 얻는 데 PIN을 요구하더라도 결국 FVEK를 RAM에 보관할 것임
      그렇지 않다면 디스크 블록을 복호화할 때마다 PIN을 입력해야 하지 않나? 디스크 작업마다 TPM을 호출하는 성능 영향도 큼
      이 공격은 RAM에서 키를 읽기 때문에 TPM PIN이 어떻게 완화책이 되는지 모르겠음
    • 분할 키 암호화나 암호화된 비밀 키를 쓰는 편이 더 낫지 않을까 싶음
      부팅 전에 비밀번호를 넣고, 그 비밀번호를 TPM 키와 결합해야 드라이브를 열 수 있다면 나중에 TPM 키가 발견되는 상황에서는 도움이 됨
      다만 이 공격에는 어떤 대책이 얼마나 도움이 될지 확신하기 어려움. OS가 드라이브 읽기/쓰기 접근을 유지하려면 키를 어딘가에 들고 있어야 하므로, 키를 찾는 위치만 바꾸면 대부분의 시나리오에서 이런 식의 RAM 데이터 회수가 가능할 것임
      Apple 기기는 키가 보안 영역(enclave) 밖으로 나오지 않는 것으로 기억해서 이런 공격에는 취약하지 않을 것 같음. TPM 3.0은 그쪽에 훨씬 더 가까워질 필요가 있어 보임
    • BIOS의 전원 켜기 비밀번호도 동작해야 하지 않나 싶음. 그게 없으면 시스템이 TPM이 FVEK를 풀어주는 지점까지 가지 못하니까
      ThinkPad에서는 전원 켜기 비밀번호 대신 지문을 쓸 수 있고, 도둑에게는 기기를 거의 못 쓰는 물건으로 만들 수 있어서 BitLocker PIN보다 이 구성을 선호함
      물론 전원 켜기 비밀번호와 지문 인증도 TPM만큼만 강하지만, BitLocker TPM+PIN도 마찬가지 아닌가
    • TPM은 일종의 허니팟 아닌가 싶음
      성공적인 오픈소스 암호화 소프트웨어 이후에 TPM으로 옮겨간 흐름이 이상하게 느껴짐. 대기업이 제공하는 초안전 저장소가 있으니 걱정도 질문도 하지 말라는 식처럼 보임
      정보기관이 모든 PIN과 비밀번호를 내려받고 데이터에 접근할 수 있는 백도어가 반드시 있을 것 같다는 의심이 듦

  • BitLocker의 보안 모델을 근본적으로 잘 이해하지 못하겠음
    대부분의 설치에서는 전원 버튼을 누르면 Windows로 부팅되는 것처럼 보임
    그러면 누군가 암호화된 하드 드라이브가 있는 기기를 훔쳤을 때 그냥 켜기만 하면 되는 건가? 그럴 리는 없겠지만, 동시에 이 특정 공격을 어떻게 막는지도 모르겠음
    SPI 버스 트래픽이 암호화되어 키를 이렇게 덤프할 수 없다고 가정해야 할 것 같지만, 어쨌든 기계가 키를 꽤 쉽게 내주는 것처럼 보임
    LUKS는 최소한 드라이브 잠금 해제용 비밀번호 프롬프트가 있음

    • SPI 버스 트래픽은 암호화되지 않음
      이상하게도 Microsoft는 TPM 매개변수 암호화를 쓰지 않고, 그래서 1~2년마다 보안 연구자가 TPM 스니핑 장치를 만들어 시연함
      LUKS도 설정에 따라 다름. Linux도 여기서 Windows와 같은 방식으로 구성할 수 있고, 내 홈 비디오 보안 서버도 조용히 재부팅해야 해서 그렇게 설정해뒀음. 웜/콜드 부팅 공격과 소프트웨어 공격 표면에는 취약하다는 걸 알지만, 누군가 드라이브만 뽑아가면 안전함
      Windows도 비밀번호를 요구하거나 PIN 인증 TPM 봉인 키를 쓰도록 설정할 수 있음
      매개변수 암호화와 버스 스니핑 문제를 빼면, BitLocker는 경계를 “누구나 드라이브를 읽을 수 있음”에서 “메모리 내용을 얻기 위한 플랫폼 수준 공격을 하거나 로그인 화면에서 돌아가는 서비스를 해킹해야 함”으로 옮겨줌
      임의로 재활용된 하드 드라이브에서 금융 데이터를 훔쳐가는 식의 상황은 아주 잘 막아주기 때문에 실제로 꽤 괜찮은 보안 개선임
    • 훔친 기기를 켜면 로그인 화면까지 갈 뿐이고, 비밀번호나 생체 인증 없이는 그 너머로 못 감
      원격 코드 실행 취약점이나 오래된 취약 Windows 부트로더로 부팅하는 식의 우회가 필요함. 드라이브가 잠겨 있어서 흔한 “소프트웨어 키보드를 cmd.exe로 바꾸기” 우회는 못 씀
      BitLocker가 없으면 Windows 드라이브를 다른 PC에 꽂아 모든 파일을 볼 수 있음. BitLocker가 있으면 취약한 Microsoft 소프트웨어, 취약점, 덤프된 메모리 같은 것들로 씨름해야 하고, 그것도 항상 되는 건 아님
      BitLocker를 TPM+PIN 모드로 설정하면 TPM을 여는 비밀번호가 없으니 그것조차 못 함. BitLocker를 비밀번호 전용 모드로 둘 수도 있지만 무차별 대입에 훨씬 취약함
      LUKS도 마찬가지로, 요즘 대부분의 Linux 배포판에서 TPM과 TPM+PIN을 지원함
    • 맞지만, 의도는 로그인 화면(winlogon)에서는 그 컴퓨터의 계정 자격 증명이 있거나 생체 등록이 되어 있지 않으면 실제로 할 수 있는 일이 거의 없다는 데 있음
      안전 모드로 재부팅하거나 다른 OS, 펌웨어 업데이트 유틸리티 등으로 재부팅하려 하면 BitLocker 복구 키를 입력해야 함
      지문 센서나 얼굴 인식 웹캠을 “해킹”하는 경우가 내부적으로 어떻게 동작하는지는 잘 모르겠음
    • BitLocker를 PIN+TPM과 함께 쓸 때의 주된 목적은, 전원이 꺼진 컴퓨터나 드라이브 자체를 벽돌처럼 만드는 것임
      TPM에 키 추출 취약점이 없다는 가정이 필요함
      핵심은 전원이 꺼져 있을 때임
      범용 드라이브 암호화에서는 TPM이 너무 느려서 실제 대량 데이터를 복호화하지 않고, 결국 OS가 추출 가능한 키를 갖게 됨
    • BitLocker 볼륨은 여러 보호자를 가질 수 있고, 키 파일, 암구문, PIN, TPM 저장소를 쓸 수 있음: https://learn.microsoft.com/en-us/windows-server/administrat...
      Pro 에디션에서는 그룹 정책으로 부팅 시 상호작용 단계를 요구할 수도 있음. TPM이 없어도 동작하며, 이 경우 시작할 때마다 비밀번호를 물어봄

  • 이건 https://trustedcomputinggroup.org/resource/pc-client-work-gr...로 완전히 막을 수 있음
    활성화되어 있으면 OS가 정상 종료되지 않아 암호화 키를 지울 기회가 없었던 경우, 다음 부팅 전에 펌웨어가 멈춰서 RAM을 지움
    Windows가 이걸 사용하지 않는 건지, 아니면 테스트한 시스템이 구현하지 않은 건지 궁금함

    • Windows는 이 기능을 사용하는 것으로 알려져 있음: https://learn.microsoft.com/en-us/windows/security/operating...
      “BitLocker는 키를 메모리에 추출하기 전에 MOR bit(Memory Overwrite Request)라고도 하는 TCG Reset Attack Mitigation을 사용한다”고 되어 있음
      다만 대부분의 플랫폼 구현은 전혀 신뢰하지 않음. 어떤 형태로든 제대로 구현에 가까운 UEFI 플랫폼을 본 적이 없음
      이 연구자가 어떤 플랫폼을 썼는지, 그리고 그 플랫폼이 MOR bit 지원을 주장하는지 알면 흥미로울 듯함
    • 그 완화책은 RAM 덮어쓰기 중에도 간섭할 수 있어서 매우 어설픔
      Team Tweezers가 원래 Wii를 어떻게 공략했는지만 봐도 됨
      진짜 완화책은 현대 CPU의 메모리 암호화 기능임. 다이 안에 있으니 핀셋이 닿지 않고, 키만 지우면 되므로 즉시 삭제되며 전원 주기를 버텼더라도 방해하기 매우 어려움
    • 그래도 RAM 모듈 전체를 뽑아서 오프라인으로 덤프하는 건 막지 못함
      이상적으로는 키가 CPU의 SRAM 캐시 안에만 남고 CPU 다이 밖으로 절대 나가지 않아야 함

  • 글을 쓴 당사자임. 질문이 있으면 이 계정으로 메시지를 보내도 됨
    작업이 정말 재미있었고 많은 관심에 감사함

  • Windows 11 BitLocker 우회와 관련된 38C3 발표: https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou...

  • BitLocker는 꺼진 컴퓨터만 제대로 보호하고, 그것도 BitLocker가 부팅 비밀번호를 요구하도록 설정했을 때에만 그렇다는 점은 꽤 잘 알려져 있음
    [0] https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...

  • Windows에는 메모리 압축과 함께 제안된 메모리 암호화 옵션이 있음
    Intel과 AMD 모두 이 기능을 CPU에 넣는 작업을 하고 있음
    다만 대상은 노트북이 아니라 여러 가상 머신을 돌리는 서버로 보임

    • Microsoft는 특정 소프트웨어 조각을 보호하기 위한 “enclaves” 실행 기능을 포함해 가상화 기반 보안으로 점점 더 이동 중임: https://learn.microsoft.com/en-us/windows/win32/trusted-exec...
      곧 암호화된 “가상 머신”을 이런 비밀값 저장 수단으로 활용해도 놀랍지 않음. 필요한 건 소비자 플랫폼에서 널리 일반화된 하드웨어 지원임
      다만 이전 CPU 부채널 공격은 암호화된 메모리도 공격 가능함을 보여줬음(https://www.usenix.org/conference/usenixsecurity21/presentat...). CPU가 정상 동작을 위해 메모리를 복호화할 때 캐시를 노림
      메모리 덤프를 무력화하는 데는 도움이 되겠지만, 암호화 RAM이 메모리에서 키를 덤프하는 일을 끝내지는 못할 것임. 특히 인내심 있거나 고도로 숙련된 공격자에게는 더 그럼
    • Intel은 현재 Total Memory Encryption 기능으로 이를 제공함. Windows 생태계에서는 맞게도 가상 머신 쪽을 겨냥함
      https://techcommunity.microsoft.com/blog/windowsosplatform/m...
      메모리 압축은 오래전부터 있었고, 적어도 Windows 10 RTM부터 존재함. 주요 운영체제는 모두 이 기능을 구현했지만, 보안과는 관련이 없음

  • 관련 글: Lenovo 노트북에서 저렴한 논리 분석기로 BitLocker 우회하기
    https://news.ycombinator.com/item?id=37249623

  • 대상 기계의 메모리 덤프를 읽는 데 의존하는 공격에서, 물리 접근이 있다면 RAM으로 들어가고 나오는 데이터를 복사하거나 수정하는 인터포저 장치가 얼마나 현실적일지 궁금함
    예전 Gameboy용 “Action Replay”처럼, 게임 카트리지에서 시스템으로 로드되거나 실행되는 메모리를 수정해 치트를 가능하게 하던 장치를 떠올림. 카트리지를 Action Replay에 꽂고, Action Replay를 Gameboy에 꽂는 방식임
    RAM과 메인보드 사이에서도 비슷한 일을 할 수 있을까? RAM을 장치에 꽂고, 그 장치를 메인보드에 꽂은 다음 메모리 읽기/쓰기를 관찰해 임의 시점의 메모리 상태를 캡처하는 식임
    그러면 수동으로 전원을 끄고 필요한 데이터가 남아 있기를 기대하는 번거로움을 피할 수 있음
    전기공학자가 아니라서 완전히 불가능한 제안일 수도 있음. 물리적 공간과 대역폭 제약은 분명 커 보이는데, 가능은 한가?

    • 이론적으로는 가능함. 실제로는 DDR 링크를 설정할 때 메모리 컨트롤러와 RAM 사이에 많은 협상이 필요하고, 같은 타이밍을 유지하면서 데이터를 덤프하는 상황을 만들기는 쉽지 않음
      기성품 솔루션으로 나올 거라고 기대하긴 어려움
    • 최신 AMD/Intel CPU는 투명한 전체 메모리 암호화를 지원하므로, 그런 인터포저는 암호화된 RAM 데이터만 보게 됨

  • 최근 몇 년 사이 출시된 Intel/AMD CPU는 투명한 전체 메모리 암호화를 지원한다는 사실을 아는 사람이 적음
    RAM 내용은 CPU 메모리 컨트롤러 안에 보관되고 리셋 때 생성되는 무작위 키로 암호화됨
    보통 BIOS에서는 꺼져 있는데, 메모리 성능에 작은 손실(0.1%~1%)이 있기 때문임
    하지만 이 공격은 완전히 막을 수 있음

    • 이해한 바로는 AMD에서는 이 기능을 SME(Secure Memory Encryption), Intel에서는 TME-MK(Total Memory Encryption-Multi Key) 라고 부름
답변달기