4 ms·

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 w

by mey 7y ago

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

lostmsu 7y ago
Probably because this is not a security issue, as you have to be an administrator on the machine to be able to do that.
- 9935c101ab17a66 7y ago
  What? An admin to do what? Also, this doesn't apply to only users with autologin enabled.
  - lostmsu 7y ago
    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.
    - kabwj 7y ago
      I’d argue FDE is off for 99.9% of users of windows
      - anieberry 7y ago
        Not anymore, most store bought laptops will have bitlocker enabled and all enterprise laptops will probably be using bitlocker too.
        tracker1 7y ago
        Bitlocker isn't even an option for Home versions of Windows... Which most store-bought laptops use.
    - shawnz 7y ago
      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.
      - deleted 7y ago
        [deleted]
icebraining 7y ago
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 7y ago
  You are correct about auto-login https://support.microsoft.com/en-us/help/4027599/windows-10-automatically-finish-setting-up-pc-after-update-restart https://support.microsoft.com/en-us/help/4027599/windows-10-... 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 7y ago
    > 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 7y ago
      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?
9935c101ab17a66 7y ago
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.

by mey 7y ago

lostmsu 7y ago

Probably because this is not a security issue, as you have to be an administrator on the machine to be able to do that.

9935c101ab17a66 7y ago
What? An admin to do what? Also, this doesn't apply to only users with autologin enabled.
- lostmsu 7y ago
  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.
  - kabwj 7y ago
    I’d argue FDE is off for 99.9% of users of windows
    - anieberry 7y ago
      Not anymore, most store bought laptops will have bitlocker enabled and all enterprise laptops will probably be using bitlocker too.
      - tracker1 7y ago
        Bitlocker isn't even an option for Home versions of Windows... Which most store-bought laptops use.
  - shawnz 7y ago
    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.
    - deleted 7y ago
      [deleted]

icebraining 7y ago

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 7y ago
You are correct about auto-login https://support.microsoft.com/en-us/help/4027599/windows-10-automatically-finish-setting-up-pc-after-update-restart https://support.microsoft.com/en-us/help/4027599/windows-10-... 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 7y ago
  > 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 7y ago
    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?

9935c101ab17a66 7y ago

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.