Extracting SSH Private Keys from Windows 10 ssh-agent

https://blog.ropnop.com/extracting-ssh-private-keys-from-windows-10-ssh-agent/

by vuln • 8 years ago

148 63 8 years ago

blog.ropnop.com

So ssh private keys are stored in plain base64 encoding in the windows registry? How is that even possible?

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.

[0] https://msdn.microsoft.com/en-us/library/ms995355.aspx

simias4• 8 years ago

~/.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).

jkaplowitz3• 8 years ago

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.

simias4• 8 years ago

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.

slrz2• 8 years ago

From [1], cited and linked to in TFA:

To do that, we simply start the ssh-agent service (as Administrator) and use ssh-add to store our private key.

Did Microsoft do some major surgery on the ssh-agent program or am I missing something else? If the agent is started as Administrator, why can I connect to it with my user privileges? And if I do, can other users on the same system do so, too, accessing the same set of keys?

[1] https://blogs.msdn.microsoft.com/powershell/2017/12/15/using...

Amezarak2• 8 years ago

And if I do, can other users on the same system do so, too, accessing the same set of keys?

No, that's what DPAPI handles. His DPAPI call works because he's decrypting his own credentials.

Someone12343• 8 years ago

Unprivileged processes can communicate with privileged services.

The service itself sometimes controls which user can access which data, but in this case since the encrypted keys are stored in the Current User Registry Hive (NTUSER.DAT) it likely doesn't need to, filesystem permissions handle that.

Plus even if another user gained access to your registry hive, the data is encrypted with your context via the Data Protection APIs.

simias4• 8 years ago

I'm sure they have a good reason to do it that way but why run a privileged process when per-user processes could do the job just fine? You'd reduce the surface of attack tremendously that way.

If somebody finds a flaw in their admin ssh-agent process they potentially have a way to access other people's key or maybe even escalate their privileges.

joombaga• 8 years ago

Wow thanks for this. I never knew the current user registry hive was stored at NTUSER.dat. I've always figured out the user id and navigated through hkey_users.

slrz2• 8 years ago

The service itself sometimes controls which user can access which data,

Sure, but ssh-agent does not. That's what I was alluding to with "major surgery".

Also, while the encrypted keys are stored in the file system or registry, the agent process necessarily has them in unencrypted form. That's the reason for loading keys into the agent in the first place.

To have an ssh-agent that can run as a privileged system service with multiple unprivileged clients, you need to extend it to have some notion of client identity and per-user key space. The standard OpenSSH ssh-agent doesn't have that. Users run their own instance each and if you can connect to it, you can use the keys loaded into it. All of them.

The agent code at github.com/PowerShell/openssh-portable doesn't look any different to me, at least from a cursory glance.

Thus, the decision to run it as a system service seems odd to me.

edit: are they hooking into the agent as a PKCS11 provider/"smartcard" and the plaintext keys never even hit the agent's in-memory table, to be queried by all connected clients?

bluesign• 8 years ago

Because they are using the same ssh-agent also for accessing host keys (for sshd)

PS: Also one agent process for all users on machine vs each user running a ssh-agent process

meredydd• 8 years ago

Just a heads-up - the pixelation used to hide the keys in the final screenshot is not safe! There aren't that many possible characters in each of those 10x10px blocks, and ~256 levels of average brightness is enough to distinguish between them. (Here's a simplistic demo: https://dheera.net/projects/blur)

Stick to the block-of-constant-colour method used in the first few screenshots. It's ugly but safer!

discreditable• 8 years ago

As I read the article I thought it was more silly they didn't simply use burner keys as PoC.

kevin_thibedeau• 8 years ago

They are burner keys. The red boxes are pointless.

EpicEng• 8 years ago

Yeah... why wouldn't you simply black it out? Easier and safer. I guess it doesn't look as fancy...

ropnop4• 8 years ago

Cool thanks for sharing! They were all burner keys anyway, just blurred/obfuscated for "best practice"

e40• 8 years ago

So, good reason to use the Cygwin version of ssh-agent? I assume it doesn't suffer from the same thing.

EvanAnderson5• 8 years ago

I don't understand what it "suffers" from. It's performing as-intended. A user needs to be able to retrieve the plaintext of their SSH private keys.

There's nothing that seems architecturally unsound about how Microsoft implemented this. DPAPI is a reasonable way to protect the keys "at rest" in the registry. The OP was able to extract the keys because he has the credentials for the user from whom he is extracting the keys.

Short of storing the keys in the memory of a dedicated crypto-processor outside the host computer (and performing the cryptographic operations there) the plaintext of the private keys will have to be recoverable to the user.

throwaway2048• 8 years ago

the entire point of agents is that they DON'T just hand you key plaintext, otherwise what would the point of them be compared to just an un-encrypted file.

ssh-agent signs requests, tokens, etc on your behalf. You never see the private key.

ropnop4• 8 years ago

I haven't looked at Cygwin's ssh-agent but I'm sure it's possible to achieve the same thing. The unencrypted private keys have to be stored somewhere (either in memory or protected on disk). Could probably just dump Cygwin's memory and extract from there.

DangerousPie• 8 years ago

Am I correct in thinking that this is working as intended, and not actually a vulnerability? Many people seem to be sharing this as "look at Microsoft screwing up ssh-agent security", but I can't actually see any evidence of this in the article.

EvanAnderson5• 8 years ago

