@wdormann, definitely, they should become a CNA!
Maxim Suhanov
Computer forensics, computer forensics tool validation, etc.
https://dfir.ru
https://github.com/msuhanov/
🕊
@kajer, it's the "Penscratch 2" theme. I tried (multiple times) to switch to another theme, but... Well, maybe I should try again. :-)
My long post about wide-block & AEAD modes in full-disk encryption: it cover threat models, vulnerabilities, and edge cases.
Key points:
- It's common for FDE implementations to fail outside of the encryption layer.
- Wide-block modes don't protect against CWE-636 (Failing Open), which can lead to things like CVE-2025-4382.
- AEAD modes vs. code that doesn't handle read errors correctly: even FS drivers can misbehave (e.g., validation errors get suppressed and also lead to missing directory entries).
- Defusing the Elephant diffuser: injecting a bunch of null bytes into the BitLocker-encrypted volume (AES-CBC with Elephant diffuser). An interesting but unexploitable bug present since Vista.
- BestCrypt Volume Encryption breaks many XTS mode guarantees (and the vendor doesn't care).
Unfortunately, this paper from 2017 is still relevant.
https://github.com/MotherOfAllVoids/bachelor_thesis/blob/master/text/flaw.pdf
1. BestCrypt Volume Encryption (BCVE) allows watermarking attacks.
2. BCVE allows plaintext injection attacks.
3. BCVE allows forced decryption of some sectors.
It doesn't matter that AES-XTS is used, the vulnerability is in the function wrapping encryption/decryption routines.
Jetico is aware of this flaw, but they won't fix it.
The first two attacks aren't relevant if your threat model excludes users mounting encrypted volumes after an adversary had access to them. This is not the same as physical access, because remote access to unmounted encrypted volumes is possible in dual-boot scenarios, etc.
The third attack allows adversaries to remotely force the decryption of some sectors (like those belonging to a database used by a web-facing application) through spraying (repeatedly causing the INSERT operation of) a specific 16-byte pattern.
Do we really need XTS key scopes here?
@wdormann, one of my colleagues had a Microsoft-assigned CVE revoked because a corresponding fix was shipped in a "regular" software update rather than a security update.
@wdormann, I thought there is an explicit rule for issues exploited ITW. But I can't find it now...
> But container contents are handled as if they have the MotW of the container.
When a program is written in a way that uses the GetStorageDependencyInformation() function or "offloads" the check to the GetZoneFromAlternateDataStreamEx() function.
Are there any programs not from Microsoft that do it?
@wdormann, AFAIK, that fix doesn't propagate MotW to files inside the container. Instead, it extends the MotW check to include parent containers. Software that simply checks the Zone.Identifier stream won't notice anything regardless of the fix.
Maxim Suhanov boosted:
Now that I think about it, perhaps it's a good thing that Trend Micro has foisted this ZDI-CAN-25373 nonsense upon us.
Sometimes it's good to have a nice litmus test to tell what parties in the infosec world are operating in purely self-serving and/or repost-without-understanding mode. 😂
@wdormann, there is no "official route" to programmatically check if a given file has MotW.
Of course, you can check the $Zone.Identifier stream, but code from Microsoft goes beyond that: it also checks that against a container file system image (if there is one).
So, opening an archive with 7-Zip (with MotW enabled for all file types) within a mounted VHDX file would bypass MotW of that VHDX file. But opening that VHDX image with 7-Zip and then navigating to the archive inside wouldn't.
My blog post and a PoC disk image are here: https://dfir.ru/2025/02/23/symlink-attacks-without-code-execution/
According to Microsoft (MSRC), attacks involving symlinks stored on removable drives or in file system images (like VHDX) are not vulnerabilities.
If an unprivileged user manages to quickly replace a regular file in such a location with a symlink to another file (can point anywhere, even into the C:\Windows directory), this is okay.
This means that attackers can defeat existing symlink mitigations ("RedirectionTrust" plus "only privileged users can create symlinks to files") when they are capable of:
- attaching and mounting a removable drive (AV:P/PR:L), or
- mounting a VHDX image (AV:N/PR:N in the worst case, when a VHDX image is delivered via e-mail and then it gets double-clicked by a user, no code execution on the target machine required), or
- mounting a custom file-based container using disk encryption software like VeraCrypt (AV:L/PR:L, because anyone can mount a file-based container).
There is a small bonus: attackers win the race (against the program that follows symlinks when performing privileged operations) in almost every case, because the "replace a regular file with a symlink to another file" primitive comes from the NTFS driver, which performs "a more atomic" replace operation than any usermode application.
The secret is... This is about a crafted file system image, when the "\test\test.txt" file is opened/listed for the first three times (this number is attacker-controlled and can be tuned), it's a regular file; when this file is opened for the fourth time, it's a symlink (the actual replace is performed by the healing routines in the NTFS driver).
I'm attaching a screenshot demonstrating the "not-a-vulnerability".
Symlink attacks without code execution? Yes!
It seems that GRUB developers decided to disable many file system drivers (JFS, NTFS, UDF, etc.) when the Secure Boot lockdown is on.
CrashXTS (CVE-2025-21210): a practical randomization attack against BitLocker (AES-XTS)
It's possible to find and corrupt a specific 16-byte block to leak unencrypted hibernation images.
Five vulnerabilities in AMI file system drivers (NTFS, exFAT): https://dfir.ru/2024/12/09/multiple-vulnerabilities-in-ami-file-system-drivers/
The vendor was fixing one of them for more than two years!
@Rairii I called it "bitlockpick". And there are two ways to exploit this vulnerability: (1) the EFI SP volume which is mountable by the firmware's FAT driver (and by the boot manager) but unrecognized by the FASTFAT driver (i.e., using an unusual sector size); (2) moving the system to an external drive and disconnecting it after the WIM image is loaded.
Operation-based prefetching (aka "Op-EXPLORER.EXE-03C49D11-000000F5.pf"): https://dfir.ru/2024/04/09/operation-based-prefetching/ #DFIR
Here is an interesting vulnerability disclosure timeline for CVE-2022-29974, a buffer overflow in the AMI NTFS driver:
- Vulnerability reported to AMI: 2021-08-27
- Vulnerability confirmed and fixed by AMI: 2021-09-10
- First fixed firmware image released by ASUS (downstream vendor): 2024-03-07
More than 900 days to bring the fixed code into the product!
And no public advisory, no change log entry. I will write a blog post later...
CVE-2023-4001: a password bypass vulnerability in the GRUB boot manager, introduced by a downstream patch.
https://dfir.ru/2024/01/15/cve-2023-4001-a-vulnerability-in-the-downstream-grub-boot-manager/
Client Info
Server: https://mastodon.social
Version: 2025.04
Repository: https://github.com/cyevgeniy/lmst