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.
>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.
It's protected by DPAPI [0] which uses the user's password to encrypt the keys. Any other programs running under that user can theoretically access it (just like how any program can access your ~/.ssh/id_rsa) but other users shouldn't be able to access it.
~/.ssh/id_rsa can be protected by a password, you'll want to access the running ssh-agent process memory to get the key in cleartext (unless the person use some security token in which case you can't access the key, just try to login on a remote computer directly while the HSM is available).
jkaplowitz|7 years ago
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.
simias|7 years ago
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.
eat_veggies|7 years ago
[0] https://msdn.microsoft.com/en-us/library/ms995355.aspx
simias|7 years ago