[Research] Unlocking BitLocker: Windows Full-Disk Encryption Under Attack: Part 1 (KR)

1. Introduction

BitLocker은 Windows 운영체제에 내장된 디스크 암호화 기능으로, 장치가 분실되거나 도난되어 오프라인 상태에서 디스크에 접근해도 내용을 읽지 못하도록 보호하는 장치입니다. BitLocker은 XTS-AES와 TPM의 결합 구조를 사용해 강력한 키 보호와 데이터 암호화를 제공하지만, 암호문 자체에 대한 무결성 보호가 제공되지 않습니다. 오늘은 AES-XTS 메커니즘을 이해해보며 이를 통해 발견할 수 있는 BitLocker CrashXTS의 방식을 함께 살펴보겠습니다.

1.1 부팅시스템 이해

UEFI 펌웨어는 EFI System Partition(ESP)에서 서명된 bootmgfw.efi와 BCD(부팅 구성 데이터)를 읽어들이며, 이 구간은 평문으로 구성되어 있습니다. Secure Boot는 이 부팅 애플리케이션과 체인의 DBX를 검사해 신뢰 경로를 구성합니다. ESP 부트 구성 요소는 읽히되, 신뢰 검증이 통과하지 않으면 VMK unseal이 거부되고 복구 경로로 이동합니다.

TPM 하드웨어 칩

암호화된 영역에는 단순히 사용자 파일만 있을까요? 아닙니다. BitLocker는 볼륨 메타데이터에 키 보호자(Key Protector)와 키 계층을 기술해두고 있습니다. 구체적으로는 VMK(Volume Master Key)와 FVEK(Full Volume Encryption Key)의 2계층 키 설계를 사용하고 있고, 실제로 블록 암호화/복호화에 쓰이는 것은 FVEK입니다.

위 화면은 manage-bde -protectors -get C: 명령으로 C: 볼륨에 등록된 키 보호기(Key Protector)를 조회한 결과입니다. 여기서 보이는 숫자 암호는 VMK를 해제하기 위한 보호기 중 하나로, 정상 부팅 경로에서 TPM 기반 unseal이 실패하거나 복구 모드로 전환될 때 사용되는 복구 수단입니다. 즉 BitLocker 볼륨에는 단순히 데이터만 암호화되어 있는 것이 아니라, VMK를 어떤 방식으로 복원할 수 있는지에 대한 보호기 정보와 키 계층(VMK → FVEK)이 메타데이터 형태로 함께 존재하며, 최종적으로 FVEK가 섹터 단위 암복호화에 사용되는 구조로 이어집니다. 이러한 2계층 키 설계가 실제로 어떻게 작동하는지 이해하기 위해, 각 단계에서 핵심적인 역할을 수행하는 TPM, VMK, FVEK에 대해 구체적으로 알아보겠습니다.

TPM

TPM은 암호화 키, 카운터 등을 칩 내부에 격리해 보관하는 보안 저장소를 가지고 있으며, 시스템이 ‘믿을 수 있는 상태로 부팅되었는지’ 부팅 신뢰도 측정값(PCR - Platform Configuration Register)을 통해 비밀 키를 꺼내 쓸 수 있도록 하는 dTPM 하드웨어 칩입니다.

BitLocker는 VMK를 특정 PCR 값에 seal합니다. 기본적으로 PCR 7(Secure Boot 상태, UEFI 변수, Boot Manager 코드)과 PCR 11(BitLocker 액세스 제어)을 사용합니다.

  • 부팅 체인이 정상이면 TPM은 VMK 해제(unseal)를 허용합니다.
  • 부팅 체인이 변조되었을 경우 PCR 값이 달라져 unseal이 실패하고 복구 화면으로 이동합니다.

