SSH: Open to the World

March 18, 2019

Recently I’ve taken an interest on real-word security and, in particular, deception mechanisms such as honeypots.

I have a personal network at home with some Raspberry Pis and a NAS, and sometimes I have to access them from elsewhere in the world, so naturally I exposed one of the Raspberries to the scary Internet. It only serves as a headnode, and only has SSH enabled (on a non standard port - although that’s security-by-obscurity, I never get connections attempts, and even if I did, they still would have to use PubKey Authentication and cross fail2ban 😉 ).

Discovering Honeypots

While I am too careful (or paranoid) to expose my actual port 22 to the world, I was still curious to see what hackers think it’s cool nowadays, so I researched into honeypots, and I found Cowrie. Basically, honeypots are processes that emulate a protocol (letting the attacker think they’re interacting with a real system); in this case, Cowrie emulates the SSH protocol, providing a simple shell (totally emulated in Python, but the hackers won’t know that) and a virtual environment that goes aways as the attacker logs out. So, no worries of actually getting into my Pi or my actual network. The nice part is that honeypots log everything that was done into files, so processing data is just a matter of running some Bash one-liners to get pretty results. But we’ll get into that later. In fact, the simplest honeypot you could make would be to leave netcat open on a public port, but that wouldn’t give you much of a log, just connection attempts.

So I followed Cowrie’s setup guide, which was pretty straightforward, and I let the honeypot open to the world on port 22 overnight. Strangely, the first night was really quiet, with only two or three connection attempts over 8-plus hours. A friend from university, which also has a home server with SSH (but always on port 22) got a ton of bot requests immediately. On the second day, nonetheless, I started getting the “normal amount” I would expect… Actually a bit more, around 7000; the next days it stabilised around 1500-2000 per day.

My theory on why it took so long to start getting requests is due to having had port 22 closed for such a long time… My friend has his port always open, and maybe his IP was already marked as attractive, while mine would be blacklisted. It may also explain why the number of requests dropped from the second day onwards: having found nothing “of value”, my IP might have got blacklisted by most bots again. But that leads to the question of what really is of value to these bots…

Analysing the bots’ behaviour

From my observation I divide them into three categories:

• The Miner - this guy does an ssh-exec of cat /proc/cpuinfo | grep name | wc -l. Thats it.
• The Forwarder - this one establishes a TCP channel (-L src_port:dst_host:dst_port) and tries to use you as their proxy.
• The Recruiter - copies a file into your system and tries to run it; that file recruits you into their botnet.

The Miner

So this one is pretty simple. They just execute cat /proc/cpuinfo | grep name | wc -l to get the number of cores of your machine. In my case, Cowrie reports 4, which being pretty standard probably does not warrant much interest from attackers. I’ll try to change that to a higher number and see if that generates interest. The bot probably logs the IP and the number of cores, and highly attractive ones may warrant human intervention. It’s not the most popular bot though, I get around 300 of such requests per day.

Are they looking for machines to mine? Being the current trend its safe to assume that (or running machine learning algorithms, but that may be a bit far-fetched 😉). What else can you get from a poor victim with no access control? Ah, that leads us to…

The Forwarder

This one is, by far, the most popular, with more than 5000 forward requests per-day, which gives an average of 2-3 forwards per connection, assuming 2000 daily connections. They just establish SSH local forwards, i.e. they turn your server into a proxy: you access another server on their behalf, returning the obtained data to them. In the case of Cowrie, the default is to accept such request, but to never actually access the remote server and return an empty response; the implications of actually performing the request could be serious: suppose they want you to access a vulnerable server, or get illegal content for them? It would be untraceable for them, and from a legal standpoint, YOU would be the one that requested that content.

That being said, most of the accesses I got seem to be just scouting for working servers. I made this one-liner for Cowrie’s .log files:

cat var/log/cowrie/cowrie.log.* | grep "] direct.*reque.*to" | cut -d' ' -f10 | sort | uniq -c | sort -n

Which gives you a breakdown of the most popular servers accessed. My top 20:

    297 104.47.41.33:25
    298 104.47.50.33:25
    314 104.47.125.33:25
    336 104.47.14.33:25
    342 104.47.48.33:25
    360 104.47.6.33:25
    388 104.47.2.33:25
    410 104.47.5.33:25
    412 104.47.0.33:25
    424 104.47.4.33:25
    425 www.google.com:443
    455 163.172.20.152:80
    462 104.47.9.33:25
    484 104.47.1.33:25
    500 104.47.10.33:25
    555 104.47.8.33:25
    1826 96.114.157.80:25
    1881 68.87.20.5:25
    3408 ya.ru:80
    13234 ya.ru:443

Lots of spam bots, right? Port 25 seems really popular too (Hey SMTP spam bots!). But most of these requests are for anonymous IP addresses, and many of those IPs (that are not shown here) only got one request each… What lies beyond them I probably do not wish to know at all.

The Recruiter

Finally we move on to the last pattern I identified, The Recruiter. This one is a bit more interesting to analyse, since they download a script to your server honeypot, and try to run it. Actually the pattern is quite rare, as I’ve only got 8 requests in the 10 days Cowrie has been running. The script is a bit long, and I won’t put it all here, lest you want to try to start your own botnet, but we’ll look into some parts together¹.

The first part is the configuration replacement. Kills running daemons such as node or minerd, among other 14 ones, including other instances of the script. Then, it replaces 127.0.0.1 with a domain, which I suppose is the attacker’s server. The domain name is something related to German payments, let me know if that rings a bell with you. It sets up Google DNS, removes .bashrc files and sets up an RSA key in .ssh/authorized_keys. It also stores a public key in /tmp.

Then we move on to the “chat” part. I didn’t particularly figure this part out, but it seems to be interacting with undernet.org. This part spawns an infinite loop to listen to private messages and pings, and the script uses messages it receives (using the previously stored public key) to execute commands on the victim.

Finally, the last part is the one that gave the name to this pattern, since what it seems to do is basically look for other devices to infect (Raspberry Pi’s in particular). It uses zmap to scan random IPs, and stores those in a file. Then, the script simply copies itself to vulnerable Pi’s. Finally, it runs the same command that I got into my honeypot, to chmod and execute the script. A true virus 😉.

Takeaways

Running a honeypot is a really interesting experience. I had no idea what to expect, apart from lots of bots trying to get in, and they delivered accordingly. Being able to analyse and understand what these bots were doing turned into an exciting past-time, and I’m looking forward to see how these patterns might change over time. I had some additional data on the bots, as their geo-location, but I thought it would be more interesting to analyse their behaviours instead. I’m looking forward to explore new configurations of honeypots and other deception tools, and I’ll probably try to get into the community to learn more. I’ll do my best to keep you posted!

If you want to contact me, write to me at [email protected] or tweet me.

Before you go

If you want my simple one-liners to get some info about your own Cowrie instance have at it:

cat var/log/cowrie/cowrie.log.* | grep "New connection" | wc -l – how many connections overall

cat var/log/cowrie/cowrie.log.* | grep "CMD.*cat /proc/cpuinfo" | wc -l – find the miners

cat var/log/cowrie/cowrie.log.* | grep "] direct.*reque.*to" | wc -l – find the forwarders

cat var/log/cowrie/cowrie.log.* | grep "CMD.*chmod" | wc -l – find the recruiters