Archive

Archive for April, 2010

Digital Security & Governance for SMEs

2010/04/28 Comments off

Yesterday I had the pleasure of attending the Digital Security & Governance for SMEs at Northumbria University. The purpose of the event was to help SMEs better understand that threats targeting their information systems, their responsibilities in securing personally identifiable information (PII) and to introduce NUWARP (more later).

After the event was introduced, the first slot was taken by David Reynolds, CEO of the International Association of Accounts Innovation & Technology Consultants (IAAITC). An accountant may have been a strange choice to start a Digital Security event but that was the point, David covered sensitive information that is handled by all types of businesses as well as covering the legal and regulatory requirements that impact all businesses. Covering the most common compliance topics including the Data Protection Act (DPA) and Payment Card Industry Data Security Standard (PCI DSS) David did an excellent job of highlighting that information security is relevant to all employees and business types, not just ‘IT’ companies or the secret techie hidden in the back corner.

Next up Paul Holborow from RMT discussed data loss and the impact that this can have on a business. Given the press coverage it received in 2007 it is no real surprise that Paul’s main case study focused on Revenue and Customs lost CDs, but Paul may have been slightly unnerved to discover some of HMRC’s auditors could be found in the audience. If you’ve spent much time working with information security or business continuity planning Paul’s talk wouldn’t have contained too many surprises, one tip that I did take from the talk was that the Information Commissioner’s Office (ICO) maintains a public list of the complaints that it has investigated, if you’re interested in a particular complaint, or just curious about what the ICO gets involved in give it a look here.

Phil and Colin, both from the University discussed their work into monitoring data leakage from an organisation. Like Paul’s talk previously if you understand and have worked with data leak prevention (DLP) technologies you’re unlikely to be surprised, but the content was definitely new to some of the delegates who I observer furiously scribbling notes. It also seemed to come as a surprise to several delegates when Phil stated that approximately 70% of security breaches are the result of insider’s not ‘mysterious hackers out there’. There were some excellent real-world examples, the one that seemed to hit home to most of the audience was the scenario of the sales person taking the client database with them to a new job. A lot of the statistics used in the talk were sourced from Cyber-Ark’s white paper ‘The global recession and it’s effect on work ethics’ (registration required), definitely worth a read if you’re interested in this area.

Chris Laing provided a live demo of an external attack. As Chris introduced himself as ‘an ethical hacker paid to break into your systems’ I was looking forward to the display, but was disappointed when Chris took control of a Windows 2000 server using an old MSRPC exploit with Metasploit. The scariest aspect of the whole event was the fact that almost every delegate took a deep breath and turned white. I did ask Chris the thinking behind using an old exploit and target, and was told he was concerned about scaring the audience too much and that some of them may be concerned that he was making exploits ‘known’ that target systems they run in production. Personally I would argue that if the exploit is already in Metasploit (framework 2, demo used WHAX as an attack platform) then it is already ‘known’ and that the demo could have had a much greater impact targeting a more recent platform. However I can understand Chris’ reasoning, and the demo still had an impact on those that hadn’t seen Metasploit at work before. My only concern would be that some may have left the event thinking ‘that was scary, glad we upgraded from Windows 2000….’

The last presentation slot was taken by Alison Pickard who discussed ‘What is effective information crisis management’. Covering the ‘softer’ side of information security Alison’s talk did an excellent job of highlighting how simple it can be for organisations to fall foul of information security regulations. Alison introduced an excellent resource that I wasn’t previously aware of in JISC infoNet. if you’re responsible for personal information or it’s security (stop thinking, after Alison’s presentation this means EVERYONE) I’d definitely recommend have a browse and seeing what you can learn.

To finish the event after scaring most of the delegates Chris again took the stage to introduce the Northumbria University Warning Advice and Reporting Point (NUWARP). For those unfamiliar with WARPs, they are:

‘a community based service where members can receive and share up-to-date advice on information security threats, incidents and solutions.’

I was definitely impressed with the proposed services to be provided by NUWARP, hopefully the group should be able to significantly improve the security awareness and defenses of local businesses and those in a wider area. Although there is a cost attached to the services provide I was honestly surprised with how low this was in relation to the specialised knowledge and information available, and as NUWARP is set-up as a non-profit all costs get fed back into the service so the resources available can only improve.

