Infosanity's Blog

This week I was interviewed for the Disaster Protocol Security Podcast. My theory is that everyone else was superstitious and didn’t want to risk being on number 13, so they got stuck with me…..

Basically, the interview is just me talking about honeypots and some of the results and findings that have been discussed discussed both on this blog and via Twitter. Hopefully you’ll find it an interesting listen, and hopefully you’ll be able to understand me. Seems a few people have struggled so I’ll need to work on my ‘BBC English’ next time around….

Always interested in hearing others thoughts or comments on honeypots or infosec in general; so if you liked, disliked or disagreed with any of the content let me know.

The podcast episode can be downloaded here.

–Andrew Waite

This morning I cause myself a problem. Annoyingly it was foreseeable and avoidable, this is my excuse (not great, but I’ll stick to it). But as every problem is merely an opportunity in disguise whist I’m re-building systems I might as well document the process. The original InfoSanity guide for installing Kippo was based off of the latest stable version, but I rapidly migrated to the development SVN on learning of the MySQL logging capabilities, so this guide covers that.

Packages

As I’m using a Debian system a lot of the system pre-requisites are packaged, this aren’t all needed immediately but we might as well grab them all at once.

apt-get install subversion #for svn
apt-get install python-twisted python-mysqldb # Python and required modules
apt-get install mysql-server #

Basic Kippo setup

Grab Kippo direct from svn, at time of writing I got version 160. (latest instructions):

svn checkout http://kippo.googlecode.com/svn/trunk/ /opt/kippo-svn

Now we can start the honeypot system:

./start.sh

That’s it, all that is required to get the system running. To confirm you can ssh locally with ssh -p2222 root@127.0.0.1, unless you’ve jumped ahead and edited the config, password will be 123456.

MySQL

Log into MySQL via commanline, assuming you’ve not modified the kippo.cfg database directives build the database:

create database kippo;
grant all on kippo.* to ‘kippo’@'localhost’ identified by ‘secret’;

Next edit the kippo.cfg accordingly you database/user/password and uncomment the [database] configuration directives. REMEBER to uncomment ;[database] line not just the parameters, that has now caught me out twice.

Finally, build the database structure with the script that can be found in <kippo>/doc/sql/:

doc/sql/# mysql -ukippo -psecret kippo < mysql.sql

Restart your Kippo process and you should be good; re-test access to the shell and view the database tables to confirm that logs are being written to the database.

Happy Honeypotting

–Andrew Waite

So far my Kippo honeypot installation has recieved a number of successful log ins from maliciuos users, some of which have been helpful enough to provide some tools for further analysis. A lot of the archives which have been downloaded show that the kits have been in use for a while, with some archive timestamps going back as far as 2004 (of course this could simply be an incorrect clock on the machine that created the archive). Picking on the most recent download (2010-07-18) I’ve taken a look at the archive containing gosh.tgz.

The archive was downloaded from linux<dot>hostse<dot>com<slash>gosh<tgz>, system is down at time of writing but take care if attempting to investigate yourself. Before downloading the user checked around the system with commands: w, uname -a and cat /proc/cpuinfo, and archive was downloaded and extracted in /dev/shm/.

Once extracted, the archive contains a number of files:

• Interesting files:
• Files 1 to 5, common and pass_file are password lists, totalling 235,523 potential passwords.
• mfu.txt is a list of IP addresses, mostly in the 38.99.0.0/16 address space.
• pscan2 is a fairly common and generic port scanner.
• scam is a shell script that appears to be the core brains of the toolkit. It essentially looks through scanning a different ranges of IP addresses while periodically emailing the contents of vuln.txt back to it’s master (mafia89tm@yahoo.co.uk).
• ss: appears to be another scanner used for looking for potential targets.
• ssh-scan: appears to be a Romanian tool from the message provided if run without arguments, according to Google Translate (possibly NSFW), and as you would guess from the file name is a scanner for SSH services.
• vuln.txt is blank in the archive, and will be the output of vulnerable systems located by the scanners.

All told this appears to be a kit for performing further scans for unsecured SSH sessions, and it is likely that a similar kit hosted on a different compromised machine was responsible for identifying my installation in the first place. Kits like this also quickly show the problem with tracking down the malicious user behind an compromise or attempt, it is rare for attacks to be launched from systems that can easily be traced back to the malicious user.

A quick Google search confirms that this kit (and user) has been seen in the wild attacking other systems, this posting on the Shell Person blog writes up the aftermath after a production system was compromised by the same kit.

–Andrew Waite

I’ve been running Kippo for nearly two weeks now (decided to live dangerously and go with SVN version) and have seen some interesting results.

Top 10 most common passwords attempted:

1. a (651)
2. 123456 (495)
3. password (331)
4. 12345 (302)
5. 123 (224)
6. 1234 (169)
7. 1 (139)
8. 12 (123)
9. root (105)
10. test (46)

Select count(password), password
from auth
where password <> ”
group by password
order by count(password) desc
limit 10;

Top 10 most common username attempted:

1. root (8510)
2. admin (144)
3. test (127)
4. oracle (96)
5. nagios (49)
6. mysql (47)
7. guest (43)
8. info (42)
9. user (41)
10. postgres (40)

select count(username), username
from auth
where username <>”
group by username
order by count(username)
desc limit 10;

Success ratio:

17065 attempts, 48 successful connections. (n.b. results skewed as account has purposefully poor choice of password)

select count(success),success
from auth
group by success
order by success;

Number of connections per unique IP:

1. 202.99.89.69 (5212)
2. 200.61.189.164 (1752)
3. 78.37.83.203 (1043)
4. 218.108.235.86 (848)
5. 195.14.50.8 (628)
6. 218.80.200.138 (271)
7. 58.222.200.226 (238)
8. 58.18.172.206 (158)
9. 119.188.7.174 (128)
10. 119.42.148.10 (113)

select count(ip), ip
from sessions
group by ip
order by count(ip) desc;

Number of attempts were relatively low IP address, in total 194 different source locations have attempted to access the server, with each typically only making 4 attemtps.

Packages:

Once exploited a number of attackers have proceeded to download various rootkits and utilities (thanks for these). Nothing too interesting yet, standard rootkit functionality, IRC clients and SSH scanners for further compromise. I still need to analyse some of these in more detail, so watch your RSS feeds for more to come.

One malicious user also attempted to create new user accounts on the server, if you have an account called ‘iony’ with a password of ‘ionyszaa’ then you may want to remove it…

If you’ve got a spare machine and public IP address, give Kippo a shot, setup is realitively easy; I’ve seen some interesting malicious user sessions and it turns out that some of those ’31337 haxxors’ that everyone fears really can’t type.

–Andrew Waite

As I started life as a Linux server admin I’m only too aware that many attackers see remote access functionality as a way into a system, and as SSH is the de facto standard for Linux access it is a prime target for attack. The stats collected by DShield give an indication to the extent of the problem.

As a result I’ve had the Kippo honeypot is something that I’ve had on my radar for a while. For a number of reasons I hadn’t found time to implement the system in a live environment, but a recent post on the Diatel blog suggested that installation may be quick and pain free.

Kippo is described by it’s author (Desaster) as:

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

Kippo is inspired, but not based on Kojoney.

Installation for me was painless, running a Debian system I downloaded the latest archive to disk, unpacked and installed the pyton-twisted package (I hadn’t read Mig5′s comment until after install so now need to go back and live on the bleeding edge…). I did hit a couple of problems when trying to start up the system, which is as simple as invoking ./start.sh

1. First, I was logged in as root when I first tried to start the system (not clever I know, was testing…). Kippo encounters an error when started by a root user. As Desaster rightly states, it’s not wise to run Kippo as a root user anyway and running as a regular user resolves the issue.
2. Second, when running as a normal user I got a ‘meaningful’ error of “Failed to load application: ‘NoneType’ object has no attribute ‘get’.” A quick piece of Google-fu lead me to this ticket, which explained Kippo was missing the file kippo.cfg, as explained copying kippo.cfg.dist to kippo.cfg correct the issue and produced a fully functional system.

There are a couple of key files that can be edited to change the feel of the system that is provided to malicious users:

• kippo.cfg contains runtime information including log location, fake hostname etc.
• kippo.tac contains an array ‘users’, which lists the username/password combination which the emulated SSH login will accept as ‘valid’.
• The honeyfs/ directory goes so far as to allow you to create a ‘real’ filesystem for the malicious user to interact with, potentially copying a live server’s filesystem to the directory to help camouflage the emulated system (after sensitive data is removed/sanitised obviously….). I haven’t tried this myself yet but is definitely on my to-do list.

From initial testing I’ve got high hopes for Kippo becoming a mainstay in my honeypot toolbox; the interaction session provided to a malicious user is reasonably convincing at first glance, and I particularly like the trick to keep users logged in after they think they’ve sent an ‘exit’ command to close the session, it could get some interesting results.