VMK (Volume Master Key)
VMK는 FVEK를 보호하는 상위 키입니다. VMK를 정상적으로 복원하지 못하면 FVEK를 풀 수가 없고 따라서 섹터 평문에도 접근할 수 없습니다. VMK는 여러 보호자로 래핑될 수 있습니다.

  • TPM Protector: TPM PCR에 바인딩
  • Recovery Password Protector: 48자리 숫자 복구 키
  • Password Protector: 사용자 암호
  • TPM+PIN Protector: TPM과 PIN 조합

FVEK (Full Volume Encryption Key)
FVEK는 디스크 섹터의 실제 암호화를 담당하며, FVEK가 암호화하는 대상에는 커널, 드라이버, 소프트웨어, 사용자 데이터를 모두 포함합니다. FVEK는 AES-256(또는 AES-128) 키이며, XTS 모드에서는 실제로 512비트(또는 256비트)가 사용됩니다. 이때 절반은 데이터 암호화용(K1), 절반은 tweak 생성용(K2)으로 사용됩니다!

BitLocker 필터 드라이버 동작 원리

커널이 올라오면 BitLocker 필터 드라이버인 fvevol.sys가 디스크 I/O를 가로채서 암호화, 복호화를 수행하는데요. 이걸 어떻게 수행하는지 한번 확인해보겠습니다!

  1. 컴퓨터가 부팅할 때 winload.efi가 커널과 BOOT_START(0) 드라이버들을 적재하며, fvevol.sys도 함께 먼저 올라갑니다. 이 시점은 NTFS가 시스템 볼륨을 마운트하기 전입니다.
  2. 키가 준비되기 전 부팅 초기에 TPM의 PCR 7/11 검증이 아직 이루어지지 않고 VMK/FVEK이 준비 전 상태일 때, fvevol.sys는 locked 상태로 동작합니다. 이 단계에서 bootmgr나 winload같은 부트 환경이 FVE-FS(메타데이터)를 읽어 TPM 검증을 수행하고, VMK를 unseal 한 뒤에 FVEK를 복호합니다.
  3. VMK가 unseal되고 FVEK가 복호된 시점일 때가 되어서야 fvevol은 unlocked 상태로 전환됩니다. 이 시점부터 해당 볼륨의 모든 데이터 I/O는 각 FVEK를 통해 투명 암호화, 복호화가 수행됩니다.

즉, 앱/서비스 → NTFS(ReFS) → I/O Manager → [fvevol] → volmgr/저장소 클래스 → 포트/미니포트(NVMe/SATA) → 디스크 순서로 내려갑니다.

BitLocker의 핵심 암호화 방식인 XTS-AES는 디스크 섹터 단위로 데이터를 암호화하며, 각 블록에 tweak 값(섹터/오프셋 기반)을 적용해 동일한 평문이라도 위치에 따라 다른 암호문이 생성되도록 설계되어 있습니다.

이 설계는 CTR/CBC 모드에서 발생하던 malleability(변형 가능성), 즉 암호문을 직접 조작해 평문을 제어하는 문제를 완화하기 위해 도입된 것입니다. 그러나 이러한 XTS 구조조차 완벽히 안전하지 않음을 보여주는 사례를 오늘 살펴보도록 하겠습니다.

2. Windows의 AES-CBC와 AES-XTS 운용 모드

2.1 XTS의 암호화 방식

앞서 BitLocker가 FVEK로 섹터 데이터를 암호화한다고 했는데요. 오늘 설명할 취약성을 이해하기 위해서는 ‘디스크라는 매체에서 사용하는 운용 모드’에 초점을 둬야 합니다. 힌트를 하나 드리자면 디스크는 ‘섹터라는 특정 위치를 임의로 읽고 쓰는 액세스 매체’입니다. 따라서 BitLocker는 랜덤한 액세스에서도 안전하게 동작하는 블록 암호 운용 모드여야 취약성이 나타나지 않습니다.

Windows 11부터 BitLocker는 기본적으로 기존에 사용하던 AES-CBC 대신 AES-XTS를 사용하기 시작했습니다. 이는 CBC 암호화 방식에서 구조적으로 생길 수 있는 attack surface를 줄이기 위해서입니다.

