To make up for this lack of hardware, it seemed like a good idea to use an OS I am very familiar with. It just so happened a few recent vulnerabilities were just made public for the OpenBSD operating system, which just happens to be the UNIX-based operating system I am most familiar with. It seemed like setting up an OpenBSD honeypot was just meant to be. Many honeypots today tend to be Redhat Linux as it has a horrible track record for security. It therefore makes for a good honeypot since the goal is to get hacked. OpenBSD on the other hand is arguably the most secure networking OS available out of the box. It was created from the ground up with security in mind and went over five years without a remote hole in the default install... until now. Two major vulnerabilities have just been released that target OpenBSD. One of them targets the Apache Web Server (not enabled by default) and the other effects OpenSSH, which is enabled by default!

Recently scripts that make it simple to exploit both of these vulnerabilities were released on bugtraq making it very easy for even the most neophyte script kiddie to break into an unpatched OpenBSD installation. Unfortunately, that's just what happened here...

Contents

Layout

The Pros of this layout:

• Very simple to set up
• Doesn't require an additional IP address
• With multiple other 'real' services running on the gateway, it gives more of a appearance from the outside of a real production machine
• The access the hacker has to the honeypot is very limited, as it's only to/from the ports you specify

• The access the hacker has to the honeypot is very limited, as it's only to/from the ports you specify
• If the hacker is smart enough to find out with a simple 'ps ax' that the processes you're running aren't the same as the processes he or she may have seen when they port scanned you (if they take the time to do that), they may realize port forwarding is going on which may raise suspicion

The Rules

Note: The first three rules must be placed before your default deny rule (if you have one).
Note 2: dc0 is the external interface

#clean up fragmented and abnormal packets
scrub in all

The above rule does exactly what the comment suggests, making it possible for snort and tcpdump to do a better job and not have to deal with fragmented packets the hacker may try using to make his/her activities harder to follow.

The above rule simply specifies passing TCP SYN packets on port 22 from any address to any address through the external interface. It almost reads like English, right? The 'keep state' at the end specifies that after the SYN packet is passed the firewall should also allow the the TCP Three-Way-Handshake to occur and the established connection to take place. This helps prevent fishy traffic such as acknowledgement packets before a connection has even taken place.

The above rule passes port 128. This was done because one of the two scripts publicly available at this time to exploit this OpenSSH vulnerability opens a root shell on port 128 instead of leading the user directly into a root shell on port 22. I wanted the honeypot to be vulnerable to both exploits so this port was passed.

There is a very common rule to have on an OpenBSD firewall that doesn't directly effect the honeypot. It's only mentioned to show that it must come after the first three rules.

###honeypot
#pass all from outside to honeypot
pass out log quick on dc1 from any to 192.168.3.100/32

The above rule simply says pass (and log) all packets that have successfully made it through the external interface's firewall rules to the internal network that are destined for the honeypot (at 192.168.3.100)

This passes in syslog messages from the honeypot to the syslogd server set up on the gateway. Although this is not *needed* in this particular case because I'm passing everything later on, it's a good idea to add it if you set up your honeynet differently.

The above two rules were put in place in an attempt to stop the hacker from using the compromised honeypot to scan/attack other hosts across the internet. Obviously there's a tremendous amount the hacker could still attack that doesn't run on port 22 (ssh) or port 111 (sunrpc), but I wanted to give the hacker the freedom to make outbound FTP connections so he/she could download a rootkit and give me something fun to analyze, the downside is this would allow them to download/run autorooters looking for vulnerable FTP Servers (and goodness knows they're out there). I also wanted to allow them to send DNS outbound so they would be able to specify their rootkit host by domain name instead of IP address, which seemed like it would likely happen, meaning they would also be able to set up an autorooter looking for vulnerable BIND servers... the chances were taken, and luckily the hackers (did you catch that s? Yes, now it's getting a little more exciting!) didn't do any of the above mentioned scans.

Pretty self-explanitory. Pass everything else

NAT

rdr on dc0 proto tcp from any to any port 22 -> 192.168.3.100
rdr on dc0 proto tcp from any to any port 128 -> 192.168.3.100

Simple as that!

The Logging

• OpenBSD's PF (Packet Filter, native OpenBSD firewall)
• Syslogd logging remotely to the gateway
• Tcpdump
• Snort

Syslogd: Syslogd was set up to use bash keystroke logging, as can be done with this patch from the honeynet project. Unfortunately, the OpenSSH vulnerability runs /bin/sh, not /usr/local/bin/bash, and I was not able to successfully statically bind bash to /bin/sh without greatly sacrificing the functionality of OpenBSD's compiling features. Since I favored the thought of a hacker compiling a rootkit over getting an easy to read log of what commands were run, I left /bin/sh be and thus did not successfully get the recorded keystrokes in that fashion.

