DPAPI security flaw in Windows 10
passcape.com
passcape.com
Edit: as has been pointed out, this could be triggered by Windows update with a setting enabled https://support.microsoft.com/en-us/help/4027599/windows-10-...
As somebody shown below, that could be done by anyone with physical access, but only if full-disk encryption is off.
Now that this feature exists, DPAPI is essentially bypassed and must be supplanted with FDE.
For the user, everything seems fine: the account is locked after reboot, not auto-logged-in. But the credentials are still readable on the disk.
Per https://vztekoverflow.com/2018/07/31/tbal-dpapi-backdoor/ After the post reboot "login" happens to the last user, the credential is removed from the disk (registry) but will stay in memory. To exploit this, you would need to find a hole in the lock screen, use an admin account to dump memory, or have physical access to the drive before boot that doesn't have bitlocker.
Is there an attack vector that doesn't require privileged access or physical access to the machine without bitlocker/tpm?
In the past, RDMA over Firewire used to be such an attack vector, see the Inception tool that could unlock Windows machines reliably. Presently, there seem to be openly described solutions for using an FPGA hooked up to the TPM to grab keys from the wire. Both types of attacks require physical access and somewhat specialized tools, but AFAIK both work even when Bitlocker and TPM is present.
I don't understand why anyone who actually cares about security uses Bitlocker, and not one of the systems that ask for a password before booting Windows. The latter reduces the attack surface by such a large amount, it's a no-brainer.
And for the TPM attack, is the FPGA able to initiate it? or would this have to be some kind of hardware implant? the latter isn't a big deal - plenty of ways to bug a machine given invasive physical access - the former would be a serious TPM breach akin to GrayKey.
also I'm a little clueless, but my secure laptop has a Bitlocker boot password, with autologin disabled even during updates iirc. does that not mitigate?
As I understand it, the FPGA is able to initiate the TPM key extraction, yes. So it's not a sniffer that has to wait for the user to input the password.
Bitlocker also supports using a password at boot.
I also don't think it's fair to say there isn't a description of mitigation. They outline exactly how this could be mitigated: microsoft should disable lock screen applications.
this quote from the article really distills what this is so bad:
> Unlike the first implementation, the new vulnerability is not a developer mistake, but a forced compromise of security and usability, so to speak.
If microsoft didn't have a secure way of implementing lockscreen applications, they shouldn't have implemented it at all.
Edit: to clarify, the solution isn't even that drastic — simply don't enable lock screen notifications until the user is logged in. It's pretty funny that this vulnerability is partially a side effect of microsoft attempting to mitigate the intrusiveness of their aggressive auto update policies.
> Our experts have found a new serious breach in DPAPI security, allowing anyone to decrypt personal data (protected by DPAPI) of the last active user in Windows 10.
As I had physical access I could boot off floppy and extract the secrets and break them using brute force - I use our art directors then top of the line mac pro.
So I never did get to set up my own cracking farm using the dozen or so suns we had not sure the secret Squirrels would have liked the competition.
This is what bitlocker is for, isn't it?
https://www.thewindowsclub.com/log-automatically-after-windo...
It's a risk if you and another person you don't trust share a machine, and that person has admin access, and you store sensitive stuff on that machine, protected by DPAPI, and some other technical restrictions on updates etc.
But seriously, don't share a machine with a hostile user with admin access and expect secrets stored on that machine to stay secret.
Edit: the auto-credentials saving happens every shutdown, not just for automatic ones, so this is much easier to exploit. The link somebody else in this thread posted is easier to follow (for me anyhow) https://vztekoverflow.com/2018/07/31/tbal-dpapi-backdoor/, and in the meantime I'm chomping down on my hat. All those fibers must be good for me, right?
I suppose if you steal a laptop that's on but locked, and doesn't use FDE, and then open it up and hook it up to the power, wait for patch tuesday, and pull out the battery/cut the power at just the right moment, this is likely reproducibly exploitable without access.
It's a risk, but a fairly far-fetched one. If you have attackers that determined and skilled, use FDE... and pray, because if you've got that kind of time, patience and physical access, there are likely over avenues to exploit.
Admittedly, the features gained for this crack in the security sound pretty limited - after auto-update lock screen apps that depend on DPAPI still display? Yawn.
Edit: https://vztekoverflow.com/2018/07/31/tbal-dpapi-backdoor/ this description is slightly different, and clearly states that the TBAL credentials-saving hack gets used every shutdown, which is much easier to trigger. Given the pointlessness of this feature in the first place, I'm turning if off.
Regardless, if you're willing to wait for Patch Tuesday, then FDE can already be bypassed by means of another bug: https://www.theregister.co.uk/2018/09/25/bitlocker_suspensio...
In this case, it turns out that if you have access to the domain controller as admin, you can decrypt DPAPI secrets by using user's private keys stored there (keys for DPAPI need to "roam" with the account, as do keys for EFS, so it's not surprising that they're there). Likewise, it also turns out that if you decline to provide a password (encryption key) for secrets stored in a PKCS#12 blob (PFX), Windows makes one up for you and this is deterministically bound to your user account (and can be broken with said access).
Neither of these "attacks" cross a privilege boundary - it just turns out crypto isn't magic. As pointed out by other commenters, bitlocker should be enough for most people, but the truth is that if you don't trust your physical environment you need to put in place physical access controls, tamper detection, have a TPM etc, as well as full disk encryption.
If you have domain admin, you can access EVERYTHING in that forest and any two way trusted forest.
This bug is another such example - you have to decide to enable this and ask Windows to store your password to log you in, and that's exactly what happens, including exposure of any secrets protected via DPAPI / bound to your account. It's a convenience feature, working as intended. Perhaps the impact should be made clearer, but there are even legitimate reasons for this sort of functionality, such as self-service kiosks that are often built with windows images.
Security is very often if not always a trade-off with usability/convenience. In this case the security threat of having your service credentials potentially exposed on a consumer device when it has been physically compromised is traded with the convenience of having your notifications and appointments work when the device is on.
You can debate which side of the trade-off you would prefer to be the default in which case. Microsoft has made choices here, which you might or might not agree with, but at the very least they seem to have thought about it, and don't seem to be 'hiding' their default choices made or forcing them.
TL;DR; provided you are an administrator on a Windows machine you can read encrypted user data from another user's home directory without having him login first.
In the video they show you have to be able to read other user's profile, which you are unable to do, unless you are already an administrator.
If the drive is not encrypted, then anybody can read any data. <- OK, that is incorrect. DPAPI is supposed to protect from this by deriving encryption key from your password.
If the drive is encrypted you'd have to know the drive encryption key, which likely (if not necessary) means you are the administrator.
That's the point: DPAPI is (deliberately) bypassed by TBAL, by storing the necessary info from the user's password to decrypt the DPAPI key after reboot.