CBC 암호화 방식은 우리에게 익숙한 암호화 방식이죠? CBC 암호화 방식은 블록 암호인 AES를 체인처럼 엮는 방식인데, CBC 방식이 디스크 관점에서 문제가 되는 포인트는 아래와 같습니다.

  1. 연쇄 구조 (Chaining Dependency)
    CBC는 본질적으로 앞 블록이 뒤 블록에 영향을 주기 때문에, 디스크처럼 중간 블록만 바꿔 쓰는 환경에서 관리가 까다롭습니다. 디스크는 파일 일부만 갱신되기도 하고, OS가 특정 섹터만 업데이트하기도 합니다. 섹터 단위로 독립적인 암복호화가 불가능해 성능 저하가 발생합니다.
  2. 비트 플립 공격 (Bit Flipping)
    CBC 복호 식에서 보듯, 공격자가 특정 비트를 뒤집으면 동일한 위치 비트가 같은 방식으로 뒤집힙니다. 즉, 암호문을 조작해 평문을 예측 가능하게 변경할 수 있습니다.
  3. IV(Initialization Vector) 관리 문제
    각 섹터마다 고유한 IV가 필요하지만, IV를 섹터 번호로 사용하면 예측 가능성이 생기고, 랜덤 IV를 사용하면 추가 저장 공간이 필요합니다.

이와 같은 흐름을 확인해볼 때, 과거 CBC 기반 FDE에서는 공격자가 디스크 상의 암호문을 비트 단위로 수정해 부트로더나 운영체제 코드에 악성 페이로드를 삽입하는 것이 이론적으로 가능했습니다.

따라서 그간 CBC 모드의 구조적 취약점인 가단성(Malleability)으로 인해 암호화된 부트 섹터나 OS 중요 파일이 변조될 위험이 제기되었습니다. 이에 따라 2008년 TrueCrypt 5.0이 XTS-AES를 도입했고, 이후 Microsoft 역시 Windows 10부터 BitLocker의 기본 암호화 표준으로 XTS-AES를 채택하여 이러한 위협에 대응하게 되었습니다.
이러한 XTS 암호문 모드의 의 동작 방식을 한번 확인해보겠습니다. 먼저 XTS는 블록마다 tweak라는 값을 씌웁니다. 이 tweak라는 값은 ‘디스크 위치’에서 결정되는 난수 값이며, 이 값은 보통 섹터 번호와 섹터 내 블록 인덱스를 기반으로 정해집니다. 디스크는 512B(4KB)같은 크기의 섹터로 읽고 쓰고, AES는 16B 블록이므로 예를들면 512B 기준으로 32개로 블록이 나뉘어집니다. 즉, XTS는 이 16B 블록마다 서로 다른 tweak가 적용되도록 설계됩니다.

XTS는 Key를 두 개 사용합니다. Key1은 실제 데이터를 암호화와 복호화하는 목적으로, Key2는 데이터의 위치 정보를 담은 tweak를 생성하는 목적으로 사용합니다.

이같은 XTS 모드를 사용하면 공격자가 특정 암호문 블록을 조작해도, 비선형성으로 인해 16바이트 블록 단위로 결과가 예측 불가능하게 무작위에 가까운 손상이 이뤄집니다. 즉, CBC처럼 바로 다음 블록의 특정 비트를 원하는 값으로 바꾸거나 하는 정교한 조작이 사실상 불가능해지는 것이죠.

2.2 XTS의 해결되지 못한 과제

그러나 XTS는 여전히 다음과 같은 근본적인 한계를 가지고 있습니다.

1. 무결성 보호 부재

XTS는 조작 결과를 예측하기 어렵게 만들지만, 조작 자체를 탐지하거나 거부하는 무결성 보호를 제공하지 않습니다. 만약 공격자가 암호문을 바꾸면, 시스템은 그 변조 사실을 감지해서 중단하지 않습니다. 시스템은 이 변조된 데이터를 그냥 복호해서 깨진 평문으로 처리합니다.