You are correct. There is no "vulnerability" here. The plaintext of the user's private keys must be accessible to the CPU performing the cryptographic operations. DPAPI is a reasonable method to keep the keys encrypted "at rest" while allowing the keys to be decrypted w/o the requiring password entry each time the keys are used.

It is helpful for post-exploitation toolkits to have this functionality.

vesinisa• 8 years ago

AFAIK the whole point of ssh-agent is that the private keys are NOT extractable by other processes.

https://man.openbsd.org/ssh-agent:

The agent will never send a private key over its request channel. Instead, operations that require a private key will be performed by the agent, and the result will be returned to the requester. This way, private keys are not exposed to clients using the agent.

This sounds like a pretty gaping security hole by Microsoft. I would not assume loading private keys to an "ssh-agent" means giving any process (browser, email client etc.) running on the same machine access to the unencrypted values!

ropnop4• 8 years ago

Yep, you're correct. Not a vulnerability or an exploit. It's always going to be possible with the right privileges, I was just wanted to see and show the "how"

netinstructions2• 8 years ago

The author of this blog must have uploaded an image without the big red block to mask the private key, realized their error, and replaced it with an image of it blocked. However they didn't remove the unblocked image first. Ghost (the blog engine here) just appends a number to the image when you replace it without changing the filename, so it's easy to find. See the two URLs below:

https://blog.ropnop.com/content/images/2018/05/base64_decode...

This is probably a good reason to use burner keys for proof of concepts.

e1ven• 8 years ago

While I agree it's good to use a burner key, you could have emailed him instead of posting links to both keys on HN...

netinstructions2• 8 years ago

I read that they were burner keys.

With people discussing reverse-engineering the pixelated images to access the keys, the merits of masks, security, etc it seemed like a lesson worth sharing for everyone's benefit here that an email wouldn't have accomplished.

ropnop4• 8 years ago

Author here...heh nice find.

All keys used were burner keys anyway.

The only reason I blurred and obfuscated where I could was just for "best practice" not for real security. I knew if I didn't people would comment that I should've ;)

dspillett• 8 years ago

I knew if I didn't people would comment that I should've ;)

That and following good practise even when not actually necessary due to other mitigations, you obviously hint to less experienced readers what good practise is.

ryan-c• 8 years ago

Even just the half of the key in that secreenshot is likely to be sufficient to recover the whole thing as well - RSA private key formats have a ton of redundant data.

zx2c4• 8 years ago

Also, see the Coppersmith method:

https://en.wikipedia.org/wiki/Coppersmith_method

vbezhenar• 8 years ago

With Linux if I'm a program running under target user, I can use unlocked ssh-agent to perform crypto operations with private key, but I can't extract the key itself. With Windows I can just steal the key itself. I think Windows is worse here. Am I misunderstanding something? What's the point of password protection if key is stored unprotected by this password in the registry?

gnopgnip• 8 years ago

The keys are protected in the registry with the current user context. You need administrator permissions on Windows to get the private keys, comparable to OSX or Linux

EvanAnderson5• 8 years ago

The private key is stored password-protected in the registry. DPAPI, the API used to protect the private key, encrypted based on the user's Windows account password, and allows decryption without further password entry by the already-logged-on user. There isn't an equivalent API in the Unix world that I'm aware of. When you fire-up the Windows SSH agent no password entry is necessary, because the password used to logon to Windows is also used to decrypt the stored private key. In a Unix environment you'd need to enter a passphrase to allow the SSH agent to decrypt the key.

bennofs• 8 years ago

The equavilent in the unix world is gnome keyring (or any other Secret Service spec implementation) unlocked by a PAM module on login.

kbumsik• 8 years ago

I don't know if I missed your point but right now I can export a private key using seahorse, a key manager program, very easily not using its password.

hirsin• 8 years ago

I have no idea how the original author soleblaze figured out the correct format of the binary data, but I am so thankful he did and shared.

Good time to point out that we open sourced [0] all of this so I have some guesses as to how soleblaze might have "reverse engineered" it :-)

0. https://github.com/PowerShell/openssh-portable

ww520• 8 years ago

I assume the author doing these under the Administrator account or had admin privilege.

EvanAnderson5• 8 years ago

They had the credentials for the user account under which the private keys were stored. This is a post-exploitation concern, not a vulnerability.

kuroguro• 8 years ago

You can read them with or without admin access on the same user. On the other hand a different user's admin account wouldn't help unless you can dump the first user's password.

https://msdn.microsoft.com/en-us/library/ms995355.aspx#winda...

a-dub• 8 years ago

OT: Does the existence of this openssh port mean that the Windows command window is now a fully functioning terminal?

oblio• 8 years ago

It depends on what you mean by fully functional.

Piskvorrr• 8 years ago

In other words, no. There's basic functionality though - 80/20 etc.

janci• 8 years ago

So basically the article is saying Windows protects the keys much better than linux, where the key sits unencrypted in ~/.ssh folder?

_ikke_• 8 years ago

No:

1. You can choose to have the keys encrypted with a password (same for Windows as for Linux)

2. The key, whether encrypted or unencrypted, are for both platforms stored on disk in the user profile (see first screenshot)

3. This talks about ssh-agent, which you can use to cache the the unencrypted key so that you don't have to type the encryption password every time you want to use the key. On Linux, this is just stored in memory, whereas in Windows, it's stored (encrypted) in the registry as well.

Extracting SSH Private Keys from Windows 10 ssh-agent

Related Stories