From 675c0e151f3a3a9442267df27eec4db855594468 Mon Sep 17 00:00:00 2001 From: Rafal Sosnowski <51166236+rafals2@users.noreply.github.com> Date: Tue, 4 Oct 2022 10:05:57 -0700 Subject: [PATCH 1/3] Update bitlocker-countermeasures.md added info about the rogue OS attack --- .../bitlocker/bitlocker-countermeasures.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/windows/security/information-protection/bitlocker/bitlocker-countermeasures.md b/windows/security/information-protection/bitlocker/bitlocker-countermeasures.md index 4f129193e8..b4a4825f7b 100644 --- a/windows/security/information-protection/bitlocker/bitlocker-countermeasures.md +++ b/windows/security/information-protection/bitlocker/bitlocker-countermeasures.md @@ -155,6 +155,12 @@ It also blocks automatic or manual attempts to move the paging file. Enable secure boot and mandatorily prompt a password to change BIOS settings. For customers requiring protection against these advanced attacks, configure a TPM+PIN protector, disable Standby power management, and shut down or hibernate the device before it leaves the control of an authorized user. +### Tricking BitLocker to pass the key to a rogue Operating system + +An attacker can modify the boot manager (BootMgr) configuration database (BCD) which is stored on a non-encrypted partition and add an entry point to a rogue OS on a different partition. During the boot process, BitLocker code will make sure that the operating system that the encryption key obtained from the TPM is given to, is cryptographically verified to be the intended recipient. Because this strong cryptographic verification already exists, Microsoft doesn’t recommend storing a hash of a disk partition table in Platform Configuration Register (PCR) 5. + +Also, an attacker can replace the entire OS disk while preserving the platform hardware and firmware and then could extract a protected BitLocker key blob from the metadata of the victim OS partition. The attacker could then attempt to unseal that BitLocker key blob by calling the TPM API from an operating system under their control. This will not succeeed because when Windows seals the BitLocker key to the TPM, it does it with a PCR 11 value of 0 and to successfully unseal the blob, PCR 11 in the TPM must have value of 0. However, when boot manager passes the control to any boot loader (legitimate or rogue) it always changes PCR11 to a value of 1. Since the PCR 11 value is guaranteed to be different after exiting the boot manager, the attacker can't unlock the Bitlocker key. + ## Attacker countermeasures The following sections cover mitigations for different types of attackers. From cf74c4bcf71030de1c3401be24073937125a61d0 Mon Sep 17 00:00:00 2001 From: Aaron Czechowski Date: Thu, 17 Nov 2022 11:12:02 -0800 Subject: [PATCH 2/3] Apply suggestions from code review Co-authored-by: JohanFreelancer9 <48568725+JohanFreelancer9@users.noreply.github.com> --- .../bitlocker/bitlocker-countermeasures.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/windows/security/information-protection/bitlocker/bitlocker-countermeasures.md b/windows/security/information-protection/bitlocker/bitlocker-countermeasures.md index b4a4825f7b..039978c46a 100644 --- a/windows/security/information-protection/bitlocker/bitlocker-countermeasures.md +++ b/windows/security/information-protection/bitlocker/bitlocker-countermeasures.md @@ -155,11 +155,11 @@ It also blocks automatic or manual attempts to move the paging file. Enable secure boot and mandatorily prompt a password to change BIOS settings. For customers requiring protection against these advanced attacks, configure a TPM+PIN protector, disable Standby power management, and shut down or hibernate the device before it leaves the control of an authorized user. -### Tricking BitLocker to pass the key to a rogue Operating system +### Tricking BitLocker to pass the key to a rogue operating system -An attacker can modify the boot manager (BootMgr) configuration database (BCD) which is stored on a non-encrypted partition and add an entry point to a rogue OS on a different partition. During the boot process, BitLocker code will make sure that the operating system that the encryption key obtained from the TPM is given to, is cryptographically verified to be the intended recipient. Because this strong cryptographic verification already exists, Microsoft doesn’t recommend storing a hash of a disk partition table in Platform Configuration Register (PCR) 5. +An attacker might modify the boot manager configuration database (BCD) which is stored on a non-encrypted partition and add an entry point to a rogue operating system on a different partition. During the boot process, BitLocker code will make sure that the operating system that the encryption key obtained from the TPM is given to, is cryptographically verified to be the intended recipient. Because this strong cryptographic verification already exists, we don’t recommend storing a hash of a disk partition table in Platform Configuration Register (PCR) 5. -Also, an attacker can replace the entire OS disk while preserving the platform hardware and firmware and then could extract a protected BitLocker key blob from the metadata of the victim OS partition. The attacker could then attempt to unseal that BitLocker key blob by calling the TPM API from an operating system under their control. This will not succeeed because when Windows seals the BitLocker key to the TPM, it does it with a PCR 11 value of 0 and to successfully unseal the blob, PCR 11 in the TPM must have value of 0. However, when boot manager passes the control to any boot loader (legitimate or rogue) it always changes PCR11 to a value of 1. Since the PCR 11 value is guaranteed to be different after exiting the boot manager, the attacker can't unlock the Bitlocker key. +An attacker might also replace the entire operating system disk while preserving the platform hardware and firmware and could then extract a protected BitLocker key blob from the metadata of the victim OS partition. The attacker could then attempt to unseal that BitLocker key blob by calling the TPM API from an operating system under their control. This will not succeed because when Windows seals the BitLocker key to the TPM, it does it with a PCR 11 value of 0, and to successfully unseal the blob, PCR 11 in the TPM must have a value of 0. However, when the boot manager passes the control to any boot loader (legitimate or rogue) it always changes PCR 11 to a value of 1. Since the PCR 11 value is guaranteed to be different after exiting the boot manager, the attacker can't unlock the Bitlocker key. ## Attacker countermeasures From b0273ae8a6e96341887a7ca0a79f85c976d7ab51 Mon Sep 17 00:00:00 2001 From: Stephanie Savell <101299710+v-stsavell@users.noreply.github.com> Date: Thu, 17 Nov 2022 13:27:15 -0600 Subject: [PATCH 3/3] Update windows/security/information-protection/bitlocker/bitlocker-countermeasures.md --- .../bitlocker/bitlocker-countermeasures.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/security/information-protection/bitlocker/bitlocker-countermeasures.md b/windows/security/information-protection/bitlocker/bitlocker-countermeasures.md index 813daa0b78..03c95bbdde 100644 --- a/windows/security/information-protection/bitlocker/bitlocker-countermeasures.md +++ b/windows/security/information-protection/bitlocker/bitlocker-countermeasures.md @@ -159,7 +159,7 @@ For customers requiring protection against these advanced attacks, configure a T An attacker might modify the boot manager configuration database (BCD) which is stored on a non-encrypted partition and add an entry point to a rogue operating system on a different partition. During the boot process, BitLocker code will make sure that the operating system that the encryption key obtained from the TPM is given to, is cryptographically verified to be the intended recipient. Because this strong cryptographic verification already exists, we don’t recommend storing a hash of a disk partition table in Platform Configuration Register (PCR) 5. -An attacker might also replace the entire operating system disk while preserving the platform hardware and firmware and could then extract a protected BitLocker key blob from the metadata of the victim OS partition. The attacker could then attempt to unseal that BitLocker key blob by calling the TPM API from an operating system under their control. This will not succeed because when Windows seals the BitLocker key to the TPM, it does it with a PCR 11 value of 0, and to successfully unseal the blob, PCR 11 in the TPM must have a value of 0. However, when the boot manager passes the control to any boot loader (legitimate or rogue) it always changes PCR 11 to a value of 1. Since the PCR 11 value is guaranteed to be different after exiting the boot manager, the attacker can't unlock the Bitlocker key. +An attacker might also replace the entire operating system disk while preserving the platform hardware and firmware and could then extract a protected BitLocker key blob from the metadata of the victim OS partition. The attacker could then attempt to unseal that BitLocker key blob by calling the TPM API from an operating system under their control. This will not succeed because when Windows seals the BitLocker key to the TPM, it does it with a PCR 11 value of 0, and to successfully unseal the blob, PCR 11 in the TPM must have a value of 0. However, when the boot manager passes the control to any boot loader (legitimate or rogue) it always changes PCR 11 to a value of 1. Since the PCR 11 value is guaranteed to be different after exiting the boot manager, the attacker can't unlock the BitLocker key. ## Attacker countermeasures