So in “proxy” mode, Cowrie is pretty damn powerful. It proxies you through to a backend pool of live systems or virtual machines. It is god damn awesome.
My previous detection methods based on shell stuff don’t work, because you are proxied through to a live system. Also, if you hit the honeypot twice from the same IP, you get the same VM, which partially mitigates my file write-and-read attack.
Furthermore, if you are going through the effort to set up your honeypot to use the “proxy” mode, you probably will spend a few seconds mitigating the fingerprinting via hassh approach.
So we are cooked. They finally made a honeypot good enough to ensnare us. Might as well quit and go home?
Not so! We can still pull off the file write-and-read trick if we come from different source IP’s, which is trivial enough using Tor or any public SOCKS proxy, but that isn’t quite neat enough of a solution to warrant a whole new blog post. Oh no. We need something better.
So based on some observations in my logs of certain botnets dropping SSH keys as a persistence mechanism, I had an idea. What if we were to drop an SSH public key onto the filesystem, then try log in with its associated public key? The Cowrie proxy handles all the authentication stuff, and likely won’t be aware that the backend VM should be letting us in with said key. So if the second login attempt using only the key fails, we can be relatively sure we are being monitored and bail out.
In order to test this hypothesis, we sat down and set up Cowrie in Proxy mode on a DigitalOcean instance.
First, we generate up some SSH keys using
ssh-keygen, and then we copy them to the honeypot from our attacker host using the following command:
ssh-copy-id -i test -p 2222 root@honeypot-ip-address.
Now that the keys have been successfully added, we simply try log in with them:
ssh -i test -l root -p 2222 honeypot-ip-address, and notice that it refuses the key, but wants the password. This indicates there is something in the way middling our SSH connection and fucking with us.
So to verify, we log into the honeypot one last time, and check our key actually was deployed. It was.
So basically, this is a variation on the write-and-read attack, and works as a replacement for it. You log in with password auth, drop your SSH key, log back out, then try log in with the SSH key.
So that confirms this technique works as a pretty good way to handle proxy-type SSH honeypots, with Cowrie as an example. I cannot yet think of a good way to work around this kind of detection for the Cowrie developers, but I’m sure there is something that would work. I can think of several things that won’t work – such as accepting any key based authentication, which in and of itself is fingerprintable.
Automating this one is left as an exercise to the reader, however you can easily modify my file-write-read tool to do it.
I’ll be back in the future possibly with more ways to detect honeypots. For now though, I’ll go back to just running them for a while.