As a taster and bonus to event delegates the event pack included a number of high quality ‘best practice’ data sheets covering a full range of information security topics including the DPA, passwords and securely outsourcing. If you want additional information on NUWARP contact Chris or Phil using information in the links above, the NUWARP is something I would definitely recommend investigating to see how it could help your organisation.

— Andrew Waite

Advertisements
Categories: Event, InfoSec, Legal, Presentation

Quick and Easy Nepenthes installation

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

Categories: Honeypot, Nepenthes

24hrs of HoneyD logs

After an initial setup and configuration of HoneyD I took a snapshot of the honeyd.log file after running for a 24hr period.

Running honeydsum against the log file generated some good overview information. There were over 12000 connections made to the emulated network, averaging one connection every 7 seconds. Despite the volume of connections, each source generally only initiated a handful of connections, likely looking for a single particular service before moving on.

Top 10 Source Hosts
Rank     Source IP       Connections
1    124.207.85.200       3066
2    203.113.137.181      984
3    121.23.82.216           65
4    79.114.107.90          65
5    61.156.31.20             57
6    62.215.178.163        48
7    193.6.48.210            39
8    24.161.18.4               37
9    190.58.213.249       30
10   195.8.36.144          30

The summaries from honeydsum also suggest that the rate of incoming connections is generally constant. The only real variation to this was between 17:00 and 18:00, but the spike coincides with the source IP 124.207.85.200 running an ordered port sweep against a single target IP address, starting at TCP1042 and running up to around TCP 1300. Not sure why anyone is scanning this particular port range (if anyone can provide any additional information to slake my curiosity I’d appreciate it) but this event explains the outliers in both the above and below summary tables, highlighting the dangers of working with a small data set.

Connections per Hour
Hour  Connections
00:00      329
01:00      325
02:00      281
03:00      366
04:00      360
05:00      322
06:00      300
07:00      299
08:00      258
09:00      369
10:00      317
11:00      324
12:00      423
13:00      367
14:00      351
15:00      479
16:00      486
17:00   3590
18:00      498
19:00      515
20:00      576
21:00      441
22:00      397
23:00      311

The below table summarises the targetted resources within the environment. It shouldn’t come as a surprise that the most popular targets were tcp ports 445 and 135, but this is the case even though the honeyd configuration does not have any services listening on those ports. From this I would suggest that if you are trying to gather data on a particular port or service that you employ a filter (firewall/ACL/etc.) to block the noise before it reaches honeyd to keep the log files relevant.

Top 10 Accessed Resources
Rank   Resource    Connections
1           445/tcp         7349
2           135/tcp         1086
3             8/icmp           123
4              22/tcp           102
5            1433/tcp          95
6           8080/tcp          73
7           4899/tcp          52
8           5900/tcp          39
9         10000/tcp         39
10           3/icmp            38

In addition to running honeydsum the data set was run through InfoSanity’s honeyd-geoip.py script, top 10 sources are listed below. The results are likely skewed as the largest ‘location’ for the results is ‘none’ according to the GeoIP Country Lite database being used. One feature of the result set is that the country linked to the public IP addresses used by the honeyd environment did not feature in the list, as infrastructure improves and botnets become more prevalent today’s malware no longer needs to target ‘closer’ IP addresses to remain efficient.

None:   692
United States:  196
Russian Federation:     123
Taiwan: 118
Brazil: 109
Germany:        99
Australia:      99
China:  90
Romania:        86
Italy:  82

— Andrew Waite

Categories: Honeypot, InfoSec, Malware

Honeydsum: HoneyD log analyser

2010/04/20 1 comment

Honeydsum is a script created by Lucio Henrique Franco and Carlos Henrique Peixoto Caetano Chaves for the Brazilian Honeynet project. As described by it’s Authors, it is:

a tool written in Perl designed to generate a text summary from Honeyd logs. The summaries may be produced using different parameters as filters, such as ports, protocols, IP addresses or networks. It shows the top source and port access and the number of connections per hour, and supports input from multiple log files. The script can also correlate events from several honeypots.

Using the script from the commandline is straightforward; simple invoke with a config file and pass the honeyd log to be analysed. In addition to the usual textual output honeydsum is also capable of generating HTML results providing a quick and easy visual. The download site also includes some sample output files, both text and html (tgz archive).

$ /usr/share/honeyd/scripts/honeydsum-v0.3/honeydsum.pl

