Hacker News Reader

Comment by jkaplowitz | Hacker News Reader

No, part of this involved using Windows's Data Protection API to decrypt it.

Other non-administrator users can't read these registry keys, it's encrypted with the login password (as is common with macOS Keychain and GNOME/KDE's credential stores) so even other administrators can't decrypt it.

On Linux, administrators (root) can extract the keys from ssh-agent. This is actually no less secure and usually more secure.

This is a cool demo of how to do it on Windows, and there's a reason the author didn't call it a vulnerability - it's working as designed and this form of attack is outside the intended threat model.

View on HN

>On Linux, administrators (root) can extract the keys from ssh-agent.

I don't understand how the situation is different. Of course you can extract the keys from a running ssh-agent since the whole point is not having to provide your password every time so they have to have access to the private key one way or an other. How is the situation different on Windows? Surely when the user is logged an administrator with access to the full RAM and storage will be able to piece everything together (like TFA does for instance)?

On the other hand if you really can't trust your admin you have a huge problem anyway, even with a HSM you could be phished very easily.

Actually overall I'd say that this Windows method is slightly less secure because it means that the Windows keychain thingy is a single point of failure, if somebody compromises it they have access to everything including the ssh keys in the registry.

I don't think Windows gives an administrator account unfettered access to the full RAM, no. And without that or the user's login password, all they could get from the registry is the encrypted version, just as on disk. The encryption is separate per-user with that user's password.

Of course there may be ways to get an even more advanced level of access than administrator, such as the system account, but honestly Windows does lock some things down really hard at the kernel level and Data Protection decryption based on in-RAM credentials might be one. I don't know modern Windows internals to that level.

>I don't think Windows gives an administrator account unfettered access to the full RAM, no.

Are you sure? Typically root has access to the full RAM on an unx system. Unless this is linked to a hardware TPM module I'm not sure why and how it would be protected. Maybe I'm wrong to assume that Windows Administrator == unx root?

Anyway, if the OS has a way to hide some of its state from even the admin then surely it could use it to hide the unencrypted SSH key in RAM instead of hiding the key-to-the-registry-key? My main argument is that at some point if the OS doesn't want to prompt the user for a password it must have access to the private key one way or an other, so I'm not convinced that Windows is more (or less) secure than Linux in this situation.

If you're admin, you might have to install a driver to scrape all memory. So... one hoop to jump through :)

Caveat: you're still trapped in your hypervisor partition. Enclaves (e.g. SGX) are also protected from admin/root snooping. IIRC, this is the same as on Linux.

Reply on news.ycombinator.com