For post compromise analysis Kippo also provides some an interesting utility, utils/playlog.py. This allows you to replay a malicious terminal session in real-time, typos and all, to truely provide a feel for the malicious users interaction with the session. To help whet your apetite whilst I wait for someone to target my kippo installation, Kippo has a few demo’s of the playlog capabilities from compromise attempts. Get your demos here.

–Andrew Waite

I’ve been a bit lax in writing this post; around a month ago Miguel Jacq got in contact to let me know about a couple of errors he encountered when running InfoSanity’s mimic-nepstats.py with a small data set. Basically if your log file did not include any submissions, or was for a period shorter than 24hours the script would crash out, not the biggest problem as most will be working with larger data sets but annoying non the less.

Not only did Miguel let me know about the issues, he was also gracious enough to provide a fix, the updated script can be found here. An example of the script in action is below:

cat /opt/dionaea/var/log/dionaea.log| python mimic-nepstats_v1-1.py

Statistics engine written by Andrew Waite – www.infosanity.co.uk

Number of submissions: 84
Number of unique samples: 39
Number of unique source IPs: 65

First sample seen: 2010-06-08 08:25:39.569003
Last sample seen: 2010-06-21 15:24:37.105594
System Uptime: 13 days, 6:58:57.536591
Average daily submissions: 6

Most recent submissions:
2010-06-21 15:24:37.105594, 113.37.56.28, emulate://, 56b8047f0f50238b62fa386ef109174e
2010-06-21 15:18:08.347568, 195.205.5.71, tftp://195.205.5.71/ssms.exe, fd28c5e1c38caa35bf5e1987e6167f4c
2010-06-21 15:17:08.391267, 195.117.74.62, tftp://195.117.74.62/ssms.exe, bb39f29fad85db12d9cf7195da0e1bfe
2010-06-21 06:29:03.565988, 195.160.222.101, tftp://195.160.222.101/ssms.exe, fd28c5e1c38caa35bf5e1987e6167f4c
2010-06-20 23:34:15.967299, 195.242.145.40, http://208.53.183.164/trying.exe, 094e2eae3644691711771699f4947536

– Andrew Waite

Amun has been running away quite happily in my lab since initial install. From a statistic perspective my wor has been made really easy as Miguel Cabrerizo has previously taken one of the InfoSanity statistic scripts written for Nepenthes and Dionaea and adapted it to parse Amun’s submission.log files.

Results generated from the script in my environment are below, if you’re wanting to get an overview of submissions from another Amun sensor the script has been uploaded alongside the other InfoSanity resources and is available here.

~$ cat /opt/amun/logs/submissions.log* | ./amun_submission_stats.py

Statistics engine written by Andrew Waite (www.infosanity.co.uk) modified by Miguel Cabrerizo (diatel.wordpress.com)

Number of submissions      : 25
Number of unique samples   : 25
Number of unique source IPs: 18

Origin of the malware:
Ukraine :     1
None :     7
Poland :     2
Romania :     1
United States :     8
Russian Federation :     2
Hungary :     1
Norway :     1
Bulgaria :     2

Vulnerabilities exploited:
MS08067 :    13
DCOM :    12

Most recent submissions:
2010-05-31, 11:37:22, 208.53.183.164, 63.exe, acf5c09d547417fe53c163ec09199cab, MS08067
2010-05-30, 19:23:09, 208.53.183.162, 63.exe, 89b578839f1c39f79d48e5f9e70b5e2f, MS08067
2010-05-28, 10:27:03, 208.53.183.162, 63.exe, f7c4f677218070ab52d422b3c018a4ba, MS08067
2010-05-27, 16:23:14, 195.34.117.180, ssms.exe, 1f8a826b2ae94daa78f6542ad4ef173b, DCOM
2010-05-24, 19:46:35, 208.53.183.163, 63.exe, 53979f1820886f089a75689ed15ecf6e, MS08067

A comment on a recent post asked for a comparison between different honeypots, while this is far from conclusive and only focuses on a single aspect of the technologies one of InfoSanity’s Nepenthes sensors ‘saw’ more attacks in the last 24hrs than my Amun installation did in the almost three weeks shown above. As both are running within the same, small, IP allocation I think I’m safe in assuming that one IP isn’t actually receiving a disproportionate level of interest from the badguys and bots that are out there.

