Today I figured out that FileZilla uses PuTTY‘s registry key (HKCU\SOFTWARE\SimonTatham\PuTTY\SshHostKeys) to cache SSH fingerprints.
This morning, I connected to my server over SFTP with FileZilla, and got this prompt:
That’s unusual. I logged in over SSH, and my SSH client did not show a warning. I checked the fingerprint on my server, and it matched the one presented by FileZilla.
What’s going on here? I started to search through FileZilla configuration files (XML files) looking for the cached fingerprints, and found nothing. Then I went to the registry, but there’s no FileZilla entry under my HKCU Software key.
Then I’m taking a look with ProcMon to figure out where FileZilla caches its fingerprints. After some searching, I found the answer:
FileZilla uses PuTTY’s registry keys!
And indeed, when I start FileZilla again and allow it to cache the key, it appears in PuTTY’s registry keys.
One last check: I modified the registry entry and started FileZilla again:
And now FileZilla warns me that the key is different. That confirms that FileZilla reads and writes PuTTY’s registry fingerprint cache.
So that answered my question: “Why did FileZilla warn me this morning?” “Because the key was not cached”.
But then I was left with another question: “Why is the key no longer cached, because it was cached?”
Well, I started to remember that some days ago today, I had been experimenting with PuTTY’s registry keys. I most likely deleted that key (PuTTY is not my default SSH client). I verified the last-write timestamp for PuTTY’s registry key, and indeed, 4 days ago it was last written to.
Thanks to Nicolas for pointing out that fzsftp is based on PuTTY:
I was able to get the “ProxyLogon PoC” Python script running against a vulnerable Exchange server in a VM. It required some tweaks to the code, and also a change in Exchange permissions, as explained in this tweet by @irsdl.
I created a capture file:
More details will follow.