Running a Honeypot (and, a quote)

First off, an (unrelated) quote, nevertheless too awesome not to lead off with:
“A connection to the past frees us from its effects… while severing ourselves from the past means those effects hang around forever.” (Blick, “Neuro-Hypnose,” Ullstein, p. 139)

Anyway. Reporting from a more prosaic layer of the security-news OSI model…

Anyone who runs an SSH server gets tons of (not very skilled) automated hacking bots trying to log in. What happens if you set up a “honeypot,” and give them a space to play? Once an “attack” succeeds, the human behind the robot goes down the list of “people with absurdly dumb passwords” and has a look at the server… in the process often leaving behind some insight as to their MO, plus copies of whatever specialized tools they may decide to use for attacking other machines. (for “specialized tools,” you can often read “scripts for people who don’t know any better.”)

For extra humor value, eventually this honeypot runs out of fake commands to present and starts producing weird error messages… from somewhat realistic ones like “Segmentation fault” and “unable to open display “:0″” to “O RLY? NO WAI!” and, of course: “Shall we play a game? y
A strange game. The only winning move is not to play. How about a nice game of chess?”

I would suggest adding the error (returned, of course, randomly) “This is not the honeypot you’re looking for.”

http://blog.macuyiko.com/2011/03/running-ssh-honeypot-with-kippo-lets.html

“Kippo is a medium interaction SSH honeypot designed to log brute force attacks and, most importantly, the entire shell interaction performed by the attacker.[…]

When looking at my logs now, I’ve had thousands of break-in attempts, hundreds of which “succeeded”. The interesting thing about Kippo is that it actually logs the shell session of the hacker. These shell sessions can be divided into three categories:

People who immediately leave once they’re logged in, probably to come back later or just take not that this server is indeed available.
People who do some basic fingerprinting of the server, using w, /proc/cpuinfo, uptime and uname -a to figure out the basics of the server. Most hackers also used wget to download a large file to test the download rate of the server. Funnily enough, this was almost always the Windows 2000 SP3. Probably because it’s (a) a large file and (b) hosted by a server you know is fast (Microsoft) and (c) is one of the few files on Microsoft’s website which is still hotlinkable.
People who performed some fingerprinting and proceeded to download and extract malware. Here Kippo intercepted the attempts to run executables and showed some bogus error messages, after which the hackers disconnected.

Viewing the logs allows for some interesting observations:

Most of the attempts aren’t thorough. Most hackers quickly move on when an attempt seems to fail.
The tools used have been repacked and rewritten multiple times. Most of the tools are outdated, contain leftover files from previous installations or attempts, or contain weak attempts at automation shell scripts (with even sillier ASCII art).
The main reasons for hacking a server seems to be: (a) installing tools to hack more servers, (b) installing hidden web servers, (c) installing IRC daemons or bouncers, (d) installing IRC bots. Surprisingly, almost none of the hackers tried to completely nuke the system.
A few hackers spotted that a honeypot was in place. Most did not, despite the fact that Kippo is sometimes very blatant about this fact, by taunting with fake error messages.
It seems that the hackers (I actually mean “script kiddies” whenever I say “hackers”) are following some kind of memorized script. Most of the attempts used to exact same fingerprinting and tried to execute the exact same tools. It makes one wonder if there’s a “SSH hacking school” out there somewhere. More realistically speaking, there probably is a “hacking tutorial” on a forum somewhere showing which commands you have to execute.”

Advertisements
%d bloggers like this: