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

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

N.B. a lot of the suggestions below are valid for most/all remote access functionality.

Restrict access from unknown locations

If possible (it isn’t always) restrict access to only come from known and trusted sources. This can be down at multiple choke points in the network and system; perimeter firewall, host firewall (iptables etc.) or sshd config. For working with sshd the /etc/hosts.allow and /etc/hosts.deny, for example:

/etc/hosts.allow

#Corporate HQ gateway
sshd: 1.2.3.4/255.255.255.255

/etc/hosts.deny

#Generic Deny All
sshd: ALL

It doesn’t matter how insecure your system is, if an attacker can’t connect and communicate with a vulnerable service they can’t exploit it, period.

Restrict remote root access

Preventing remote access to the root account can reduce the damage that can be caused by a compromised. With SSH this can be achieved with a single configuration line:

/etc/ssh/sshd_config

PermitRootLogin no

Only allow access to specific accounts

Does every account on you system need to be able to remotely access the system via SSH? No? Then why can it?

Remote system access can be restricted on a per user basis. This can be either as a whitelist using the AllowUsers directive or as a blacklist with the DenyUsers directive. For example, if I only wanted to allow my own account access via ssh:

/etc/ssh/sshd_config

AllowUsers andrew

These capabilities can be useful with certain honeypot systems; if you create a weak user account linked with an ftp or pop3 honeypot (for example), then the same weak accounts can be prevented from gaining access to a shell with the DenyUsers directive, limiting the weak account to only access those services that are being monitored.

Run on non-standard port

Yes, this is ‘security by obscurity’; if this is the only change you make you haven’t really improved security any, but it is still useful as part of wider security posture. Attackers are continually scanning the internet looking for new systems to exploit, currently the ISC statistics show connections to tcp22 at around 100k targets; even moving to a relatively common alternative port of 2222 drops the malicious traffic by around 90%.

/etc/ssh/sshd_config

Port 2222

This reduces the number of malcious attempts targeting the service, which will both reduce processor/network load and ‘noise’ in the log. If you now get a burst of failed log-in attempts in the logs, then this may be indicative of a specific attacker rather than just the usual background noise of bots and worms scanning for new victims.

Summary

Implementing the above can drastically improve SSH security above the defaults, with a relatively small effort required providing a great ROI. So what’s your excuse? Go harden that SSH installation

–Andrew Waite

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

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 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

Triad: Cost, Functionality, Time

Following InfoSanity’s recent (and unexplainable) focus on triads in previous posts is the relationship between cost, time and functionality. For the purpose of this discussion assume a scenario for introducing a new product/service or adding new capabilities to an existing service.

In an ideal world all projects would have enough resources and realistic timescales to develop all required functionality to the highest level of quality. However in the real world this is rarely achievable when working with external constraints. Therefore in any project compromises are inevitable.

The theory stands that with a given set of resources, only a finite amount of functionality can be developed. Therefore it stands to reason that additional functionality can be added to a project by increasing the length of the project or adding additional resources (although the Mythical Man Month and Dilbert may refute this simplistic theory).

Within ever tightening economic conditions and competition, in order to reduce costs and/or development and implementation time functionality is stripped from the service. As security is often seen by wider business as a nicety rather than a necessity, security features are commonly the first to be dropped, or the security of features still implemented is reduced.

Despite what infosec professionals (myself included) may like to think, reducing security to meet business or market drivers isn’t necessarily a bad thing. Providing that the benefit gained is proportionate to the additional risks introduced, and those risks are acceptable to the business and/or client. However, in the increasing world of regulatory compliance this can provide a false economy to a business as it is almost universally more costly in implement additional security on-top of an existing solution than it is to bake the required security into the design and development phases.

And if anyone tells you that a less secure solution is temporary and will be rectified at a later date… Don’t believe them

– Andrew Waite

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

ENISA Common Assurance Maturity Model (CAMM) Project

Colin Watson did a good job of explain the work he and others have been working on. The project have released two documents which Colid discussed, the Cloud Computing Risk Assessment[.pdf] and the Cloud Computing Information Assurance Framework[.pdf]. Don’t be put off by the focus on ‘Cloud’, whilst this was the focus and reasoning behind the work at the start of the project, the information and processes Colin describes could easily be related to any IT environment and at first glance seem to be well worth a read.

Open Source Security Myths