Usage: honeydsum.pl -c honeydsum.conf [-hVw] log-file1 log-file2 … log-filen
-c   honeydsum.conf file.
-h   display this help and exit.
-V   display version number and exit.
-w   display output as web page (HTML).

The bulk of the text based output provides a list of connections made from external sources to the systems emulated by the HoneyD instance. Using the provided sample output as an example provides the information below; on a live and publically accessible system this output will be significantly longer:

--------------------------------------
Honeypot: 10.0.0.70
--------------------------------------
Source IP        Resource  Connections
192.168.50.20        21/tcp       1
192.168.100.130      21/tcp       1
192.168.177.253     11/icmp       1
192.168.139.133     11/icmp       1
--------------------------------------
IPs             Resources  Connections
4                       2        4
--------------------------------------

The end of the output contains the information that I find most useful. It provides several different summaries of all the traffic captured by the whole HoneyD environment. Summaries include:

The most frequent remote sources:

Top 10 Source Hosts

Rank  Source IP       Connections
1      192.168.100.130        3
2      192.168.139.133        2
3      192.168.50.20           1
4      192.168.131.157        1
5      192.168.217.41         1
6      192.168.207.84         1
7      192.168.177.253        1

Most requested emulated services/resources:

Top 10 Accessed Resources

Rank Resource    Connections
1    21/tcp             4
2    11/icmp            4
3    53/udp             2

— Andrew Waite

Categories: honeyd, Honeypot, InfoSec, Tool-Kit

Determining connection source from honeyd.log

After getting a working HoneyD environment I wanted to better dig into the information provided by the system. First up was a quick script to get a feel for where the attacks/connections originate from. For location functionality GeoIP is the package for the job, as we’re using both Debian and Python installing the required tools is as simple as ‘apt-get install python-geoip’.

At first glance I really like the log format that is used by honeyd.log, it is nice an easy to parse from. From this I quickly knocked up a python script to parse the honeyd.log file, collect a list of unique source addresses and finally use GeoIP to determine (and count) the county of origin. The script (below) is basic, and most likely full of bugs but shows the ease with which tools can be forged to quickly gain the full value from the information collected by the HoneyD environment.

Version 0.01 is below; ignoring any likely bugs that need fixing the one thing that it definitely needs is to order the output, although I’m undecided if this should be alphabetically by country or by hit-count. Source Code:

#!/usr/bin/python
import GeoIP
import sys

#log file location hard coded, change to suit environment
logfile = open(‘/var/log/honeypot/honeyd.log’, ‘r’)
source = []
for line in logfile:
source.append(line.split(‘ ‘)[3])

#http://www.maxmind.com/app/python
#http://code.google.com/p/pygeoip/
gi = GeoIP.new(GeoIP.GEOIP_MEMORY_CACHE)

src_country = []
src_count = []
for src in set(source):
country =  gi.country_name_by_addr( src )
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] ) )

Sample output:

# ./honeyd-geoip.py
Uruguay: 12
None:   249
Australia:      17
Lithuania:      11
Austria: 4
Russian Federation:     43
Jordan: 3
Taiwan: 29
Hong Kong:      3
Brazil: 39
United States:  54
Hungary: 23
Latvia: 10
Morocco: 1
Macedonia:      3
Serbia: 4
Romania: 44
Argentina:      23
United Kingdom: 12
India:  10
Egypt:  2
Italy:  33
Switzerland:    2
Germany: 43
France: 13
Poland: 27
Canada: 12
China:  23
Malaysia:       8
Panama: 1
Colombia:       6
Japan:  14
Israel: 9
Bulgaria:       9
Turkey: 6
Vietnam: 2
Mexico: 1
Chile:  1
Pakistan:       1
Spain:  7
Portugal:       4
Moldova, Republic of:   1
Antigua and Barbuda:    1
Venezuela:      3
Singapore:      1
United Arab Emirates:   1
Philippines:    2
Croatia: 1
Korea, Republic of:     4
Ukraine: 5
Georgia: 2
Bahamas: 1
Ecuador: 1
South Africa:   1
Peru:   1
Kazakhstan:     2
Costa Rica:     1
Bolivia: 1
Iran, Islamic Republic of:      2
Greece: 1
Bahrain: 1

— Andrew Waite

Categories: honeyd, Honeypot, InfoSec, Tool-Kit

Basic HoneyD configuration

After first getting HoneyD up and running previously for a proof of concept I’ve begun a wider implementation of HoneyD to function as the backbone for an upgraded research environment.