2. 세분화된 변조 탐지

XTS는 어떤 섹터나 블록이 바뀌었는지의 변화를 블록 단위로 정확히 격리합니다. 이는 CBC보다 세분성이 좋아서, 변형이 이루어진 특정 위치를 파악하는 데 유용한 단서를 제공합니다. 공격자는 어떤 블록이 변경되었는지 전체 디스크 관점에서 쉽게 확인할 수 있습니다.

3. Copy-Paste 공격

XTS 모드에서 동일한 평문 블록은 동일한 섹터에서 항상 동일한 암호문을 생성합니다. 공격자는 같은 섹터의 이전 버전 암호문을 복사해 현재 버전을 덮어쓸 수 있거나, 다른 섹터의 암호문을 복사해 붙여넣을 수 있습니다.

4. 좁은 블록 크기

XTS는 16바이트 블록 단위로 동작하므로, 동일한 16바이트 평문 패턴이 반복되면 암호문에서도 패턴이 관찰될 수 있습니다. 이는 암호문 분석에 활용될 수 있습니다.

이를 직접 확인해보기 위해서 BitLocker 볼륨에서 XTS-AES의 무결성 부재를 직관적으로 확인해볼 수 있는 실습을 진행했습니다. 먼저 BitLocker가 적용된 볼륨 V:에 16MiB 크기 파일을 생성하고, 생성 직후 파일의 SHA-256 해시를 출력하도록 하고 이를 기준값으로 기록합니다. 이후 볼륨을 잠근 상태에서 디스크 원시 영역을 직접 편집해 해당 파일이 포함된 16바이트 단위 암호문 블록을 일부 변조하고, 다시 볼륨을 해제한 뒤 동일 파일의 SHA-256 해시를 재계산해 기준값과 비교해보면 해시값이 바뀌는 것을 확인할 수 있습니다.

암호문에서 딱 1비트만 변경하더라도, XTS 결과에서 암호문을 1비트만 바꿨지만 해당 16바이트 블록 전체가 무작위로 randomizing되는 것을 확인할 수 있습니다. 동시에 이를 통해, 다른 이웃 블록들에는 영향이 없는 것을 확인할 수 있습니다.

Windows가 AEAD로 전환하지 못하는 이유
하지만 Windows 입장에서는 MAC이나 AEAD 같은 무결성을 붙인 형태의 디스크 암호화로 완전히 넘어가기에는 한계가 있습니다. 이는 단순히 암호화 알고리즘을 교체하는 차원을 넘어, 부팅부터 파일 시스템, 크래시 덤프에 이르는 전체 I/O 경로가 무결성 검증 실패를 어떻게 처리할지 시스템 아키텍처를 전면 재설계해야 하는 거대한 작업이 동반되기 때문이죠.. 또한, 모든 섹터에 MAC 태그를 저장해야 하는 공간 효율성 저하, I/O 성능 오버헤드 문제는 물론, 파일 시스템의 부분 쓰기 동작과의 불일치를 해결해야 하는 문제도 발생합니다. 무엇보다도 작은 데이터 손상에도 엄격한 검증 실패로 인해 볼륨 전체의 마운트가 거부될 수 있는 가용성 저하 우려로 인해서 아직까지도 이에 대한 완전한 대책을 마련하기 어렵다고 합니다.

2.3 CASE: CVE-2025-21210 (CrashXTS)

같은 섹터는 같은 tweak로 암호화된다는 XTS의 성질은, 같은 섹터 번호와 같은 FVEK가 주어지면 같은 평문은 항상 같은 암호문으로 변환되며, 부팅을 여러 번 하더라도 섹터 번호가 바뀌지 않는 한 암호문은 일정하게 유지됩니다. 또한 XTS에서 우리는 Write primitive를 얻기는 어렵지만 Corrupt를 통해 시스템 동작 경로 흐름을 실패하게 할 수 있습니다. 이 점을 CrashXTS로 알려지는 CVE-2025-21210가 설명합니다.