– Andrew Waite

No single technology can do or handle every situation; the same holds true with honeypot sensors which is why I’m always interested in finding new systems to add to my environment. I’d had Amun on my list of potentials for a while, but after reading a short blog post by Miguel Cabrerizo that suggested install and setup was relatively quick and painless, it got moved up the to-do list.

As suggested the install was quick and easy, with no real problems. Since being installed the system has done what it says on the tin, emulating vulnerabilities and logging interaction with attacking sources. The sensor has been active for around 5 days and has collected 14 unique malware samples to date. Whilst not immediately being indicative of any comparison, three of these samples have not also been ensnared by Nepenthes or Dionaea sensors running within the same IP space.

The Amun log directory shows some interesting information, with logging being split between several different files. From initial results there is some interesting information collected by the system. One aspect of the logging that I’m unsure if I like is that Amun rotates it’s log files on a daily basis, so far this is resulting in my log directory getting cluttered with rotated files. For the curious available log files are:

• amun_request_handler.log
• amun_server.log
• download.log
• exploits.log
• logging.log
• shellcode_manager.log
• shellemulator.log
• submissions.log
• successfull_downloads.log
• unknown_downloads.log
• vulnerabilities.log

Going forward there are a number of installation and configurations options available from Amun that I intend to experiment with; high up this list is the ability to log to a MySQL database, I’m hoping that this will provide both a convenient and powerful way to search and analyse the information collected by the sensor. In the meantime Miguel has extended one of InfoSanity’s submission_stats to gather similar statistics from Amun sensors, Miguel’s work is available here.

– Andrew Waite

InfoSanity’s honeyd-geoip.py script has been useful for analysing the initial findings from a HoneyD installation, but one of weaknesses identified in the geolocation database used by the script was that a large proportion of the source IP addresses connecting to the honeypot environment weren’t none within the database. Markus pointed me in the direction of the cymruwhois (discussed previously)python module as an alternative. I’ve re-written the initial script, below:

#!/usr/bin/python
from cymruwhois import Client
import sys

logfile = open('/var/log/honeypot/honeyd.log', 'r')
source = []
for line in logfile:
    source.append(line.split(' ')[3])

src_country = []
src_count = []
c=Client()

results=c.lookupmany_dict(set(source))

for res in results:
    country = results[res].cc
    try:
        pos = src_country.index( country )
        src_count[pos] += 1
    except:
        src_country.append( country )
        src_count.append( 1 )

for i in range( 0, ( len( src_country ) - 1 ) ):
    sys.stdout.write( "%s:\t%i\n" %( src_country[i], src_count[i] ) )

So far this has resulted in far fewer unknown source locations, 249 using geoip compared to 3 using cymruwhois. The downside unfortunately is performance, the cymruwhois communicates with a remote host to gather information compared with the geolocation database that is already stored locally on the machine. Both perform some local caching of results/data however so I would expect the performane difference to decrease as larger datasets are analysed.

Using the newer script, based on the same 24hr data set, the top ten host countries communicating with InfoSanity’s honeyd environment are:

RU:     397
US:     234
TW:     179
BR:     158
CN:     123
RO:     107
DE:     101
IT:     96
JP:     91
AR:     86

– Andrew Waite

I’ve just completed a new Nepenthes installation, and found the process far simpler than my first attempt as I didn’t compile from source.

Running on a Debian 5.0/Lenny server the install was both quick and easy, ‘apt-get install nepenthes’ handles install and dependencies nicely. The only issue I encountered was the permissions of files and directories within /var/log/nepenthes/. The contents had owner and group settings as root:root, as the nepenthes process should (and does under the default init.d script) drop permissions after initialisation this meant that the process was unable write to some of it’s logfiles, reducing the amount and quality of collected information. Thankfully this is easily fixed with a simple ‘chown -R nepenthes:nepenthes /var/log/nepenthes/*’.

I’ve frequently seen complaints/queries on the Nepenthes development mailing list that there are issues with Nepenthes’ hexdump functionality. While it isn’t enabled by default, using this install method works perfectly after uncommenting the “loghexdump.so” line from /etc/nepenthes/nepenthes.conf, depositing collected dumps in /var/lib/nepenthes/hexdumps/.

Initial testing shows the system working nicely (not bad for 30 minutes work) and is beginning to collect new binaries and attack statistics. Next step is some integration with Honeyd to provide the start of a combined honeynet environment, more to come later.

– Andrew Waite