Next up David Anumudu gave a somewhat brave talk considering the audience discussing and (potentially) debunking the assumption that open source software is more secure than it’s closed source competitors. David picked on the now famouse phrase from The Cathedral and the Bazaar, ‘ Given enough eyeballs, all bugs are shallow’. David argues that while this is true and reasonable, it only works in practice if all the eyeballs have both the incentive and the skills to effectively audit the code for bugs, something is rarely discussed. A sited example of insecurities in prominent open source software was that of the MD6 hashing algorithm, intruced at Crypto 2008, where despite being designed and developed by a very clued up team still had a critical flaw in it’s implementation.

My ultimate take away from this talk was that software’s licensing model has no direct impact on the security and vulnerabilities of any codebase, only the development model and developers themselves have any real impact.

SSL/TLS – Just when you thought it was safe to return

Arron Finnon (Finux) gave a great presentation on vulnerabilities and weaknesses with the implementation of SSL protection. Arron argues that most problems with SSL are actually related to the implementation rather than methodology itself, and that despite the high profile of problems related to SSL most techies still don’t ‘get’ it; and most users, regardless of user awareness training will continue to blindly click through the cert warning prompts.

Several of Moxie Marlinspike’s tools were discussed, mainly SSLStrip and SSLSniff. I was aware of both tools, but hadn’t tried them out in my own lab yet, after Arron’s discussion of the problem and capabilities this is definitely something that I intend to rectify shortly. Especially when combined with other SSL issues, including the SSL renegotiation attack and the Null Prefix[.pdf] attack issues with SSL can be deadly to an environment.

Main takeaway from this talk was that SSL isn’t as secure as some would state, and that when planning to defend against the attack vectors we need to stop thinking ‘what if’ and start working towards ‘what when’.

AppSensor – Self aware web app

Colin Watson came back to the front to discuss the work currently being undertaken with the AppSensor project. The idea behind the project is to create web applications that are ‘self aware’ to a lesser extent enabling any user making ‘suspicious’ web requests to be limited or disconnected to limit the damage that they can cause to the target system, and works on the premise that the application can identify and react to malicious users in fewer connection requests than the user needs to find and exploit a vulnerability.

The identification comes from watching for a collection of red flags and tripwires built throughout the system, from simply looking for X number of failed log-in attempts to real-time trend analysis looking for an unusual increase in particular functionality requests. A lot of the potential indicators and trapped reminded me a lot of an old post on the Application Security Street Fighter blog, convering using honeytokens to identify malicious activity, which I’ve covered previously.

Summary

Overall I really enjoyed the event, I’m hoping that the Leeds/Northern OWASP chapter decide to run more events within Newcastle, but if not it’s convinced me that the events are worth the time and cost to travel down to the other locations. Always good to discuss infosec topics face to face with some really knowledgeable people.

–Andrew Waite

Triad: Security, Functionality, Ease of Use

Following from an introduction of the C.I.A. Triangle another triangle is used to help explain the relationship between the concepts of security, functionality and ease of use. The use of a triangle is because an increase or decrease in any one of the factors will have an impact on the presence of the other two.

As an example, increasing the amount of functionality in an application will also increase the surface area that a malicious user can attack when attempting to find an exploitable weakness.

The trade-off between security and ease of use is commonly encountered in the real world, and often causes friction between users and those responsible for maintaining security. Microsoft had long been targetted by the security community for allowing everyday users to operate the system with administrative or system level permissions, which resulted in any exploit targeting a userland application was immediately given access with full rights. When Microsoft tried to limit this functionality by forcing users to specifically request elevated privilages via User Access Control (UAC) there were high number of complaints from users who weren’t happy with the extra actions required to complete tasks. As a result many instructions and guides were created to teach users how to disable the UAC functionality; increasing the ease with use and decreasing the steps needed to perform some tasks, but at the expense of disabling an improved security system.

A recent blog post discussing the security of windows operating system states, quite colorfully that:

Windows is an open cesspool to anyone developing applications. Developers can store information anywhere in the registry and store executable components anywhere in the file system – this includes overwriting existing registry entries and files. They can also write “hooks” to intercept, monitor and replace operating system calls to do fancy things. While all of this is great from a functionality standpoint, it’s also the main reason why Windows can never be secured.

Leaving the bias and hyperbole of the above, rightly or wrongly developers are able to write to the filesystem, registry and hook API calls in order to provide the functionality expected and requested by end users. From this standpoint no functional operating system will never be 100% secure, what every system and ultimately user must settle on a compromise between acceptable functionality and usability, and acceptable security.

–Andrew

<Update>:

I’d been looking for this Dilbert strip when writing the post, just came across it now, enoy:

Dilbert - Security trade-off

</update>