윈도우에서 BitLocker가 정상 런타임 I/O를 처리할 때는 fvevol.sys 스택을 통해 섹터 단위로 XTS-AES 암복호화가 적용됩니다. 하지만 크래시 덤프/하이버네이션처럼 정상 파일시스템 경로가 아니라 최소 덤프 스택으로 디스크에 직접 쓰는 특수 경로에서는, 일반 I/O 경로의 필터들이 모두 동작한다고 가정할 수 없습니다. 이 때문에 BitLocker는 dumpfve.sys 같은 덤프 필터를 별도로 로드해, 덤프/하이버네이션 데이터가 디스크에 기록될 때도 암호화가 유지되도록 설계됩니다.

이 흐름은 디컴파일 코드에서도 확인됩니다. 함수는 SYSTEM\CurrentControlSet\Control\CrashControl 아래의 DumpFilters값을 읽어오는 과정 FveGroupPolicyGetMultiSzValue()을 거치고, 목록을 순회하면서 dumpfve.sys가 포함되어있는지 _wcsicmp()를 통해 확인합니다. 또한 dumpfve.sys가 없거나 파싱에 실패할 경우 즉시 중단하고, 정상적으로는 암호화 덤프 필터가 빠진 상태에서는 덤프/하이버네이션을 계속 진행하지 않게 하는 흐름이 나타나고 있습니다.

하지만 문제는 XTS기반 디스크 암호화가 무결성을 제공하지 않는다는 점이에요. XTS의 성질을 이용해 특성 암호문 블록을 조작해 16바이트 블록 평문을 깨뜨리면, 레지스트리 하이브 내부에서 DumpFilters 오프셋이 들어있는 블록을 손상시켜 파서가 DumpFilters 엔트리를 정상적으로 탐색하지 못하는 상태를 유도할 수 있게 됩니다. 즉, 이 Corrupt를 통해서 기대한 동작을 수행하지 못하게 유도하는 것이 목적입니다.

화면은 SYSTEM 레지스트리 하이브 안에서 ControlSet…\Control\CrashControl 키 주변 바이트를 Hex 값으로 보여줍니다. 오른쪽 ASCII 영역에 CrashControl, AutoReboot, CrashDumpEnabled, DumpFile, DumpFilters 같은 문자열이 보이는데, 이건 키/값 이름이 실제 파일 내부에 문자열 형태로 존재한다는 뜻입니다.

XTS에서는 암호문을 조작하면 해당 16바이트 블록의 평문이 통제 불가능하게 랜덤화됩니다. 즉, 레지스토리 하이브 구조체 안의 4바이트짜리 이 오프셋을 노려서 이 필드가 들어있는 16바이트 블록을 랜덤화하면, 커널 입장에서는 DumpFilters 값이 없는 것처럼 보이면서 하이브 로더가 값 목록 위치를 못 찾는 상태가 됩니다. 그리고 우리는 이걸 유도하는 것이 목적입니다!

디스크 전체를 생각해보면 16바이트 블록은 엄청나게 많습니다. DumpFilters를 깨뜨리기 위해 수십 GB 디스크에서 무작위 블록을 찍어낼 수는 없으니, CrashControl 문자열이 하이브 파일 오프셋 0x13B330 근처에 있다는 점을 찾은 다음, 그 주변 몇십 개 블록만 후보로 두고 하나씩 깨뜨려보는 방법을 생각해봅시다. CrashControl이 들어있는 위치에서 대략 248바이트 떨어진 근처에 DumpFilter 관련 구조가 있다는 것을 Hex 값을 통해 확인했고, 248바이트는 16바이트 블록 기준으로 대략 15.5 블록입니다. 따라서 +0xF0 또는 +0x100 주변 블록을 후보 블록으로 잡아볼 수 있습니다.