Tcpdump: Tcpdump was set running in the background on the gateway on the internal interface. This was done by simply running the following command as root:
# tcpdump -n -i dc1 -s 2500 -w /home/mike/honeypot/day1.dump host 192.168.3.100 &

Where syslog failed, tcpdump prevailed. Every command that was entered by the hackers was caught by tcpdump. It's interesting to note that even though it's the SSH daemon that's hacked, the connection that takes place is not via ssh, and so everything is in clear text. The tcpdump logs are available later in the report.

Snort: Snort was the backbone of the logging. While it didn't catch anything tcpdump didn't catch too, it organized everything in way that made it easy to tell exactly when the honeypot was hacked!

Snort was run with the following command:
# /usr/local/bin/snort -D -d -c /home/mike/hm/snort/snort2.conf -i dc1 -l /home/mike/honeypot

Note: it's possible to run snort on two different interfaces at the same time. Snort was still running
on the external interface (dc0) throughout the entire honeypot lifetime.

If you've got a good eye, you probably noticed the snort above isn't running the default 'snort.conf'.
To catch the traffic on the internal network, I created a whole new snort.conf file called snort2.conf by using the complicated method below:

1. cp snort.conf snort2.conf
2. Edit snort2.conf and add the following line near the beginning: var HONEYPOT 192.168.3.100/32
3. Edit snort2.conf and add the following line at the end: include $RULE_PATH/honeypot.rules

Obvious Note: Replace 192.168.3.100/32 with your honeypot's IP

The honeypot.rules file I created and used is available here. Simply put, it logs all TCP traffic as "Honeypot TCP Traffic", it logs all UDP traffic as "Honeypot UDP Traffic", it logs all ICMP traffic as "Honeypot ICMP Traffic", and it catches the GOBBLES SSH vulnerability that was used to compromise my honeypot.

Using Snort and ACID

Here's an interesting shot of hacker #1 trying to restart inetd.

But wait a minute, what do we have here? The same hacker is trying to run a root shell as "httpd" from inetd! It's too bad this does not work, as we can see from this syslog message:

Jul 3 15:21:00 pufferfish inetd[10597]: httpd/tcp: unknown service

Oh well.

Silent on the set, and... Action!

Imagine, you've already checked your ACID console about 300 times today and seen nothing interesting every single time, it's the first day your first honeypot is up and you're beginning to wonder if it's going to get hacked anytime soon... when all the sudden you see something like this... Look out, it's on now! Who knows what kind of exciting things can be learned from this dynamic duo attacking your honeypot at the same time?!

Well the truth is... not much. The following is a list of the 11 different connections made by the two hackers. The lists were created with Ethereal's TCP Stream Follow function.

Connection 1

Hacker 1 logs in and looks around to see what's running.

Connection 2

Hacker 1 checks open connections and takes a seemingly pointless look around at files on the hard drive and their permissions.

Connection 3

Hacker 2 logs in and looks for tcsh and checks the open connections.

Connection 4

Hacker 2 looks at the fake website and begins to look for the real one.

Connection 5

Hacker 1 looks at inetd.conf, tries to edit it but can't due to terminal type, looks at some files in /var/log, checks the network interface and starts to ping the gateway. After the connection dies the ping continues and it was still hours later after I closed out the hackers and returned home.

Connection 6

Hacker 2 tries to backdoor inetd and checks netstat to see it's not working. He also creates a directory called "nn" in /usr/libexec and tries to use the fetch command.

Connection 7

Hacker 2 does just about nothing.

Connection 8

Hacker 2 does just about nothing.

Connection 9

Hacker 1 tries to retrieve a file called newnick.tar.gz from his site.

Connection 10

Hacker 1 tries wget and sees it's not installed, then tries lynx but sees he can't without a valid terminal type. Why can't he just use scp or FTP and give us something exciting to analyze?

Connection 11

Hacker 1 stops apache, tries to backdoor inetd, and looks for a *get program to get his newnick.tar.gz.

Some of the highlights include:

10 of these: EXPLOIT ssh CRC32 overflow /bin/sh
13 of these: SUCCESSFUL Gobbles OpenSSH challenge-response exploit
14 of these: GOBBLES OpenSSH challenge-response exploit attempt
And 29 of these: ATTACK RESPONSES id check returned root

