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.
You only have to make it as far as the fourth section to see that this doesn't apply only to accounts with auto login enabled.
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.
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.
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?
> 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.
> 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.
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?
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.
Literally the second result on goog for "arso tbal". Did the authors of this article not look to see if anyone else had found this? I guess it's good for seo and visibility?
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)
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.
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.
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
Absolutely a few years ago I was asked to break into some systems (nt) for one of the UK's cinema chains - this was with express permission and the OK from very senior management on our side I should say.
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.
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..
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?
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.
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/ 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.
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.
It's also a risk in case of theft or loss of mind if the hardware is misplaced/lost. Any org with laptop deployments should take a hard look at this bug.
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.
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.
None of the 'features' involved are undocumented. Depending on the Windows SKU parts of these are opt-in (The business and server SKU's) or opt-out (the home/personal SKU's), and configurable through a documented registry key.
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.
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.
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."
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.
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.
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.
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.
> 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.
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-...
You only have to make it as far as the fourth section to see that this doesn't apply only to accounts with auto login enabled.
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.
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.
You are correct about auto-login https://support.microsoft.com/en-us/help/4027599/windows-10-...
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?
> 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.
> 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.
Bitlocker also supports using a password at boot.
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?
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
Probably because this is not a security issue, as you have to be an administrator on the machine to be able to do that.
What? An admin to do what? Also, this doesn't apply to only users with autologin enabled.
To read the credential file from other user's profile.
As somebody shown below, that could be done by anyone with physical access, but only if full-disk encryption is off.
Right, but without this feature, you could NOT perform that attack even with physical access and no FDE.
Now that this feature exists, DPAPI is essentially bypassed and must be supplanted with FDE.
I’d argue FDE is off for 99.9% of users of windows
Not anymore, most store bought laptops will have bitlocker enabled and all enterprise laptops will probably be using bitlocker too.
Bitlocker isn't even an option for Home versions of Windows... Which most store-bought laptops use.
(Almost) a year late: https://vztekoverflow.com/2018/07/31/tbal-dpapi-backdoor/
Literally the second result on goog for "arso tbal". Did the authors of this article not look to see if anyone else had found this? I guess it's good for seo and visibility?
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)
That's a different bug: https://www.theregister.co.uk/2018/09/25/bitlocker_suspensio...
also this: https://edgeprod.evrideo.com/HTML/matrix.html
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.
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.
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
Absolutely a few years ago I was asked to break into some systems (nt) for one of the UK's cinema chains - this was with express permission and the OK from very senior management on our side I should say.
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.
"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?
If you have to rely on bitlocker anyway, then what problem is DPAPI solving?
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..
Isn’t this easily addressed by unchecking the Windows Update feature that uses it?
https://www.thewindowsclub.com/log-automatically-after-windo...
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/, and in the meantime I'm chomping down on my hat. All those fibers must be good for me, right?
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.
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/ 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.
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...
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.
It's also a risk in case of theft or loss of mind if the hardware is misplaced/lost. Any org with laptop deployments should take a hard look at this bug.
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...
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.
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.
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.
This seems like less of a flaw and more of an "undocumented feature".
None of the 'features' involved are undocumented. Depending on the Windows SKU parts of these are opt-in (The business and server SKU's) or opt-out (the home/personal SKU's), and configurable through a documented registry key.
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.
You mean security by obscurity?
I can't be the only one tired of this pedantic platitude.
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.
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."
Is this an auto login feature? If so seems necessary. The question might be if this is the default behavior.
Exactly how terrified should I be right now?
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.
Just keep people from having physical access to your computer and 0/10 terrified.
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.
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.
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.
> 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.
Is it Windows 10?
Is that even news?
snarky or honest? either way, I agree.
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...