David Ramsden
30Jul/16

Creating a Highly Interactive Honeypot With HonSSH

HonSSH is essentially an SSH proxy, acting like a Man-in-The-Middle attack. It sits between the attacker and a honeypot and proxies the SSH connections. By doing this it can log all interactions, spoof (rewrite) login passwords and even capture files downloaded by the attacker on to the honeypot for later analysis.

Below is my topology:

HonSSH topology

HonSSH topology

Configuring the Honeypot Server

For the honeypot server (the server attackers will login to), I'm using Ubuntu 14.04 but maybe using an unsupported Linux distribution may yield more interesting results. I'm using QEMU as the hypervisor and tried to configure the honeypot to be as "real" as possible, using an emulated Intel Gigabit Ethernet NIC and setting a valid Intel MAC address, using an emulated SATA adapter etc.

I installed the following on the honeypot:

  • OpenSSH server (essential!).
  • Apache.
  • PostgreSQL.
  • ProFTPd.
  • Build tools (GCC, make etc).

I set a password of 123456 for the system created "ftp" and "postgres" users and ensured their shells were valid. I created two new users called "setup" and "test" with a password of 123456. I gave the "setup" user root privileges via sudo. Finally, I also enabled the root account with a password of 123456.

The honeypot server needs to route via the HonSSH server and not via the firewall. This is because the advanced networking features in HonSSH will be used, allowing the HonSSH server to automatically source NAT (SNAT) the SSH connection to the honeypot server, so if the attacker ran a netstat they'd see their public IP address and not the IP address of the HonSSH server, therefore making it less suspicious.

After everything was configured I took a snapshot of the honeypot server so it could easily be restored to its non-pwned state.

Configuring the HonSSH Server

For the HonSSH server I'm using Debian. This time fully updated, support, patched etc.

Clone HonSSH from git:

Look at the requirements file and install the packages listed.

Copy the default honssh and users cfg files:

Edit the users.cfg file. This maps usernames and passwords sent by the attacker to HonSSH to the honeypot server. There are two modes. Fixed, where you supply a list of valid passwords that HonSSH will accept and random, where you specify a random chance that the password will be accepted. You also define the users and the "real password" that HonSSH will send to the honeypot server. My users.cfg looks something like:

In this scenario if an attacker tries to login with root, only the passwords jiamima, wubac and toor will be accepted. HonSSH will in turn login to the honeypot server as root but using the real_password defined. For the other users defined (setup, test, postgres, ftp), HonSSH will accept any password but only with a 25% chance of success. When successful HonSSH will login to the honeypot server as the user and using the real_password defined.

Note that random mode can be confusing for the attacker once logged in and raise suspicion. If the attacker tries sudo, the password they logged in with will not be the same as the password actually configured on the honeypot server.

For a list of popular usernames and password combinations used in SSH scanning, Dragon Research Group produces a handy SSH Username and Password Tag Cloud.

Next edit honssh.cfg.

Under the [honeypot] section:

  • ssh_addr: Set this to the IP address of the NIC on the HonSSH server connected to the "outside" (192.168.0.1).
  • ssh_port: Set this to the port that the HonSSH daemon should listen on for incoming SSH connections (2222).
  • client_addr: Set this to the IP address of the NIC on the HonSSH server connected to the "inside" (192.168.1.254).

Under the [honeypot-static] section:

  • sensor_name: Set this to something meaningly, for example honssh-honeypot1.
  • honey_ip: Set this to the IP address of the honeypot server (192.168.1.193).

Under the [advNet] section:

  • enabled: Set this to true which will enabled the SNAT feature talked about previously.

Under the [spoof] section:

  • enabled: Set this to true.

Under the [download] section:

  • passive: Set this to true so HonSSH locally captures all files uploaded to the honeypot server via SFTP/SCP.
  • active: Set this to true so HonSSH locally captures all files downloaded to the honeypot server via wget.

Enabling email notifications under the [output-email] section is also useful to keep tabs on when a login has been successful and what was done.

Since the HonSSH server will also be acting as a router for the honeypot server, enable IP forwarding:

Secure the HonSSH server with suitable firewall rules using iptables:

It's a good idea to implement some basic filtering from the honeypot server. When the honeypot server becomes compromised it's highly likely it'll be used to scan other systems, take part in DDoS attacks etc. The below rules will implement some basic rate limiting as well as filtering egress access to SMTP and SSH:

Save the iptables rules:

Start the HonSSH daemon:

Finally, test connectivity and ensure that everything works as expected. Remember to forward TCP port 22 from the Internet to the HonSSH server on TCP port 2222.

Other Notes

As mentioned previously, I'm running the honeypot server under QEMU. On the host I have a cronjob that restores the honeypot server to a default state every few hours. The script looks like this:

HonSSH can run scripts on certain events, so it may be possible to somehow get HonSSH to notify the host to do this automatically after an attacker has closed an SSH session (maybe via an email thats picked up directly on the host which triggers a snapshot revert?).

I'm also running a packet capture on the HonSSH server for better analysis of compromises:

This runs tshark in screen (detaching the session), capturing traffic to and from the honeypot server (192.168.0.193) but not capturing SSH traffic. HonSSH is capturing the SSH sessions which can be replayed. A new capture file is created when the current capture reaches 20MB.

Finally

Be careful. You're allowing a machine connected to the Internet to become compromised. When (not if) this happens, it's likely the attacker will:

  1. Attempt to root the server.
  2. Start scanning for other vulnerable devices.
  3. Add the server to a botnet.
  4. Start sending out spam.
  5. All of the above.

Use a honeypot to learn more about attacks and attackers but always try to mitigate against adding to the problem.

Analyse any captured files in a sandboxed, offline, environment.

Don't run a honeypot on any public IP addresses/space you care about.

Share your experiences, captures, files and sessions! I'm sure the guys over at SANS ISC would be interested.

29Mar/16

Disabling WordPress XML-RPC and banning offenders with fail2ban

This isn't something new. SANS ISC reported on this 2 years ago. The bad guys love anything that can be used in a reflection DoS and the WordPress XML-RPC functionality is a prime candidate. There are various ways to disable it, through WordPress plugins for example, or by hacking away at code. All of these are fine if you're in control over what gets installed on the web server. In a shared hosting environment you've got to rely on your users.

Running Apache you can disable XML-RPC globally and simply with the following:

The configuration should be placed as part of the global Apache configuration. When any file called xmlrpc.php is requested, on any vhost, from an IP address not listed by the Require ip line, an Error 403 Forbidden will be served instead. This configuration should ensure that WordPress plugins like Jetpack continue to work.

I've seen a few examples where even after doing this the bad guys still continuously request xmlrpc.php even though they're being served a 403 error. To further protect the web server fail2ban can be deployed.

Firstly create a filter definition:

Then create the jail:

Now when someone requests xmlrpc.php 3 times within the defined findtime their IP address will be blocked.

21Mar/16

Banning repeat offenders with fail2ban

More and more I see fail2ban banning the same hosts repeatedly. One way to tackle this could be to increase the ban time but you could also have fail2ban monitor itself to find "repeat offenders" and then ban them for an extended period of time.

Firstly, create a filter definition:

This will be used against the fail2ban log and will find any hosts that have been unbanned. We don't want to monitor hosts that have been banned because, er, they're already banned. We also want to ignore any log entries that are generated by the jail itself.

Next edit jail.local to add a new jail:

This jail will monitor the /var/log/fail2ban.log file and use the repeat-offender filter that was defined earlier. If 3 unban's are seen within 5 hours, the host will be banned for 48 hours. You could adjust the banaction to use the route action which may give some performance benefits on a very busy server.

28Aug/14

Open curtains – VNC with no authentication

A few weeks ago I read an article about mass scanning the Internet for VNC servers that don't require authentication. Dubbed "open curtains" because it's like having your curtains open allowing anyone passing by to glance in. The person doesn't need to bypass any security in place or have a key to your door to get this access - it's open for everyone to take a peek inside.

To achieve this I used:

It's completely automated. No human interaction is required.

The nmap NSE script I wrote is as follows:

It's used with nmap to scan random targets:

The above continuously scans random addresses on TCP/5900 (the default VNC server port) and uses the open-curtains.nse script. The NSE script simply says "if the protocol is TCP and the port is 5900, execute the open-curtains.pl script passing the host IP and port number as arguments". The open-curtains.pl script is run in the background so things don't hang.

The open-curtains.pl Perl script I wrote is as follows:

This will first open a TCP connection to the target and negotiate the VNC protocol. The VNC server will first send an RFB header containing the server version (e.g. RFB 003.008). We then send back a response of "RFB 003.003" to tell the server what our client capabilities are. The server will then respond with the authentication mechanisms that are accepted. This is the important part. We only then continue if the server tells us that no security is configured (0x1). At no point do we try to bypass the security or try any passwords. Finally the vncsnapshot program is invoked to connect and take a screenshot from the VNC server.

And the results were quite interesting.

I found a lot of digital signage, all of which appear to be located in South Korea and mostly relating to "LG U+" (telecoms and mobile phone operator controlled by LG Group):

Quite a few desktops. Surprisingly a lot of them were Ubuntu desktops, proving that the Operating System is only as secure as the user makes it:

This desktop was pretty ironic. Look at the websites the user has open in Firefox:

vnc9

And an OS X desktop. Oddly enough it looks like someone has tried to pwn it but with win32 files?

vnc11

A few home automation type systems and embedded devices such as MFPs:

A few Danfoss terminals that appear to be running a UNIX like-OS popped up too:

vnc18A few Point of Sale/Back Office systems:

Worryingly one of these is likely pwned already and is connected to a C&C server via IRC. The mIRC registration web page that has opened gives the game away. Unfortunately the user is probably just closing the window each time:

vnc21

Other systems included a pharmacy system and a radar system on a ship:

Over the space of about 2 weeks I collected 399 screenshots. The process could be a lot quicker if something such as masscan were to be used. As of yet I've not found any SCADA systems but they are out there...

Tagged as: , , 2 Comments