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.
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.
Bitlocker also supports using a password at boot.
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.
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.
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-...