Most FDE vendors/projects don't consider vectors requiring repeated physical access as a vulnerability.

But there is another side to this: an HDD/SSD firmware backdoor (or a network attacker injecting arbitrary data into a disk image booted over the network) has a way to inject attacker-controlled data into an encrypted volume despite code integrity controls like Secure Boot and TPM-based unlocks (the "Implementation and Implications of a Stealth Hard-Drive Backdoor" paper told us the opposite).

In one MSRC case, Microsoft agreed to treat the data-only attack against BitLocker from the storage path as a vulnerability.

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?

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!

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...

The ntfs3 driver can produce files without names (but with valid data).

Currently, such files (and their allocated clusters) can't be deleted without booting into Windows.

And many #DFIR tools don't list such files as orphan ones...

https://github.com/sleuthkit/sleuthkit/issues/2813

https://bugzilla.kernel.org/show_bug.cgi?id=217130