3 ms·

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 stor

by emn13 7y ago

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 7y ago
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 7y ago
  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 7y ago
    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_suspension_patching_mystery/ https://www.theregister.co.uk/2018/09/25/bitlocker_suspensio...
    - emn13 7y ago
      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.
Beltiras 7y ago
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.

by emn13 7y ago

shawnz 7y ago

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 7y ago
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 7y ago
  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_suspension_patching_mystery/ https://www.theregister.co.uk/2018/09/25/bitlocker_suspensio...
  - emn13 7y ago
    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.

Beltiras 7y ago

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.