Attacking Kippo


I was perusing my usual reddits and saw a post about tutorial requests. I was looking for ideas on something to do to kill a couple hours and happened across this:
“Id love to see some stuff on recognizing and breaking out of a honey pot (Kippo?)”

I’ve never looked at kippo code before and was intrigued if I could actually break out of the honeypot and/or what else I could do with one. Well, I haven’t been able to break out of it just yet, but I did find you could abuse them as internal (leaking internal address) and external full connect scanners. Read down for more information.

Stage 1.) Fingerprinting (Kippo)

Fingerprinting honeypots is not hard when you actually know what to look for. Kippo is no exception. It doesn’t allow a variety of commands that a normal host would, it uses static replies for several other commands ( *sigh* you really submitted that?) easily found in txtcmds directory and the source all over, it breaks command structure arguments like “wget -o log” would attempt to retrieve http://log, and allows ssh to any host with any password such as “ssh a”. Really, there’s no challenge in detecting Kippo nor any other honeypot as it’s really meant for kids that don’t know linux or automated bots trying to infect machines.

The most stealthy approach I found for Kippo detection is attempting to execute a command on login (ssh root@blah id). When attempting this Kippo causes a NotImplementedError exception and won’t allow you to connect:

def execCommand(self, protocol, cmd):
        raise NotImplementedError

This completely kills the connection attempt and doesn’t return the command output as normal operation would be.

Stage 2.) Universal Fingerprinting

The problem with honeypots is they are emulated layers. Even if a machine attempted to look as realistic as possible, there’s still certain things root can do that will likely not be emulated. The style I’ve been using for a while is adduser. Kippo likes to toy with people, so it endlessly loops through the adduser screen. Easy spotting.
However, other honeypots simply won’t let you add users or they will only emulate that they added them with /etc/passwd, /etc/shadow, emulated su/sudo, and etc. By making sure the user has appropriate rights and going through a new session with the new user you should be able to spot any honeypot so far. A session restart usually just refreshes the emulation as if nothing happened in your previous session. If it didn’t do that, one could just deplete your honeypot by rm -rf /*.

/* Note that this can be worked around. Kippo has a userdb for users one could dynamically populate, I just have yet to see it happen. */

Stage 3.) Let’s Toy With Kippo (external port scan)

Kippo allows a ‘malicious’ user to download external files for malware analysis. This, of course, allows us to go ahead and make connections outbound with the honeypot via wget. We don’t have much to go off of as no commands with wget are implemented, but we can do port scans. The emulation shows that wget adds http:// in front of all requests, however these are just passed off to connectTCP from the twisted library:

self.connection = reactor.connectTCP(
            host, port, factory, bindAddress=out_addr)

So what we can do is wget and see if we get:

“HTTP request sent, awaiting response… Connection was closed cleanly.”

For an open port or:

“HTTP request sent, awaiting response… User timeout caused connection failure.”

Not the fastest thing in the world considering timeout rate is 20 seconds. You can connect to the same host multiple times if you really wanted to speed that process up. And remember this is a full connect, so in some cases it can be fairly useless.

How about a potential for abuse? Imagine you’re hosting this honeypot in a cloud hosting environment and someonie abuses your honeypot to run attacks on a corporate network with IPS/ID or a government entity. GET/REQUEST attacks can be performed as wget will return the content back from the attempt. This can either be attacks at will or at random to attempt to suspend or drop the account.

Stage 4.) Let’s Toy With Kippo (internal port scan)

I sectioned this off because there’s an extra trick in here to find the internal address. Of course, one can just scan .1 and .254 in typical to all rfc1918 ranges and see if they get a response for remote control ports. Assuming they’re disabled, even though that’s not likely just stick with me for the fun of it, we have another toy to use. We can scan internal ranges under the same honeypot port and use the last command.

Let’s assume the honeypot is running under on the default port 2222. By attempting to “wget″, getting a “Connection was closed cleanly.” response back indicates we might have found our own address. We can verify by running the last command and seeing if the internal address is in the log file. If you were to simply try localhost:2222, we’d just see in the logs file.

This is a more interesting and, situationally, more severe attack vector when it’s ran in an internal setting. Imagine SOHO and even some corporate routers that have GET/REQUEST issues like password reset, persistent XSS, and/or config pages that return back passwords.

Stage 5.) Future Attacks

This framework uses quiet a bit of libraries including twisted. If issues were found in these libraries, one could potentially compromise or crash the honeypots. There’s certainly more to toy with in Kippo, I just ran out of time and need to continue other work you’ll be seeing here soon. Enjoy!

Misc.) Meta Characters

Kippo doesn’t strip or replace all meta characters when writing to file. Depending on what kind of program is used to read these files in (I was using last), issuing \x08 (backspace) multiple times will remove entries. Try “ssh -p 2222 -l $(echo -e “\x08\x08\x08\x08blah)” and tail -f log/kippo.log to see. It’s not likely something you’ll know of off hand, but if Kippo interfaces get popular and they correctly treat these meta characters or someone told you how they read log files for analysis on a forum/mailing list, it could be of use.

Contribution By Tyler Borland (TurboBorland)

About the Author

Stephen Coty - Chief Security Evangelist at Alert Logic

Stephen Coty

Stephen Coty originally joined Alert Logic as the head of the Threat Research team, where he led the effort to build threat content and deliver threat intelligence. He later became the Chief Security Evangelist for the company. Prior to joining Alert Logic, Coty was the Manager of Cyber Security for Rackspace Hosting, and has held IT positions at multiple companies, including Wells Fargo Bank, Applied Materials, Stanford Medical Center and The Netigy Corporation. He has been in the Information Technology field since 1993. Research has been his primary focus since 2007.

@StephenCoty | More Posts by Stephen Coty