
DPAPI security flaw in Windows 10 - iohn
https://www.passcape.com/index.php?setLang=2&section=blog&cmd=details&id=38
======
mey
My brief understanding. If you have auto login enabled, it is possible to gain
access to an account secrets stored in a security store. That sounds bad, but
with auto login you are already unlocking an account. No CVE posted. No
description of mitigation. A hostile view of Microsoft in closing remarks.

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-...](https://support.microsoft.com/en-
us/help/4027599/windows-10-automatically-finish-setting-up-pc-after-update-
restart)

~~~
icebraining
This is what I first thought, but here the auto-login is not enabled by the
user, but configured automatically by Windows Update so that it automatically
logs in the previous user (and immediately locks the session) after a reboot
for installing updates, so that the lock screen apps work.

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.

~~~
mey
You are correct about auto-login [https://support.microsoft.com/en-
us/help/4027599/windows-10-...](https://support.microsoft.com/en-
us/help/4027599/windows-10-automatically-finish-setting-up-pc-after-update-
restart)

Per [https://vztekoverflow.com/2018/07/31/tbal-dpapi-
backdoor/](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?

~~~
semi-extrinsic
> 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.

~~~
sterlind
If I'm understanding correctly, did the RDMA attack work because it was able
to probe arbitrary memory-mapped registers on request?

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?

~~~
semi-extrinsic
I think if you have Bitlocker set up with a boot password, and you are careful
to shut down when you're not using the computer, then you're probably fine.
But in my experience most people use Bitlocker just with the Windows login
prompt.

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.

[https://pulsesecurity.co.nz/articles/TPM-
sniffing](https://pulsesecurity.co.nz/articles/TPM-sniffing)

------
icebraining
(Almost) a year late: [https://vztekoverflow.com/2018/07/31/tbal-dpapi-
backdoor/](https://vztekoverflow.com/2018/07/31/tbal-dpapi-backdoor/)

~~~
sascha_sl
What's interesting is that neither mention that a windows update triggered
reboot - at least when i was on insider builds - somehow auto-unlocks
bitlocker (or it may be using a kernel level restart like kexec, which
apparently is a thing that exists in windows server at least)

~~~
shawnz
That's a different bug:
[https://www.theregister.co.uk/2018/09/25/bitlocker_suspensio...](https://www.theregister.co.uk/2018/09/25/bitlocker_suspension_patching_mystery/)

------
gloflo
I was wary to click because of the unknown domain name and the vague
clickbaity title but it seems legit and quite severe:

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

------
a-dub
so basically, if you have "root", you can get at another user's secret store
through some esoteric weird means under some weird windows post update auto
reboot auto logon whatever... which means absolutely nothing because if you
have "root" you can do a billion other things to get at the same secret store
anyway... i don't see the point of this.

~~~
S-E-P
This is for when an attacker has physical access, as in they can just pull the
information from the drive (by mounting the drive to another OS, i.e. from
USB), without any restriction from the Windows OS

------
13of40
"The problem for a user is that after the system is shut down, anyone who has
physical access to the PC..."

This is what bitlocker is for, isn't it?

~~~
caf
If you have to rely on bitlocker anyway, then what problem is DPAPI solving?

~~~
la_barba
It was created as a system level vault to store private keys, passwords and
the like without requiring a library. But that was 20 odd years ago, so who
knows what problem its solving now. Full-disk encryption was probably
considered computationally expensive back then too..

------
floatingatoll
Isn’t this easily addressed by unchecking the Windows Update feature that uses
it?

[https://www.thewindowsclub.com/log-automatically-after-
windo...](https://www.thewindowsclub.com/log-automatically-after-windows-
update)

~~~
emn13
Or don't, because this isn't a real risk.

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/](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?

~~~
shawnz
It's a risk if anyone has physical access, you have sensitive stuff stored in
DPAPI, and FDE isn't enabled. The risk isn't related to having other admin
users on the system or anything to do with updates.

~~~
emn13
In theory perhaps: but by the description given in this article the keys are
not permanent, and that means you'd need to wait for an automatic reboot, and
cut the power while that's occurring, and you need to do that right on the
very first try, because if the system fails to store the key for any reason,
it's not retrievable without the user logging in (and if you could do that,
this whole saga wouldn't have been necessary). The demo appears to require
admin access anyhow.

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/](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.

~~~
shawnz
Ah, I didn't see that the article indicated that this only occurred on
automatic reboots. Between this and the other article it's not clear if it
happens on every reboot or not, but if that's not the case then this is indeed
somewhat less severe.

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...](https://www.theregister.co.uk/2018/09/25/bitlocker_suspension_patching_mystery/)

~~~
emn13
I'm not sure anymore if it's every shutdown or patch tuesday anymore; but it
sounds like every shutdown? Somebody would need to repro.

------
zahllos
This is not the first time "serious" flaws have been found with DPAPI. Here's
another example: [https://cqureacademy.com/blog/windows-internals/black-hat-
eu...](https://cqureacademy.com/blog/windows-internals/black-hat-europe-2017)

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.

~~~
lordlimecat
A domain admin can access the user's long term kerberos encryption keys and
generate arbitrary key tabs for that user.

If you have domain admin, you can access EVERYTHING in that forest and any two
way trusted forest.

~~~
zahllos
Of course. Hence it isn't really a flaw if you need domain admin to gain
access. It's a vulnerability or major fault if an ordinary user can get
access, or worse an unauthenticated user / someone with a specially crafted
network packet. Obviously domain admin accounts need to be suitably protected
and you hint at this in your comment (ESAE) but that's another matter.

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.

------
fileoffset
This seems like less of a flaw and more of an "undocumented feature".

~~~
ekianjo
You mean security by obscurity?

~~~
PeterStuer
I can't be the only one tired of this pedantic platitude.

------
ocdtrekkie
I have some serious concerns about the security chops of the author, who
recommends using the Syskey startup password feature, which is trivial to
crack, mostly used by support scammers, and removed in recent versions of
Windows 10 because it is like having a screen door on a submarine.

------
x0n
Smells like some slashdot neckbeard propaganda when you punctuate your
objective facts with statements like "As we warned in our previous article,
the next versions of Windows will become less and less focused on ensuring the
safety for an end-user."

------
kerng
Is this an auto login feature? If so seems necessary. The question might be if
this is the default behavior.

------
billpg
Exactly how terrified should I be right now?

~~~
NikkiA
Unless you're a snowden, DPR or khashoggi you're probably not worth the
headache, effort and time that this process would require just to get your
encryption keys.

------
lostmsu
I think this article is quite misleading as to the severity of the issue. It
is basically by design.

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.

~~~
icebraining
You don't need to be an admin, just have physical access and plug the drive
into another computer. Which is why the early W10 versions used to require
enabled full-disk encryption before allowing this feature.

~~~
lostmsu
I am not sure what you mean.

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.

~~~
icebraining
> OK, that is incorrect. DPAPI is supposed to protect from this by deriving
> encryption key from your password.

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.

------
mikojan
Is it Windows 10?

------
timeimp
Doesn't this happen on macOS after an update? I mean, I have returned to my
Mac to see my login sitting there as if nothing happened...