The reason there were 29 ID checks was because the script they used automatically checked their ID every time they logged in again. The number was about double the number of exploit attempts because it was trigger twice for each time it happened. Once by the snort on the external interface, and again by the snort on the internal interface. There was also one instance where the first hacker manually checked their ID himself.

One of the hackers took particular interest in what the Apache server was used for. It's interesting to note that if he checked the IP he was attacking from his web browser he would see the actual web server running on the gateway, and not the one on the honeypot. Apache was also running on the honeypot for two main reasons:

1. To make the honeypot look like it was really being used for something.

2. To help take the attention off of the fact that syslog was running. This was more influencial when syslog was renamed and running as "screend" and /etc/syslog.conf was renamed to /etc/screen.conf to make it appear as though syslog wasn't running on the system. With 8 apache children and a honeypot user (idle for hours so as to not scare the hackers) running the real screen software making it look as though it's legitimate, hopefully the hacker would let something like 'screend -f /etc/screen.conf' slip their attention in the "ps aux" queries even if he/she did know that screen doesn't run like that!

The hacker's search for information on the website can be found here. It's interesting what length this hacker went to in search of information as to the honeypot's purpose.

Five attempts of binding a root shell in inetd were made:

Note: Attempts 2 and 3 appear to be more of a testing phase but on the same topic

Attempt 1:

But because these script kiddies had no idea what they were doing it didn't quite work:

A few attempts at installing backdoors:

Attempt 2:

Attempt 3:

Attempt 4:

Attempt 5:

One attempt at downloading an interesting file was made:

Alert! censored.censored.org ... Could this lead us to the hacker? Very interesting!
After checking the website there and at www.censored.org, it wasn't too hard to find
the hacker's name/age/etc. Not a very smart hack indeed, but what can you expect from a 10th grader?
Note: Now you must say "It's possible someone else compromised censored.censored.org to use it as a
decoy!" but after looking at the hacker's website I have a strong hunch that
was not the case in this situation. Especially after doing a little more research
on the hacker's domain at google.com.

Unfortunately this didn't work as fetch wasn't installed on the system.

They managed to successfully stop the Apache web server:

My guess is this was done because they thought Apache running was
conflicting with them running their "httpd" rootshell in inetd.

To safely end the events and leave the honeypot in a condition safe for me to analyze it at a later time the following rules were quickly added to /etc/pf.conf:

#people to block
#hacker1
block in log quick on dc0 from HACKER.1.IP/32 to any
#hacker2
block in log quick on dc0 from HACKER.2.IP/32 to any

#honeypot ssh
#pass in log quick on dc0 inet proto tcp from any to any port = 22 flags S keep state

#honeypot pass shell on 128
#pass in log quick on dc0 inet proto tcp from any to any port = 128 flags S keep state

The first two rules were added to block the hackers from visiting the real web server at my IP and following the link currently on the front page pointing to the class I taught on 'OpenBSD and Network Security', giving them a very big hint they were on a honeypot, which I did not want to happen.

The 2nd two rules were previously there and commented out to prevent anyone else from hacking the honeypot so I could get back home later to analyze exactly what happened.

Important Note: Even after adding these rules it's very important to remember that your hackers connections will not be killed instantly as they are established and in the firewall's state table. You must run pfctl -F state to flush out all the state entries and kick their butts out for good (at least from those IPs)!

It should go without mention 'pfctl -R /etc/pf.conf' must be used to implement the new rules, and before the state flushing above to prevent the hackers from just logging right back in again.

A few important things we can learn from this honeypot:

• Some honeypots can serve their purpose with only a single port forwarded.
• Seeing as I had two people completely unprovoked attacking my system at the same time in under a day it makes it very clear that this OpenSSH vulnerability is currently an enormous threat on the internet. A note of advice to OpenBSD administrators who have not yet patched their systems: Patch your systems! If you still haven't by now (Are you really an OpenBSD administrator?), you may want to take the time to look for suspicious connections/backdoors before something very important to you or your company is effected.
• 10th graders and below are capable of hacking (if you can call the displayed activities hacking).
• When scripts are publicly available that make gaining remote root this easy you can expect to find script kiddies hacking your system that don't actually know enough to successfully retrieve their files, much less install them.
• When vulnerablities are released targeting an OS that's such a rare target like OpenBSD, it seems very evident the common script kiddies have no clue what to do once they get in as few good root kits are available/developed for their victim OS.

It's 1:59:46am EST. A honeynet like this is so simple in nature to set up that it was designed, configured from scratch, hacked, analyzed, and this paper was written, all within a 28 hour period. This is Michael Anuzis, signing off.