그럼 암호화된 볼륨 안에서 SYSTEM 하이브가 어디에 있고, 그 중 CrashControl 키 노드가 어디에 위치하는지 구체적으로 어떻게 찾을 수 있을까요? SYSTEM 하이브 파일의 같은 컴퓨터를 클린 셧다운, 강제종료, 크래시 후 재부팅 같은 상태를 유발하면 특정 블록이 바뀌는데, 이 부분을 SYSTEM 하이브 시작 근처임을 확인할 수 있습니다. 구체적으로 BSOD 이후 재부팅을 거치면 CrashControl 아래에 LastCrashDump라는 특정 휘발성 서브키가 생겼다가 클린 종료 후에 사라지는데, 이때 해당 키 노드 구조체의 필드 일부만 예측 가능한 방식으로 바뀌게 됩니다. 즉, 하이브 전체를 훑으면서 딱 그 패턴대로 변한 블록들을 CrashControl 키 노드로 생각할 수 있습니다!

정상 부팅 상태

Offset      Hex bytes (16B)                                      ASCII
0x0056e2f0  a0 ff ff ff 6e 6b 20 00 ad 71 01 42 ed f0 da 01    ....nk ..q.B....
0x0056e300  03 00 00 00 e8 03 00 00 01 00 00 00 00 00 00 00    ................
0x0056e310  28 7b 74 00 ff ff ff ff 0c 00 00 00 38 f4 a7 00    ({t.........8...
0x0056e320  08 bc 46 00 ff ff ff ff 20 00 00 00 00 00 00 00    ..F..... .......
0x0056e330  2c 00 00 00 30 00 00 00 00 00 00 00 0c 00 00 00    ,...0...........
0x0056e340  43 72 61 73 68 43 6f 6e 74 72 6f 6c 00 00 00 00    CrashControl....

크래시/BSOD 직후 상태

Offset      Hex bytes (16B)                                      ASCII
0x0056e2f0  a0 ff ff ff 6e 6b 20 00 73 62 74 ab 14 f7 da 01    ....nk ..sbt.....
0x0056e300  03 00 00 00 e8 03 00 00 01 00 00 00 00 00 00 00    ................
0x0056e310  28 7b 74 00 c8 8e 01 80 0c 00 00 00 38 f4 a7 00    ({t.........8...
0x0056e320  08 bc 46 00 ff ff ff ff 20 00 00 00 00 00 00 00    ..F..... .......
0x0056e330  2c 00 00 00 30 00 00 00 00 00 00 00 0c 00 00 00    ,...0...........
0x0056e340  43 72 61 73 68 43 6f 6e 74 72 6f 6c 00 00 00 00    CrashControl....

두 덤프를 보면 먼저 눈에 띄는 건, 문자열 자체는 유지된다는 점입니다. 두 상태 모두 0x0056e340 라인에 CrashControl 문자열이 그대로 남아 있습니다. 즉, CrashControl이라는 텍스트가 사라져서 못 찾는 상황이 아니라, CrashControl을 기술하는 구조체 내부의 일부 필드가 바뀌는 형태로 상태로, 전체가 통째로 뒤바뀐 것이 아니라 구조체의 일부 필드만 선택적으로 변합니다. 그리고 이는 무작위 덤프가 아니라 어떤 의미를 갖는 구조를 보고 있다는 강한 단서가 됩니다!

Offset      Hex bytes (16B)                                      ASCII
0x00000000  9c 1e d1 7a 39 39 d4 13 0c d4 40 c5 a8 6f c4 de    ...z99....@..o..
0x00000010  e0 79 bc 2d dd 66 e2 25 b0 48 0f 58 53 2f 06 5d    .y.-.f.%.H.XS/.]
0x00000020  74 ac c3 51 86 9e 74 64 e2 d9 6e d0 9c 11 ee 4d    t..Q..td..n....M
0x00000030  03 40 03 52 05 e0 bc 37 41 c1 3f a2 7e 2a 09 84    .@.R...7A.?.~*..
0x00000040  24 80 dc b8 6a 20 c8 81 2d c6 61 30 39 9f 30 51    $...j ..-.a09.0Q
0x00000050  31 1b 0c 74 80 96 8c f2 ad 9d 28 26 f9 ce 8d 16    1..t......(&....
0x00000060  1c 23 fd d1 08 45 f0 c1 84 bb e5 84 bf b6 73 17    .#...E........s.
0x00000070  f0 e3 50 f2 7c 35 7b 91 bd e5 5e b3 a7 4d 4c bf    ..P.|5{...^..ML.
0x00000080  db f0 de 96 ba 50 d9 09 3d 83 b2 fb 1a f4 35 aa    .....P..=.....5.
Offset      Hex bytes (16B)                                      ASCII
0x00000000  48 49 42 52 09 00 00 00 33 c0 00 00 d8 04 00 00    HIBR....3.......
0x00000010  04 3e 0a 00 00 00 00 00 00 10 00 00 00 00 00 00    .>..............
0x00000020  3e 73 b2 1f 2b f7 da 01 3e 1d 07 2a 00 00 00 00    >s..+...>..*....
0x00000030  ff bd 9b bd 7f a4 5f 06 01 ca 00 00 0a 00 00 00    ......_.........
0x00000040  00 30 44 a8 80 c2 ff ff 00 00 14 00 4e 21 00 00    .0D.........N!..
0x00000050  61 d7 00 00 00 00 00 00 34 54 00 00 00 00 00 00    a.......4T......
0x00000060  00 00 00 00 00 00 00 00 2c 00 00 00 00 00 00 00    ........,.......
0x00000070  7c 13 00 00 00 00 00 00 fc 57 02 00 00 00 00 00    |........W......
0x00000080  a7 bf 12 00 00 00 00 00 82 99 a9 68 02 00 00 00    ...........h....

exploit 전후의 raw 섹터를 비교하면, exploit 전에는 암호문 특성상 무작위처럼 보이는 바이트열이 관찰되지만, exploit 후에는 HIBR 시그니처로 시작하는 하이버네이션 헤더를 그대로 관찰할 수 있습니다! 즉, 특수 경로에서 덤프/하이버네이션 데이터가 암호화되지 않은 형태로 그대로 노출되어 나타나있는 것을 확인할 수 있습니다.

2.4 Reliability vs. Randomization

이러한 CrashXTS 같은 확률적 취약점의 핵심은 무결성 부재를 통한 corrupt인데, 이 반응은 Windows 시스템이나 버전, 상태에 따라 쉽게 달라지는 특징 때문에 실제로 유도하기가 쉽지 않습니다. 같은 Windows 버전이라도 설치 이력, 업데이트 내역, 드라이버 설치/제거에 따라 레지스트리 하이브 내부 구조와 파일 배치가 달라지기 때문에 매 시스템마다 차등 분석을 처음부터 다시 수행해야 하며 이 과정의 자동화가 사실상 불가능하다고 합니다. 또한 BitLocker 정책이 변경되어도 이미 암호화된 블록은 재암호화되지 않지만 운영 이력에 따라 레이아웃 자체가 달라지므로 한 번 성공한 공격 위치가 다른 시스템에서는 전혀 작동하지 않는 문제가 발생하기도 합니다.

3. Conclusion

이번 연구글에서는 CrashXTS는 XTS의 근본적 한계를 실증했지만, 실용성 측면에서는 다소 제한적입니다. 따라서 다음 Part에서는 BitLocker의 이런 암호화 모드 블록 자체의 corrupt를 일으키기보다는, WinRE 검증 누락, 복구 경로 결함, 키 관리 실수 같은 논리적 결함을 이용한 exploit에 대해 알아보도록 하겠습니다! 오늘도 읽어주셔서 감사합니다.😄

References