My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Kippo Users Beware: Another fingerprinting trick

Published: 2014-05-14. Last Updated: 2014-05-14 14:05:17 UTC
by Johannes Ullrich (Version: 1)
6 comment(s)

We all know that the ssh honeypot "kippo" is a great tool. But it is awful easy for an attacker to figure out that they are connected to a kippo honeypot. The latest trick I see people use is to run the "file" command, which is not impleneted in kippo. For example:

# file /sbin/init
bash: file: command not found

While on a real system, I would get

# file /sbin/init
/sbin/init: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x7aa29ded613e503fb09fb75d94026f3256f01e7a, stripped

This is a bit a tricky one to "fix" in that it requires more then just a static response as the attacker may try different files to test. So it would require something like a full database of possible files to try. Or (risky...) an implementation that would use actual output from the system kippo is running on.

Maybe I will have a patch for kippo latre today to implement either solution.

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords:
6 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

I've given up on kippo. The more sophisticated attackers (from a large Asian country) know they are in a kippo honeypot without even typing a command. They've automated detection somehow after the authentication step. I've seen them break in in the logs and then exit immediately.
They are likely looking for the banner. it is pretty easy to change the banner. Look in kippo/core/honeypot.py for the banner (just search for OpenSSH) and replace it with something more current/real.

To get a better banner, connect via telnet to any ssh server and see what comes back.

They could also look at the set of ciphers, but from what I can tell, kippo looks pretty "real" with the ciphers offered.
Interesting. My Real CentOS6 system says
-bash: file: command not found

Because I don't have the file-x.y.z package installed.
I use minimal installation images whenever possible.

That also means there are no unnecessary programs, such as 'wget', except on a few systems that do actually need it.


Maybe if more people use minimal installs.... any 'real' systems an intruder gains access to,
will be mistaken for a honeypot, and they'll just go away? :)
I did change my banner before opening my kippo install to the internet. I chose a slightly old linux banner. The test I see most often is for sftp. I installed the fork with sftp from https://github.com/micheloosterhof/kippo and now they stay around.

Most of the attacks I've seen have been scripts downloading linux malware from 122.224.34.75:8188. These don't show up in the input record, they show up only in the playlog. I'll get 50 attacks a day but they all do the same thing. It's getting boring so I think I'll change the banner to some other Unix and see if the attack changes.

It also helps to have your system up long enough that Shodan publishes it. I noticed a spike in attacks after my ip showed up in Shodan.
I'm still getting some interesting new hits in my kippo traps (for example - http://blog.infosanity.co.uk/2014/05/15/tales-from-the-honeypot-bitcoin-miner/).

My working theory on the immediate disconnects isn't that it's necessarily attackers identifying the honeypot for what it is, but that the immediately disconnected sessions are from automated scanners and mass-compromises finding vulnerable systems for their masters. Whilst I have nothing but gut feeling to back this up, the fact that many logins with manual interactions source from IP addresses that have never connected to the vulnerable system before lend credence to the basis that advanced knowledge of the system and credentials came from somewhere.
I have seen some sysadmins purposefully duplicate behaviour of kippo in production systems to try to trigger precisely this kind reaction from an attacker.

I'd advise caution attempting this though, I've watched too many logged sessions where the attacker has identified the honeypot and fired off a potentially spiteful 'rm -rf /' prior to disconnecting. Not sure I'd want to get a production system hosed due to being to cute with the obfuscation.

Definitely agree with the minimal install aspect though.

Diary Archives