HoneyD’s key strength is it’s flexibility, HoneyD’s website contains some sample configuration files that show HoneyD emulating multiple systems running different OSes and applications, a large multi-site network and even a config file to create a honeypot environment for a wireless network. I’ve found these samples immensely useful references for developing custom templates for my own implementation.

At a bare minimum a HoneyD configuration file requires a defined default template, the current default template for this environment is borrowed from one of the sample files and is a tarpit, designed to slow down network sweeps and automated worms; similar to LaBrea tarpit.

create default
set default personality “Microsoft Windows XP Professional SP1”
set default default tcp action tarpit open
set default default udp action block
set default default icmp action open

HoneyD can emulate both Windows and ‘nix systems (and many less common systems), for initial deployment we’re going with an even mix of Windows and Linux host template, each each with a template for a e-mail, web and development server.

Linux configuration:

# Linux Mail
create linux_mail
set linux_mail personality “Linux 2.4.20”
set linux_mail default tcp action reset
set linux_mail default udp action block
set linux_mail default icmp action open
set linux_mail uptime 73921
add linux_mail tcp port 110 “sh scripts/unix/linux/suse8.0/qpop.sh $ipsrc $sport $ipdst $dport”
add linux_mail tcp port 143 “sh scripts/unix/linux/suse8.0/cyrus-imapd.sh $ipsrc $sport $ipdst $dport”
add linux_mail udp port 161 “perl scripts/unix/linux/suse8.0/fake-snmp.pl public private –config==scripts/unix/general”
bind 10.x.y.x linux_mail

# Linux Web
create linux_web
set linux_web personality “Linux 2.4.20”
set linux_web default tcp action reset
set linux_web default udp action block
set linux_web uptime 13282
add linux_web tcp port 21 “sh scripts/unix/linux/suse8.0/proftpd $ipsrc $spor$ipdst $dport”
add linux_web tcp port 80 “sh scripts/unix/linux/suse8.0/apache.sh $ipsrc $sport $ipdst $dport”
add linux_web udp port 161 “sh scripts/unix/general/snmp/fake-snmp.pl $ipsrc $sport $ipdst $dport”
bind 10.x.y.z linux_web

# Linux Development Box (EVERYTHING installed)
create linux_dev
set linux_dev personality “Linux 2.4.20”
set linux_dev default tcp action reset
set linux_dev default udp action block
set linux_dev default icmp action open
set linux_dev uptime 8324
add linux_dev tcp port 21 “sh scripts/unix/linux/suse8.0/proftpd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 22 “sh scripts/unix/linux/suse8.0/ssh.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 23 “sh scripts/unix/linux/suse8.0/telnetd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 25 “sh scripts/unix/linux/suse8.0/sendmail.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 79 “sh scripts/unix/linux/suse8.0/fingerd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 80 “sh scripts/unix/linux/suse8.0/apache.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 110 “sh scripts/unix/linux/suse8.0/qpop.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 111″perl scripts/unix/general/rpc/bportmapd –proto tcp –host scripts/unix/general/rpc/hosts/debian –srcip $ipsrc –dstip $ipdst –srcport $srcport –dstport $dport –logfile /var/log/honeyd –logall”
add linux_dev tcp port 143 “sh scripts/unix/linux/suse8.0/cyrus-imapd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 515 “sh scripts/unix/linux/suse8.0/lpd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 3128 “sh scripts/unix/linux/suse8.0/squid.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 8080 “sh scripts/unix/linux/suse8.0/squid.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 8081 “sh scripts/unix/linux/suse8.0/squid.sh $ipsrc $sport $ipdst $dport”
add linux_dev udp port 53 proxy 24.35.0.12:53
add linux_dev udp port 111″perl scripts/unix/general/rpc/bportmapd –proto udp –host scripts/unix/general/rpc/hosts/debian –srcip $ipsrc –dstip $ipdst –srcport $srcport –dstport $dport –logfile /var/log/honeyd –logall”
add linux_dev udp port 161 “perl scripts/unix/general/snmp/fake-snmp.pl public private –config=scripts/unix/general”
add linux_dev udp port 514 “sh scripts/unix/linux/suse8.0/syslogd.sh $ipsrc $sport $ipdst $dport”
bind 10.x.y.z linux_dev

Windows configuration:

# Windows Mail Server
create win_mail
set win_mail personality “Microsoft Windows Server 2003 Standard Edition”
set win_mail default tcp action reset
set win_mail default udp action block
set win_mail default icmp action open
set win_mail uptime 42256
add win_mail tcp port 25 “sh scripts/win32/win2k/exchange-smtp.sh $ipsrc $sport $ipdst $dport”
add win_mail tcp port 110 “sh scripts/win32/win2k/exchange-pop3.sh $ipsrc $sport $ipdst $dport”
add win_mail tcp port 143 “sh scripts/win32/win2k/exchange-imap.sh $ipsrc $sport $ipdst $dport”
add win_mail udp port 161 “perl scripts/unix/general/snmp/fake-snmp.pl public private –config=scripts/unix/general”
bind 10.x.y.z win_mail

# Windows Web Server
create win_web
set win_web personality “Microsoft Windows Server 2003 Standard Edition”
set win_web default tcp action reset
set win_web default udp action block
set win_web default icmp action open
set win_web uptime 12256
add win_web tcp port 21 “sh scripts/win32/win2k/msftp.sh $ipsrc $sport $ipdst $dport”
add win_web tcp port 80 “sh scripts/win32/win2k/iis.sh $ipsrc $sport $ipdst $dport”
add win_web udp port 161 “perl scripts/unix/general/snmp/fake-snmp.pl public private –config=scripts/unix/general”
bind 10.x.y.z win_web

# Windows ‘Dev’ Server
create win_dev
set win_dev personality “Microsoft Windows Server 2003 Standard Edition”
set win_dev default tcp action reset
set win_dev default udp action block
set win_dev default icmp action open
set win_dev uptime 8826
add win_dev tcp port 21 “sh scripts/win32/win2k/msftp.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 25 “sh scripts/win32/win2k/exchange-smtp.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 80 “sh scripts/win32/win2k/iis.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 110 “sh scripts/win32/win2k/exchange-pop3.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 143 “sh scripts/win32/win2k/exchange-imap.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 389 “sh scripts/win32/win2k/ldap.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 5901 “sh scripts/win32/win2k/vnc.sh $ipsrc $sport $ipdst $dport”
add win_dev udp port 161 “perl scripts/unix/general/snmp/fake-snmp.pl public private –config=scripts/unix/general”
bind 10.x.y.z win_dev

As others have should in the sample configs I’ve linked to above, this config barely scratches the surface of HoneyD’s capabilities but it is sufficient to rapidly get a working honeypot environment working and collecting attack information.

Something that frequently surprises anyone not involved in infosec on a daily basis is the speed at which a newly connected system on the Internet will be targeted by a malicious party. In this case the environment was functioning for under a minute before it received it’s first contact from the outside world, as shown in the timestamps from HoneyD’s log file:

2010-04-17-16:41:09.2549 honeyd log started ——
2010-04-17-16:42:04.9735 tcp(6) – 188.26.75.203 2027 10.3.1.15 445: 48 S [Windows XP SP1]
2010-04-17-16:42:05.4878 tcp(6) – 188.26.75.203 2027 10.3.1.15 445: 48 S [Windows XP SP1]
2010-04-17-16:42:06.0341 tcp(6) – 188.26.75.203 2027 10.3.1.15 445: 48 S [Windows XP SP1]
2010-04-17-16:43:00.3707 tcp(6) – 91.1.250.229 1450 10.3.1.6 445: 64 S [Windows 2000 RFC1323]
2010-04-17-16:43:00.9051 tcp(6) – 91.1.250.229 1450 10.3.1.6 445: 64 S [Windows 2000 RFC1323]
2010-04-17-16:43:01.4310 tcp(6) – 91.1.250.229 1450 10.3.1.6 445: 64 S [Windows 2000 RFC1323]
2010-04-17-16:43:27.1202 tcp(6) – 94.24.134.186 1103 10.3.1.5 445: 48 S [Windows XP SP1]

— Andrew Waite

Categories: honeyd, Honeypot, InfoSec, Lab

Return from intermission

2010/04/17 Comments off

Apologises for the break in regular postings, I was caught by surprise when I realised that it had been over a month since the last InfoSanity post. Unfortunately I haven’t won the lottery and been living in the lap of luxury, just real life and work getting in the way of extra curricula activities.

Normal service should now be resuming shortly.

— Andrew Waite

Categories: Uncategorized