Department Of Computer Science

Diploma Thesis

Advanced Honeynet Based Intrusion Detection

Jan Gerrit Gbel July 27, 2006
First Examiner: Prof. Dr. Felix C. Freiling Second Examiner: Prof. Dr. Christian Bischof Advisor: Thorsten Holz

Hiermit versichere ich, dass ich die Arbeit selbstndig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe.

Aachen, den 27. Juli 2006

Jan Gerrit Gbel

Abstract In this diploma thesis, we introduce the setup of a high-interaction Honeynet, deployed at RWTH Aachen University. We show how the operation of the Honeywall Roo can greatly facilitate the process of building such a network of electronic decoys and present the benets of this concept. In addition, we illustrate two intrusions that happened during the time of this thesis, and give an in-depth view on the tools and techniques used by the particular attackers. Furthermore, we take a look at the low-interaction Honeypot Nepenthes, and how it can be extended, to serve as an highly ecient Intrusion Detection sensor, to t into our automated notication and handling system, called the Blast-oMat. In this context, we describe the added features and the distributed design of the new Blast-o-Mat version 4. Finally, we substantiate the eectiveness of our Honeynetbased Intrusion Detection system with concrete results, that we obtained during the last months. Zusammenfassung In dieser Diplomarbeit stellen wir den Aufbau des an der RWTH Aachen aufgesetzten High-interaction Honeynets vor. Wir zeigen, wie der Einsatz der Honeywall Software Roo, die Einrichtung eines solchen Netzwerkes von elektronischen Kdern unterstzt and prsentieren den Nutzen, den man aus diesem Konzept ziehen kann. Zustzlich betrachten wir zwei Einbrche, die whrend der Zeit der Diplomarbeit passierten, genauer und liefern eine detailierte Beschreibung der Werkzeuge und Techniken, die von den jeweiligen Einbrechern verwendet wurden. Desweiteren betrachten wir den Low-interaction Honeypot Nepenthes und zeigen wie er erweitert werden kann, um als hoch ezienter Intrusion Detection Sensor in unserem automatisierten Benachrichtigungs- und Handhabungssystem, dem Blast-o-Mat, zu dienen. In diesem Zusammenhang beschreiben wir die hinzugefgten Eigenschaften und das verteilte Design des neuen Blast-o-Mat Version 4. Abschliessend untermauern wir die Eektivitt unseres Honeynet basierten Einbruchs Erkennungssystems mit konkreten Ergebnissen, die wir in den letzten Monaten gewonnen haben.

Contents
List of Figures List of Tables 1. Introduction 1.1. Motivation . . . . . . 1.2. Tasks . . . . . . . . . 1.3. Results of this Thesis 1.4. Thesis Outline . . . . 1.5. Acknowledgements . xi xiii 1 1 2 3 3 4 5 5 5 6 6 6 6 7 7 8 8 9 11 11 12 13 13 15 15 17 18 21 21 22 24 24 25

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

2. Basics 2.1. Introduction . . . . . . . . . . . . . 2.2. Attacker Classication . . . . . . . 2.2.1. Low-level Attacker . . . . . 2.2.2. Medium-level Attacker . . . 2.2.3. High-level Attacker . . . . . 2.3. Malware . . . . . . . . . . . . . . . 2.3.1. Worms . . . . . . . . . . . . 2.3.2. Viruses . . . . . . . . . . . . 2.3.3. Trojans . . . . . . . . . . . 2.3.4. Bots . . . . . . . . . . . . . 2.3.5. Rootkits . . . . . . . . . . . 2.4. Network Basics . . . . . . . . . . . 2.4.1. ISO/OSI Reference Model . 2.4.2. Internet Relay Chat . . . . 2.5. Attack Patterns . . . . . . . . . . . 2.5.1. Phishing . . . . . . . . . . . 2.5.2. Linux ptrace Root Exploit 2.5.3. Denial of Service . . . . . . 2.5.4. Man-in-the-Middle Attack . 2.6. Summary . . . . . . . . . . . . . . 3. Honeywalls and Honeypots 3.1. Introduction . . . . . . . . . . . . . 3.2. Honeypot History . . . . . . . . . . 3.3. Honeypot Classication . . . . . . . 3.3.1. Low-interaction Honeypots . 3.3.2. High-interaction Honeypots

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

vii

3.4. Honeywall Overview . . . . . . . . . . 3.4.1. Data Control . . . . . . . . . . 3.4.2. Data Capture . . . . . . . . . . 3.4.3. Data Analysis . . . . . . . . . . 3.5. Building a Virtual Honeynet . . . . . . 3.5.1. Honeywall Roo . . . . . . . . . 3.5.2. Installation and Administration 3.5.3. Operating Roo . . . . . . . . . 3.5.4. Virtual Honeynet . . . . . . . . 3.6. Lessons Learned . . . . . . . . . . . . . 3.6.1. Suse Honeypot Compromise . . 3.6.2. Red Hat Honeypot Compromise 3.7. Summary . . . . . . . . . . . . . . . . 4. Nepenthes 4.1. Introduction . . . . . . . . . . . . . 4.2. Nepenthes Overview . . . . . . . . 4.3. Inside Nepenthes . . . . . . . . . . 4.3.1. Module: log-mail . . . . . . 4.3.2. Module: log-syslog . . . . . 4.3.3. Module: log-blastomat . . . 4.3.4. Module: log-mysql . . . . . 4.3.5. Module: vuln-exchangepop3 4.3.6. Module: vuln-logssh . . . . 4.3.7. Module: vuln-smtp . . . . . 4.4. Summary . . . . . . . . . . . . . . 5. Blast-o-Mat 5.1. Introduction . . . . . . . . 5.2. Overview . . . . . . . . . . 5.3. Blast-o-Mat Version 4 . . 5.3.1. Intrusion Detection 5.3.2. Notifying . . . . . 5.3.3. Handling . . . . . . 5.4. Implementation . . . . . . 5.4.1. Snier . . . . . . . 5.4.2. BlastServer . . . . 5.4.3. PortScan Sensor . . 5.4.4. Spam Sensor . . . 5.5. The Web Interface . . . . 5.6. Results . . . . . . . . . . . 5.7. Summary . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

26 26 28 33 34 35 35 37 39 42 44 48 55 57 57 57 59 60 61 62 63 69 70 72 74 75 75 75 76 77 79 79 81 81 83 91 93 95 96 100 103 103 103 103

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

6. Conclusion and Future Work 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1. Blast-o-Mat Extensions . . . . . . . . . . . . . . . . . . . . . . . .

6.2.2. Quarantine Honeynet . . . . . . . . . . . . . . . . . . . . . . . . . 105 6.2.3. Honeynet-based Firewalls . . . . . . . . . . . . . . . . . . . . . . 106 6.3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 A. Additional Tools B. Images Bibliography 109 113 122

List of Figures
2.1. 2.2. 2.3. 2.4. 2.5. Setup of a botnet with a central server for command The OSI reference model [Ver98] . . . . . . . . . . Setup of an IRC network . . . . . . . . . . . . . . . Phishing report [Gro06] . . . . . . . . . . . . . . . Man-in-the-Middle Attack . . . . . . . . . . . . . . & control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 11 13 14 18 21 27 28 30 31 32 33 33 34 36 37 38 38 39 42 46 47 51 58 61 62 66 66 67 67 68 70 71 72 73 73 77

3.1. Example of a simple Generation III Honeynet setup . 3.2. IPTables rule to limit TCP connections . . . . . . . . 3.3. Snort_Inline rule to replace packet content . . . . . . 3.4. Snier trace . . . . . . . . . . . . . . . . . . . . . . . 3.5. Swatch rule . . . . . . . . . . . . . . . . . . . . . . . 3.6. Typical Sebek deployment [Pro03b] . . . . . . . . . . 3.7. Sebek read system call redirection [Pro03b] . . . . . . 3.8. Trac Overview . . . . . . . . . . . . . . . . . . . . 3.9. Sebek process graph . . . . . . . . . . . . . . . . . . . 3.10. Walleye Conguration Overview . . . . . . . . . . . . 3.11. Walleye Overview . . . . . . . . . . . . . . . . . . . . 3.12. Walleye Flow View . . . . . . . . . . . . . . . . . . . 3.13. eMail warning about an outbounded TCP connection 3.14. GenIII Honeynet setup at RWTH Aachen . . . . . . 3.15. Trac inspection with Walleye . . . . . . . . . . . . . 3.16. Phishing URL and real eBay URL . . . . . . . . . . . 3.17. The eBay phishing site . . . . . . . . . . . . . . . . . 3.18. SHv5 startup screen . . . . . . . . . . . . . . . . . . . 4.1. Nepenthes design overview . . . . . . . . . . . . . . 4.2. Nepenthes log-mail example mail . . . . . . . . . . 4.3. Nepenthes log-syslog example message . . . . . . . . 4.4. NepVirus: Recognition with a newer signature . . . 4.5. NepVirus: Change in virus classication . . . . . . 4.6. Live feed of the Nepenthes web interface . . . . . . 4.7. Nepenthes statistics: top ten malware . . . . . . . . 4.8. Nepenthes overall statistics . . . . . . . . . . . . . . 4.9. EXchangepop3 remote buer overow POC [Mas06] 4.10. vuln-logssh statistics . . . . . . . . . . . . . . . . . 4.11. Example of the SMTP Procedure . . . . . . . . . . 4.12. Log-smtp received eMail . . . . . . . . . . . . . . . 4.13. Nepenthes log-smtp received SPAM . . . . . . . . . . . . . . . . . . . . . .

5.1. Blast-o-Mat setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xi

5.2. Tcpdump commandline . . . . . . . . . . . . . . 5.3. XML Document Type Denition (DTD) . . . . 5.4. Blast-o-Mat incident summary line . . . . . . . 5.5. The quarantine website . . . . . . . . . . . . . . 5.6. Blast-o-Mat IPTables redirection rule . . . . . . 5.7. XML message for a Blast-o-Mat PortScan event 5.8. Tcpdump command line . . . . . . . . . . . . . . 5.9. SpamSender.py command line options . . . . . . 5.10. Blast-o-Mat web interface . . . . . . . . . . . . 5.11. Overall detections of the Blast-o-Mat . . . . . . 5.12. W32/Blaster.A Norman Sandbox Report . . . . 5.13. Detections per port by the Blast-o-Mat . . . . . B.1. PHP script to send SPAM eMails . . . . . . . . B.2. PHP script to send phishing data to the attacker B.3. Sebek data (40 minutes behind actual time) . . . B.4. SSH scanner startup script by Methadon . . . . B.5. Module: log-mail . . . . . . . . . . . . . . . . . B.6. Analysis Output of the Norman Sandbox . . . . B.7. Blast-o-Mat Snier main loop . . . . . . . . . . B.8. Blast-o-Mat PortScan detection stages . . . . . B.9. Message body of a Blast-o-Mat warning eMail . B.10.Blast-o-Mat BlockMac.py script . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

82 85 85 90 91 92 94 94 95 96 98 99 113 114 114 115 116 117 118 119 120 121

List of Tables
3.1. Summarized comparison of Honeypots . . . . . . . . . . . . . . . . . . . . 3.2. Summarized Honeypot compromises . . . . . . . . . . . . . . . . . . . . . 4.1. log-mail conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. log-blastomat conguration . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. log-mysql conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. 5.8. Blast-o-Mat Snier conguration . . . . Tcpdump parameter description . . . . . Blast-o-Mat BlastServer conguration . . AccountLookUp dictionary object . . . . Blast-o-Mat AccountLookUp conguration Blast-o-Mat BlastHelper conguration . . Blast-o-Mat PortScan conguration . . . Blast-o-Mat Spam detection conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 56 61 63 63 82 83 84 86 87 88 91 93

A.1. ndFiles command line options . . . . . . . . . . . . . . . . . . . . . . . 109 A.2. getHosts conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

xiii

Chapter 1. Introduction
You can learn much from your enemy - much more than from your friends. (Dalai Lama) The Internet has evolved to a platform for all kinds of services and applications. Thus, the times of a computer serving as an electronic type writer or data storage facility are long gone. Nowadays one can use the Internet as a place to chat with people from around the world, book ights to distant places or even buy a car. Online banking and payment have become part of todays way of life. For this reason, even home computers store valueable and security sensitive information, like passwords to online shops, credit card numbers, account data and personal identication numbers. Furthermore, the continous progress in computer industry has led to more powerful machines and broadband connections in almost every home, resulting in an increasing number of hosts being permanently online. Therefore, almost any machine on the Internet can be seen as a valuable target to computer criminals, to either steal sensitive data, misuse bandwith to send out unsolicited bulk eMail, or threaten companies to attack their facilities. Moreover, autonomously propagating malware and automated tools for vulnerability scanning have drastically simplied the process of compromising and misusing machines on the Internet. In summary, an attacker with full control over a victims host can do serious damage. The following section 1.1 describes the motivation of this thesis. Afterwards, we provide a brief description of the task of this diploma thesis in section 1.2, followed by a summary of the results in section 1.3. In section 1.4, the thesis outline is presented. Finally, section 1.5 presents a list of people, who supported this work and contributed useful information.

1.1. Motivation
Obviously, network security is the number one subject and must not be neglected. The current situation demands more active and preventive measures, in order to successfully ght computer crime. For this reason, one needs to study and analyse the motives and tools, utilised to compromise vulnerable systems on the Internet by todays cyber criminals. The operation of electronic decoys, so called Honeypots, greatly supports this process. Equipped with special logging facilities, Honeypots pretend to be a valueable

Chapter 1. Introduction target, thus luring an attacker into the trap. The knowledge that can be gained comprises, for example, the discovery of unkown software aws, dierent attack patterns, and new tools. Furthermore, Honeypots can be used to collect autonomous spreading malicious software, which, thoroughly analysed, can serve as an input vector for building new anti-virus signatures or anti-malware software. As a result, the collected information can be used to further strengthen defensive measures. Additionally, to prevent contaminated or compromised hosts from further attacking other, possibly vulnerable, systems on the network, countermeasures must be initiated. For this reason, many sensors have been developed in the past, to watch for network anomalies, such as probes for vulnerable systems. However, the main problem remains open: intrusion detection systems generate by far too many false alarms and rarely undertake any eective countermeasures on true incidents. For this purpose, Honeypot technology can be utilised to construct an accurate intrusion detection sensor, which serves as input for an automated notication and handling system. The resulting system is able to notify the owner of a compromised or infected machine and take additional actions, like blocking access to this host, to prevent any further propagation of malicious software. Thus, we eciently extend the classical reactive security measures with more active and preventive ones.

1.2. Tasks
The task of this diploma thesis is to build a distributed Intrusion Detection System (IDS) based on the low-interaction Honeypot, named Nepenthes and the automated notication and handling system, called Blast-O-Mat. This system is capable of eciently detecting hostile hosts within the campus network of RWTH Aachen. Therefore, the low-interaction Honeypot Nepenthes is modied to serve as an additional intrusion detection sensor for the Blast-o-Mat system. The main goal is to detect and permanently block network access of contaminated hosts to prevent infection of any further vulnerable machines on the network. Furthermore, an alerting mechanism is present, to inform both, the network administrator and the owner of an oending host. In addition to the eMail based notication method, the Blast-o-Mat oers the possibility to redirect trac, of contaminated hosts, to a prepared website for further information. Besides the intrusion detection mechanism, the operating of a large-scale Honeynet at the Laboratory for Dependable Distributed Systems at the Department for Computer Science of Aachen University, is the second main task of the diploma thesis. For this purpose, the Honeywall software Roo, of the Honeynet Project, is utilised, which greatly facilitates and accelerates the process of setting up a Honeynet. Additionally, several Honeypots, with dierent operating systems and vulnerable applications installed, are deployed and actively maintained to lure attackers. The goal is to analyse their behaviour and learn more about tools and techniques used to compromise vulnerable systems on the Internet. Furthermore, observed burglaries should be presented in more detail in the diploma thesis.

1.3. Results of this Thesis

1.3. Results of this Thesis

Currently, we maintain a total of eigth distinct Honeypot machines, seven deployed at RWTH Aachen and one at University of Karlsruhe. Each with a dierent degree of interaction, thus providing variability of results. At RWTH Aachen, we operate four high-interaction Honeypots and three Nepenthes machines, with about 16.000 Internet Protocol (IP) addresses distributed among each other. Altogether, we were able to capture over 5.000 unique malware binaries and monitored seven successful Honeynet burglaries. Two of those incidents along with the experiences we have gathered since the beginning of this thesis, are described in detail in chapter 3. Additionally, a thorough analysis of the tools, that were used by the attackers to compromise and misuse our Honeypot systems, is presented. Furthermore, we have introduced the low-interaction Honeypot Nepenthes and its automated malware collection features. Due to the modular structure we were able to extend Nepenthes to several new elds of applications. For example, we provided interesting results in the area of securing user passwords, as well as, SPAM detection and presented an in-depth view on how to write new vulnerability modules. Additionally, we set up a web interface to access and browse through all results gathered from the Nepenthes machines, as well as the output of the various malware analysis tools, which are described throughout chapter 4. Moreover, we deployed an automated notication and handling system at the campus network of RWTH Aachen, utilising Nepenthes, as an ecient and accurate intrusion detection sensor, to lter out infected hosts. Finally, we presented some concrete results to prove the eectiveness of this approach

1.4. Thesis Outline

The thesis is outlined as follows. The second chapter deals with the network basics and dierent attack patterns, which are needed for better understanding of the incidents described at the end of the third chapter. In the third chapter, we deal with Honeynets, their setup and management. Additionally, we present a detailed report of two successful compromises, including a thorough analysis of the tools involved. In chapter 4 we take a closer look at Nepenthes, the low-interaction Honeypot for automated malware collection. We extended the software in several dierent ways, e.g. to serve as an accurate Intrusion Detection sensor for the Blast-o-Mat system. In chapter 5, we describe the automated notication and handling system deployed at RWTH Aachen, called the Blast-o-Mat, especially the new distributed system approach of version 4. Furthermore, we explain the dierent detection mechanisms, the notication techniques, and how contaminated hosts are handled to form a highly ecient, overall system for securing large scale networks, like the campus network of RWTH Aachen University.

Chapter 1. Introduction

1.5. Acknowledgements
First of all, I would like to thank Prof. Dr. Freiling, who gave me the opportunity to work in this exciting area of computer science. In this context, I would also like to thank my advisor Thorsten Holz for his great support and valuable feedback, he gave me throughout the thesis. Although, he was not always physically present, I never had a question unanswered. Furthermore, he introduced me to all kinds of persons, who help me to fullll my tasks. I would also like to thank Prof. Dr. Bischof for being my second examiner and allowing me to work on my thesis at the Center for Computing and Communication of RWTH Aachen. In addition, I would like to thank all members of the Network Operations Center, especially Jens Hektor, who became kind of my second advisor and supported me with all kinds of security and Blast-o-Mat related questions, Thomas Bttcher, the number one person in charge for any Python related stu, Silvia Leyer, Andreas Schreiber, Frank Meesen, Frank Brggemann, as well as, all other people working at the Center for Computing and Communication. Without their help and infrastructure provided, this thesis would not have been possible. There are also many other people I would like to thank for supporting me in the development of various aspects of my work. First of all, I would like to thank Martin Mink and Diego Biurrun, who provided me with useful information and a very important CrossOver cable in the beginning of the thesis, when the Honeynet was still stationed at the former Laboratory for Dependable Distributed Systems of RWTH Aachen. Moreover, I would like to thank Markus Koetter and Georg Wicherski and all other people from the #nepenthes IRC channel, for the patients and answers to all my questions, as well as the bugxing of the Nepenthes modules. Additionally, I would like to thank Adrian Wiedemann for allowing me to deploy and maintain a Nepenthes sensor at the University of Karlsruhe. Special thanks go to Philipp Trinius for proof reading my thesis and providing me with so many corrections and suggestions. This work also beneted from the valuable feedback and enhancements of Carsten Willems. He was working on his own thesis [Wil06] at the same time, which we managed to integrate into the Blast-o-Mat system, and, furthermore, proved to be an uncomplicated and friendly coworker. Finally, I would like to thank the Deutsche Forschungsnetz Computer Emergency Response Team, who provided me with useful data in the area of incident response and on the other hand were eager to read my detailed descriptions of attacks against our Honeynet. Both the atmosphere and cheerfulness at the Laboratory for Dependable Distributed Systems of the University of Mannheim, as well as the Center for Computing and Communication of the RWTH Aachen was amazing and tremendously contributed to the outcome of this diploma thesis. It was a pleasure working with all of you.

Chapter 2. Basics
2.1. Introduction
This chapter serves as an introduction to computer crime and network related basics. In the rst section, we picture and classify the typical attackers, which can be distinguished by their skills, motives and knowledge. Furthermore, we give a short explanation of the dierent kinds of malicious software and illustrate some common Rootkit techniques. A Rootkit is a collection of tools, which facilitates the process of keeping control over a previously compromised machine. Additionally, we introduce the Open Systems Interconnection (OSI) reference model and its seven layers. Although the model is not realized in todays network implementation, it provides a good overview of where host blocking can take place. Following, the Internet Relay Chat (IRC) is explained, which is a network service commonly misused as command and control (C&C) server for remotely controllable machines, called bots. Moreover, we describe two dierent attack methods used by intruders, that were trapped by our high-interaction Honeynet during the time of the thesis. First, an example for misusing a Honeypot to trick others into revealing personal information, called phishing, is presented. Then, a way to escalate user privileges to gain root access to a machine an attacker has already remote access to, is described. Another frequently used attack method is the so called Denial of Service or Distributed Denial of Service attack, which is described in the second last section of this chapter. Finally, we delineate a technique called Man-in-the-Middle attack, used by intruders to intercept network messages between two hosts, without being noticed.

2.2. Attacker Classication

This section gives a short overview about the dierent kind of attackers, their motives and knowledge. According to Ed Skoudis [Sko02] we can classify an attacker into the following groups: Low-level attacker Medium-level attacker High-level attacker

Chapter 2. Basics Each group dierentiates in its faculties, tools and techniques that are used when hacking into other systems. While some own only rudimentary skills, utilising precast scripts with little to no knowledge about the way they work or their outcome, others savor a great education about dierent operating systems and programming languages.

2.2.1. Low-level Attacker

The low-level attackers are also often called Script Kiddies. Their goal is to compromise systems in a fast and easy way. They utilise precast scripts to exploit known vulnerabilities, without the understanding of how these scripts or the underlying attacks work. Many of these ready-to-use hacking tools can be easily found and downloaded from the Internet, making this kind of attacker the most common. Although these methods are rather primitive, they have a high success rate, due to the great number of vulnerable and unprotected systems within the Internet. The attackers motives are more to show o in front of their friends or out of sheer curiosity, than of a nancial incentive.

2.2.2. Medium-level Attacker

Next to the Script Kiddies reside the so called medium-level attackers. Their knowledge in computer science is more advanced. Thus, they are able to adapt scripts and tools to their needs, as they have more background knowledge on the vulnerabilities they exploit. However, they do not possess enough knowledge to reveal new aws in software applications or even write their own tools to exploit newly discovered vulnerabilities. Their motives can be described as of economic incentives, by setting up phishing sites or sending of SPAM eMails, for example.

2.2.3. High-level Attacker

The most advanced group of attackers form the so called high-level attackers. In contrast to the Script Kiddies, they know how to hide and cover their traces. With the knowledge of dierent computer programming languages, they have the ability to write their own tools and exploits. Incidentally, they research in the area of computer security to reveal new aws in operating systems, user applications or other programs. Thus, these group of attackers carefully selects and eectively compromises their targets. Most of the times the newly discovered vulnerabilities are kept secret, however, there exists some high-level attackers that reveal their knowledge to the public to support the computer security community [Hof04].

2.3. Malware
Malware is the abbreviation for malicious software. This software actively harms the computer it is executed on or other systems within the network. This section gives a short overview over the four main kinds of malicious software, which can be frequently

2.3. Malware found on the Internet. Additionally, we explain the term Rootkit and three dierent implementation methods, commonly used by attackers.

2.3.1. Worms
The category of worms includes software that copies itself via local or global networks with the goal to: intrude remote hosts execute a local copy of itself on the remote host spread further via the network to infect other systems Worms propagate via computer networks by utilising dierent mechanisms. For example, eMail, instant messaging (ICQ,MSN), Peer-to-Peer, or Internet Relay Chat (IRC) networks. In some cases, they travel in form of a self-contained le that needs to be executed on the remote host in order to activate the worm. This can be an eMail attachment, a hyperlink on a website, or a le distributed with the help of lesharing programs. However, the most common type of worms are the ones, that propagate as network packets themselves, thus remotely exploiting vulnerabilities on dierent operating systems to achieve their goals. In addition to the propagation mechanisms, worms contain functions to harm the machines they infect, the so called malicious payload. This includes backdoor capabilities, like trojans or le infection mechanisms as used by viruses [Lab06].

2.3.2. Viruses
The traditional computer virus disseminates with the goal to: become active upon the execution of certain programs infect other computer resources In contrast to the computer worms, viruses do not have an own mechanism to automatically spread via networks. Therefore, remote hosts are not infected by means of the virus itself, but due to manually sent eMail, with contaminated attachments or attached portable data carriers, containing the malicious software [Lab06]. Viruses often contain characteristics of other malware, like a backdoor or le deletion mechanisms. They are even capable of destroying basic input/output system (BIOS) components, rendering a computer unusable. For example, the virus W32/Kriz is programmed to damage the BIOS, as well as, delete the Complementary Metal Oxide Semiconductor (CMOS), which holds the user settings for the BIOS. Additionally, all data on local and network devices is overwritten. As a result, a successfully infected machine needs to have the BIOS chip replaced to be functional again [Sop99].

Chapter 2. Basics

2.3.3. Trojans
Trojans are programs that execute various unlawful actions on the infected host. A common operation is the gathering and retransmission of private information, like passwords and credit card numbers, to a villain. This is, for example, accomplished with the help of keyloggers, which record keystrokes performed on the victim host. Additionally, trojans contain a backdoor, which allow an attacker to return to the contaminated host at any time and unnoticed. This enables an intruder to keep full control over the compromised system, which can be further misused for all kinds of vicious actions. Similar to a virus, a trojan does not own a spreading mechanism or exploits a vulnerability to infect another machine. It either needs to be manually installed by an attacker or by another program, like a worm.

2.3.4. Bots
The term bot is derived from the word robot and refers to a program, which can, to some degree, act in an autonomous manner. A computer system that can be remotely controlled by an attacker, is called a bot or zombie. Bots started o as little helper tools, especially in the IRC community, to keep control of a private channel or as a quiz robot, randomly posting questions [Mox02]. In the context of malware, bots are harmful programs, designed to do damage to other hosts on the network. Moreover, bots can be grouped to form so called botnets, consisting of several hundreds up to thousands of hosts, whose combined computing power can be utilised by the owner of the botnet to perform more powerful attacks, such as a Distributed Denial of Service (DDoS) attack. This is a technique which involves more than one attacking host and is described in more detail in section 2.5.3.

Figure 2.1.: Setup of a botnet with a central server for command & control

2.3. Malware To control a large group of bots, a command & control (C&C) server is utilised, which all zombie machines connect to and receive instructions (Figure 2.1). A common method of an attacker to communicate with the botnet, is to use IRC, which is described in section 2.4.2. In this case, the infected machines automatically join a specic channel on a public or private IRC server, to receive further instructions, such as, perform an attack on a specied victim or scan certain network ranges for hosts with known vulnerabilities. For bots are able to propagate themselves across the network and feature keylogging and backdoor functionallities as well, they can be seen as a combination of worms and trojans. A more detailed description of botnets and their attack features is provided in the work of [All05b].

2.3.5. Rootkits
As soon as an attacker has compromised a vulnerable host, one of the next steps is to cover all the tracks, that would lead to the detection of the intrusion. This step includes the removing of suspicious logle entries and disabling of running logging services. Additionally, a common action is to install a backdoor, to be able to return to the compromised host at any time, with full root privileges. Thus, the attacker stays in control of the system to further misue it for attacks or collect user sensitive data. Furthermore, the intruder might install a number of dierent tools, to monitor keystrokes or sni passwords on the compromised system. To achieve all this tasks, a great number of modications need to be done, which can be dicult and time consuming to perform. Thus, there exists a variety of programs, combining and automating all the above mentioned tasks in one kit, the so called Rootkit. The name Rootkit is derived from the term root, which is the name of the superuser in UNIX based operating systems, where these tool kits have their origin. Nowadays there exist Rootkits for all kinds of operating systems. Their purpose is to automate the process of setting up and maintaining a compromised host without being noticed. The rst Rootkits were discovered around the mid-1990s, although there existed some less sophisticated log le cleaners some time before [Chu03]: 1989: First log cleaners found on hacked systems 1994: Early SunOS kits detected 1996: First Linux Rootkits publicly appear 1997: Loadable Kernel Module (LKM) Trojans proposed in the "Phrack" magazine 1998: Non-LKM kernel patching proposed by Silvio Cesare 1999: Adore LKM kit released by TESO 2000: T0rnkit v8 libproc library Trojan released 2001: KIS Trojan and SucKit released 2002: Snier backdoors start to show up in Rootkits

Chapter 2. Basics Today, we can distinguish between three main types of Rootkits: Binary Rootkits, Kernel Rootkits and Library Rootkits [Chu03]. Binary Rootkits Binary Rootkits are the more simple Rootkits, that replace critical operating system binaries with trojaned ones. Thus, the output of the programs is modied to eciently hide the presence of the attacker and allowing concealed remote access to the compromised host. The rst Rootkits were just simple compressed archives holding the most common binaries, frequently used by system administrators to monitor the status of a computer, as well as some additional tools, such as log le cleaners to remove the tracks of the intruder. Some binaries, that are typically replaced, are: ls, netstat, ps, login, lsof and pstree. The trojaned equivalents implement the same functionality as the originals, but do not show the activities of the attacker. In this case, activities can be of any of the following kinds [Mue05]: running malicious services, such as keystroke sniers or backdoors les and directories created by the intruder established network connections Kernel Rootkits A kernel module is a program that can be loaded by the running kernel to extent its functionality. For example, if a certain device needs to be accessed and there is no appropriate driver available in the kernel, it can be loaded on demand in terms of a module. Loadable Kernel Module (LKM) Rootkits use this ability to inject themselves into the running kernel. Unlike the binary Rootkits, which modify or replace system binaries, the Kernel Rootkit modies system calls, thus operating at a much higher level. For example, the system call open(), usually used to open a certain le on the harddisk, is modied to open all les, except those belonging to the Rootkit. As a result, the very core of the operating system becomes untrusted, thus any command executed on the compromised host may return incorrect information [Chu03]. Examples of a kernel Rootkit are the KNARK Rootkit or SucKIT, which were released in 2001. A detailed analysis of KNARK is provided in the work of [Mil01]. Library Rootkits Similar to the binary Rootkits, the library Rootkit replaces les of the operating systems to hide any evidence of the intrusion. But this time the Rootkit aims at the standard system libraries, which relay process information from the kernel space to user space utilities, e.g. ps or top. Thus, it is possible to sanitize the data provided by the kernel from any evidence of the intrusion, prior to relaying it to the executed system command. However, this aects only non-statically linked binaries, i.e. the libraries are not part of

10

2.4. Network Basics the program itself [Chu03]. For example, T0rnkit v8 hides its presence by integrating its own library le, libproc.so into the system. It is responsible for relaying process information of the /proc-lesystem to user space utilities [Dol03].

2.4. Network Basics

2.4.1. ISO/OSI Reference Model
The Open Systems Interconnection (OSI) reference model is based on a suggestion of the International Organization for Standardization (ISO) and represents a preliminary step to the standardization of the dierent network protocols.

Figure 2.2.: The OSI reference model [Ver98] The OSI reference model consists of seven layers, as shown in gure 2.2. As each layer provides services to the layer above, they all add their header information to a network packet (A.H. - Application layer Header), that is to be send. On the receiving site, each of this headers is removed at the appropriate layer, thus eciently reassembling the transmitted information. The dierent layers can be shortly described as follows [Sys99]: The Physical layer (layer 1) denes the mechanical, electrical or optical specications of a physical link between two communicating network systems. Characteris-

11

Chapter 2. Basics tics such as voltage levels, timing of voltage changes, physical data rates, maximum transmission distances, and physical connectors are specied in this layer. The Data link layer (layer 2) ensures an error-free transmission of data across a physical network link. Devices at the data link layer are addressed by their physical Media Access Control (MAC) address, which is hard coded into the network cards. Bridges and switches usually operate on layer two. The Network layer (layer 3) denes a logical addressing scheme. For example, the Internet Protocol (IP), denes network addresses in a way, that allow routing of data through intermediary nodes, to destination systems with no direct connection. This is accomplished by comparing the source network address with the destination network address and applying the subnet mask. Routers, for example, operate on layer three to determine how to forward a packet. The Transport layer (layer 4) receives data from the session layer and segments it for transport across the network. Generally, the transport layer is responsible for assuring, that data is delivered error-free and in the proper sequence. Flow control generally occurs at the transport layer. The Session layer (layer 5) provides the mechanisms to establish, manage, and terminate communication sessions, initiated between end-user application processes. The Presentation layer (layer 6) provides a set of conversion and encoding functions, to ensure that information sent from the application layer of one system is readable by the application layer of another system. For example, the conversion of character representation formats or data compression. The Application layer (layer 7) interacts directly with the software applications that implement a communication component. Typical functions provided by this layer include: communication partner identication, resource availability checks and communication synchronization. Examples of this layer include, Telnet or the Simple Mail Transfer Protocol (SMTP). Each of the presented layers provides the possibility to block the network access of a certain host. For example, one can just pull the plug, thus leading to a blocking on the physical layer. Another method is to use rewall rules to either block the IP address or disallow certain protocols, thus, using higher layers of the OSI model for locking. The advantages and disadvantages of locking a host on certain network layers are described in chapter 5.

2.4.2. Internet Relay Chat

The Internet Relay Chat (IRC) is a concept that allows clients to communicate with each other in real time. There exist several separate networks of so called IRC servers, that provide users a connection to the IRC. These networks often have several thousand users online, at the same time. The users connect via IRC client programs to a server on one of the networks (Figure 2.3). The server relays information to and from other

12

2.5. Attack Patterns servers on the same IRC network. Each of the dierent servers hosts a huge number of dierent chat rooms, called channels, which a user can join to discuss certain topics. Every user, that is connected to an IRC server, has its own unique username, called nickname, which can be up to nine characters long. Conversations within the channels can be private, just between two persons, or public, so that every one in the channel can read the messages. The channel names can be freely chosen, but usually start with the character # or &. Channels with the latter prex are not shared by all servers on the network, but exist only on a single server. It is even possible to create ones own private or public channel [CL00].

Figure 2.3.: Setup of an IRC network IRC is a common method to remotely command and control bots. Therefore, an IRC server, which hosts bots, is usually referred to as the command and control (C&C) server. All compromised machines connect to a predened IRC channel, where they receive further commands by the botnet owner. Usually, the channel topic holds instructions for each connected bot, such as, scan for vulnerable machines or perform a distributed denial of service attack on a certain host. The reason for this is, that the topic is read by any client entering the channel, thus it provides a useful method to automatically instruct thousands of machines to perform certain tasks. Additionally, it is possible to send single commands via the IRC channel to all or just a selected group of zombie machines.

2.5. Attack Patterns

2.5.1. Phishing
Phishing is an attack method, that uses social engineering techniques to purloin personal identity information and nancial account credentials from incautious Internet

13

Chapter 2. Basics users. With the help of spoofed eMails, i.e. the eMail sender address is modied to a trusted name, the attacker leads customers to counterfeit websites, the so called phishing sites. These websites hijack brand names of, for example, banks, e-retailers and credit companies, to look like the original site and beguile any victims. Thus, visitors are tricked into divulge nancial data, such as credit card numbers, account usernames, passwords, and social security numbers. For example, an attacker sets up a website on a previously compromised host, that looks exactly like the login site of a popular online portal, like the one from eBay. Customers authenticate via a web formular, by entering their account name and a valid password. Upon authentication, users are, for example, able to place bets on certain items. The phishing site utilises a modied script for customer authentication, which usually works in two steps. In the rst step all entered user credentials are send via eMail to the attacker. In the second step, the visitor of the phishing site is redirected to an error page of the original website, in this case of the eBay online portal. The error page displays, that the authentication process has failed. The purpose of the last step is to make the victim believe some of the previously entered data was wrong, due to mistyping. The unsuspecting customer repeates the login process, this time on the original website, and succeeds. As a result, the attacker is able to collect user credentials without raising suspicion. After the set up of the prepared phishing site, the attacker needs to lure potential victims. This is usually accomplished by sending out masses of eMails or posting of hyperlinks leading to the prepared website to Internet forums or discussion boards.

Figure 2.4.: Phishing report [Gro06] Another frequently used technique to steal credentials directly, is the use of trojans,

14

2.5. Attack Patterns keyloggers or spyware, which are installed without being noticed by the machine owner [Gro06]. Figure 2.4 shows the threatening development of phishing attacks, reported over the past twelve month. Although phishing is not a new method in computer crime, the large number of reported attacks, reveals the eciency of this technique. A detailed description of various phishing techniques and observed incidents can be found in the work of [All05a].

2.5.2. Linux ptrace Root Exploit

Published on March 23th 2003, the local root exploit aects all Linux kernel versions 2.2.x < 2.2.25, as well as, 2.4.x < 2.4.20 and allows a local user to attain root privileges, by exploiting a bug in the ptrace function. The Linux ptrace function is a diagnostic function, that permits a parent process to monitor and control a child process. Every time a process executes functions implemented as a Linux kernel module, a child process is created. The new child sets its eective group (EGID) and user identication (EUID) to zero, i.e. it acquires root privileges. In contrast to the standard user (UID) and group identication (GID), the EUID and EGID can be temporarily extended to provide access rights to les that otherwise are protected from non-root users. This happens, for example, whenever a user changes his password with the Linux passwd command. An attacker that has already attained remote access to a system, for example, due to a less secured guest account, is then, with the help of the ptrace function, able to escalate the user privileges. Before a newly created child process extends its EUID and EGID, the intruder can attach to the process using ptrace and inject any malicious code, which will then be executed with root privileges. This kind of attack is referred to as a race condition. A race condition occurs whenever a programs outcome critically depends on the sequence or timing of other tasks, which take place simultanously. For example, a program runs two dierent threads, one reads from a le and the other one writes to the same le. If both threads are executed at the same time, a race condition happens, for the program must not read before writing to the le. Otherwise the program crashes or provides unpredictable output. To exploit the ptrace vulnerability, a few assumptions have to be fullled [Bue03]: The kernel needs to have loadable kernel module support enabled, i.e. no monolithic kernel. The /proc/sys/kernel/modprobe le needs to have at least one valid entry. Execution of the ptrace function needs to be allowed.

2.5.3. Denial of Service

A Denial of Service (DoS) attack aims at inundation of a victim host with network packets or service requests, so that it cannot continue to perform its tasks or even crashes. As a result, innocent customers are unable to make a draft on their usual services, such as connecting to their webmail account, placing online bets, or even perform online banking.

15

Chapter 2. Basics Well-known service providers have been attacked this way before, like Amazon, Yahoo or eBay. Their servers were overwhelmed with more than four times the trac than usual and simply collapsed, as it is described in the news article of [SW00]. There are several tools present to perform dierent DoS attacks, some use aws in applications, operating systems or network protocols, and others just overwhelm the victim host with too many requests. Thus, depending on the technique used, there exist a few dierent kinds of Denial of Service attacks [fSidI], of which three are described in more detail here. The rst is an example for misusing a wrong implemented protocol. The second, exploits a vulnerability in an applications or operating system and the last is an example of overwhelming a victim host with thousands of requests. Syn Flooding: Before two hosts establish a TCP/IP connection between each other, a so called three-way handshake is performed to allocate needed resources and verify the state of readiness of both machines. The handshake procedure can be summarized as follows [Cor03a]: The initiating host sends a TCP SYN packet to the receiver. In case the receiver is ready to establish a new connection, it replies with a TCP SYN-ACK packet. The sender nishes the handshake with a nal TCP ACK packet. At a Syn Flooding attack, the oending host sends a large number of SYN packets to the victim host. The sender IP address of each outgoing packet is replaced to prevent any back tracking of the attack. The attacked host replies to each SYN packet with a SYN-ACK packet and allocates the needed resources to establish a new connection. As the sender address of each SYN packet is forged, i.e they belong to nonexistent or noninvolved machines, the victim never receives the nal ACK packet to nish the handshake. Thus, the attacked host continuously allocates limited resources for each partly established connection. At some point, all the systems capacities are consumed. As a result, the victim host is not reachable anymore, as long as the attacker keeps sending SYN packets. After a predetermined time frame, the partly established connections of the attacked machine receive a timeout, thus freeing the allocated resources. In 1996, Daniel J. Bernstein developed a method to protect computer systems against the Syn Flooding attack, with the help of so-called SYN Cookies. The technique takes advantage of the fact, that all sender addresses, participating in the DoS attack, are forged. In case a SYN packet is received, no resource allocation is performed, but the server sends a SYN Cookie, containing the connection information, to the initiator. As a countermove, the client needs to send the cookie back, to nalise the connection procedure [Ber96]. As a result, the use of forged IP addresses at SYN Flooding is no longer of any use to successfully denial service to a host. Ping Flooding: Ping is a program designed to check the availability of a host on the Internet. For this purpose, it utilises the Internet Control Message Protocol (ICMP) to send out ICMP Echo Requests and waits for the according ICMP Echo

16

2.5. Attack Patterns Replies. As a result, one is able to check the reachability of systems, as well as the network latency, as ping also measures the Round Trip Time (RTT). RTT is the time a packet needs to travel to a host and back. According to RFC 1122, every machine must implement an ICMP Echo server function [Pos81]. At a Ping Flooding attack, the attacker overwhelms the victim with a huge number of ICMP Echo Requests. Each request is replied with the corresponding counterpart, ICMP Echo Reply. As a result, the victim is occupied with replying to the thousands of incoming request, so that there are no resources left to process any other queries. Some older machines even crash upon receiving a certain type and size of ping (Ping of Death [Ken96]). Additionally, the victims network is congested, which makes the reachability of the victim host even worse. Mailbombing: This kind of attack utilises the sending of huge amounts of eMails to a victim mailserver, to either denial customers the access to this service or prevent a single customer from receiving any further mail. The rst case leads to a slow down of the mailserver, which results in a delay of mail processing or might even crash the server. In the second case, the inbox of the destination eMail address is overwhelmed with incoming messages. For inboxes are limited in size, due to restriced harddisk capacities, at some point all resources are used up, which results in the dropping of any further data. Distributed Denial of Service At a Distributed Denial of Service (DDoS) attack, more than one attacking machine is used to overwhelm a victim host by performing a large coordinated attack. The more dierent machines are involved, the more ecient is the attack. Therefore, the attacker needs to have a large amount of bots or zombie machines under his control. On each of the compromised machines, some kind of DDoS software is installed, which is capable of being activated from a single master host, the botnet owner. Examples for Distributed Denial of Service programs are Stacheldraht or TFN 2K. The advantage of using DDoS attacks is that countermeasures, like the SYN cookie, do not work anymore. In this case, the attacker does not need to use forged IP addresses, but utilises the bots to initiate mass connections, thus overwhelming the target. Distributed Denial of Service attacks have become increasingly dangerous in recent years, due to the simplicity and the success rate of the attack pattern. Furthermore, the attacks are hard to prevent, since the target host has to receive the packets rst to determine if it is a normal request or part of a DDoS attack. A technique to protect systems against DDoS attacks is presented in the work of [FHW05]. In contrast to previous work in this area, this approach is preventive instead of reactive, by eliminating the root-cause: the control network of the zombie machines.

2.5.4. Man-in-the-Middle Attack

The Man-in-the-Middle (MITM) attack is a technique that aims at the communication channel between two connected machines. The goal is to be able to read, insert, and

17

Chapter 2. Basics modify passing messages at will, without being noticed by either party. Therefore, the attacker feigns to be the real communication partner for each of the involved machines. Whenever, host A sends a message to host B, it is intercepted by the Man-in-the-Middle M, modied and forwarded to B, who believes the message originated from A. The basic concept of the MITM is illustrated in gure 2.5.

Figure 2.5.: Man-in-the-Middle Attack The MITM attack can be eciently avoided by the application of cryptographical methods to encrypt messages and the use of host authentication. Thus, the modication of messages and the forging of sender addresses is successfully prevented, which are the main weak points in client communication.

2.6. Summary
In this chapter, we introduced some of the network and security related basics, to form a common ground for the following chapters. In the rst part, an overview of the typical attackers, was provided. The low-level attacker or Script Kiddie has little to no skills and utilises precast software to exploit known vulnerabilities. The medium-level attacker has more background knowledge and is driven by nancial intentions. The high-level attacker is the most experienced one, reveals new aws in software and some even support the computer security community. In Section 2.3, we presented a short overview of the dierent kinds of malicious software, like viruses, worms, or trojans. Additionally, we described the term Rootkit, as a collection of tools to facilitate the process of covering tracks, after a successful burglary, and staying in control of the system. In this context, a brief explanation of the three dierent kinds of Rootkits, the binary Rootkits, the Kernel Rootkits and the library Rootkits, was given. Following, we presented the ISO/OSI reference model, to visualize the dierent possibilities of blocking a hosts access to the network. Furthermore, the concept of IRC was presented, which is often misused to serve as a command and control facility, in the area of bots. Moreover, we introduced a number of dierent attack patterns, of which some were experienced during the time of the diploma thesis. First, the method of phishing, a technique to purloin personal identity information with the help of social engineering, is described, followed by the local root exploit, that uses a bug in the Linux ptrace function. Furthermore, three kinds of DoS attacks, each utilising a dierent approach to denial service to a host,

18

2.6. Summary were introduced. The Syn- and Ping Flooding methods use large amounts of network packets to overwhelm a victim host, whereas the technique of Mailbombing uses masses of eMails. Besides the normal DoS attack, there also exists the distributed approach, which involves more than one attacking host. Finally, we presented the Man-in-theMiddle attack, as an additional way to steal sensitive information of the network, without being noticed.

19

Chapter 2. Basics

20

Chapter 3. Honeywalls and Honeypots

3.1. Introduction
All defensive mechanisms, utilised to protect a network or single computer, are based on the knowledge about certain attack patterns, vulnerable services or tools. Even the sequence of ports a single host connects to during a certain amount of time, can be used to identify hostile hosts, like those infected with computer worms [Hol05a]. Therefore, intrusion detection systems analyse trac for known patterns or rewalls block access to ports, known to be used as backdoors on infected machines. Examples can be found in the work of [All05b], [Pro00] and [All03]. One ecient way to gain knowledge about how systems are compromised, is to deploy electronic decoys, so called Honeypots. A Honeypot is a closely monitored computer which is intended to be compromised to gather information about the methods, motives, and tools an attacker uses to exploit a known, or even unknown vulnerability. The collected information can then be used to further improve the defensive mechanisms, i.e. developing of new rules for intrusion detection systems, that match a newly discovered attack pattern.

Figure 3.1.: Example of a simple Generation III Honeynet setup To increase the possibility for any intruder to compromise an electronic bait, usually more than one Honeypot is deployed, thus forming a large Honeynet. Figure 3.1

21

Chapter 3. Honeywalls and Honeypots visualizes one possible setup of a Generation III (GenIII) Honeynet. The rst Honeynets deployments were crude, providing only rudimentary data control and capture capabilities. They were limited to layer three routing gateways, the counting of outgoing connections, and were able to analyse unencrypted trac only. These initial deployments were considered the Generation I (GenI) of Honeynet technology [Pro05c]. With the release of Generation II (GenII) the optional layer 2 bridging, intrusion prevention technology and a tool to capture data prior to encryption, called Sebek (Section 3.4.2) were introduced. Generation III and Generation II Honeynets have the same architecture, but GenIII adds more improvements to the deployment and management of a Honeynet and integrates new tools needed for data analysis. The Honeynet research community, distinguishes two main types of Honeypots, production Honeypots, to protect an organization and research Honeypots, which are used to learn [Spi02]. The classication of Honeypots can be extended to Honeynets. In this case, a production Honeynet not only simulates a single productive server that needs to be protected, but a whole network of servers. Running an exact copy of an organizational network as a Honeynet can reveal new information about weaknesses, which eventually lead to a compromise of a machine that needs to be protected. This includes compromising a less valuable system within the network, from which passwords can be retrieved via Man-in-the-Middle attacks or other techniques, that allow the sning of local network packets. In contrast, a research Honeynet combines dierent operating systems in the same environment and unveils how they interact with each other, especially in the case of an attack. Unknown vulnerabilities can be detected depending on the patch level of the operating system and the running services. Statistical information about the number of incidents per system can be retrieved, as well. This chapter serves as an introduction to Honeywall and Honeypot methodologies. In the rst part, we give a short overview of Honeypot history and the dierent types of Honeypots. The following part deals with the Honeywall Roo of the Honeynet Project Research Alliance [Pro05c] and the setup of a virtual Honeynet, with the help of the virtualization software, VMWare [Ser]. Finally, we give an in-depth view on two selected attacks against our high-interaction Honeypots, which were deployed at RWTH Aachen. A summary concludes this chapter.

3.2. Honeypot History

In the early nineties, several publications on concepts expounded that can be seen as the foundations of todays Honeypot development. Cli Stolls The Cuckoos Egg [Sto90] and Bill Cheswicks An Evening with Berferd [Che91] are two of the more outstanding publications during that time. Both describe many concepts not unfamiliar to the Honeypot society. For example, Cheswicks paper chronicles the movements of a hacker, the baits and traps used to lure and detect him and the chroot Jail, that was build to watch the activities. Chroot is a Linux operation which changes the root directory of a specied program. As a result, this program cannot access any les outside of the new root directory, thus it is an appropriate method to run untrusted software. In 1997, Fred Cohen released the Deception Toolkit (DTK). The DTK is one of the

22

3.2. Honeypot History precursors of todays low-interaction Honeypots. The toolkit comprises a collection of scripts, that emulate a variety of known vulnerabilities. The main purpose of the toolkit is deception. For example, an old sendmail, a Linux mailserver, vulnerability is simulated, that hands out fake password les. Luring the attacker to spend valuable time cracking passwords that are not real. As a result, valuable time is won to track down and respond to an intrusion attempt, before a real productive system, that is susceptible to the vulnerability, is compromised [Coh97]. In the following year, the rst commercial Honeypot, called Cybercop Sting, was released. A software that runs on Microsoft Windows NT based computers and simulates an entire network, with dierent hosts, by replicating the IP stacks of various operating systems. Each of these emulated decoys runs its own simulated vulnerable services. The main disadvantage of this approach is the limited functionality of the services oered, thus there is no real interaction with the attacker [Pro01]. Another commercial Honeypot implementation released during 1998 was NetFacade. Like Cybercop Sting, it is capable of simulating a network of hosts running apparently vulnerable services. NetFacade is capable of simulating up to 255 hosts across both, class B and C address spaces [NFS98]. Despite the little commercial usage, it was a valuable tool in network based debugging and ultimately led to the development of Snort IDS by Marty Roesch. In 1999 the Honeynet Project [Pro05a] was founded. The non-prot group dedicated itself to research the blackhat community and to share the results with others. Furthermore, the commercial Honeypot implementation, ManTrap, which is now named Decoy Server, was released in 1999, as well [Sym99]. Decoy Server simulates a network with up to four dierent machines for an attacker to interact with. Additionally, it is capable of generating network trac and sending eMail between the simulated machines, to feign a real company network. Attack information is handled by dierent data analysis modules, which, in case of a threat, can even shutdown endangered systems. In 2002 the Tiny Honeypot program was released by George Bakos [Bak02]. The simple Perl based script listens on every TCP port, currently not in legitimate use, loggs all activity and provides some basic responses to commands issued by an attacker. The goal is to keep an intruder busy with a large number of fake services, so that additional intrusion detection mechanisms have enough time to trigger. Another interesting Honeypot concept, which was released in 2002, was the Google Hack Honeypot (GHH) [All02]. The Google search engine indexes huge amounts of data every day, which users can browse to nd useful information on the Internet. However, Google also indexes sites of miscongured web applications, which are not intended to be found and viewed by unauthorized persons, as they provide sensitive data, like credit card numbers. The GHH emulates such a vulnerable web application, which is indexed by Google, to nd out more about attacks against web sites and online shops. In the same year, another Honeypot related initiative was born out of the Honeynet Project, involving the whole security community to further Honeypot related research, the so called Honeynet Research Alliance. Several important tools emerged from this alliance, such as Snort_Inline, Sebek and virtual Honeynets, as well as the bootable

23

Chapter 3. Honeywalls and Honeypots Honeywall Roo, released in 2005 [Pro05c]. These tools are described in more detail throughout the chapter. More information about the history of Honeypots can be found in the work of [Tal05a].

3.3. Honeypot Classication

A Honeypot is a security resource with no productive value, i.e. in the normal case there should be no interaction occuring. Therefore, any observed activity is suspicious. Any outbound connection from a Honeypot means that it has been compromised. Inbound connections are most likely network probes, scans, or attacks. Honeypots can be classied by their level of interaction [CFM05].

3.3.1. Low-interaction Honeypots

The so-called low-interaction Honeypots are systems, which simulate network services with the help of software and feign the existence of active components, such as Telnet or a HyperText Transfer Protocol (HTTP) server. Since the emulated services do not oer full functionality, it is possible to implement services belonging to dierent operating systems on one Honeypot. Providing only limited functionality, low-interaction Honeypots are usually used to gather information on types of attacks and scans, which can be further used for creating alerts and attack signatures to form an early warning system. Additionally, they can be used to deect an adversary from intruding productive systems, by simulating a vulnerable host and pretending to be an easy entry point for an attacker, planning to break into the network [Ros03]. Low-interaction Honeypots provide a low risk method for capturing information on initial probes, as there is no full interaction with an attacker. Thus, they are easier to maintain and enable the collection of information in an automated manner. Nevertheless, they should be closely monitored, because low-interaction Honeypots are easier to detect, than for example high-interaction Honeypots, due to their limited functionality [Mue05]. Once their true purpose is revealed, they can be targets for attacks against possibly existing real vulnerabilities in the implementation of one of the emulated services. As a result, this could lead to a compromise of the system and loss of gathered information. One of the most common low-interaction Honeypots is Honeyd, developed by Niels Provos [Pro06b]. It is a small Linux daemon, i.e. a program that runs independently in the background, which creates a virtual host on a network, oering arbitrary services. The virtual host can be congured to appear as a particular operating system, thus, allowing a personalized setup to t the users needs. Honeyd features a plug-in system for easy extension and some helpful tools like Honeycomb, which can automatically generate intrusion detection signatures from the data captured at Honeypots [Kre]. Another low-interaction Honeypot is Nepenthes. In contrast to Honeyd, it aims at capturing malware in an automated manner. The emulated services allow as much interaction as is necessary for a worm or other malicious software to download itself to the system. As soon as a connection is established to an emulated service, the appropriate

24

3.3. Honeypot Classication vulnerability module is loaded to handle the incoming exploitation attempt. The payload send by an attacker is then analysed to extract any Uniform Resource Locators (URL) pointing to binaries, such as trojans, viruses or bots, which can be downloaded by Nepenthes. The gathered malware is stored locally for further analysis. Nepenthes is described in greater detail in chapter 4.

3.3.2. High-interaction Honeypots

High-interaction Honeypots are real commercial, o-the-shelf computers. Unlike a lowinteraction Honeypot, they run actual operating systems and fully functional services, just like in a productive environment. Therefore, high-interaction Honeypots are hard to distinguish from a normal computer, connected to the Internet. However, there still exist a few methods, that can reveal the Honeypot to an attacker, as described in the work of [DHK04] The advantages of such a solution are twofold. First, high-interaction Honeypots capture extensive amounts of information. By giving attackers a real system to interact with, complete burglaries and any of the tools involved in the compromises of the systems are logged. Thus, this approach allows an in-depth analysis on new techniques and software used. The second advantage is, high-interaction Honeypots make no assumptions on how an attacker will behave. Instead, they provide an open environment that captures all activity. This allows the maintainer of a high-interaction solutions to learn about behaviour one would usually not expect [Spi03]. As a result, new vulnerabilities can be discovered, the so called 0day exploits. With increasing interactivity, the risk increases simultaneously. As the attacker has full control over the Honeypot, it can be misused as a platform for further attacks. Therefore, high-interaction Honeypots need to be stationed behind a special entity called Honeywall, as described in the next section, to mitigate the risk. Table 3.1 recapitulates the main aspects of electronic decoys and reveals the dierences between low and high-interaction Honeypots. low-interaction Low No Low Connections/Requests No Medium high-interaction High Yes High Everything Yes Very High

Degree of Interaction Real Operating System Risk Knowledge to Gain Can be Conquered Maintenance Time

Table 3.1.: Summarized comparison of Honeypots Summarized, the main focus of high-interaction Honeypots is rather to capture manually executed attacks on computers, than automatically spreading malware. In contrast to low-interaction Honeypots, they serve more as a research system than an intrusion detection mechanism.

25

Chapter 3. Honeywalls and Honeypots

3.4. Honeywall Overview

Since Honeypots are intended to be compromised, they form a serious threat to the Internet or network they are stationed in. Therefore, it is crucial to protect other systems from being probed and attacked by compromised high-interaction Honeypots. To achieve the needed protection, Honeypots are placed behind a special entity called Honeywall. The Honeywall acts as a transparent network bridge [Sys99] between the Internet and the Honeynet. In order to mitigate the risk of the electronic decoys and facilitate the process of incident analysis and response, the Honeywall complies three main properties: Data control - The ability to modify or drop outgoing malicious trac to protect other resources on the network Data capture - All trac leaving and entering the Honeynet is logged to a centralized database for further investigation. Data analysis - All gathered data can be observed and investigated with the help of a web interface. In the following sections we describe each of the properties in more detail.

3.4.1. Data Control

As stated above, the purpose of data control is to protect other non-Honeypot systems in the network, by preventing an intruder to use a compromised Honeypot as a stepping stone for further attacks. With the help of data control, one is able to limit the outbound connections a Honeypot can establish, on the one hand, and disable known attacks by modifying outgoing packets, on the other hand. All data control is handled by the Honeywall, because it is a choke point for the attackers activity [Pro05b], as all outbound and inbound trac must ow through. IPTables To reduce the risk of a Honeypot being misused for attacks on other network resources, the number of connections that can be established from the decoy is restriced. However, an attacker is still able to download needed tools o the network. To limit the number of outbound connections per Honeypot, a packet ltering tool, called IPTables [Tea] is used at the Honeywall. IPTables is a command line program, applied to congure the Linux IPv4 packet ltering rule set, called Netlter. It is giving assistance to dene rules which every packet entering or leaving a system has to pass through. According to the target of an IPTables rule, packets can be dropped, logged or allowed. When every outbound connection from a certain Internet Protocol (IP) address is counted, it is possible to set up a rule that drops every other connection attempt as soon as a predened threshold of outgoing connections has been reached [Zie03]. The

26

3.4. Honeywall Overview main purpose of limiting the outbound connections is to decrease the risk of a Honeypot taking part in a Distributed Denial of Service attack (DDoS), mass scanning, or other activities that require many outbound connections. With IPtables it is possible to set a per protocol connection limit, i.e. it is possible to allow unlimited outbound ICMP, but only ten TCP connections. Figure 3.2 illustrates an example IPTables rule for limiting TCP connections. The rst and second row intruct IPTables to append the rule to the FORWARD chain (-A FORWARD) and to consider only TCP packets (-p tcp), that arrived via the network bridge (-m physdev physdev-in $HwLAN_IFACE) of the Honeywall, and belong to a new connection (-m state state NEW). The last two rows accomplish the limiting. The $HwTCPRATE parameter indicates the maximum number of packets, that are allowed to pass during a given time period, dened by the second parameter $HwSCALE. The time limit can be of any of the following kinds: second, minute, hour or day. The last row indicates how many packets can pass the interfaces until the above mentioned restrictions apply [Zie03]. iptables -A FORWARD -p tcp -m physdev --physdev-in ${HwLAN_IFACE} \ -m state --state NEW \ -m limit --limit ${HwTCPRATE}/${HwSCALE} \ --limit-burst ${HwTCPRATE} -s ${host} -j tcpHandler Figure 3.2.: IPTables rule to limit TCP connections The disadvantage of limiting the number of connections is that it can reveal the system as a Honeypot. An attacker might detect the trap by initiating outbound connections and waiting for them to be blocked, after a certain number has been reached. The number of connections allowed depends on how much risk one is willing to take, as well as, how much one wants to learn. Limiting the means of an attacker, restricts his activities and therefore, not all information about attack patterns or methods may be revealed [Pro05b]. Network Intrusion Prevention System The second step in data control is to modify or drop any known malicious outgoing trac. The reason for this is that not all attacks which can be initiated from a Honeypot, utilise many connections, and are therefore not blocked by the IPTables rules described above. For example, if an attacker has already decided on the next victim host to inltrate and knows the vulnerability to exploit. In this case he does not need to scan the network or probe machines for running services. Thus, the attack can consist of just a few outgoing connections, containing malicious payload. To prevent this kind of outgoing targeted attacks against vulnerable systems, it is possible to disable them in certain cases, as it is described later on. For this purpose a Network Intrusion Prevention System (NIPS) is utilised. A NIPS listens to a network interface and inspects all passing packets in real time. If a packet matches one of the Intrusion Prevention rules, an alert is sent out and, additionally, the packet can be dropped to block any outgoing attack or it can be modied to disable

27

Chapter 3. Honeywalls and Honeypots an attack. Both might lead to an early detection of the Honeypot, as an attacker can quickly determine, if an attack was successful or not. A major drawback of this method is, that it only works for known attack methods, i.e. a rule that matches the attack pattern needs to exist. Therefore, it is necessary to combine the Network Intrusion Prevention System with the limiting of the outbound connections [KGO05]. The common open source Network Intrusion Prevention System utilised by the current Honeywall implementation is Snort_ Inline. It has the capability to not only detect known attack patterns, but also generate the appropriate IPTables rules to block or modify them. Thus, it provides a proper rst defense line in protecting non-Honeypot systems from compromised and misused Honeypots. alert tcp any any <> any 80 \ (msg: "tcp replace"; content:"GET"; replace:"BET";) alert udp any any <> any 53 \ (msg: "udp replace"; content: "yahoo"; replace: "xxxxx";) Figure 3.3.: Snort_Inline rule to replace packet content Figure 3.3 illustrates two Snort_Inline sample rules to modify the content of network packets. These rules parse trac destined to TCP port 80 and UDP port 53 for occurances of GET and yahoo, regardless of the sender and destination IP addresses (any any <> any). Any matches are replaced with BET and xxxxx, respectively. Especially when dealing with bots, the modication of known commands is a useful measure to limit the risk of a Honeypot taking part in further attacks. For example, a common command to order a bot to perform a DDoS attack is: ddos.syn 192.168.xxx.xxx 80 600. In this case the zombie host should initiate a SYN Flooding attack on host 192.168.xxx.xxx and port 80, with a duration of 600 seconds. To disable such an assault, one can instruct Snort_Inline to modify packets containing to string ddos.syn to something arbitrary. Thus, the bot can not interpret the received command. For a detailed description of the Honeywall data control standards and requirements, established by the Honeynet Project Research Alliance, refer to [Tal05c] and [Pro05b].

3.4.2. Data Capture

Collecting information is the main purpose of deploying a Honeynet. This way it is possible to gather knowledge about intrusion techniques, tools and motives of an attacker, as well as, any further misuse of the Honeypot to gain access to other systems in the network. So the collected data forms the basis of all research and analysis. Therefore, it is highly intentional to have more than one logging mechanism installed to accumulate as much information about an incident as possible. Typically, data capture takes place outside of the Honeypots, at the Honeywall, by sning the network packets passing through. Since the Honeywall works in bridge mode, it is not accessible from any other systems, as there are no IP addresses assigned to the bridging interfaces. Thus, the

28

3.4. Honeywall Overview data capture mechanisms are hidden from any attacker and the stored data is safe from deletion or modication by an intruder [Mue05]. To safely maintain the Honeywall, it consists of an additional interface, called the management interface. Only hosts, which are connected to this interface are able to access the Honeywall and its data analysis features (Section 3.4.3). In case an intruder uses encrypted channels for communication, logging of network packets no longer suces. For this purpose additional software, which will be described later, has to be installed on each Honeypot, to capture data prior to the encryption. The main input for data capture is form the rewall and the log les of the Intrusion Prevention System (IPS). The rewall records all connections entering and leaving the Honeypots and stores the information on disk. These records include, for example, the source IP address and port the connection originated from, as well as the destination IP address and port of the targeted host. In case of an intrusion, it is possible to determine the attacker and derive the service exploited from the destination port that was addressed. Furthermore, the source IP address can be used to pinpoint the location of the attacking system, as certain IP address ranges are assigned to certain countries. Additionally, it is sometimes possible to determine the city, an attacking host originated from, by utilising the WHOIS service. This services is freely available in the Internet and provides useful information to a given IP address. One can even determine the operating system, that was used by an intruder, with the help of OS ngerprinting techniques, which are described later. The Intrusion Prevention System matches entering and leaving packets of the network against a list of known attacks. The IPS helps to distinguish malicious trac from normal system activity and alerts the system administrator in case of unusual activity. In contrast to the rewall, the IPS saves the payload of suspicious packets. Thus, it is possible to examine the content of any received packet for uncommon strings to learn how the attacker nally gained access to the system [Tal05b]. In addition to these common capturing methods, a few other, more specialised services are running on the Honeywall: p0f - passive OS ngerprinting Argus - Audit Record Generation and Utilisation System Swatch - Simple System Log watcher Sebek server - Collect data from the Honeypots OS Fingerprinting When collecting data about an incident, it is of interest to know what kind of operating system an attacker uses. The common way to remotely determine an operating system of another host, is to examine the headers or banners of services oered by the host, one wants to identify. Tod Beardsley [Bea02] uses a dierent identication method, by measuring the intervals between repetitive sending of packets with the TCP ags SYN and ACK set during connection establishment. The SYN+ACK packets are part of the

29

Chapter 3. Honeywalls and Honeypots three-way handshake when connecting to a service on a host. The host initiating the connection sends a single packet with the SYN ag set. The server then replies with a SYN+ACK packet, where the SYN signals the server is ready for a connection and the ACK acknowledges the SYN received by the client. To complete the handshake the client sends one last packet with the ACK ag set. If this last reply is skipped, the server will resend his last packet after a certain timeout. The time between those resends is the so called Retransmission Timeout (RTO), which is measured. This method was rst published by Franck Veysset, Olivier Courtay, and Olivier Heen in April 2002 [VCH02]. Another technique is to send a number of malformed packets and analyse the reaction of the remote host. For more detail on this refer to [Fyo02]. The techniques described above, are also called active ngerprinting, as it involves interaction with the target machine. Passive ngerprinting follows the same concept, but it is implemented dierently. Since one does not want an attacker to notice that his system is being probed, one cannot actively query the remote operating system. Thus, passive ngerprinting utilises captured packets rather than replies to specially crafted packets. Based on snier traces of those packets, one can determine the operating system of the remote host. Figure 3.4 shows an example of a snier trace. To keep it simple, we concentrate on the following four settings, which can be used to remotely identify an operating system: Time To Live (TTL) Window Size Do not fragment bit Type of Service (ToS) There are other values, which can be used as well, like the initial sequence number, IP identication numbers or dierent TCP/IP options. However, by combining a variety of dierent packets and values, the remote system can be reliably approximated, by just using the four parameters above. 07/08-13:33:45.129721 192.168.xxx.xxx:6596 -> 192.168.xxx.xxx:514 TCP TTL:45 TOS:0x0 ID:58347 ***F**A* Seq: 0x9DD90553 Ack: 0xE3C65D7 Win: 0x7D78 Figure 3.4.: Snier trace The detection process is based on the fact, that each operating system sets dierent values for the above mentioned parameters. For example, if the TTL value was initially set to 64, it is likely to be a Linux or FreeBSD system, from which the packet originated. On the other hand, if the Window Size constantly changes, it is more likely to be a Microsoft Windows system. As a result, one can compare the gathered information to a database of operating system signatures, to determine the remote host. One tool that oers the option of passive ngerprinting is p0f [Pro02], which is part of the Generation III Honeywall Roo.

30

3.4. Honeywall Overview Audit Record Generation and Utilisation System (Argus) Argus is an IP transaction auditing tool, that categorizes IP packets, which match a boolean expression, into a protocol-specic network transaction model [Bul00]. Monitoring the trac ow in real time, Argus analyses and reports the status and performance of all network transaction seen in the trac stream. The reports include connectivity, capacity, demand, loss, delay and jitter on a per transaction basis. Argus can not only monitor live interfaces, but can also be used to analyse packet capture les. At the Honeywall it is used for a joint evaluation of the rewall and Intrusion Detection System log les. For more details on trac ow measurement refer to [HSBR99] Swatch Swatch (Simple WATCHer of Logles) is a tool, which is implemented in the programming language Perl, that monitors log les while they are written. Every new line in the log le is matched against some user-dened regular expressions. As soon as a match is found, Swatch can execute another software with the line contents as parameters. Therefore, it is possible to notify the administrator as soon as an important incident happens, which requires human interaction. This is the case, if one of the Honeypots starts to establish outbound connections, which is a true evidence that a Honeypot has been hacked. The automated notication is helpful wherever huge amounts of log message appear. Figure 3.5 presents an example of a Swatch rule, which monitors SSH login attempts. In this example, it parses a given log le for the occurance of Invalid User, whereas the leading characters are case-insensitive. As soon as, a match is found, Swatch sends an eMail with the subject SSH: Invalid User and the found log line as the message content. Finally, it executes IPTables to drop all further incoming packets, originating from the host, which failed to login. #Invalid SSH Login Attempts watchfor /: [iI]nvalid [uU]ser/ mail addresses=root\@localhost.net,subject="SSH:\ Invalid\ User" exec "/sbin/iptables -A swatch-rejects -s $10 -j DROP" Figure 3.5.: Swatch rule More information on Swatch can be found at the ocial website [Atk]. Sebek Server One of the most important software tools used in data capture is Sebek. Once an attacker has control over a Honeypot, it is important to observe all actions performed on the machine, as well as any output provided by the tools installed by an attacker. Sebek accomplishes this task, by intercepting specic system calls at the kernel level.

31

Chapter 3. Honeywalls and Honeypots As long as commands and program output are send in plaintext over the network, there is no need for any additional capturing software, than the one described above. If an adversary uses encryption software to hide his actions, capturing data between the sender and receiver is no longer of any use. Without the encryption key one cannot decrypt and read the captured information. To circumvent this problem, a clientside logger was developed, called Sebek. The Sebek client runs on all Honeypots as a part of the operating system, intercepting system calls at the kernel level. It utilises techniques similar to those used by kernel-based Rootkits. A typical Sebek deployment is illustrated in gure 3.6. The attacker has initiated an encrypted communication channel to one of the Honeypots. However, the installed Sebek client provides us with a complete decrypted copy of the trac, which is covertly exported to the Honeywall.

Figure 3.6.: Typical Sebek deployment [Pro03b] The project started out as a modication of the Adore Rootkit, that uses a trojaned system call (sys_read) to capture keystrokes at the infected host. Instead of executing the real system call, the one provided by Sebek is called, which stores the captured keystrokes and sends them directly via the raw socket implementation to the Sebek server. Additionally, the le and process hiding, that is implemented in the Adore Rootkit, through the use of patched system calls, is here used to conceal the activities of the Sebek system. The Sebek server, running on the Honeywall, is able to collect and display the captured information, exported by the Sebek clients. Thus, one is able to capture commands before they are encrypted, providing the possibility to accurately reconstruct the events on the Honeypot [Pro03b]. Figure 3.7 illustrates the process of system call redirection. The redirection of system calls is implemented by overwriting the appropriate entry in the Syscall table with the memory address of a custom handler. In the illustrated case, the table is modied to point to the New_Read function of the Sebek Kernel Module. Whenever a program calls the read function, it will now execute the redirected function. At this point, the provided parameters and values are send to the Data logger, which is responsible for transmitting the data to the Sebek server. Furthermore, the original read

32

3.4. Honeywall Overview

Figure 3.7.: Sebek read system call redirection [Pro03b] function is executed, to provide the calling user program with the necessary information to move on. As a result, all entered data is captured without being noticed by the attacker. To hide the additional trac generated by the Sebek clients, the network packets are extended with a previously chosen magic number. Furthermore, the socket implementation of the Honeypots is modied to silently drop incoming trac marked with this number. Additionally, the Honeywall ensures that none of those packets leave the Honeynet, therefore the extra trac is not visible for an attacker. There are, however, techniques to detect the presence of Sebek. Most of them are based on common Rootkit detection and are discussed in greater detail in the work of [DHK04]. More information on data capture mechanisms and tools can be found in the work of [BV05].

3.4.3. Data Analysis

Figure 3.8.: Trac Overview

33

Chapter 3. Honeywalls and Honeypots To visualize the collected information, the Honeywall runs a webserver, that is accessible over a Secure Socket Layer (SSL) encrypted connection via the management interface. The Graphical User Interface (GUI), called Walleye, oers an easy approach to congure and maintain the Honeywall. Almost all aspects that were congured during the Honeywall installation can be modied with the help of the web interface. Additionally, data analysis capabilities are integrated in Walleye, which allow to track and analyse all Honeypot activities. Figure 3.8 shows an overview of all inbound and outbound trac of the past 24 hours. Thus, one can quickly determine from the trac graph, if any incident has happened, for any outgoing trac is suspicious. Outgoing trac is marked yellow, whereas incidents reported by the IPS are highlighted in red. Sebek data can be viewed with Walleye in form of process graphs, as show in gure 3.9. The graphs provide an accurate overview of the actions taken at the Honeypot, as well as, the programs which were executed. For an in-depth analysis of captured data, it is possible to extract network connections in PCAP format, the standard format for captured packet data. Thus, one can make use of other tools, such as WireShark [Com06] (formerly known as Ethereal), to visualize and browse through the collected information. WireShark is a program for the Microsoft Windows operating system that is capable of reading and displaying les in PCAP format. Furthermore, special lter rules can be applied to blind out unimportant information.

Figure 3.9.: Sebek process graph

3.5. Building a Virtual Honeynet

Roo is the current collection of tools provided by the Honeynet Project, which form a complete implementation of a Generation III Honeywall. Accordingly, it accomplishes the three main tasks of a Honeywall: data control, data capture and data analysis.

34

3.5. Building a Virtual Honeynet

3.5.1. Honeywall Roo

As described in the previous chapter, various distinct tools, like Snort, Sebek and p0f, are used to accumulate information from the Honeynet. For these tools are usually not designed to interact with each other, they all produce dierent output of collected data in an incompatible format. In case of a successful compromise of a Honeypot, it takes a lot of time and eort to gather all the data related to the incident, i.e. one has to parse through all logles manually, extracting the related information in order to get a comprehensive overview about what happened. Roo is able to collect all this information from the individual sources and proportion it in an automated manner. The combined data is then stored in a single centralized database for further investigation, e.g. with the help of the web interface, Walleye. Thus, it is possible to easily view attack patterns or even complete process trees of actions taken on Honeypots which are currently under control of an attacker. Roo is available at the Honeynet Project homepage and is under constant development [Pro05c].

3.5.2. Installation and Administration

As the Honeywall is the heart of the Honeynet, it should be carefully installed and extensively tested, before deploying it. Therefore, a more detailed description of the installation process and the conguration of the Honeywall Roo is presented. With the help of this tool collection, a complete Honeywall can be set up within a couple of minutes, as the setup program is straightforward. The bootable CD-ROM hosts a Fedora based Linux, modied to t the needs of a Generation III Honeywall. At least two network interface cards (NIC) are required to run the Honeywall, but three is the better choice. Two are used to build the transparent layer 2 network bridge and the optional third one, called management interface, provides secure shell (SSH) access to the Honeywall itself, as well as Secure Socket Layer (SSL) access to Walleye, for administrative and analysis tasks. The bridge relays the network trac from the gateway to the Honeypots and vice versa. In contrast to a normal bridge, the Honeywall may modify Internet packet content, in case an outgoing malicious packet is detected. This prevents the Honeypots from taking part in known attacks on non-Honeypot systems, as it was described in the data control section. Roo is not a Live-Linux distribution, which means it does not run directly from a Compact Disc (CD), but needs to be installed on a harddisk. The dialogue-based installation wizard guides one through the setup process. Among the needed information during the installation are the Internet Protocol (IP) address of the gateway, in order to access the Internet, a range of IP addresses designated for the individual Honeypots, as well as a couple of IP addresses that are allowed to access the Honeywall via the management interface. The latter should be carefully selected, as these will be the only systems able to access the Honeywall directly after a successful installation. All congurations done to the system during the installation can later be adjusted via the web interface, making it easy to adapt the Honeywall, as new Honeypots join the Honeynet or compromised systems are taken oine for further investigation. Addition-

35

Chapter 3. Honeywalls and Honeypots

Figure 3.10.: Walleye Conguration Overview ally, restrictions applying to outbound connections, for systems currently under control of an attacker, can be adjusted. Figure 3.10 shows the conguration screen of Walleye. Some of the more important settings include: Remote Management: List of IP addresses that are allowed to remotely access the Honeywall and what ports can be used for that. The default ports are 22 for SSH and 443 for HTTP over SSL. Furthermore, the Honeywall itself can be restricted to only access certain systems, like a predened Domain Name Service (DNS) or File Transport Protocol (FTP) server. Connection Limiting: Congure the number of allowed outgoing connections for the Honeypots on a per protocol basis. Additionally to the number of connections, the time interval, in which this threshold must not be reached, can be dened. For example, ten TCP connection per hour. After this limit is reached, the Honeywall will block all further connection, allowing only one connection every six minutes. Alerting: Set an eMail address, to receive an alert message as soon as one of the Honeypots initiates an outgoing connection. Black and White List: These lists hold IP addresses or ranges of systems that are either allowed to enter the Honeynet or not. In both cases the Honeywall ignores the trac, meaning there will be no rewall logle entries. Sebek: Congure the port, on which to listen for incoming Sebek packets and whether these packets should be dropped or not. Sebek is the kernel module, that runs on each of the Honeypots to capture keystrokes on a compromised system. Roach Motel Mode: If the Roach Motel Mode is enabled, all outbound trac from the Honeypots will be blocked. Fence List: List of IP addresses or ranges, to which Honeypots are not allowed to initiate connections to, i.e. the rewall drops and logs any connections to these hosts. This is useful, for example, to protect a productive network from compromised Honeypots.

36

3.5. Building a Virtual Honeynet The installation process constitutes all necessary services like Sebek, p0f or Snort_Inline. Keeping ones Honeywall up to date is easily done, utilising the Fedora packet manager yum (yellowdog updater modied). A special Honeynet repository takes care of the various Honeywall specic software. The command yum update initiates the update process. Although this feature supports the maintenance of a Honeywall a lot, it can also lead to problems relating to directory or le permission changes due to Fedora Core based updates. These problems have been eliminated with the current version of Roo. After the successful installation, there are some common settings, which need to be adjusted. This includes changing the keyboard layout and the timezone, as well as the default passwords for the local root user and the user of the web interface. During the time of the diploma thesis, we installed the Honeywall software on a dual PentiumIII computer, with three network interface cards installed and 2GB of memory. To store all collected information, a 40GB harddisk was used. This is the minimum hardware requirement to use with Roo. Therefore, the performance was rather slow and we suered big delays while processing incident data. Moreover, we were not able to display the Sebek process tree of all compromises while maintaining the Honeynet. As a result, we often had to manually extract the actions performed on the Honeypots from the PCAP les, which is a very time-consuming task.

3.5.3. Operating Roo

Figure 3.11.: Walleye Overview Besides the system administration, Walleye also facilitates the data analysis process, i.e. it is possible to monitor each individual Honeypot while operating. Figure 3.11 shows the main screen of the Honeywall web interface. It gives a short summary about

37

Chapter 3. Honeywalls and Honeypots what was going on in the past 24 hours. This includes the number of connections to and from the Honeypots, as well as, the number of intrusion detection events that were triggered. The menu on the lower part of Figure 3.11 allows the extraction of detailed information about certain connection events, e.g. all connection originating from a port >1024 with destination IP address 192.35.xxx.xxx and target port 445. The output of such a query can either be viewed with Walleye (Figure 3.12) or downloaded as a le in PCAP format, to be furthered analyse with the help of dierent tools, like WireShark [Com06].

Figure 3.12.: Walleye Flow View Figure 3.12 also exemplies how much detail Walleye oers about incidents. One of the main advantages is the correlation of the data, to give a general view of an attack [Kel06]. Additionally, the Honeywall oers the possibility to send out eMail alerts about outgoing connections from the Honeypots. Thus, allowing the administrator to stay informed about any incidents happening in real time. Figure 3.13 illustrates the content of such a message, regarding an outbound TCP connection of one of our Honeypots. These messages are generated with the help of Swatch, which is described in section 3.4.2.

Figure 3.13.: eMail warning about an outbounded TCP connection

38

3.5. Building a Virtual Honeynet

3.5.4. Virtual Honeynet

To set up a Honeynet, one needs to deploy some machines, to serve as Honeypots. These can either be several physical computers or one physical computer with several virtual machines, a so called virtual Honeynet. According to [Pro03a], virtual Honeynets can be divided into two categories: Self-Contained Virtual Honeynet: The entire Honeynet network is condensed onto a single computer. Hybrid Virtual Honeynet: The Honeywall resides on a separate system, whereas the Honeypots run each in their own virtual machine on a single host. The kind of operating system installed on a machine depends on the type of Honeynet, that is to be deployed. In a production Honeynet one is limited to the software used in the network one wants to simulate, whereas in a research Honeynet one has free choice in software. The machine running the virtualisation software is referred to as the host and each virtual machine represents a guest. In this thesis we build a research Honeynet, with dierent operating systems, to have a wide variety of vulnerabilities from which information about exploits can be gathered. We limit ourself to Linux and Windows based Honeypots. Additionally, we use the virtualisation software VMWare [Ser] to build a hybrid virtual Honeynet, reducing the needed physical computers besides the Honeywall to one. Figure 3.14 shows the setup of the GenIII virtual Honeynet, which is currently deployed at RWTH Aachen.

Figure 3.14.: GenIII Honeynet setup at RWTH Aachen Using VMWare or another virtualisation software as a basis for a Honeynet and following the approach of a hybrid virtual Honeynet, has some advantages: It is more secure than the self-contained approach. An attacker cannot compromise the Honeywall in case of security issues in the virtualisation software. Several Honeypots can be installed on one single machine, thus, saving money and resources.

39

Chapter 3. Honeywalls and Honeypots VMWares snapshot function allows easy reintegration of previously compromised systems, after the forensic analysis is completed. On the other hand, there exist some ways for an attacker to identify the system as a virtual one, thus, revealing the trap [HR05]. Once the adversary detects the virtualisation software, he might cancel his actions or try to compromise the host system itself. As we are running a research Honeynet, learning how someone identied the Honeypot is also worth knowing. The VMWare installation is rather straightforward. Given the needed kernel headers, the script asks a few questions, of which those about the virtual network are the most important ones. For example, one needs to specify if the VMWare acts as a bridge and if the virtual machines are to be accessible from outside. After the successful installation of VMWare, for each virtual Honeypot, a new virtual machine has to be created. An easy to use wizard guides through the necessary steps. To nalise the setup of a virtual Honeynet, a guest operating system has to be installed on each virtual machine, either from a CD or from a CD image. The host system running VMWare is supposed to have a sucient amount of free memory available, as there will be several guest systems running simultaneously. Our setup includes three virtual machines running Linux based Honeypots, each using 128 MB of memory and one virtual machine running a Windows based operating system with 256 MB of memory. Each Honeypot allocates 6 GB harddisk space. As we usually do not need to install more than a few additional applications, this should suce for a common out of the box installation. Setting up a credible Honeypot is, next to the maintenance, the most time consuming part when deploying a Honeynet, as operating systems and several dierent applications need to be installed and congured. Especially, web application are not always vulnerable per default, some require a certain conguration, e.g. turning PHPs safe mode o. There are no good ways to automate this part, as it was done with the Honeywall, for uniformity turns Honeypots into an easy target for detection. Therefore, customizing the Honeypots is an essential step in the Honeynet deployment. For this reason, we installed several dierent applications on the Honeypots, making each one a unique target for an attacker. Additionally, this gives an intruder the opportunity to exploit dierent vulnerabilities to gain root access. The most important modication applied to all our Honeypots, is the installation of the Sebek client software [Pro03b]. In order to properly install it on the Honeypot, a kernel version number 2.4.18 or above, including the according source les is required. The conguration le provides a test parameter, which gives the opportunity to extensively verify the proper setup, as in this case the hiding mechanisms of the Sebek kernel module are disabled. If the Honeypot is not yet connected to the Honeywall, a tcpdump on the VMWare host system should show the Sebek packets passing through. For a complete description of how to set up the Sebek version 3 client software refer to [Sil06a] and [Sil06b].

40

3.5. Building a Virtual Honeynet Honeypot: Linux Red Hat 8.0 The rst deployed Honeypot runs a Red Hat 8.0 Linux with kernel 2.4.18, which is vulnerable to the ptrace exploit described in section 2.5.2. The operating system was released in 2002 and therefore contains a number of known security risks. In addition to the basic installation, a Washington University (wu-ftpd) FTP server v2.6.0 was set up. The Washington University FTP server is known to have several vulnerabilities, thus, it should be an easy target for an attacker to take control of this system. Particularly, version 2.6.0 is vulnerable to a remote attack in the SITE EXEC implementation, which leads to a buer overow. Thus, it is possible for an attacker to execute commands with root priviledges [oIS04]. We modied the basic installation to allow upload of arbitrary les to everybody. Furthermore, an Apache webserver v2.0 with PHP v4.3.0 support and a MySQL database server v3.28.58 were installed, which form the basis of all common web applications. As a web application, the Horde Application Framework version 3.1 was set up. This particular software version suers a remote code execution vulnerability in the help viewer. Therefore, an attacker is able to upload and run arbitrary tools in the context of the webserver process to compromise the host [Sec06a]. Honeypot: Linux Suse 9.1 The second Honeypot set up runs a Suse 9.1 Personal Linux with kernel 2.6.4. Released in 2004, the system is more up to date, oering the opportunity to investigate more recent exploits. In addition to the base system, an Apache webserver v2.0.49 with PHP v4.4.2 support, a MySQL database server v4.1.18 and the database administration application PhpMyAdmin version 2.5.6 was set up, which was heavily targeted by automated attacks in the last weeks. Due to insuciently sanitized user-supplied data, an attacker can execute arbitrary commands in the context of the webserver, thus, leading to a compromise of the host [Sec04]. To minimize suspicion, we set the MySQL root password and lled the database with some fake data. We also created a website, stating that a new company will publish their web content soon. Additionally, we set up the web application phpAdsNew version 2.0.5. It can be exploited by an attacker to execute arbitrary commands, due to an unspecic error in the XMLRPC library [FrS05]. Honeypot: Windows XP SP2 The third Honeypot in our setup runs a Windows XP with service pack 2 installed. Running the most up to date system, we did not expect to investigate much activity here. However, as we are running a research Honeynet, we also wanted to be able to detect unknown vulnerabilities (0day). To make the target more interesting for an attacker a shared directory was provided with read and write permissions set for anybody. Additionally, the warFTPd Daemon version 1.82 RC10 has been installed, which is vulnerable to a remote buer overow. Passing excessive data may overow a nite-sized internal memory buer, which may lead to the execution of arbitrary code [Sec06e].

41

Chapter 3. Honeywalls and Honeypots Honeypot: Fedora Core 3 The last Honeypot set up runs a Fedora Core 3 Linux with a 2.6.12 kernel. The services installed comprises the Apache webserver v2.0.52 with PHP v4.3.9 support, the MySQL database server v3.23.58 and three dierent web applications. The rst, phpListPro version 2.0.1, is prone to a remote le-inclusion vulnerability, due to unproperly sanitized user data. An attacker can exploit this vulnerability to execute malicious PHP code in the context of the webserver process [Sec06d]. Next, is the Russcom Ping application, which does not properly validate user-supplied input and, thus, is vulnerable to arbitrary remote command execution [Sec06c]. Finally, we installed the NewsPortal software version 0.36, which has a remote code injection vulnerability. An a attacker can exploit this issue to execute malicious PHP code in the context of the webserver process [Sec06b].

3.6. Lessons Learned

The Honeynet was put into operation on February 13th, 2006. Although none of the IP addresses of the Honeypots had been made public, the rst wave of automatic scans hit the Honeynet about 20 minutes later. Figure 3.15 show three of those scans against the Windows based Honeypot. Due to the fact that this system is almost up to date, none of these attacks led to a compromise of the machine.

Figure 3.15.: Trac inspection with Walleye However, not all network trac regarding a Honeynet can be considered as malicious. According to [KGO05] we can categorize the network trac into three dierent types: Trac generated by the Honeypot due to normal network operations, like querying the timeserver Worms and other automated adversaries scanning for vulnerable machines on the Honeynet Human attackers trying to gain access The rst category includes all kinds of network trac originating within the Honeynet, and belonging to the usual trac, like the le sharing propagation service of the Windows Honeypot or the hourly system time update. The communication with the Domain Name Service (DNS) to resolve domain names of machines trying to connect, generates trac as well, which cannot be categorized as malicious.

42

3.6. Lessons Learned The second category refers to already infected machines on the Internet, scanning for new vulnerable systems to take over. In most cases these are worm contaminated machines, trying to spread further. They use all kind of automated scanning techniques and exploits, to propagate themselves across the network. A common way seems to be the Netbios Server Message Block (SMB) protocol which is used for le or printer services in several network services, like Microsofts LAN Manager for the Windows product family or Samba for Unix-based systems. Additionally, the exploiting of vulnerable web applications, like PHP-based web forums has gained much popularity lately. As soon as access to a system is granted, the worm downloads and installs itself on the newly compromised system. Consequently, the propagation mechanism is activated to continue infecting other hosts on the Internet. Capturing a worm helps to get hands on these techniques, which can be further analysed to disable the exploited software aws. The last category is the one we are most interested in, as it provides the most information on methods and tools, involved in successfully conquering vulnerable machines. In contrast to automatically spreading malware, human attackers usually utilise new and unknown vulnerabilities to compromise a system. We can distinguish two groups of human attackers according to their motives. The rst are the ones usually paid to hack into corporate systems, to steal valuable information. These kinds of attacks are carefully planned and the target host is carefully selected, thus, it is very unlikely to hit a Honeypot. This group contains the high-level attackers. The other group compromises computer systems to either have fun or make prot, by selling the combined computing power or bandwidth of a so called botnet. The main dierence is that they do not attack predened targets, but scan the whole Internet for vulnerable systems with automated tools and, therefore, frequently hit our Honeynet. This group comprises the low- and medium-level attackers. Throughout the diploma thesis, our Honeypots were successfully compromised seven times. Thus, we had an average of one compromise per month. The most frequent hacked Honeypot was the Red Hat based Linux system, with four successful take overs, closely followed by the Suse system, with three. Unfortunately, neither the Microsoft Windows nor the Fedora based Honeypots were compromised during the time of the diploma thesis. One reason might be the high patch level of the Windows system, with few additional service applications installed. Another reason could be the relative new vulnerable applications, installed on the Fedora machine, with no or only a few exploits in the wild. Furthermore, the Fedora Linux Honeypot was put into operation just one month before the end of the diploma thesis. During the attacks we were able to retrieve many dierent tools that were used to either conquer or misuse our Honeypots. Among the collected applications are several SSH brute force scanners with the according username and password lists, a few Rootkits that were used to hide the tracks of the intruder, and two phishing kits. A phishing kit includes tools and complete websites, to quickly set up a phishing site on a compromised host. Additionally, it contains spamming software to automate the mass mailing process to lure victims. Two selected compromises that were observed during the time of the diploma thesis are presented in more detail in the following section. Besides the actions that were taken on the Honeypot we provide a thorough analysis of the tools that were used by the attackers at the end of each incident.

43

Chapter 3. Honeywalls and Honeypots

3.6.1. Suse Honeypot Compromise

On May 5th 2006 our Suse 9.1 based Honeypot was attacked and successfully compromised by exploiting a vulnerable web application, the Horde Application Framework. The vulnerability could be exploited by a remote attacker to execute arbitrary commands with the privileges of the running Apache webserver process. This aw is due to an input validation error in the help viewer of the application. The vulnerability was rst discovered in March 2006 and aects all Horde Application Framework versions prior to 3.1.1. Attack Summary The hostname of the compromised Honeypot was master and it was running with the IP address 192.35.xxx.xxx at that time. The attacker used three dierent hosts to connect to our Honeypot. The rst oending machine was a Linux system with the IP address 125.241.xxx.xxx, positioned in Seoul, Korea. The second machine, with the IP address 82.79.xxx.xxx, is located in Bucharest, Romania and the last computer, with the IP address 172.162.xxx.xxx, seemed to be positioned in Dulles, Virginia. For the last two we were not able to determine the running operating system. Although the attacker was able to execute arbitrary commands on the Honeypot and, therefore, could download and install any kind of local root exploit, no attempt was made to gain root privileges. Instead, the webserver account was misused to install an eBay phishing site and a PHP script for eMail sending. The attack started on May 5th at about 14:30 p.m., when the intruder scanned our Honeynet for vulnerable Horde Application Framework software. The rst remote command to be executed by the attacker was id, a Linux command to display privilege information about the executing user. In this case, it showed the user and group identication of the running Apache webserver. Only two dierent tools were downloaded to the Honeypot during the attack, a PHP script designed to send SPAM or phishing mails, with replaceable message body and recipient list, containing the subject Question from eBay Member and the sender address eBay Member <member@eBay.com>. The second tool contained the actual eBay phishing site, together with a script to send the entered username and password combinations to a specied eMail address. When we discovered the presence of the phishing site, it was decided to take the Honeypot oine, to prevent innocent users from being take in by the fake eBay site and entering their credential information. According to the Honeywall logs, no other than the attacker himself visited the prepared website, nor was any SPAM or phishing mail sent via the installed PHP script. Following, we take a closer look at the actions that were performed to compromise and further misuse the Honeypot. Each event is marked with its initial timestamp to present a complete timeline of the attack.

44

3.6. Lessons Learned Attack Details May 5th 2006 14:30:19 p.m.: The host 125.241.xxx.xxx connected to the webserver of the Honeypot for the rst time, executing the remote command id, by exploiting the known Horde Application Framework vulnerability. The command displayed the group and user identication number of the Apache webserver. 14:30:26 p.m.: The remote command pwd was executed to determine the path to the currently displayed website. 14:30:48 p.m.: The attacker issued the wget command to download a le named 111.zip from the URL http://66.218.xxx.xxx/isdulce/sex/, but failed to do so, for the le did not exist at this location. 14:30:54 p.m.: The remote command ls was executed to show all les in the current directory of the webserver and verify if the above initiated download was successful. 14:32:37 p.m.: The intruder managed to download the le 1111.php.zip from the URL http://217.113.xxx.xxx/marianne/. The archived le contained the PHP script for sending eMail. 14:32:46 p.m.: The attacker issued the remote command unzip 1111.php.zip, to extract the compressed le to the current webserver directory. 14:34:42 p.m.: First connection of the second hostile host 82.79.xxx.xxx to the freshly installed PHP mail script. GET /horde/services/help/1111.php/1111.php. 20:25:22 p.m.: The third host 172.162.xxx.xxx connected to the PHP mail script for the rst time. GET /horde/services/help/1111.php/1111.php. 20:48:51 p.m.: Another connection from 125.241.xxx.xxx was made and the remote command rm -rf 1111.php/ was executed by the attacker. As a result, the PHP mail script has been deleted. Since none of the prior connection to the script did send any eMail, it probably was not working correctly. 20:49:01 p.m.: The intruder downloaded another le to the compromised Honeypot, named eb.zip, from the URL http://217.113.xxx.xxx/marianne/. The compressed le contained the eBay phishing site. 20:49:06 p.m.: After successful downloading of the phishing site, it was extracted to the current web folder by executing the remote command unzip eb.zip. 20:49:19 p.m.: The attacker downloaded the PHP mail script again from the same location as before and decompressed it just a few seconds later.

45

Chapter 3. Honeywalls and Honeypots 20:49:33 p.m.: A connection from the host 82.79.xxx.xxx was established to the freshly installed eBay phishing site. GET /horde/services/help/eb/ws/eBay.... 20:50:18 p.m.: The third oending host connected to the phishing site, as well. These connections are probably made to verify the correctness of the installed scripts and the website. GET /horde/services/help/eb/ws/eBay.... 21:17:37 p.m.: A connection from the host 82.79.xxx.xxx to the PHP mail script was established. GET /horde/services/help/1111.php/1111.php. 22:56:14 p.m.: The host 172.162.xxx.xxx connected to the PHP mail script. GET /horde/services/help/1111.php/1111.php. 22:56:33 p.m.: The host 172.162.xxx.xxx connected to the eBay phishing site. GET /horde/services/help/eb/ws/eBay.... At this point it was decided to take the Honeypot oine to perform a more detailed analysis of the machine itself and to prevent other Internet users from getting harmed. Tools Involved This section describes the tools that were downloaded to the compromised Honeypot and used by the attacker to establish the eBay phishing site, as well as, the SPAM or phishing mail sending PHP script. Phishing URL: eBay URL:
/eb/ws/eBayISAPI;dllSignIn&co_partnerId=2/pUserId=. . . /signin.ebay.de/ws/eBayISAPI.dll?SignIn&co_partnerId=2&pUserId=. . .

Figure 3.16.: Phishing URL and real eBay URL

1111.php.zip: The compressed le extracts to a directory called 1111.php and contains a single PHP le, with exactly the same name as the created directory. The script can be used to send SPAM or phishing mails to various recipients, utilising the PHP function mail() as shown in gure B.1. The subject of all outgoing eMails was set to Question from eBay Member and the sender address to eBay Member <member@eBay.com>. When executing the script via a web browser, two text elds and a submit button are presented to the user. The rst text box is used for the message body, which should be used for each mail. The second text box receives the list of recipient addresses, all mails will be delivered to. Thus, the script is highly customizable, and can be adapted to dierent phishing pages. In fact, when we downloaded the script from the same location as the attacker, the subject and sender parameters were still set to phishing mails destined for Amazon customers.

46

3.6. Lessons Learned eb.zip: This le contains the actual eBay phishing site and an additional PHP script to send any entered username password information to a predened eMail address. When extracting the zip le, it creates four subdirectories. The rst is called eb, the second ws and the latter two contain words and characters to make the victim believe it is visiting the real eBay site (Figure 3.16). Figure B.2 shows the script that is executed upon entering login information on the fake eBay site. After successful submission of the data, the victim is redirected to the real eBay site, stating that the entered password information were wrong. Upon reentering the username and password, this time on the real eBay site, the user can successfully login, thus, no suspicion is raised.

Figure 3.17.: The eBay phishing site

Attack Evaluation One can conclude from this intrusion, that it is not always necessary to gain complete control over a system or even login to it, in order to misuse the attacked host for illegal purposes, such as phishing. Although the attacker was able to execute arbitrary commands on the victim host, no attempt to gain root privileges was undertaken. Instead, the privileges of the webserver suced to setup and run all necessary tools of the intruder. On the one hand, this behaviour can be seen as a wise proceeding, leaving as little traces on the compromised system, as possible. On the other hand, there are marks of the attackers actions left on the Honeypot. The Apache error log shows every single download that was initiated by the intruder to get his tools.

47

Chapter 3. Honeywalls and Honeypots Considering the short time slot, during which the initial attack happened and the fact that a non-Honeypot webserver is far less monitored and generates much more network trac, these log entries are easily overlooked. From this point of view, it is a very ecient attack, with little chance of being noticed. Finally, we can classify the attacker as being only little experienced, as he tried to download a non existent tool, set up the same script twice and checked back to his phishing site several times.

3.6.2. Red Hat Honeypot Compromise

On May 7th 2006 our Red Hat 8.0 based Honeypot was attacked and successfully compromised, by exploiting a vulnerability in an installed web application, named phpAdsNew. The vulnerability allows a remote attacker to execute arbitrary commands, with the privileges of the webserver on the victim host. This aw is due to an unspecied error in the XML-RPC library for PHP. It was rst discovered in July 2005 and aects all phpAdsNew versions up to 2.0.5. Attack Summary The hostname of the compromised Honeypot was clooney and it was running with the IP address 192.35.xxx.xxx at that time. The attacker used four dierent hosts to interact with our Honeypot. The rst oending system had the IP address 72.29.xxx.xxx, which is located in Orlando Florida. The next computer that was used during the attack, with the IP address 83.104.xxx.xxx, is positioned in Great Britain and the last two machines, with the IP addresses 86.107.xxx.xxx and 81.181.xxx.xxx, are stationed in Bucharest Romania. None of the used operating systems could be determined. The nickname of the intruder seems to be Methadon, because a SSH key for this user was uploaded to our Honeypot during the attack. Additionally, several tools, that were used while the Honeypot was under the attackers control, for which Methadon claims to be the author, were found. The attack started at about 15:06 p.m., when our Honeypot was scanned by the intruder for vulnerable PHP applications utilising a le called xmlrpc.php. The rst remote command that was executed by the attacker was uname -a, a Linux command to display system specic information, such as the hostname and running operating system. During the attack several dierent tools were downloaded to the compromised host and the intruder managed to escalate the webserver privileges to root, i.e. he took complete control over the Honeypot. Among the downloaded tools were several SSH scanners, a scanner for vulnerable PHP applications, a simple backdoor script and a Rootkit with backdoor functionality. The Honeypot was misused to scan several other machines on the network for weak SSH passwords, as well as, vulnerable PHP applications, such as the one installed on the Honeypot itself. Furthermore, the attacker temporarily setup a PayPal phishing site. Right after the Honeypot was identied as being vulnerable to the XML-RPC attack, the intruder downloaded and installed a simple Perl based backdoor script named Data ChaOS Connect Back Backdoor. This tool ran with the rights of the Apache webserver

48

3.6. Lessons Learned and was used to provide a simple method for interacting with the Honeypot. Thus, remote commands could be executed on the victim host without the need to exploit the web application vulnerability each time. Finally, the intruder acquired root privileges, by executing a binary to exploit the kernel ptrace vulnerability. After the system was successfully conquered, a Rootkit named SHv5 was installed, with a backdoor listening on port 1400. Additionally, several system binaries were replaced by trojaned ones, to cover the traces of the intrusion. The fact, that several tools that were downloaded by the attacker to the Honeypot were especially designed for Red Hat based operating systems, concludes that the assault was carefully planned. As soon as the intruder started to successfully compromise other systems in the network, by utilising the same method our machine was conquered with, it was decided to take the Honeypot oine. Unfortunately, the Honeywall was not able to blight the outgoing attacks, because the exploits used the standard HTTP protocol to execute remote commands on the victim hosts, which by default is not considered as harmful and is necessary to allow an attacker to download his tools to the Honeypot. Therefore, we also informed the Deutsche Forschungsnetz (DFN) Computer Emergency Response Team (CERT) about the incident, who were already investigating a related case, which involved machines belonging to the same network range (whitehat.cc) as the ones that were attacked by our Honeypot. Following is a detailed description of the actions taken by the attacker to compromise and misuse the Honeypot. Each event is marked with its initial timestamp, to form a complete timeline of the attack. Attack Details May 7th 2006 15:06:47 p.m.: The host 72.29.xxx.xxx connected to the Honeypot for the rst time, searching for vulnerable PHP applications by trying several dierent URLs to a le named xmlrpc.php. 15:08:12 p.m.: The Remote command uname -a was executed, which displayed the hostname, kernel version and operating system running on the Honeypot. 20:50:40 p.m.: The attacker downloaded the le s.txt from the URL mafiaboy. ca to the Honeypot by utilising the vulnerable PHP application. The le contained a Perl script called Data ChaOs Connect Back Backdoor, which opens a shell with the privileges of the webserver to the attacker. Thus, providing the intruder a more simple way to interact with the victim host, while trying to further escalate his privileges. 20:51:01 p.m.: With the help of the Perl backdoor, another le was downloaded named root.tar.gz from rokyOo.evonet.ro. This tar archive holds a large number of dierent exploits to gain root access for Red Hat based operating systems, as the one running on the Honeypot. Roughly 30 seconds later the machine was compromised by Methadon by exploiting the kernel ptrace vulnerability.

49

Chapter 3. Honeywalls and Honeypots 20:51:32 p.m.: Another le, named shv5.tar.gz, was downloaded to the successfully conquered system from www.cleverworldnet.com. This le contained the SHv5 Rootkit, which installed several trojaned binaries to hide its presence and additionally opened a backdoor on port 1400. 20:52:32 p.m.: The host with the IP address 86.107.xxx.xxx connected to the freshly installed SHv5 backdoor on port 1400 for the rst time. 21:38:23 p.m.: The host with the IP address 81.181.xxx.xxx connected to the SHv5 backdoor on port 1400 for the rst time. 21:48:49 p.m.: The attacker downloaded his SSH key to the Honeypot from the URL http://whitehat.cc/~meth/ and installed it in the proper location. Although the SHv5 backdoor was installed and hidden, many of the following connections to the Honeypot were made using the standard SSH daemon. Figure B.3 shows the activity of the intruder on the Honeypot that happened, before and after the download of the SSH key. 21:49:26 p.m.: The attacker logged in from the host 81.181.xxx.xxx via SSH. During the next minutes, several changes to the webserver, the /cgi-bin/ folder and a le named pin.html were made by the intruder. Additionally, a folder named cgl-bin was created hosting the PayPal phishing site, the attacker tried to setup. Although the site was accessible from the web, it was removed for unknown reasons only a few minutes later. May 8th 2006 00:36:29 a.m.: Another le, named ioi was downloaded from the URL whitehat. cc to the Honeypot. This archive contains a large number of various SSH scanners, including Methadons personal brute force scanner: - -=- Gr33tz to MethadoN ;) -=- -. 00:37:47 a.m.: The attacker started several SSH brute force attacks against dierent hosts from the network ranges 192.35.0.* and 66.252.10.*. 13:32:41 p.m.: The host 81.181.xxx.xxx logged in and started downloading a le called udp.txt from the URL http://www.whoopis.com/howtos/phpBB-viewtopic-hack/. The le contains a Perl based UDP ooding program, which was then used to ood the host 62.161.xxx.xxx, which belongs to a web hosting company. 23:16:53 p.m.: The host 81.181.xxx.xxx connected to the SHv5 backdoor on port 1400 of our Honeypot and downloaded the le udp.pl from the URL http:// packetstormsecurity.org/DoS/. This is the same UDP ooder as described above. May 10th 2006 23:27:16 p.m.: The host 86.107.xxx.xxx connected to the SHv5 backdoor on port 1400 of our Honeypot and downloaded the le alexu.jpg from the URL http://www.free-ftp.org/unnamed/. The le contains another SSH brute force scanner, with a password list holding more than 12.000 entries.

50

3.6. Lessons Learned 23:30:35 p.m.: The intruder initiated another SSH brute force attack, with the freshly installed brute force sanner, on hosts with the IP addresses 24.3.* and 66.98.48.*. 23:37:19 p.m.: Another le named cola.tar was downloaded from the URL http://whitehat.cc/~sorin/. This le contained a vulnerability scanner for PHP applications, utilising a le named xmlrpc.php. This is probably the same scanner used to identify our Honeypot as being vulnerable. May 11th 2006 00:08:49 a.m.: The intruder scanned several hosts for vulnerable PHP applications and managed to exploit the xmlrpc vulnerability on a few of them. To take over the machines, the attacker remotely executed a concatenation of the following commands: wget 208.25.xxx.xxx:443/bind.jpg, tar xzvf bind.jpg, chmod a+x and ./httpd. As a result, a backdoor is installed on the remote host, similar to the Perl script that was installed on our Honeypot in the rst place. At 00:10:39 a.m., a total of six systems were compromised this way. (66.xxx.xxx.74, 66.xxx.xxx.121, 66.xxx.xxx.34, 66.xxx.xxx.160, 66.xxx.xxx.107 and 66.xxx.xxx.202) At this point it was decided to shutdown the Honeypot, to prevent any further damage to other systems vulnerable to the xmlrpc.php exploit. Tools Involved This section deals with the tools that were downloaded to our Honeypot. These tools were then used by the attacker to take over and misuse the machine to harm other system on the network. We were able to reconstruct all download locations from the logles of the Honeywall. Therefore, we could retrieve and analyse all tools on a second host, without the attacker taking any notice. As a result, examination of the utilities could take place, while the intruder was still active on the Honeypot. shv5.tar.gz:
============================================================================ MMMMM MMMMMM MMM MMMMMMMMM MMMM MMMM MMM [*] Presenting u shv5-rootkit ! MMM MMMM MMMM MMMM MMMM MMM [*] Designed for internal use ! MMM MMMMMMM MMMMMMMMMMMM MMM MMM MMMMMMMM MMMMMMMMMMMM MMM [*] brought to you by: PinT[x] MMM MMMM MMMM MMMM MMM [*] April 2003 MMM MMMM MMMM MMMM MMMM MMM MMM MMMMMMMMM MMMM MMMM MMM [*] *** VERY PRIVATE *** MMM MMM [*] *** so dont distribute *** MMMMM -C- -R- -E- -WMMMMMM ============================================================================

Figure 3.18.: SHv5 startup screen

51

Chapter 3. Honeywalls and Honeypots The compressed le contains the SHv5 Rootkit, that enables the intruder to have persistent root level access to the compromised host. Upon installation, the Rootkit modies a number of system commands, to hide its presence and cover the tracks of the attacker. For example, it replaces the original netstat command (netstat displays the active TCP connections of a computer), so that the execution will not show the hidden SSH server, which is setup by the Rootkit. The Rootkit is distributed in a package named shv5.tar.gz and contains the following les: drwxr-xr-x drwxr-xr-x -rw-rr -rw-rr -rw-rr -rw-rr -rwxr-xr-x -rw-rr 6 8 1 1 1 1 1 1 root root root root root root root root root root root root root root root root 4,0K 4,0K 491K 442 29K 2,8K 24K 121K 21. 11. 1. 18. 15. 23. 2. 17. Mai Mai Mai Apr Apr Apr Mai Apr 14:36 10:12 2003 2003 2003 2003 2004 2003 . .. bin.tgz conf.tgz lib.tgz README setup utils.tgz

The setup le is an executable shell script, used to install the SHv5 Rootkit on the victim host. Figure 3.18 shows the startup screen which is presented after the installation process is initiated. It takes two command line arguments: ./setup <sshd password> <sshd port>. The attacker started the shell script with the password timelimit and the port 1400 on our Honeypot. When executed, the setup rst veries that the current user has root privileges and then uncompresses all archived les included in the distribution. In the next step, the syslog daemon is stopped and the script checks if any remote logging mechanisms are enabled, to prevent information leaking, that would alert the system administrator. Additionally, the setup process looks for certain administration tools, like Tripwire [SK]. Tripwire is a tool for detecting changes in a le system, by comparing it against a previously build database containing checksums of each le. In case a Tripwire database is found, it gets overwritten, with the log message stating that the database is corrupt due to a disc-geometry or bad disc-sector error. Thus, tricking the administrator into rebuilding the database using the trojaned binaries as a basis for the new checksums. In the next step, the Rootkit installs a series of modied binaries, as well as, the hidden SSH server. The modication made to the binaries aects the output that is displayed to the user, so that the presence of the attacker is concealed. All MD5 checksums of replaced les are stored in a single le named .shmd5 and encrypted into /dev/srd0. Future executions of the trojaned md5sum command will read this le to display the original MD5 hashes of all modied binaries. The following tools are trojaned after the successful installation of the SHv5 Rootkit: ps, ifconfig, netstat, top, slocate, ls, find, dir, lsof, pstree and md5sum, which are included in the bin.tgz le. In addition to the trojaned binaries, two utilities are installed from the utilz.tgz le: mIRKfORCE and SynScan. The rst tool simulates multiple hosts on the same subnet and is capable of ooding an IRC server. It can be used to take over IRC

52

3.6. Lessons Learned channels, as well as, to perform Distributed Denial of Service attacks (DDoS). The second tool is a fast portscanner, with the possibility to detect vulnerable services running on a scanned host, by parsing the banner output of services running on certain ports. The le named conf.tgz contains a few conguration les for the dierent trojaned binaries. For example, the le file.h contains the list of les, to be hidden from directory listing. Finally, the setup process scans the computer for other Rootkit installations, as well as vulnerable services running on the compromised host. If a vulnerable application is found, the user is notied and urged to patch it. In the case of our Red Hat Honeypot the vulnerable wu-ftpd FTP server v2.6.0 was detected, but no patch was applied by the attacker. s.txt: This le contains a Perl script named Data ChaOs Connect Back Backdoor. When executed, an outgoing connection from the victim host is established to the given host and port. As a result, the attacker is able to circumvent rewalls that lter inbound network trac only. The spawned shell has the same level of access as the user executing the script, in this case it was running with the privileges of the Apache webserver. Therefore, it serves as a simple method to remotely perform further actions on the victim host, until full control is obtained. root.tar.gz: The compressed le contains a whole collection of local root exploits, especially designed to work on Red Hat based operating systems. The binary executed by the attacker on our Honeypot is called hator and exploits the kernel ptrace vulnerability. The technique used by the intruder to gain root privileges was described in detail in the basics chapter section 2.5.2. Among the other exploits contained in the distribution are, for example, a local /sbin/ifenslave buer overrun exploit, an efstool local stack-based exploit and a SHOUTcast v1.8.9 remote exploit. Altogether, we found about 62 dierent exploits, for all kinds of applications, some even had the source code included. udp.txt and udp.pl: Both scripts contain the same simple UDP ooder written in Perl. It was released by Odix in February 2001 and is freely availably at the URL http: //packetstormsecurity.org. The script takes three parameters, the IP address of the victim host to be ooded, the port all UDP packets will be send to and a time value, which denes the duration of the attack. If the latter two arguments are left blank, the script chooses a random destination port and runs continuously. ioi: The archived le contains the attackers personal utilities collection, as we determined from the header of the SSH scanner script, shown in gure B.4. The distribution also includes ve les named 0 to 5, which contain the dierent username and password combinations that are used, when performing a SSH brute force attack. Altogether, the les contain around 15.000 login credentials. Furthermore,

53

Chapter 3. Honeywalls and Honeypots the compressed le contains a few standard Linux tools, which might not be available on a more secured compromised host. For example, the le editor pico and the utility for le retrieval via HTTP wget. Additionally, a binary named vanish is included, which is capable of removing traces from various system log les, like /var/log/messages and the list of last logged in users. alexu.jpg: The compressed le contains another SSH brute force scanner called pscan, together with a number of startup shell scripts. Additionally, a le named pass.txt is included, with over 12.000 username and password combinations to be used with the scanner. Another le named vuln.txt contains the results of a SSH scan, i.e. a list of IP addresses and hostnames with the associated working login credentials. cola.tar: The compressed le contains a scanner for PHP applications which are vulnerable to the same XMLRPC vulnerability that was exploited to conquer our Honeypot. Among several les, with lists of many dierent IP addresses that have already been scanned, the distribution contains a le named vuln.txt with about 2.000 hosts, each with a URL associated to it, pointing to les named xmlrpc.php or adxmlrpc.php. Furthermore, another le named xmlrpc.log, which contains the scanner output for systems being vulnerable to the XMLRPC vulnerability, existed. When executed, the script gets a class B network as a parameter and starts scanning for hosts with a webserver running on the standard port 80. Each found webserver is then queried for les named xmlrpc.php or adxmlrpc.php. If such a le is found on a server, the IP and URL is stored to a le named vuln.txt. Finally, the scanner tries to exploit the XMLRPC vulnerability on every host, that was gathered in the previous step, with the payload uname -a. The results of the nal step are stored in the le named xmlrpc.log. Notice, that the same command was also the rst one to be executed on our Honeypot and it took almost six hours for further actions to happen. This leads to the conclusion, that our Honeypot was detected as vulnerable by the same tool. bind.jpg: This is the le that was downloaded to the hosts that were attacked and successfully exploited from our Honeypot. The compressed le contains a backdoor, several local root exploits and a small mail script. The name of the installed backdoor is bindtty, which spawns a shell on a predened port. Its binary is camouaged as httpd, thus it will look like a running Apache webserver process. Among the local root exploits are the ptrace exploit, a linuxconf buer overow and a suidperl exploit. The mail script captures the /etc/passwd and /etc/shadow les, which contain the encrypted passwords of all system users and mails them to a Romanian webmail account. Attack Evaluation The attacker utilised an automated scanner (cola.tar) to nd hosts running PHP applications that are vulnerable to the XMLRPC exploit, such as the the phpAdsNew

54

3.7. Summary application which was installed on our Honeypot. According to the attack pattern and the analysis of the scanner, we can conclude that this utility was also used to detect our Honeypot, which as a result was successfully compromised by exploiting the kernel ptrace vulnerability. The behaviour of the intruder can be classied as little careful and little experienced. The tools that were downloaded to the Honeypot did all work well, which implies that they were carefully selected prior to the attack. Almost all traces of the attacker on the system were properly covered, due to the trojaned binaries of the SHv5 Rootkit. Although the Rootkit checked the victim host for some security tools, like Tripwire, there was no attempt made to check for any Honeypot specic traits. The motive of the attacker is not quite sure. The rst intent to setup a phishing site was skipped for unknown reasons. The Honeypot was then misused as a stepping stone to attack other systems within the network. For example, several hosts were scanned for weak SSH passwords, utilising one of the installed SSH brute force scanners. Furthermore, the intruder scanned for systems with vulnerable PHP applications installed. Finally, the attacker changed the password of the root user, which does not t the careful behaviour, either, as this is the rst to be noticed by a system administrator.

3.7. Summary
In this chapter we have introduced the basics of Honeynet based research in the area of network security. We presented the history of Honeypots and how they can be classied based on the interaction which they provide to an intruder. The low-interaction Honeypots lure an attacker with emulated vulnerable services, therefore, assumptions on the behaviour have to be made, which restrict a villain to certain actions. An example of a low-interaction Honeypot is Nepenthes, which is described in greater detail in the next chapter. On the other hand, there are the high-interaction Honeypots, which oer a full operating system, with all its installed applications for an attacker to exploit. As a result, much more knowledge can be gained about methods, intentions and tools used to acquire root access on a victim host. At this reason, a high-interaction Honeynet was deployed at RWTH Aachen, with the help of the bootable Honeywall CDROM Roo. The Honeynet comprised four dierent high-interaction Honeypots with the following operating systems installed: Red Hat 8.0, Suse 9.1, Fedora Core 3 and Microsoft Windows XP. A detailed view on each of the Honeypots, with the according vulnerable applications, was presented. Additionally, an in-depth view on the tasks of a Honeywall and the dierent services that are needed to eciently fulll the properties of data control, data capture and data analysis, as implemented in the Honeywall Roo, was provided. Finally, two selected incidents were presented in detail, revealing two distinct ways a system can be abused, after it has been successfully conquered. In addition, a thorough analysis of the dierent tools, that were downloaded to the compromised Honeypots and used for either escalating user privileges or misusing the machine for illegal purposes, was provided. The deployment of Honeypots, with known vulnerable applications, can be seen as controversial, as it is very unlikely to detect new vulnerabilities. Furthermore, most

55

Chapter 3. Honeywalls and Honeypots Operating System Red Hat 8.0 Suse 9.1 Red Hat 8.0 Suse 9.1 Red Hat 8.0 Red Hat 8.0 Suse 9.1 Vulnerability used Weak Password Web Application Web Application Web Application Weak Password Weak Password Web Application Actions SSH scans IRC proxy installation Phishing/Scanning Phishing User space IRC-bot Phishing None

1 2 3 4 5 6 7

Table 3.2.: Summarized Honeypot compromises of the security issues have already been xed and new versions have been released. However, Honeypots are not only used to reveal new aws in software, but also to collect information about tools and techniques, used by intruders, to misue a system. Although, we provided a mixture of new and old vulnerable applications, we can conclude from the incidents we monitored, that the number one method to conquer a host is by exploiting vulnerable PHP based web application, such as the Horde Application Framework. The second most prosperous method to compromise a host is by SSH brute force attacks. Simple passwords are still the weak point in computer security, therefore, we provide a method to improve this issue, with the help of Nepenthes, in the next chapter. Table 3.2 summarizes the incidents, which were observed during the time of the diploma thesis. It shows, which operating system a Honeypot was running, the kind of vulnerability, which was used to compromise the host, as well as the main action, that was performed by the attacker currently in control of the system. The major drawback of a high-interaction Honeynet is its high complexity and the time consuming maintenance. Although, the set up of a Honeywall can be simplied by the operation of Roo, the single Honeypots still need a lot of attention and ne tuning of the installed applications. As a result, high-interaction Honeynets are not qualied for intrusion detection sensors, but for research purposes only.

56

Chapter 4. Nepenthes
4.1. Introduction
Nepenthes was released in June 2005 by Markus Koetter and is currently maintained by the mwcollect.org development crew. Similar to the name giving carnivorous plants, this software pretends to be a luring target for malicious software. It is a prey trapping mechanism, featuring emulated vulnerabilities, to attract hostile or already contaminated systems and download capabilities, to collect autonomous propagating malware. The chapter is outlined as follows. First, we give a short overview of Nepenthes and how it works. In the next part, we describe the dierent techniques, implemented in Nepenthes to serve as an automated malware collection software. Finally, we explain the methods used to build new modules to extend Nepenthes in many ways. For example, we present the module log-blastomat which extends the low-interaction Honeypot to serve as an intrusion detection sensor for the Blast-o-Mat system (Chapter 5). A summary concludes the chapter.

4.2. Nepenthes Overview

Nepenthes is categorized as a low-interaction Honeypot, which aims at capturing malware, especially worms, which spread in an autonomous manner. The main focus is to get hold of the malicious software itself, i.e. to download and store the application for further in-depth analysis [KBH+ 06]. To keep up with the constantly raising number of distinct malware, utilising new vulnerabilities as they are discovered, Nepenthes is build as a modular system. Thus, it is simple to accommodate to new threats. Figure 4.1 illustrates the design of Nepenthes and the dierent interacting modules, that are needed to capture malicious software. Each of the involved modules will be described in detail in the following section. Unlike other low-interaction Honeypots, as Honeyd, Nepenthes does not emulate full services for an attacker to interact with. It oers only as much interaction as is needed to exploit a vulnerability. For this reason, it is not designed for any human interaction, as the trap would be easily detected. On the contrary, for the automated attack, just a few general conditions have to be fullled, consequently, maximizing the eectiveness of the approach. These conditions usually include to display the correct banner information of

57

Chapter 4. Nepenthes

Figure 4.1.: Nepenthes design overview an emulated service, malicious software is trying to exploit, as well as some simulated commands. Therefore, the resulting service is only partly implemented. A common way, used by all kinds of malware, to gain access to a host, is to precipitate a buer overow [One00] in one of the oered services and inject its shellcode, which contains instructions about how to proceed. A buer overow occurs when the boundaries of a program buer are not properly checked before writing to it and can therefore be overwritten, causing anomalous behaviour of the software or service [Koh02]. Hence, an attacker causes a buer overow to inltrate malicious code with the goal to conquer a host. Nepenthes feigns that the system is successfully compromised. As a result, one is able to analyse the conveyed shellcode, to determine the way the malware spreads and what modications it does to the operating system. Usually, the malware downloads itself from a previously infected system in terms of a binary, which is then executed to take complete control of the system. Once in control the malicious software tries to spread further or performs other vicious actions, e.g. it launches attacks against other machines on the network. Nepenthes parses the provided shellcode for any download locations to get hold of the malware binary. Any received binary is stored in a predened location for further investigation. Thus, Nepenthes provides an automated mechanism to collect autonomous spreading malicious software. The main advantages of this approach, in the context of incident detection, is that no false-positives are generated. A false-positive means, an alert is falsely raised. As Nepenthes provides only emulated vulnerabilities, an alert can only be triggered, in case such a vulnerability is exploited. Any honest host, trying to use one of the oered services, will receive an error, as no full functionality is given. Therefore, a slightly modied Nepenthes can be used as an ecient and accurate sensor in an intrusion detection system.

58

4.3. Inside Nepenthes

4.3. Inside Nepenthes

The Nepenthes application is written in C++. It was developed in 1983 as an enhancement to the C programming language, which started with the addition of classes [Ale01]. The popularity and the fact that Unix based operating systems are written in C, makes it a good choice for open source applications, like Nepenthes. Nepenthes is designed as a single-threaded core daemon, with a variety of modules facilitating each task of the malware collection process. Besides the modular structure, Nepenthes provides an event driven notication mechanism. Each step of an attack triggers certain events, which other modules can register to and therefore react on. Nepenthes features an easy to use Application Program Interface (API) for writing new modules. There are a couple of dierent module types, which can be categorized as follows [KBH+ 06]: Vulnerability modules Shellcode parsing modules Download modules Data logging modules Submission modules The vulnerability modules prelude the malware collection process. Each of these modules simulates a known vulnerability, to the extent that is needed, to lure malware applications into sending their payload. Once the malicious software is tricked into sending the actual payload to Nepenthes, the shellcode is extracted and passed on to one of the shellcode handler modules. An example of a vulnerability module is presented in detail in section 4.3.5. The shellcode parsing modules analyse the given shellcode, to extract the information on how to download the particular malware. That is to determine the actions the shellcode would have performed on a real machine. For example, the rst step of one of the basic shellcode parsing modules is to recursively detect XOR decoders in a generic way. XOR decoders are used to encrypt the malicious shellcode to evade intrusion detection system, which examine network packet content. According to the ascertained decoder, the code is decoded and specic patterns, like the names of the API functions CreateProcess or URLDownloadToFileA, are ltered out. These API functions are commonly called to either create a backdoor connecting to the attacking host or to directly download the malware binary from a given location. The resulting URLs are then passed to one of the download modules [Hol05b]. The task of the download modules is to fetch the concrete malicious software of the Internet. Accordingly, there exist a number of modules, each implementing a dierent network protocol. Besides the standard protocols like Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP) or Trivial File Transfer Protocol (TFTP), there

59

Chapter 4. Nepenthes are also some malware specic transfer protocols. For example, linkbot uses a nonstandardized mechanism (link://), which requires additional information, as in this case of an authentication key [Wic06]. The data logging modules serve the purpose of an information system, i.e. they send out information, as soon as certain events are raised. An event can be an established connection or a successful download of a binary. In addition to the le-based logging, there exist some other congurable methods utilising dierent destinations. For example, the log-syslog module. Each time a vulnerability module is triggered, it sends data containing the time of the attack and the IP address of the attacker to a predened syslog server, thus, notifying the administrator of any suspicious activities within the network. The module is thoroughly described in section 4.3.2. Usually, all downloaded malware les and the according shellcodes are stored locally, utilising the various submission modules. However, it is also possible to store all downloaded binaries at a centralized location, or submit them to an analysing facility, like the Norman Sandbox [Nor06]. The Norman Sandbox runs the malicious software in a secure, emulated environment to investigate and record the behaviour of worms, viruses or bots. The resulting report provides helpful information about what parts of the system are modied or what techniques a malware uses to infect other systems on the network. The term sandbox describes an environment, in which an executed program is able to perform any task, as if run in a real operating system. In contrast, all modications done, are recorded and the sandbox can be reset to an initial clean state. Figure B.6 shows a sample analysis reported of the Norman Sandbox application. On the strength of the exible modular structure, Nepenthes can be highly customized to accommodate to new tasks. To serve the purpose of an intrusion detection sensor, we added some data logging modules. In this way, allowing us to interconnect the low-interaction Honeypot with our automated notication and handling system, the Blast-o-Mat. Additionally, new vulnerability modules were added to adapt our sensor to the newest threats. For Nepenthes can be congured to listen to many IP addresses at the same time, we were able to place it in dierent subnetworks of RWTH Aachen campus network. As a result, the chance to be hit by a contaminated host drastically increased, without the need of extra hardware. In the following sections we describe the various dierent logging and vulnerability modules, which were written and put into operation during the time of the diploma thesis.

4.3.1. Module: log-mail

The log-mail module is used for alerting an administrator via mail about incidents happening. In the event of a successful break in, a notication message is sent to a predened eMail address. Upon the startup of Nepenthes, the log-mail module registers itself to the EV_DIALOGUE_ ASSIGN_AND_DONE event. This event is raised when an emulated vulnerability is successfully exploited. Once the log-mail module is triggered, it gathers information, summariz-

60

4.3. Inside Nepenthes ing the incident. Figure B.5 shows part of the source code, that deals with the collection and preparation of the data to be send. As a result, a message is generated including the time of the event, the IP address of the oending host, as well as, the name of the vulnerability module that was exploited. An example of a log-mail message is shown in gure 4.2. Nepenthes Automatic Mail: Connection Event: Time of Event: 19.01.2006 23:01:11 Socket TCP (accept) 192.168.xxx.xxx:47175 -> 192.168.xxx.xxx:445 AttackerIP: 192.168.xxx.xxx Module: LSASSDialogue Figure 4.2.: Nepenthes log-mail example mail Prior to the operation of the module, it needs to be congured. The conguration le comprises four settings, as shown in table 4.1. log-mail settings IP address of the SMTP server. Port of the SMTP server. Sender address. Recipient address. Table 4.1.: log-mail conguration The rst two items specify the Simple Mail Transport Protocol (SMTP) server, which is used upon a successful exploitation, to send out the alerting eMail. Additionally, a valid sender and recipient address must be dened.

serverIP serverPort fromEmail toEmail

4.3.2. Module: log-syslog

The log-syslog module is used for logging to either a local or remote syslog server. A syslog server is a central repository, where log messages from several devices and services are accumulated. These messages are then distributed among the dedicated logles [Par03]. Log messages do not necessarily have to originate from the same system the server runs on, but can also be collected from several machines among the network, to form a large centralized logging database. Large scale networks usually use a centralized host for collecting all kinds of logles, the so-called syslog server. Having collected all information in one central point, facilitates the analysis process in case an incident has happened. To support this idea, the log-syslog module was written. The module registers itself to the same EV_DIALOGUE_ASSIGN_AND_DONE event as the log-mail module. The generated messages include the time of the incident, the IP address of the attacking

61

Chapter 4. Nepenthes host and the name of the vulnerability module that was triggered. An example of a Nepenthes syslog alert is shown in gure 4.3. Nepenthes: Time: 8.7.2006 13:33:45 Socket TCP (accept) 192.168.xxx.xxx:53090 -> 192.168.xxx.xxx:445 AttackerIP: 192.168.xxx.xxx Module: LSASSDialogue Figure 4.3.: Nepenthes log-syslog example message In order to use this mechanism, one needs to specify an Internet Protocol address of a syslog host and a port where the User Datagram Protocol (UDP) packets will be send to. UDP is a connectionless transport protocol. The fact that no connection establishment is used makes it a fast and easy to use protocol. On the other hand, it oers no ow control, error correction or resending of corrupt or lost packages. It is mainly used in time sensitive applications, where it does not matter if a packet gets lost and does not have to be retransmitted, like real-time multimedia applications [Tan03]. As long as no critical information is transmitted UDP totally suces. For our intrusion sensors are hit more than once by a single oending host, plenty of alerts are generated, thus we can safely ignore the case that packet loss might happen. If no syslog server is specied, the standard settings, localhost and port 514, apply. In combination with the logle analysis program, Swatch (Section 3.4.2), which is based on regular expressions, it is possible to execute a user dened script, upon receiving a Nepenthes syslog message [Par00]. For this reason, it is possible to automatically block or redirect a host detected by Nepenthes, when Swatch is used in combination with the packet ltering tool IPTables.

4.3.3. Module: log-blastomat

The log-blastomat module is used for directly communicating with the automated notication and blocking system, Blast-o-Mat. With the help of the event system of Nepenthes, we are able to collect all necessary information for the Blast-o-Mat to lookup and notify the owner of the hostile or infected system. The log-blastomat module is very similar to the previously described log-syslog module, i.e. it registers to the same EV_DIALOGUE_ASSIGN_AND_DONE event. At this point, the time of the attack, the IP address, the port of the attacking host and the name of the vulnerability module, which was exploited, is known. The complete information is wrapped up in an Extensible Markup Language (XML) based message and sent directly to the Blast-o-Mat Server (BlastServer), for further handling. As an underlying transport the UDP protocol is utilised, which, in contrast to TCP, is more straightforward and does not block the sender, in case the connection cannot be established. Then again, we have to accept that packet loss can occur, which might lead to a delayed detection of infected systems. To minimize the risk of having undetected intruders in the network, usually more than one intrusion detection sensor is deployed. Prior to operating this module, the conguration le needs to be adjusted to the proper IP address and port, the Blast-o-Mat server listens on (Table 4.2).

62

4.3. Inside Nepenthes log-blastomat settings IP address of the BlastServer. Port of the BlastServer. Table 4.2.: log-blastomat conguration

BlastServerIP BlastServerPort

4.3.4. Module: log-mysql

The log-mysql module stores all incident information, including the downloaded malware, to a MySQL database server. Additionally, a PHP based web interface is provided. It enables a user to browse through the collected samples and analysis reports, which are created by dierent tools, e.g. the Norman Sandbox reports. The web interface is thoroughly described later on. The conguration of the log-mysql module comprises the IP address of the MySQL server, a valid username and password, as well as a database name, where the samples will be stored (Table 4.3). log-mysql settings hostIP IP address of the MySQL server. database Name of the database to use. user MySQL user with read/write privileges. password Password of the MySQL user. Table 4.3.: log-mysql conguration In contrast to the previously described logging modules, log-mysql registers to two events, namely EV_DIALOGUE_ASSIGN_AND_DONE and EV_SUBMISSION. The second event is raised, as soon as malicious software is successfully downloaded by Nepenthes. Thus, in case of an incident, not only the usual information about the attackers IP address and vulnerability module triggered is recorded, but the binary together with the URL it was downloaded from are stored in the MySQL database, as well. This collected data can be used as a platform for further malware analysis and statistics about the most frequent types of malicious software, target ports or vulnerability modules, which were exploited. Currently, we are running one Nepenthes sensor with over 16.000 assigned IP addresses, logging to its own MySQL database and another two sensors with less IPs, logging to a centralized server. The latter two also submit their collected binaries to the Norman Sandbox and the CWSandbox. The CWSandbox is based on the diploma thesis by Carsten Willems. Similar to the Norman Sandbox, it runs the malware in a controlled environment. Thus, it records both all changes to the operating system and all network communication taking place while the malware is running. In the end a detailed report of the behaviour of mailicious software is created. An extract of one of those reports is given below. Some parts were stripped to minimize the size of the generated text.
<a n a l y s i s c w s v e r s i o n=" Beta 1 . 3 2 " time=" 1 5 . 0 5 . 2 0 0 6 18 : 3 4 : 2 4 "> <p r o c e s s e s> <p r o c e s s i d=" proc_1 " f i l e n a m e=" c : \ a n a l y s e \ b i n a r y \ b 6 e 0 d 4 1 9 2 4 3 e 4 b a 7 7 5 d 9 5 e a a 1 0 0 e 3 f e d . exe " p i d=" 1712 " username=" A d m i n i s t r a t o r "

63

Chapter 4. Nepenthes

md5=" b 6 e 0 d 4 1 9 2 4 3 e 4 b a 7 7 5 d 9 5 e a a 1 0 0 e 3 f e d "> <d l l _ h a n d l i n g _ s e c t i o n> <l o a d _ d l l d l l=" c : \ a n a l y s e \ b i n a r y \ b 6 e 0 d 4 1 9 2 4 3 e 4 b a 7 7 5 d 9 5 e a a 1 0 0 e 3 f e d . exe " s u c c e s s f u l="1 " /> <l o a d _ d l l d l l=" C: \WINDOWS\ system32 \ n t d l l . d l l " s u c c e s s f u l="1" /> <l o a d _ d l l d l l=" C: \WINDOWS\ system32 \ k e r n e l 3 2 . d l l " s u c c e s s f u l="1 " /> <l o a d _ d l l d l l=" C: \WINDOWS\ system32 \ advapi32 . d l l " s u c c e s s f u l="1 " /> </ d l l _ h a n d l i n g _ s e c t i o n> <f i l e s y s t e m _ s e c t i o n> <c o p y _ f i l e f i l e t y p e=" F i l e " s r c f i l e =" c : \ a n a l y s e \ b i n a r y \ b 6 e 0 d 4 1 9 2 4 3 e 4 b a 7 7 5 d 9 5 e a a 1 0 0 e 3 f e d . exe " d s t f i l e =" C: \WINDOWS\wlRPrMH8 . exe " d e s i r e d a c c e s s="FILE_ANY_ACCESS" f l a g s="SECURITY_ANONYMOUS" f i l e i n f o r m a t i o n c l a s s=" F i l e B a s i c I n f o r m a t i o n " /> <o p e n _ f i l e f i l e t y p e=" F i l e " s r c f i l e =" C: \WINDOWS\wlRPrMH8 . exe " c r e a t i o n d i s t r i b u t i o n="OPEN_EXISTING" d e s i r e d a c c e s s="FILE_ANY_ACCESS,FILE_READ_ATTRIBUTES" f l a g s="FILE_ATTRIBUTE_NORMAL,SECURITY_ANONYMOUS" f i l e i n f o r m a t i o n c l a s s=" F i l e B a s i c I n f o r m a t i o n "/> <s e t _ f i l e _ a t t r i b u t e s f i l e t y p e=" F i l e " s r c f i l e =" C: \WINDOWS\wlRPrMH8 . exe " d e s i r e d a c c e s s="FILE_ANY_ACCESS,FILE_WRITE_ACCESS,FILE_WRITE_DATA, FILE_AD D_FILE" f l a g s="FILE_ATTRIBUTE_HIDDEN,SECURITY_ANONYMOUS" f i l e i n f o r m a t i o n c l a s s=" F i l e B a s i c I n f o r m a t i o n "/> </ f i l e s y s t e m _ s e c t i o n> <mutex_section> <create_mutex name="GhostBOT" owned="0"/> </ mutex_section> <r e g i s t r y _ s e c t i o n> <enum_values key="HKEY_LOCAL_MACHINE\ s o f t w a r e \ m i c r o s o f t \ windows \ c u r r e n t v e r s i o n \ run " /> <query_value key="HKEY_LOCAL_MACHINE\ s o f t w a r e \ m i c r o s o f t \ windows \ c u r r e n t v e r s i o n \ run " subkey_or_value="MWATCH" /> </ r e g i s t r y _ s e c t i o n> <p r o c e s s _ s e c t i o n> <enum_processes showwindow="SW_HIDE" a p i f u n c t i o n=" P r o c e s s 3 2 F i r s t " s u c c e s s f u l="0 " /> </ p r o c e s s _ s e c t i o n> <WinSock_section> <c o n n e c t i o n s _ o u t g o i n g> <c o n n e c t i o n p r o b a b l e w e b p r o t o c o l t y p e="Unknown" c o n n e c t i o n e s t a b l i s h e d=" 1" s o c k e t=" 1236 "> <plain_communication_data> <send>NICK A d m i n i s t r a t o r 7 4 . .</ send> <send>USER A d m i n i s t r a t o r 7 4 GhostBOT:GhostBOT . .</ send> </ plain_communication_data> </ c o n n e c t i o n> <c o n n e c t i o n t r a n s p o r t p r o t o c o l="TCP" remoteaddr=" 2 1 7 . 1 6 0 . xxx . xxx " r e m o t e p o r t=" 8888 " p r o b a b l e w e b p r o t o c o l t y p e="Unknown"

64

4.3. Inside Nepenthes

c o n n e c t i o n e s t a b l i s h e d=" 0" s o c k e t=" 2144 "/> <c o n n e c t i o n t r a n s p o r t p r o t o c o l="TCP" remoteaddr=" 7 4 . 8 6 . xxx . xxx " r e m o t e p o r t=" 3127 " p r o b a b l e w e b p r o t o c o l t y p e="Unknown" c o n n e c t i o n e s t a b l i s h e d=" 0" s o c k e t=" 2756 "/> </ c o n n e c t i o n s _ o u t g o i n g> <c o n n e c t i o n s _ o u t g o i n g _ b l o c k e d> <c o n n e c t i o n t r a n s p o r t p r o t o c o l="TCP" remoteaddr=" 1 3 4 . 6 1 . xxx . xxx " r e m o t e p o r t=" 139 " p r o b a b l e w e b p r o t o c o l t y p e="Unknown" c o n n e c t i o n e s t a b l i s h e d=" 0" s o c k e t=" 2144 "/> <c o n n e c t i o n t r a n s p o r t p r o t o c o l="TCP" remoteaddr=" 1 3 4 . 6 1 . xxx . xxx " r e m o t e p o r t=" 445 " p r o b a b l e w e b p r o t o c o l t y p e="Unknown" c o n n e c t i o n e s t a b l i s h e d=" 0" s o c k e t=" 2144 "/> </ c o n n e c t i o n s _ o u t g o i n g _ b l o c k e d> </ WinSock_section> </ p r o c e s s> <p r o c e s s i d=" proc_2 " f i l e n a m e=" s e r v i c e s . exe " p i d=" 708 " username="SYSTEM"> </ p r o c e s s> </ p r o c e s s e s> </ a n a l y s i s>

The report is partitioned in several sections describing dierent actions performed by the malicious software. Each created process is explained in the according subsection. In the example above one can see the monitored application loading several Windows libraries (ntdll.dll, kernel32.dll, etc.) and copying itself to the root directory of the operating system. In the next step the mutex GhostBOT is created to prevent more than one instance of the software running at the same time. Additionally, the malware modies some entries in the registry, thus it is executed upon each startup of the infected host. The last part of the report shows several attempts of the program to connect to other computers on the Internet. These can be either attempts to propagate further by scanning for vulnerable hosts or to contact a command & control server to receive further commands on how to proceed. To observe the actions taken by the running malware, the CWSandbox utilises the techniques of Windows Application Programming Interface (API) hooking [Wil06]. This is a similar technique as used by the Sebek client (Section 3.4.2). However, Sebek monitors all operating processes on a Honeypot, whereas the sandbox examinates a single program. Prior to the execution of a malicious binary, the CWSandbox injects its own Dynamic-Link Library (DLL) into the address space of the malware process. A detailed description about Windows DLL injection can be found in the work of [Ric94]. As a result, the library creates hooks to all original API functions. Therefore, all further calls to API functions are rerouted to the ones provided by the injected library. At runtime of the malware, all call parameters are analysed and stored localy, to present a detailed report of the softwares actions afterwards. Additionally, the injected DLL invokes the original API functions to return correct results to the malware process. Thus, the malicious software does not notice that it is monitored. To protect other systems on the network, the CWSandbox can disable outgoing connections destined to certain ports. For example, connections with destination port 445 are blocked, as many malware uses this port to propagate further. This is accomplished by monitoring the Windows

65

Chapter 4. Nepenthes Socket API functions. On each outgoing connection to precongured ports, the injected DLL simply rejects the connection establishment. In this case, invoking of the original function can be skipped and an error value can be returned to the calling application directly. At the same time, virus scanners frequently check the downloaded binaries for known types of viruses, worms or bots, utilising the NepVirus script. NepVirus The NepVirus Python script is responsible for checking each downloaded binary for known types of malicious software. It currently supports AntiVir, BitDefender and Clam AntiVirus. All scanners support automatic update of their virus databases or are manually updated prior to each scanning process, which ensures that binaries are always analysed with the latest signatures. Currently, the NepVirus script is scheduled to run every hour and scan all downloaded binaries. The virus scanner output for each binary and each dierent anti-virus software is stored in the MySQL database, together with a link to the signature and program version that was used. Finally, all duplicate entries are removed, i.e. if the virus scanner output is the same as the output of the same scanner with an earlier signature version, it is discarded, thus, keeping always the oldest unique output. As a result, we have a database containing the output of dierent virus scanners for the same les. Some of the virus scanners will not recognize a le as being a virus or worm in the rst place, however, this might change with the next update of the signature le. Therefore, we have some kind of timeline, indicating when a new virus was rst recognized by which scanner (Figure 4.4) or if a le, previously dened as virus A, is classied as virus B after a signature updated occurred (Figure 4.5). The supported virus scanners are implemented as Python classes, which are imported into the main NepVirus script. The dierent classes contain the needed command line options, that are to be passed to each anti-virus application to either scan a given directory or retrieve the version and signature information. When executed, the core program creates a new thread for each scanner class, so they can run simultaneously, thus, accelerating the detection process.

Figure 4.4.: NepVirus: Recognition with a newer signature

Figure 4.5.: NepVirus: Change in virus classication

66

4.3. Inside Nepenthes The Web Interface To provide an interface for navigating through the collected binaries and the output of the various analyses software, we developed a simple website. It currently features a live feed of the Nepenthes sensors logging to the MySQL server, displaying the hundred latest additions. Figure 4.6 illustrates the information, which is presented to a visitor. It includes the time a malicious host attacked one of the low-interaction Honeypots, the IP address of the attacking host, the IP address of the victim host, the URL the victim should download the malware from, the MD5 hash of the binary and the size of the le. Additionally, the live feed page provides buttons to the analysis reports of the Norman Sandbox and the CWSandbox about each downloaded malicious software.

Figure 4.6.: Live feed of the Nepenthes web interface To summarize all collected information, the web interface features a statistic page, which is generated over all gathered data and updated every hour. Besides some global information about when the rst database entry was created and how many unique IP addresses have already exploited the low-interaction Honeypots, it shows several more specialised information like the top ten gathered malware or most frequently exploited vulnerabilities, as shown in gure 4.7.

Figure 4.7.: Nepenthes statistics: top ten malware Additionally, the web interface provides an overview of all the collected information, which is presented in gure 4.8. The statistics show that the destination port 445, com-

67

Chapter 4. Nepenthes monly used for Windows le sharing, and the LSASS vulnerability [Cor04b], is currently the number one targeted by hostile hosts on the Internet, with more than twelve million hits. The second and third most hit ports, 135 and 139, belong to the le sharing ports of Windows as well and are frequently targeted by malicious software. An example for a worm utilising port 139 to infect other systems is the W32.Mumu.B.Worm, which was rst discovered in 2003. It attempts to establish a Null Session connection (Anonymous Logon connection) to hosts sharing data on the Internet. Once successfully connected, the user accounts of the machine are enumerated and added to the worms dictionary. In the next step, the worm tries to guess weak passwords for each extracted account and copies itself to the remote share if it succeeds. A more detailed description of the worm can be found in the work of [Sym04a].

Figure 4.8.: Nepenthes overall statistics Furthermore, one can observe the high number of attacks targeting port 80, which substantiates the conclusion drawn in the Honeynet chapter, that web applications are an increasing target of computer criminals. The top ten virus/worm list shows the summed up output of the virus scanners of the NepVirus script described in section 4.3.4. It shows that various forms of the Padobot family are currently one of the most frequently spreading malware, next to the W32/Parite virus. This virus is also known as W32/Pin and infects all .EXE and .SRC les on the machine it is executed on. It even tries to infect les over network shares, which is a rather uncommon approach

68

4.3. Inside Nepenthes of viruses [Sym05]. Besides the statistical purposes, the top ten list of target ports can serve as a reliable input vector for the Blast-o-Mat PortScan intrusion sensor. For it provides a list of the most frequently used ports by automatically spreading malicious software. Next to the statistical overview, the web interface provides the possibility to browse the list of downloaded binaries and examine each of the corresponding analysis reports. Furthermore, the website oers the possibility to search for certain hosts, MD5 hashes or even patterns that appear in CWSandbox analysis reports. For example, it is possible to search for all reports containing the pattern IRC. As a result, a list of binaries is displayed, of which each tries to contact an IRC server. This feature can be used to quickly extract bots from the collected malware for further investigation. To store the Norman Sandbox reports in the MySQL database, a script is run every hour, which connects to a Post Oce Protocol Version 3 (POP3) server, which receives all the Norman analysis mails. Nepenthes oers a module, to submit each downloaded binary to the Norman Sandbox for examination. The resulting report is sent to a predened eMail address. The getNormanMails PHP script, connects to the mailserver and downloads the Norman messages, which are determined by the eMail subject and the sender address.

4.3.5. Module: vuln-exchangepop3

ExchangePOP3 is an eMail gateway (connector) that retrieves messages from Internet POP3 eMail accounts and delivers them to an Exchange Server. Additionally, it provides the possibility to send eMail, either directly to the receiver or via an Internet Service Providers (ISP) smart host (SMTP server). In February 2006, a remote buer overow exploit was found in version 5 of this software, which enables an attacker to execute arbitrary code and gain root access to the system. Figure 4.9 shows an abridged version the Proof of Concept (POC) code. The availability of the POC greatly facilitates the process of building a vulnerability module for Nepenthes, simulating an exploitable ExchangePOP3 server. The process of exploiting a vulnerability can be divided into several stages, leading from the rst connection of a hostile host, to the nal injection of malicious code. Inbetween, one has to simulate the correct behaviour of the service, which is to be oered. The rst stage of writing a vulnerability module for Nepenthes involves the transmission of the banner information of the service one is trying to emulate. This is essential, for most of the exploits trigger only if the correct service name and version is displayed. In this case we, display the following text, to each connecting client: 220 ExchangePOP3 v5.0 Ready. Once the header information is sent, we have to wait for the connected client to react. In this particular case we wait for the client to send the Mail command, which initiates the mail sending process on a real ExchangePOP3 Server. As we expect the buer overow to happen in the recipient address, we need to reply to this request with 250 OK. This reply is dened in the Requests for Comments (RFC) 821 of the SMTP protocol and indicates the client to proceed with its mail sending process. A sample mail delivering process is shown in gure 4.11. As a result, we switch to the next stage in the exploit process, which, in this case, expects the client to send an oversized recipient address to cause the buer overow. To distinguish a correct request from an

69

Chapter 4. Nepenthes #!/usr/bin/perl -w # for educational purposes only. use IO::Socket; if ($#ARGV<0) { print "\n write the target IP!! \n\n"; exit; } $buffer2 = "\x90"x1999999; $mailf= "mail"; $rcptt ="rcpt to:<"; $buffer = "\x41"x4100; $ret = "\x80\x1d\xdc\x02"; $shellcode = "\xEB\x03\x5D\xEB\x05\xE8\xF8\xFF\xFF\xFF\x8B\xC5\x83\xC0\x11\x33". "[...]" "\xD3\x4A\x8C\x88"; $enter = "\x0d\x0a"; $connect = IO::Socket::INET ->new (Proto=>"tcp", PeerAddr=> "$ARGV[0]", PeerPort=>"25"); unless ($connect) die "cant connect" print "\nExchangepop3 v5.0 remote exploit by securma massine\n"; print "\n+++++++++++www.morx.org++++++++++++++++\n"; $connect->recv($text,128); print "$text\n"; $connect->send($mailf . $enter); $connect->recv($text,128); print "$text\n"; $connect->send($rcptt . $buffer . $ret . $buffer2 . $shellcode . $enter); print "\nsending exploit......\n\n"; print "\ntelnet to server port 9191 .........\n\n"; Figure 4.9.: EXchangepop3 remote buer overow POC [Mas06] exploit attempt, a predened threshold for the length of the recipient value is used. In case the length exceeds our threshold, we send the given input to the ShellcodeManager of Nepenthes. Otherwise, the client is disconnected, as the emulated service does not oer any more functionality. At this point, Nepenthes handles all further steps to obtain and store any malicious software found.

4.3.6. Module: vuln-logssh

Based on the vuln-ssh module, that is distributed with Nepenthes, the vuln-logssh module emulates a secure shell (SSH) daemon. SSH is a server/client program for logging onto a remote machine and executing arbitrary commands. It provides secure encrypted communications between two hosts over an insecure network.

70

4.3. Inside Nepenthes In contrast to a real SSH server or the original vuln-ssh module, this module does not allow any remote login at all. It merely serves the purpose to record any login attempts to the Nepenthes machine. Any host that tries to connect to the SSH port is prompted to enter a username and password. The transmitted data is then stored to a local le and the connection is closed, just as if the entered login information were wrong. Thus, forcing the remote client to try dierent combinations. We observed a lot of SSH brute force attacks, that were constantly hitting our Nepenthes sensors during the time of the diploma thesis. For this reason, we were able to safely collect a huge number of username and password combinations. With the help of the gathered data, system administrators can improve the protection of their network from intrusions, by verifying that only strong passwords and none of the collected are used within their organization. This verication can be accomplished directly upon creating or changing of user passwords on Linux based operating systems, by utilising the command line application passwd, which supports the Pluggable Authentication Manager (PAM) [Hat06]. As PAM provides a exible modular structure for customization, it is possible to write a new module, which is capable of checking each entered login credentials against a database of collected unsafe combinations. Additionally, existing accounts can be veried with the help of a password cracker, like John the Ripper [Pro06a]. It allows the use of multiple word lists and is capable of brute-force password cracking.

Figure 4.10.: vuln-logssh statistics Over the time of three weeks, we were able to collect about 12.081 unique username and password combinations. Almost half of these (5.207) were attempts to login as the root user. Figure 4.10 summarizes what we have discovered so far. Besides a large number of dictionary based passwords (fussball,berlin,...), we found a lot of username equals password login attempts (Username: george Password: george) or slight modica-

71

Chapter 4. Nepenthes tions, like adding the digits 123 to the beginning or end of the password (Username: pgsql Password: pgsql123). Other interesting combinations make use of alternating characters and digits that are in close range on the keyboard. For example, 1q2w3e, which is then extended to the two successors 1qa2ws3ed and 1qay2wsx3edc. However, the number of SSH brute force attempts and the simplicity of most of the collected user credentials show that weak passwords are still a serious threat in computer security.

4.3.7. Module: vuln-smtp

The vuln-smtp module emulates a Simple Mail Transport Protocol (SMTP) server, which is open to the public, i.e. any host can connect to the server and apparently send messages with it. However, in contrast to a real SMTP server, the module does not transmit any entered eMail data to a given list recipients. Additionally, vuln-smtp implements only the basic commands of the simple mail transfer protocol, which are required to send a text based message. Figure 4.11 shows an example of a mail delivery sequence, showing the request and reply commands, which are needed for a successful mail transaction. Server: Client: Server: Client: Server: Client: Server: Client: Client: Server: 220 SMTP MailServer Ready MAIL FROM:<John@Smith.com> 250 OK RCPT TO:<Any@body.com> 250 OK DATA 354 End data with <CR><LF>.<CR><LF> Any kind of text... <CRLF>.<CRLF> 250 Message accepted for delivery Figure 4.11.: Example of the SMTP Procedure Instead of delivering the entered mail data, the vuln-smtp module writes everything to disk, together with the IP address of the connected client host. The purpose of this module is to nd out more about the way open mail relays are detected and misused for sending out unsolicited bulk email, also known as SPAM. The term open mail relay refers to a SMTP server, which processes eMail messages, where neither the sender nor the recipient is a local user. Although, the vuln-smtp module is still in its development phase, we have already collected a great number of short messages. The message body usually contains just one word, like hello or Greeting, as it is shown in gure 4.12. Considering the fact, that the sender and recipient addresses are almost always equal or at least within the same domain and the subject of all those eMails is identical (BC_<IP of the SMTP server>), we can conclude that these mails are used for notifying the sender about newly discovered open mail relays.

72

4.3. Inside Nepenthes From: <josunin10@daum.net> To: <josunin1221@daum.net> Reply-To: <josunin10@daum.net> Subject: BC_134.61.xxx.xxx Date: Mon May 22 09:16:57 2006 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="--ltmebnicyubult" X-Priority: 1 ----ltmebnicyubult Content-type: text/html hello ----ltmebnicyubult-. Figure 4.12.: Log-smtp received eMail To verify the above statement, we manually forwarded one of the received hello messages to one of the destined recipients. About 12 hours later, the rst wave of SPAM eMails hit our Nepenthes sensor. Figure 4.13 shows the message content of one of the received eMails.

Figure 4.13.: Nepenthes log-smtp received SPAM

73

Chapter 4. Nepenthes The nal version of the module will be able to automatically relay one eMail per sender with a message body, containing the single words hello or greeting, to observe if the server is further misused to send out SPAM. As a result, the gathered eMail samples can be used to improve SPAM ltering applications to increase the detection rate. Additionally, as we found out, many of the SPAM sending hosts are infected with some kind of malicious software. Therefore the owner of such a machine needs to be informed. This conclusion was made, while observing that most of these machines were also detected by Nepenthes, exploiting vulnerabilities and by the Blast-o-Mat, scanning for ports.

4.4. Summary
Nepenthes is a exible, modular written, low-interaction Honeypot, capable of collecting malware in an automated manner. New vulnerability modules can easily be written and integrated, to keep up with the fast changing spreading mechanisms of todays network worms, as we showed with the implementation of the vuln-exchangepop3 module. In addition to the identication of hostile hosts, malicious software is downloaded for further analysis, by dierent utilities like the CWSandbox. For this reason, we also implemented the NepVirus script, which regularly scans the collected binaries for known types of malware, by utilising three common anti-virus applications: AntiVir, BitDefender and Clam AntiVirus. Additionally, we developed a simple web interface to browse through the collected data and the analysis reports. These generated statistical information can be used to determine new trends in computer crime. With the help of the log-blastomat modul, we were able to integrate Nepenthes as an intrusion detection sensor, into the distributed Blast-o-Mat system. Consequently, providing an ecient and accurate detector for infected hosts, within the campus network of RWTH Aachen University. During the time of the diploma thesis, we deployed three dierent Nepenthes sensors, two of them captured external data from the Internet and the third one, as part of the Blast-o-Mat notication and handling system, collected data from internal hosts, belonging to RWTH network. With over 16.000 IP addresses, divided among the three sensors, we were able to collect about 5.000 unique binaries within the past six month. During the four month of actively monitoring infected hosts, by the new Blast-o-Mat system, the Nepenthes sensor successfully detected over fty contaminated machines. Therefore, we can conclude from the results, that low-interaction Honeypots, such as Nepenthes, make a great enhancement to any standard intrusion detection mechanism. Besides the standard vulnerability modules, we also presented the vuln-logssh and vulnsmtp modules. The rst is used to collect all kinds of login and password combinations, provided by the increasing number of SSH brute force attacks, we monitored during the last months. The latter is an attempt to utilise Nepenthes in the area of SPAM detection, by emulating an open mail relay. Both modules supplied interesting results for further research. Especially in the area of password allocation, a Nepenthes system, with installed vuln-logssh module, can greatly increase security, by eliminating the use of weak passwords.

74

Chapter 5. Blast-o-Mat
5.1. Introduction
With the appearance of the Internet worm W32.Blaster, in August 2003, the amount of simultaneously contaminated hosts drastically increased. Although, there have been worms in the past, like CodeRed [eDS01] or Nimda [CER01], which propagated in huge numbers, their spreading mechanisms were more limited. For example, CodeRed infected only Internet Information Servers (IIS) version 4 and 5 of Microsoft Windows NT and 2000, which is not installed by default in most of these Windows versions. In contrast, the Blaster worm exploited a vulnerability (RPC/DCOM) that existed in every Microsoft Windows NT based operating system [Cor03b], namely: Windows NT 4.x, Windows 2000, Windows XP, and Windows 2003. Thus, manually detecting infected hosts, notifying the owner of that system and taking further actions to reduce the amount of newly contaminated systems, was highly ineective [Hek06]. Therefore, the need of an automated approach arose, which resulted in the development of the notication and handling system, called Blast-o-Mat. In this chapter we will introduce the Blast-o-Mat in more detail and show the techniques used to eectively detect, notify and handle infected hosts within a large scale network. The chapter is outlined as follows. In the rst part, we give a short overview of the Blast-o-Mat history, how it evolved and some major drawbacks of the previous release. Section 5.3 describes the three main parts of the Blast-o-Mat: Intrusion Detection (Section 5.3.1), Notifying (Section 5.3.2) and Handling (Section 5.3.3) of infected systems. In section 5.4, we nally present the implementation of the new Blast-o-Mat version 4 and the results achieved during the time of the diploma thesis. A summary concludes the chapter.

5.2. Overview
The Blast-o-Mat is an automated notifying and handling system developed at RWTH Aachen University, to facilitate network administrators in the process of owner notication, as well as blocking contaminated hosts from further accessing the network. Thus, it actively prevents the mass infection of vulnerable hosts on the campus network, by initiating appropriate actions.

75

Chapter 5. Blast-o-Mat The rst version of a system for automated detection and notifying was implemented in October 2003. At this time, it was a simple shell script, facilitating the manual process of detecting infected hosts and notifying the owner. Due to the Blaster Worm, that was actively contaminating machines over the Internet at that period of time, the software received the working title Blast-o-Mat. The outstanding results achieved with the help of the application, raised the need for a better structured and more advanced version. As new malicious software became active, the Blast-o-Mat was extended to monitor more dierent ports the new threads used for their spreading mechanisms. By the year 2005, the software evolved to version 3, covering about 1.500 lines of Python code, a simple database supporting the notifying process, as well as a ban procedure to preclude contaminated hosts from connecting to the campus network and infecting other vulnerable machines. Although the system constantly evolved, it was rigid and inexible. The script was working in two phases, the sample collection phase and the sample evaluation phase. During the rst phase, the Blast-o-Mat was sning data from a SPAN -(switch port analyser) or Mirror port, of a centralized network router. This port outputs a copy of the complete network trac, that passes through an active network component, like a switch or router. Subsequent to the collection phase, the samples were evaluated, so that during that time no data was collected. Due to the fact that the Blast-o-Mat utilised a threshold based detection mechanism, an infected host could stay undetected, as long as the created trac during the collection phase was low enough. Furthermore, there were no possibilities to integrate additional detection mechanisms to the Blast-o-Mat. Therefore, to be able to add new needed features and making the Blast-o-Mat a more exible piece of software, it had to be completely rewritten.

5.3. Blast-o-Mat Version 4

With the recent Blast-o-Mat version 4, a series of new features and improvements have been introduced. For example, the low-interaction Honeypot Nepenthes, as an additional intrusion detection sensor, the Spammer detection module, and the Gnu Privacy Guard (GPG) signed notication eMails, have been added. Furthermore, the XML based message exchange between intrusion detection sensors and the Blast-o-Mat server, enables an easy integration of new detection modules and mechanisms. Figure 5.1 shows one feasible setup of the Blast-o-Mat system with a centralized database server. Besides this distributed approach, it is also possible to run all components of the Blast-o-Mat on one single machine. The setup at RWTH Aachen involves two machines. The rst machine hosts the Snier, which is responsible for collecting data of the network, to provide input for other detection modules, and the BlastServer, which coordinates the notication and handling processes. The second machine maintains the MySQL database, as well as the dierent intrusion detection sensors. Although the software is adapted to the campus network of RWTH Aachen, it can as well be transferred to other networks, with only a little modication of the code. To support the approach of a distributed notication and handling system, we split

76

5.3. Blast-o-Mat Version 4

Figure 5.1.: Blast-o-Mat setup up the software into three main parts: Detecting infected hosts, approximately in real-time Notifying the owner of the infected computer Taking measures to prevent the contaminated hosts from infecting others Each part contains one or more programs, that either communicate with the server entity of the Blast-o-Mat system in terms of XML messages, or utilises remotely executed Python scripts, to build the overall system. Although each part can be seen as a standalone program, they are referred to as modules, for they all together form the Blast-o-Mat system. In the following sections each part of the Blast-o-Mat and its function is described. Furthermore, an in-depth view on each module, how it works and how it can be extended or modied to t into dierent network environments, is provided.

5.3.1. Intrusion Detection

Intrusion detection mechanisms can be put into operation at many places of a network. This section describes a few of the most common and easy to implement techniques, to determine attacks from normal trac. Each technique can be implemented without installing a complex and costly intrusion detection software, which needs to be deeply integrated into the network structure. Logle Based Sensors A common technique to detect infected hosts, is to analyse logles for any suspicious activity or network anomalies. The major advantage of this approach is, that no special-

77

Chapter 5. Blast-o-Mat ized intrusion detection system is required. To facilitate the logle evaluation process, it is recommended to have a centralized logging server, collecting all the data of the dierent hosts on the network. The gathered information can then be analysed with the help of regular expressions, to determine conspicuous patterns, which point to contaminated or oending hosts. The major drawback of this method is, that only attacks against the own systems can be detected, as these are the logles one has access to. Additionally, one has to deal with the huge amount of data gathered and the mixed logging formats used by the dierent programs which record information. SPAN-Port Based Sensors Almost every active network component, such as a switch or router, hass a SPAN(switch port analyser) or mirror port. For this reason, an intrusion detection system, that is attached to this port, can analyse every passing packet. There are two aspects, that need to be considered when dealing with SPAN-Ports. First, the copied trac can easily exhaust the capacities of the used interface, so the number of mirrored ports should be carefully selected. Second, the system attached to a SPAN-port must be able to handle the incoming packet rate, as well. Blast-o-Mat Intrusion Sensors The intrusion detection sensors form the main input for the Blast-o-Mat system. At this point in time, we support three dierent sources: Nepenthes PortScan Detector Spam Detector The low-interaction Honeypot Nepenthes, forms the most accurate detection mechanism, as it produces no false-positives. It was integrated with the help of the log-blastomat module, which was described in detail in the previous chapter. The PortScan detection module is based on the previous Blast-o-Mat version 3. It monitors the number of initiated connections per host during a given time period, and sends out an alert message if a certain threshold is reached. The PortScan module is described in section 5.4.3. The Spam detection module works in a similar fashion, but it also considers the number of dierent sender addresses used by a suspected host, to mark a host as a spammer. The Spam detection module is described in section 5.4.4. In contrast to Nepenthes, the PortScan and the Spam detection modules do not get their input data directly from the network, but from a database server. For this purpose, we have a sning module, called Snier, which listens on a SPAN-port of a centralized router, within RWTH network and writes all collected connection information to a database server. The PortScan and Spam detection modules continuously read from this database, to determine infected hosts. Thus evading the issue of the two phase sample evaluation of the previous Blast-o-Mat version.

78

5.3. Blast-o-Mat Version 4 All intrusion detection modules utilise XML type messages, to transmit the necessary information about suspicious hosts to the Blast-o-Mat server entity. Included in these messages is the type of incident: PortScan - This is the message type the PortScan detection module dispatches. Spam - This message type is generated by the Spam detection module. Exploit - Exploit message originate form the Nepenthes module log-blastomat. Additional information, that is included in the alert messages, are the IP address of the conspicuous machine, the time the event occurred, the ports involved, as well as some incident specic attributes, like the name of the vulnerability module that was triggered in case of an exploit. A detailed description of the XML messages is given in section 5.4.2.

5.3.2. Notifying
One of the vital problems, when dealing with infected hosts, is to inform the owner of the system about the circumstance. One can distinguish between two kinds of systems to be notied, the ones belonging to administered networks, with a responsible contact person and the single-position systems, with dynamically assigned IP addresses. In the rst case, a database query usually suce to nd out the person in charge for a given IP address. For systems belonging to networks of rooming houses, RWTH Aachen maintains a database, containing the contacts of all responsible administrators. In case of a hostile event, the administrator is notied by the Blast-o-Mat and summoned to take further actions. Another established way to nd out the responsible person for a system is the WHOIS service. Nowadays, most of the large networks maintain a special abuse eMail address, which can be retrieved via this public service. In the case of dynamically assigned IP addresses, like dial-up connections, Digital Subscriber Lines (DSL) or Virtual Private Networks (VPN), an authentication step is needed for each host, prior to the connection to the network. Typically, this authentication is done utilising a RADIUS- or Lightweight Directory Access Protocol (LDAP) server. At RWTH Aachen, a slightly modied FreeRadius server, that logs all authentication and accounting data to a centralized MySQL database, is maintained. This database is then queried by the Blast-o-Mat, to retrieve the account and eMail address of the user that was online during the time of incident, with the given IP address.

5.3.3. Handling
As soon as an infected system has been detected, the question raises about how to deal with the malware spreading, port scanning, or spamming host. The various methods available each have their advantages and disadvantages, which will be described subsequently. The easiest method is to ignore the case and take no actions at all. That way no modications to the network service have to be done and no customers are disgruntled.

79

Chapter 5. Blast-o-Mat On the contrary, other vulnerable systems within the network might get infected, as well. In the worst case, that leads to a highly insecure network with masses of malware contaminated hosts, performing all kinds of malicious actions. Additionally, the network trac increases, as each machine scans for more vulnerable hosts, which can drastically deteriorate the reachability of certain services, like eMail or DNS. The best way to deal with contaminated hosts, in the context of network security, is to immediately take them oine, giving them as little chance, as possible, to infect other systems in the network. The inhibition can take place on any of the OSI layers, depending on the given infrastructure. If direct access to switch port of the conspicuous machine is given, one can disable this port. In this case the host is locked at the physical layer of the OSI model. An inhibition on layer 2, is equal to blocking the MAC address of the hostile host. This approach would also prevent the system to be taken online again, on a dierent switch port. The disadvantage of the two methods is the eort to determine the correct network device, the contaminated machine is connected to. Less costly is the locking of the IP address, with the help of access lists (OSI layer 3). In this case, we need to determine the router, which routes the appropriate network. Although the host is properly blocked, it can still infect systems, within the same local area network (LAN). On higher layers of the OSI model, it is possible to lock certain TCP or UDP ports or operate dierent protocol specic lters, to isolate an infected host. However, all modications to network components have to be reverted, as soon as the problem is solved and the user wants to get back online [Hek06]. Mobile users with laptop computers get dynamically assigned IP addresses, thus, locking on the higher OSI layers is not a feasible method. In this case, the machine needs to be disconnected from the dialup server (Modem, DSL or VPN). The disadvantage is, that once the customer notices the connection loss, he either manually or even automatically reconnects to the server. Furthermore, there exist many dialup servers, that are not capable of disconnecting a host automatically [Hek06]. As a result, it is necessary to permanently block the account of the responsible person, that is needed to authenticate with the dialup server, until the problem is solved, i.e. the malicious software is removed. Finally, an ecient way to unblock the machine after successful malware removal needs to be provided, as well. Quarantine Network A dierent approach to taking a contaminated host oine, is to place it into a quarantined network, isolating it from other possibly vulnerable systems. Although this requires a certain infrastructure, this is the most eective solution, as additional information can be collected from the quarantined host, too. A suggestion of a quarantine network is given in the Future Works section of chapter 5. A slightly less sophisticated method is currently implemented in our automated notication and handling system, to facilitate the process of owner apprisement. The Blast-o-Mat is capable of redirecting HTTP trac of infected machines to a special webserver. Due to the given infrastructure at RWTH Aachen, this works only for hosts of the wireless LAN, right now, e.g. customers with notebook computers. The main advantage of this approach is, on the one hand, that the owner of the conspicuous host

80

5.4. Implementation is directly pointed to a website presenting facts about the infection and, on the other hand, is still able to receive eMail to get further information from the Blast-o-Mat alert mails.

5.4. Implementation
The Blast-o-Mat system is completely written in Python, with a few shell scripts, that take care of user inhibition, for example. Python is a dynamic, object-oriented, programming language, that can be used for many kinds of software development. It oers strong support for integration with other programming languages and tools and includes extensive standard libraries. It is distributed under an OSI-approved open source license, that makes it free to use, even for commercial products [Fou]. The previous Blast-o-Mat version was also implemented using Python and proved well over the years, so there was no need to switch to a dierent programming language. In this section, we take a more detailed look at the single Blast-o-Mat modules, which form the distributed system. For each module, we explain the way it is implemented and present the number of conguration options available. Additionally, the individual settings of RWTH Aachen are described.

5.4.1. Snier
The Snier module serves as the main input entity for the PortScan and Spam intrusion detection modules. It listens on a number of predened interfaces and records all TCP SYN packets to a MySQL database. TCP SYN packets are generated each time a new connection is tried to be established. As none of the currently implemented intrusion sensors inspect the content of network packets, there is no need to collect any further data than the initial packet. Table 5.1 shows the content of the conguration le for the Snier module. It provides the possibility to adjust the software to dierent network environments. The rst four settings comprise the MySQL server parameters, to which the intrusion sensor transmits all collected data. Furthermore, one needs to set the network interface(s), which are connected to a mirror port. The connection information received on the congured interfaces will serve as input to the MySQL database. Additionally, a list of ports needs to be specied, which one wants to monitor. Thus, we can extent or restrict the collected data, by adding or removing port numbers to the list. This is necessary to adapt the Snier to new malware, which exploits vulnerable services on dierent ports. With the help of the source (SRCignore) and destination (DSTignore) whitelists, it is possible to exclude some hosts or even entire networks from the detection of the Blasto-Mat modules. Except for the Nepenthes module, which does not rely on the MySQL database as an input vector. At RWTH Aachen the source whitelist is used to exclude the incident analysis host. Otherwise, it would be frequently triggering the Blast-o-Mat, as it is regularly used to port scan infected machines, to nd out more about possibly installed backdoors.

81

Chapter 5. Blast-o-Mat MySQL settings MySQLHost IP address of the MySQL server. MySQLDB The name of the database where all input is stored. MySQLUser The username with write privileges for the previously dened MySQL database. MySQLPass The password for the user declared above. Snier settings Interfaces List of network interfaces the Snier module listens on. Ports List of ports that are monitored. SRCignore List of source IP addresses that should be ignored, i.e. suspicious trac originating from one of these IPs will not be recorded to the database. DSTignore List of target IP addresses that should be ignored. Table 5.1.: Blast-o-Mat Snier conguration For each interface listed in the conguration le, the Snier module initiates a new thread, running an instance of tcpdump to capture packets o the network. Tcpdump prints out the headers of SYN packets on a network interface, that match a user dened boolean expression [JLM]. Furthermore, the captured packets are decomposed into the necessary parts, source host and port, destination host and port and the timestamp of the packet, to t the standardised database format. Finally, the disassembled information is sent to the congured MySQL server for storage. A part of the Sniers main loop source code, which shows the execution of tcpdump and the forwarding of each gathered output line to the decomposition function, is illustrated in gure B.7. tcpdump -l -n -nn -i eth0 -q -tt not ether proto \arp && ip && not ip proto \pim && ( port 25 ) && tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn Figure 5.2.: Tcpdump commandline Figure 5.2 visualizes the command line, used to intercept TCP SYN packets of a network interface (eth0). As both the PortScan and the Spam Detector count the number of connections initiated per host during a given time, TCP SYN packet monitoring suces. In order to minimize the number of packet headers, that need to be disassembled and transmitted to the MySQL server, tcpdump oers a number of parameters to customize its output. The options we used are described in table 5.2. The regular expression, in single quotation marks shown above, states, that we want to capture packets of the Internet Protocol (IP), but neither Address Resolution Protocol (ARP) packets nor Protocol Independent Multicast (PIM) packets. In the case shown in gure 5.2, we only monitor connections related to port 25 to keep the output simple. The last expression states, that only packets with the TCP ag tcp-syn set are of interest, i.e. TCP SYN packets. At the moment, we monitor a total of seventeen dierent ports at RWTH Aachen that are known to be abused by malicious software to spread further and infect other machines. This includes the standard Microsoft Windows lesharing ports 135, 139 and

82

5.4. Implementation Parameter -l -n -nn -i Description Buers the output. Do not convert host addresses to names. Do not convert protocol and port numbers to names. Listen on the given interface. Table 5.2.: Tcpdump parameter description 445, as well as some common ports used by worms, like port 4444 of the Blaster worm. The Snier runs on an IBM Xseries 346 Dual Xeon 3.2Ghz, with Fedora Core 3 as operating system and is connected via two 1Gbit lines to SPAN-ports of two routers placed in dierent locations. The rst line is linked to the router that connects to the Internet (XWiN), the other one leads to a centralized router, thus capturing trac from the outside, as well as the inside of RWTH network. The Snier captures approximately fteen to thirty packets every second. To minimize the consumed disk space of the MySQL database, the Blast-o-Mat runs a cleanup program every hour, which removes old entries. As the intrusion sensors rely on recently inserted data, we currently delete all information, that has been added more than one hour ago.

5.4.2. BlastServer
The BlastServer represents the core of the Blast-o-Mat software. All information about network incidents are gathered here. The BlastServer, implemented as a Python SocketServer, listens for incoming UDP packets, on a predened port. For each incoming request a new thread is created. This way, it is possible to handle more than one incident at a time. Additionally, in case one thread fails to fulll a request, the server is not blocked or crashes. To properly operate the BlastServer in dierent network environments, it has a conguration le, to adjust common parameters. Among these settings are the port and IP address, on which the server receives incoming event messages. Further settings adjust the way how to proceed with detected contaminated hosts. This comprises the number of minutes that have to pass between two outgoing warning mails, the number of minutes until a suspected machine is disconnected, and the number of times a machine has to be disconnected, before it is permanently locked. For security purposes, a list of valid Blast-o-Mat intrusion sensor IP addresses must be congured, as well, to prevent unauthorized hosts from sending event messages. The JustWarn value can be set, to disable all disconnecting or locking of infected hosts, thus only warning messages are send out. Furthermore, it is possible to enable an eMail fallback mechanism, to overwrite the recipient addresses of all outgoing alert messages with a precongured value. This is helpful in case, the Blast-o-Mat is set up in an environment without the possibility to determine the owner of a machine. The nal settings of the BlastServer comprise the eMail parameters. This includes the sender address of all outgoing Blast-o-Mat mails, as well as the IP address and port of an external mailserver, which is used for eMail transmission. A summarization of all BlastServer conguration settings is shown in table 5.3. To communicate with the BlastServer, all intrusion detection sensors use simple struc-

83

Chapter 5. Blast-o-Mat BlastServer settings BlastIP IP address of the BlastServer. BlastPort Port the BlastServer listens on. KicksTillBan This option sets the number of disconnections until a user account will be locked. MinutesToWarn Denes the delay in minutes between each warning mail. MinutesToKick Denes the delay in minutes until a suspicious user is disconnected. JustWarn Sets the Blast-o-Mat into just warning mode, i.e. it sends only warning mails, neither disconnecting, nor locking will be performed. EnableFallback When set to true, all eMail addresses will be overwritten with the fallback addresses. ValidSender List of IP addresses of valid Blast-o-Mat intrusion sensors. logLevel Determines the output level of the logle (DEBUG,INFO,WARNING, and ERROR). eMail settings mailFrom Sender address of the Blast-o-Mat eMails. mailReplyTo Reply address of the Blast-o-Mat eMails. mailAdminCC Copy outgoing eMails to this address. mailFallBack In case no valid eMail address for a suspicious host is found the fallback addresses are utilised. smtpServer IP address of the mailserver. smtpPort Port of the mailserver. Table 5.3.: Blast-o-Mat BlastServer conguration tured XML messages. Figure 5.3 shows the XML Document Type Denition (DTD) of those messages. The purpose of a DTD is to dene the document structure, with a list of all legal elements and their optional or required attributes. A DTD can be declared inside a XML document, or as an external reference. The rst XML element, show in gure 5.3, determines the type of incident. Up to now this can be PortScan, Exploit or Spammer, according to the implemented intrusion detection modules. The following elements describe the IP address of the intruder, the time interval in which the suspicious trac was monitored, the ports involved, and how the BlastServer should proceed with this event. The proceed value can be either set to Inform or Kick. Similar to the JustWarn parameter of the BlastServer, neither disconnecting, nor locking of the suspicious user account will happen, if set to Inform. Therefore, it is possible to implement sensors whose generated events restrict the BlastServer to send out warning mails only. The elements tagged with a question mark are optional, i.e. they are not required by the BlastServer, to determine the responsible person for an oending host. For example, the elements NumPackets, NumTargets and Module are used for statistical purposes only. Furthermore, the Module element can only be set by the Nepenthes based intrusion sensors, as the PortScan and Spam detection programs do not oer any

84

5.4. Implementation <?xml version="1.0" encoding="UTF-8"?> <!ELEMENT BlastEvent (Type, IP, TStart, TEnd, Proceed, Ports?, NumPackets?, NumTargets?, Module?)> <!ELEMENT Type (#PCDATA)> <!ELEMENT IP (#PCDATA)> <!ELEMENT TStart (#PCDATA)> <!ELEMENT TEnd (#PCDATA)> <!ELEMENT Proceed (#PCDATA)> <!ELEMENT Ports (#PCDATA)> <!ELEMENT NumPackets (#PCDATA)> <!ELEMENT NumTargets (#PCDATA)> <!ELEMENT Module (#PCDATA)> Figure 5.3.: XML Document Type Denition (DTD) vulnerability modules. As soon as a BlastEvent message arrives, the sender of the message is checked against the valid sender list, set in the conguration le. Messages of invalid senders are dropped and a notication, including the IP address of the invalid host, is sent to the BlastServer logle. Otherwise, the delivered information is extracted from the message. All Blast-o-Mat events are associated with a certain type, based on the intrusion sensor that sent it (PortScan, Exploit or Spammer). For each type, there exists a special function in the BlastServer, that handles only this specic event type. For example, if an exploit event is received from one of the Nepenthes sensors, a new thread is created. This thread determines the type of the message and calls the appropriate function, that is responsible for handling exploit events. Currently, the only dierence of this function to the function that deals with port scanning hosts, is the extraction of the name of the vulnerability module that was triggered. The reason they are separated is to provide the possibility to handle each event in a dierent manner. For example, in future versions of the Blast-o-Mat, exploiting hosts can be disconnected and permanently locked immediately. Furthermore, all additional information is gathered from the sensor message, to build up a short summary line, that is written to the logle immediately. An example line is shown in gure 5.4. The additional information includes, for example, the name of the exploited vulnerability module or the number of dierent hosts scanned, in case of a portscan detection. INFO Exploit Attempt: 134.130.xxx.xxx > 135 (Module: DCOMDialogue)

Figure 5.4.: Blast-o-Mat incident summary line In the next steps, an active thread, which currently deals with a BlastEvent, creates an instance of the AccountLookUp class and the BlastHelper class, which support the process of determining the owner of a contaminated machine and provide access to an incident storage database.

85

Chapter 5. Blast-o-Mat AccountLookUp class The AccountLookUp class holds all functions, to determine the accounting data for a given IP address. This includes the correct subnet and eMail address of the person responsible for the infected machine. Based on the subnet of the IP address, there exist several dierent methods for looking up the appropriate account. For example, if the IP address belongs to the dialup or VPN network, the RADIUS server accounting database is queried. Along with the IP address, we also provide the time interval during which the circumstance was recorded. As a result, the AccountLookUp class returns a dictionary object to the calling thread, which holds the information described in table 5.4. AccountLookUp dictionary object Registered account name for the IP address. Information including the account ID, account name, login and logout times. CallingStation In case of dialup or VPN, this holds the actual IP address of the machine. eMails List of eMail addresses of the responsible person(s). IsAdmin True, if we administrate the suspicious machine. Kickable True, if the machine can be disconnected. AdminWhiteList True, if we administer the suspicious machine, but it is whitelisted. IsUnknown IP address does not belong to any congured subnet. SubNet Name of the subnet the IP address belongs to. Account Accounting Table 5.4.: AccountLookUp dictionary object We decided to place the account lookup functions in an extra class, so it can be easily replaced or enhanced with new functions, to either adapt to a change in the way accounting data is retrieved or to t the Blast-o-Mat system into another network environment. To support this approach, the AccountLookUp class possesses its own conguration le, which is shown in table 5.5. The network of RWTH Aachen currently comprises three dierent networks. The mediaways and dialup_vpn networks contain the machines with dynamically assigned IP addresses, whereas the rwth network contains the hosts, with static IP addresses, like the residential homes and research institutes. The policy at RWTH Aachen, when dealing with infected systems is to immediately lock hosts with static IP addresses, whereas machines with dynamically assigned IP addresses have to be disconnected twice before they are permanently locked. Currently, the Blast-o-Mat is congured to wait at least 30 minutes prior to detaching a suspicious host. As a result, a user has roughly one hour to get aware of the infection and take actions, before being permanently blocked. To identify the responsible person for a dynamically assigned IP address, we have to ascertain the account name from the authentication or accounting server. Therefore, we have to compare the IP address and the time of the circumstance with the information stored in the Radius server. RWTH Aachen runs a slightly modied version of the FreeRadius software, which writes its accounting data to a MySQL database, on a daily basis. Thus, we have a database table for each day, which greatly accelerates the process

86

5.4. Implementation MySQL settings MySQLHost IP address of the MySQL server. MySQLDB The name of the database where all input is stored. MySQLUser The username with read/write privileges for the previously dened MySQL database. MySQLPass The password for the user declared above. Accounting settings timeTolerance Tolerance in seconds when searching for a user that was online during an incident subNames The list of networks the accounting data can be determined for, together with the list of IP addresses, that can be disconnected. In the case of the RWTH, this includes: mediaways, dialup_vpn, rwth, kickable and AdminWhitelist. For each of those entries, there must follow an equivalent entry, holding the appropriate IP addresses. mediaways List of IP addresses belonging to machines of the UniDSL network. dialup_vpn List of IP addresses of hosts with a dynamically assigned IP address. rwth List of IP addresses of machines with a static IP address. kickable List of IP addresses that can be disconnected. AdminWhiteList List of IP addresses of systems that we administrate and are allowed to scan, spam or exploit, but we still get a notication eMail if this happens. Table 5.5.: Blast-o-Mat AccountLookUp conguration of searching for specic accounting data. One major drawback of this method is, that the Radius protocol is UDP based, thus, we have to deal with possible packet loss, which leads to data inconsistency. In this case, it is impossible to nd the responsible person. As a result, the fallback eMail address is activated and all undetermined incidents are reported to the Network Operation Center (NOC). The Account locking of a detected host, is accomplished by setting a special ag in the LDAP database, which is used for user authentication. Once the ag is set, a user with an infected machine can no longer connect to the campus network and has to contact the helpdesk to be unlocked again. To identify the responsible person(s) for hosts with static IP addresses, RWTH Aachen maintains a XML-based database, with all relevant information. This database contains for each known subnet the registered administrators, their phone number and eMail address, the net mask, the acronym of the institute and, if available, the assigned Virtual Local Area Network (VLAN) number. Additionally, for each entry there exists a Managed on Router and Vlan (MoRV) parameter, which species the manageable network router, through which the associated subnet is routed. To lock a host with a static IP address, a Perl script, written by Jens Hektor [Hek], is utilised, which is capable of automatically creating Anti-Spoong access lists. These access lists can be extended with rewall rules or, in our case, with lists of locked machines, thus eciently blocking

87

Chapter 5. Blast-o-Mat contaminated hosts from accessing the network. BlastHelper class The BlastHelper class holds all the functions for gathering example lines and saving all incident related information. Each incoming event gets its own database entry, storing the IP address, the ports, the account name, the type of circumstance, the time when it rst occurred and the time of its last occurrence. Additionally, we store the time when the last warning mail was sent to the user, as well as, the last time the user was disconnected on purpose. The BlastHelper class provides an interface to all these information. Furthermore, it oers a function to collect a few example rows from the Snier database, to send with the warning mail, as an evidence for a portscan incident. For exploit events, the class provides an additional function, which queries the Nepenthes database created by the log-mysql module (Section 4.3.3). As all other modules, the BlastHelper class has its own conguration le, which is displayed and explained in table 5.6. MySQLHost MySQLDB MySQLUser MySQLPass kickMaxAge MySQL settings IP address of the MySQL server. The name of the database where all input is stored. The username with read/write privileges for the previously dened MySQL database. The password for the user declared above. BlastHelper settings Kicks, older than the dened number of hours, do not count to the number of kicks needed until a user is permanently disconnected. Denes the number of hours during which a machine, that was permanently disconnected before, can not be locked again. Denes the number of minutes an account is still considered as suspicious.

banMaxAge

suspectMinutes

Table 5.6.: Blast-o-Mat BlastHelper conguration To prove the participation of a host taking part in an incident, e.g. port scanning or exploiting, a set of sample rows have to be collected. For this reason, the BlastHelper function getExamples is invoked with the IP address and the ports, that we want to pick up a few examples for. In the next step, the Snier database is queried for each of the involved ports, to return ten sample lines. Each line contains the time of the incident, the oending host IP address and the destination host IP address and port. These rows are later added to the outgoing warning mails. Every incoming event is checked against the incident database, with the help of the BlastHelper class, to determine if it is a new incident or if a previously suspected machine is still active. In the rst case, a new database entry is created and the Blast-o-Mat immediately sends out a warning mail to the owner of the suspected system. If the

88

5.4. Implementation machine was already conspicuous before, notication only happens, if the time of the last warning mail is older than the congured value. Furthermore, the time of the last kick is retrieved, to determine further actions. As soon as a host has been disconnected for the predened number of times, the dedicated account is permanently locked, to prevent any further damage to other systems on the network. Besides the incident database table, there exist two other tables holding the accounts and the number of times that they have been disconnected and those that have been permanently disconnected. eMail notication For each purpose there exists a precast eMail message body and subject, the Blasto-Mat can revert to. The currently implemented intentions are: warning, kicking and banning. The warning mail noties a suspected user, that he has been detected by the Blast-o-Mat and that the infected system is to be taken oine immediately, otherwise his account will be permanently locked. Additionally, the message holds data, that comprises the helpdesk contact information, an URL to a current virus scanner software, as well as the previously gathered sample lines. The kick and ban eMails dier from warning mails only in the text contained in the message body. Figure B.9 shows the message content of a Blast-o-Mat warning mail. The example rows have been excluded, due to the size of the gure. As some administrators of constitutions, especially residential homes, automatically lock their users locally upon receiving Blast-o-Mat eMails, we decided to digitally sign outgoing messages, to prevent misuse of any kind. As a software to achieve this goal, the GNU Privacy Guard (GPG) [Fou03] was utilised. GPG is a complete and free implementation of the OpenPGP standard, as dened by RFC2440. The command line tool allows to encrypt and sign data and communication, featuring a versatile key management and easy integration with other applications. The public key, used to verify the authenticity of a signature, is also signed by the members of the Network Operating Center (NOC). As a result, all outgoing eMails can be clearly identied as originating from the Blast-o-Mat system. Redirection One of the more complicated tasks in automatic locking of infected systems, is to notify the user of the suspected host. The main method, implemented by the Blast-o-Mat, is to notify any responsible person via eMail. For every student at RWTH Aachen gets his own eMail address upon registration to the rst semester, we can assure to have a valid possibility to reach each student. On the contrary, we can not assure that the students read their eMail frequently or even check their university account at all. Therefore, we needed to nd an ecient way to inform even those who do not read their mail about any suspicious behaviour of their computer systems. For this purpose, the Blast-o-Mat is capable of redirecting certain trac to a specially designed webserver. Due to the network structure at RWTH Aachen, the redirection currently works only for the wireless MoPS (Mobile Professors and Students) network customers. All trac of wireless hosts has to pass one central entity, the MoPS Gateway.

89

Chapter 5. Blast-o-Mat Thus, we are able to eciently redirect any trac of hostile hosts at this point, via the use of certain IPTables rules. The main advantage of this approach is, that the responsible person of a redirected host, is eciently informed, even if the warning mails of the Blast-o-Mat are not read. Every attempt to open a website on a redirected host, displays the information site of the quarantine webserver, showing all gathered data about the incident so far (Figure 5.5). This includes the output of the Norman Sandbox and the CWSandbox. Furthermore, eMail delivery is still possible, allowing the user to get additional information, provided with the Blast-o-Mat warning messages.

Figure 5.5.: The quarantine website To achieve the redirection of a contaminated host, the Blast-o-Mat remotely executes a Python script (BlockMac.py) on the gateway server and transmits the account name, the IP address and the time the system was online, as parameters. The easiest way would be to do the redirection based on the IP address of the infected host, but since we have to deal with dynamically assigned addresses, this would not prevent the user from logging in again, with a dierent IP address, thus, circumventing the redirection measures. Therefore, we have to determine the MAC address of the oending machine. This is accomplished with the help of an additional script, which queries the Dynamic Host Conguration Protocol (DHCP) server, with the time the host was online and its IP address, as parameters. Every DHCP server maintains a le, containing all MAC addresses of hosts it assigned an IP address to, together with the time interval the given IP address is valid, called lease le. With the help of the lease le of the DHCP server, we are able to determine the MAC address of the system, that was online with a certain IP during a given time. The part of the BlockMac.py script, which calls the external script on the DHCP server, is illustrated on gure B.10.

90

5.4. Implementation In case this lookup method fails, due to unreachability of the DHCP server, there exists an additional method, implemented in the BlockMac.py script. This method queries the local Address Resolution Protocol (ARP) table of the MoPS gateway server for the given IP address. For every computer stores the IP to MAC address relation of machines it recently communicated with in a local table one can check this table for a match. Therefore, the script sends a single ping request to the host, thus, initiating the ARP table update. As a result, the BlockMac.py script generates an IPTables rule (Figure 5.6), which redirects any further HTTP trac of the specied MAC address to the quarantine webserver. Additionally, all blocked accounts are stored in a local le, which is parsed by the rewall at least once a day. For each entry, we determine if the user is permanently locked by checking the LDAP database. Only those entries with the permanently locked ag set, will still be redirected upon the next restart of the rewall. iptables -t nat insert PREROUTING -p tcp -m mac mac-source 00:00:00:xx:xx:xx dport 80 -j DNAT to-destination 134.130.xxx.xxx:80 Figure 5.6.: Blast-o-Mat IPTables redirection rule

5.4.3. PortScan Sensor

The PortScan sensor analyses the data provided by the Snier module and detects systems that are scanning a huge range of IP addresses for certain ports during a predened period of time. In case a port scanning host is found, the module sends a BlastEvent message to the BlastServer, as described earlier. The reason we look for massive port scanning hosts is that it is a true sign of an infection. MySQL settings MySQLHost IP address of the MySQL server. MySQLDB The name of the database where all input is stored. MySQLUser The username with read/write privileges for the previously dened MySQL database. MySQLPass The password for the user declared above. PortScan settings ScanPorts The list of ports that are to be monitored. WaitTime The time interval to consider when looking for port scanners. TargetThreshold The number of unique target hosts, that need to be scanned, before a machine is marked as a port scanner. logLevel Determines the output level of the logle. whitelist List of IP addresses of machines, that are allowed to scan. BlastIP IP address of the BlastServer entity. BlastPort Port of the BlastServer entity. Table 5.7.: Blast-o-Mat PortScan conguration Table 5.7 shows the conguration le of the PortScan sensor. The module checks the Snier database, in regular congurable time intervals, for all entries containing a

91

Chapter 5. Blast-o-Mat destination port and timestamp not older than dened. Entries with a number of unique target hosts, greater than a chosen threshold, are considered as a port scan. The PortScan detection sensor initiates a three stage process, to determine a scanning host (Figure B.8). To facilitate the detection process, the module manages additional database tables, to store interim results. In the rst stage, we select all entries from the Snier table, that have a destination port within our congured port range and a timestamp not older than the dened value. The resulting rows are grouped by the source IP address, the destination port and the destination IP address, to eliminate duplicate entries. Starting with the outcome of the previous step, the second stage selects all those rows with a number of unique targets, greater than the congured threshold. The last two stages deal with some statistical information, such as the number of unique targets and the number of ports that were scanned. As a result, we have a table in which each entry represents a port scanning host, together with the number of packets sent, the number of targets contacted and the number of ports scanned. Finally, the PortScan detection module sends out a BlastEvent message, for each determined port scanner, to the Blast-o-Mat server (Figure 5.7). <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE BlastEvent SYSTEM "xmlblast.dtd"> <BlastEvent> <Type>PortScan</Type> <IP>137.226.xxx.xxx</IP> <TStart>1153222133</TStart> <TEnd>1153222311</TEnd> <Proceed>Kick</Proceed> <Ports>139,445</Ports> <NumPackets>7295</NumPackets> <NumTargets>4520</NumTargets> </BlastEvent> Figure 5.7.: XML message for a Blast-o-Mat PortScan event The PortScan sensor, running at RWTH Aachen, currently monitors the most common ports used by malware to propagate. For example, SSH (22), Windows-RPC (135), Microsoft-DS (445), MS-SQL (1433), as well as the standard ports of the remote administration software Radmin (4899) and Dameware (6129). The parameter WaitTime, in the conguration le, is set to 3, i.e. the PortScan module wakes up every 3 minutes and parses all entries of the Snier database that are not older than 3 minutes. The TargetThreshold value is set to 50 unique hosts, thus, a hostile or infected machine has to scan at least 50 dierent hosts within 3 minutes, to be considered as a port scanner. Both values were taken from the previous Blast-o-Mat version and have proved well over the past three years. In the current setup at RWTH Aachen, we run all three intrusion sensors, the PortScan module, the Spammer detection and Nepenthes, on an Intel Pentium4 2,66Ghz machine, with a total of 2 GigaByte working memory. Furthermore, the computer system hosts the MySQL database, responsible for all incident storage operations, as well as, the

92

5.4. Implementation Blast-o-Mat web interface for intrusion visualization. About 180 additionally assigned IP addresses increase the hit ratio of the Nepenthes intrusion sensor. As a result, we noticed about the same detection rate as the PortScan sensor, that operates on the Snier input.

5.4.4. Spam Sensor

Similar to the PortScan module, the Spam detection sensor parses the Snier database for entries with destination port 25 and counts their frequency during a certain time period. To support the many dierent mailservers of research institutes and residential homes, the Spam detection module provides source (SRCWhiteList) and destination (DSTWhiteList) based whitelists (Table 5.8). Unlike the other implemented intrusion sensors, the Spam module sends only a suggestion to the Blast-o-Mat server. The suggested Spammer is then further analysed at the BlastServer module. MySQL settings MySQLHost IP address of the MySQL server. MySQLDB The name of the database where all input is stored. MySQLUser The username with read/write privileges for the previously dened MySQL database. MySQLPass The password for the user declared above. Spam detection settings ScanPorts The list of ports that are to be monitored. WaitTime The time interval to consider when looking for port scanners. TargetThreshold The number of unique target hosts that need to be scanned before a machine is marked as a port scanner. logLevel Determines the output level of the logle. SRCWhiteList List of IP addresses of machines that are allowed to send out eMail with many dierent sender addresses (Mail relays). DSTWhiteList List of mailservers that users are allowed to connect to. BlastIP IP address of the BlastServer entity. BlastPort Port of the BlastServer entity. Table 5.8.: Blast-o-Mat Spam detection conguration Once a BlastEvent about a possible spammer is received, the server executes an external Python script, that starts sning the SMTP trac of the provided host for a given time period and extracts all unique eMail sender addresses used. Based on the number of messages and the number of dierent sender addresses, the BlastServer decides if the suspicious host can be considered a Spammer or not. The reason, this sning step is performed at the server and not in the Spam detection module is, that the sensor is single threaded and would be blocked while sning the SMTP headers, thus, no other detected machines could be handled simultaneously. Furthermore, to support the distributed approach, the SMTP data gathering is handled in an external script (SpamSender.py), as one should be able to run the BlastServer on a dierent host.

93

Chapter 5. Blast-o-Mat tcpdump -l -n -nn -i eth0 -q -A -tt -s300 -c50 ( dst port 25 && tcp[20:4] = 0x4D41494C && src host 134.130.xxx.xxx) Figure 5.8.: Tcpdump command line Similar to the Blast-o-Mat Snier module, the script for capturing sender eMail addresses utilises tcpdump, with some special parameters (Figure 5.8) to gather the necessary information. The most important parameter is tcp[20:4] = 0x4D41494C, it instructs tcpdump to capture only packets, that contain the word MAIL in the header. The sender address is then extracted with the help of regular expressions. As a result, the script returns the number of unique sender addresses to the BlastServer. Figure 5.9 shows the command line options, that can be passed to the script. We are currently experimenting with the values that decide if a suspected host is to be considered a spammer or not. For this reason, one has to decide the number of dierent sender addresses a machine is allowed to use, according to the number of messages sent. For example, a host sending 50 mails, each with a dierent sender address, within a time period of 40 seconds, can be clearly considered a spammer. Whereas, a machine sending the same amout of mails, but using only 5 dierent sender addresses, is hard to decide. At the moment, the Blast-o-Mat simply counts the number of unique sender addresses, which is then subtracted from the number of mails, that were send during the sning period. If this dierence is less then ten and the overall number of unique sender addresses greater than four, we consider a machine as a spammer and send out a warning mail to the responsible person. As one can easily determine, these values are still experimental, for a machine, which sends 60 eMails with 40 dierent sender addresses would not be considered a spammer. Therefore, all cases are logged to the local syslog server in detail, to investigate each detected event and adjust the values accordingly. Parameter version help ip packets timeout getnumbers show Description Show program version number and exit. Show this message and exit. IP address of the host to monitor. Number of packets to capture. Number of seconds until sning is stopped. Return only the number of distinct sender addresses and eMails. Return a list of collected sender addresses.

Figure 5.9.: SpamSender.py command line options Unlike the PortScan module, the Spam detection sensor makes heavy use of whitelisting, to cover all the mailservers of the dierent institutes and residential homes. For this reason, the Spam detection module oers source and destination based whitelists. The source based whitelists are used for relaying mailservers and the destination whitelists are used for the public mailservers, intended to be used by users.

94

5.5. The Web Interface

5.5. The Web Interface

Considering, that the Blast-o-Mat is implemented as a distributed system with single modules working on dierent hosts, it was necessary to provide a single point for a network administrator to monitor detections and actions taken by the Blast-o-Mat software. For this purpose, we designed a web interface which shows the status of the complete system, as well as the status of each of the installed intrusion detection modules. Currently, the Blast-o-Mat system has three possible states while running. The rst state is called Grn, which means green in German. Accordingly, it is displayed in green letters and it indicates that there have been no incidents reported on the current day. The second state is called Gelb, which means yellow in German and it is coloured in yellow. This state advertises that attacks have been detected today by the Blast-o-Mat system. The last state is displayed, in case infected hosts are detected and currently active in the network, i.e. they have not yet been disconnected by the Blast-o-Mat. The status is called Rot, German for red and is highlighted with a red colouring. Figure 5.10 shows the complete layout of the web interface.

Figure 5.10.: Blast-o-Mat web interface In addition to the overall status, the website also provides the states of the intrusion sensors, which can be active or inactive. To retrieve the status of the separate modules, we have written a simple PHP script, which is executed every three minutes. The condition of the Snier module is determined by the timestamp of the last database entry. In case the latest row is older than sixty seconds, we can conclude that the sensor is not running. The status of the PortScan and the Spam detection modules are determined in a similar fashion, but in this case, the timestamp must not be older than four minutes. Since both sensors update their databases every three minutes, the four minute threshold is more than enough to determine the current state. To get the current status of the Nepenthes sensor, we establish a TCP connection to one of the vulnerability modules.

95

Chapter 5. Blast-o-Mat If a connection is established, we know the program is still running. Retrieving the state of the BlastServer is a little more complicated, for it does not update any database entries in a frequent manner. Furthermore, the BlastServer utilises the connectionless UDP protocol for remote communications, thus, we cannot check for an established connection, as it is done with Nepenthes. Therefore, we implemented a method used by common portscanners, to detect services running on UDP ports. We send an empty UDP packet to the port we want to probe and wait for a predened timeout. In case no reply is received within the dened time, we can assume that the port is open, i.e. a service is listening on that port. If the port is closed, a correctly congured system would return an Internet Control Message Protocol (ICMP) packet, stating that the destined port is unreachable. Besides the various status indicators, the website displays three tables. The rst table indicates the last 25 incidents that were discovered by the Blast-o-Mat. Each row shows the IP address of the infected host, the ports that were scanned or exploited, the anonymized account name, the type of event (Spammer, PortScan, Exploit) and the time when the host was conspicuous for the rst and for the last time. The other two tables shown on the web interface, display the accounts that have been temporarily disconnected and the ones that are permanently blocked. Thus, the network administrator gets a general view of all incidents that happened and the actions that were taken by the Blast-o-Mat system. Furthermore, the website provides additional information about circumstances reported by the Nepenthes intrusion sensors. The extra data comprises the output of the Norman Sandbox and the CWSandbox about captured malicious software, that was spread by the detected contaminated host. Finally, the website visualizes all unique events that were discovered. Therefore, two dierent graphs are periodically generated from the entries of the incident database of the Blast-o-Mat system. The rst graph displays all the events that happened during the last seven days and the second one gives an overview of the current year.

5.6. Results

Figure 5.11.: Overall detections of the Blast-o-Mat The Blast-o-Mat version 4 started detecting infected hosts of RWTH Aachen network in mid-March, working in parallel to the old release. In the beginning, it operated in warning mode only, thus leaving the disconnecting and locking to the previous version. Since end of May, the new Blast-o-Mat version 4 has successfully replaced its predecessor

96

5.6. Results and handles all incoming events. So far, 145 hosts were notied, due to massive port scanning, another 62 were warned, because of exploiting known vulnerabilities and 8 spammers were dunned (Figure 5.11). One reason for the great dierence in the detection ratio is that the PortScan sensor was the rst actively working module, followed by the Nepenthes sensor, which was operating with only two distinct IP addresses in the beginning. The last module that joined the Blast-o-Mat system, was the Spam detection sensor, which is operating for about four weeks now. Another reason is the relative small number of vulnerability modules, thus the detection ratio of the Nepenthes sensor is restricted. A short overview of the number of unique incidents discovered on dierent ports, by both the Nepenthes and the PortScan sensor, is displayed in table 5.13. In contrast to the results received from the standard Nepenthes sensors deployed at RWTH Aachen, we monitored the most incidents utilising port 135 of the Microsoft le sharing system. Although the Distributed Component Object Model (DCOM) Remote Procedure Call (RPC) vulnerability is long known and patches are available for almost three years, there are still many contaminated and vulnerable machines on the Internet. The software aw in the DCOM/RPC enables an attacker to gain complete control over a vulnerable Windows-based system, utilising one of the following TCP and UDP ports: 135, 139, 445 and 593. The infection sequence can be summarized as follows [Sec03]: The Attacker sends a packet to port 135 with the DCOM exploit code As a result, a remote shell is opened at port 4444 of the victim host The attacker sends the TFTP get command to the victim, using the shell on port 4444 The victim connects to the TFTP server at the attacking host and starts downloading the binary (msblast.exe MD5sum packed: 5ae700c1db00cef492844a4db6cd69 6176 Bytes) Figure 5.12 shows an excerpt of the Norman Sandbox report of a W32/Blaster.A worm captured by one of the Nepenthes sensors, which exploits the DCOM/RPC vulnerability. The PortScan module reported over seventy unique hosts scanning for port 135, during the time of the diploma thesis. The fact that the Nepenthes sensor detected almost the same number of exploiting hosts reveals that the thresholds used by the PortScan module are well chosen and provide an accurate detection mechanism. The results also show that vulnerability exploiting and port scanning are closely related, as in most cases the Blasto-Mat was triggered by both intrusion sensors, almost at the same time. Although, the PortScan module can, in contrast to the Nepenthes sensor, provide false-positives, it has proved to be a useful enhancement to the other intrusion modules. It detected a great number of hosts scanning for ports, that were not discovered by the other mechanisms before. The second most frequently hit port by infected hosts, is port 445. It belongs to the Microsoft le sharing ports, as well, and was triggered by about the same number of machines of RWTH network as port 135. Discovered in August 2004, the Local Security Authority Subsystem (LSASS) vulnerability, enables an attacker to execute remote code

97

Chapter 5. Blast-o-Mat
[ * * * General information ] Decompressing UPX. File length: 6176 bytes. MD5 hash: 5ae700c1dffb00cef492844a4db6cd69.

[ Changes to registry ] * Creates value "windows auto update"="msblast.exe" in key "HKLM\Software\Microsoft\Windows\CurrentVersion\Run". [ * * * * * * * * * Network services ] Looks for an Internet connection. Connects to "31.xxx.xxx.1" on port 135 (IP). Connects to "31.xxx.xxx.2" on port 135 (IP). Connects to "31.xxx.xxx.3" on port 135 (IP). Connects to "31.xxx.xxx.4" on port 135 (IP). Connects to "31.xxx.xxx.5" on port 135 (IP). Connects to "31.xxx.xxx.6" on port 135 (IP). Connects to "119.211.xxx.xxx" on port 4444 (IP). Starts remote TFTP session.

[ Security issues ] * Uses DCOM RPC vulnerability (MS03-026).

Figure 5.12.: W32/Blaster.A Norman Sandbox Report on a vulnerable host, thus taking full control over the system. One of the worms, which was frequently sighted, exploiting the LSASS vulnerability, is Worm.Sasser.B. Infected machines run a FTP server and regularly scan the network for more vulnerable systems. Similar to the W32/Blaster.A, the Sasser worm transmitts shellcode, which opens a remote shell on port 9996, to the victims to reload its binary. The name of the binary consists of four to ve digits and is suxed by the following characters: _up.exe. A detailed technical description can be found in the work of [Sym04b]. The third port, we monitored quite often, is 139. On this port listens the Network Dynamic Data Exchange (NetDDE) services of Microsoft Windows-based operating systems. A remote code execution vulnerability exists in this services, which, successfully exploited, enable an attacker to take full control of an aected system [Cor04a]. However, the NetDDE services do not run by default, thus they have to be manually started for an attacker to remotely exploit this vulnerability. The POC code for this vulnerability was released in 2004 and is publicly available. The reason, the Nepenthes sensor did not detect any of the malware contaminated hosts propagating via port 139, is that it was not running at this point in time. Another interesting port, which was detected, is 3127. This is the common backdoor port of the MyDoom worm, which was discovered for the rst time in January 2004. Although, the worm propagates by means of an infected eMail attachment, it has been called the fastest spreading eMail worm yet recorded, infecting one in every twelve messages [Fis04]. In case the attachement is executed, MyDoom opens a backdoor,

98

5.6. Results

Figure 5.13.: Detections per port by the Blast-o-Mat commonly on port 3127, on the victim host and waits for remote instructions. As the statistics show, only two systems of RWTH Aachen network have been detected as being contaminated, so far. However, the Nepenthes sensors with external IP addresses revealed a much large number of infected host scanning for this port in the Internet. The last port that was conspicuous, during the time of the thesis, was the Microsoft SQL server port 1433. In the year 2002 a worm called SQLSnake compromised masses of machines running the SQL server, as the default installation included an administrator account without a password set. For the server is able to run batch les and command line programs, it can be used to download and install malicious software [McW02]. As there was only one host ever detected utilising this port for scanning and the vulnerability is more than four years old, it might as well be a false-positive alert of the PortSan sensor. Although the Nepenthes sensor currently does not recognize exploits on all ports, due to missing vulnerability modules, it works as a great intrusion detection mechanism. The biggest advantage is its accuracy, as no false-positives are reported, and its modular structure which enables it to be extended in many ways, e.g. adapt to new vulnerabilities. Furthermore, the Nepenthes sensor currently operates with only 180 dierent IP addresses and provides already the same detection ratio as the other detection mechanisms deployed. This is less than 0.1% of the whole RWTH Aachen network, which has about 200.000 IP addresses. In contrast, the PortScan module utilises data which is read from a SPAN-port of a centralized router, thus receiving trac from all machines on the network. As the bandwith of future networks will increase, the amount of data passing through a Mirror port will drastically increase, as well. It might even become impossible to be handled by a single machine, whereas Nepenthes will still achieve the same quantitative results. In addition to the detection of contaminated hosts, we are also able to supply qualitative high-class reports for almost every incident, by utilising dierent

99

Chapter 5. Blast-o-Mat tools to analyse the collected malicious software. For example, the CWSandbox provides tremendous results in the area of malware behaviour analysis, thus greatly facilitating the process of cleaning infected hosts and raising the users security awareness.

5.7. Summary
In this chapter we have introduced the automated notication and handling system, called Blast-o-Mat. First, we provided a short overview of the previous releases and indicated some of their drawbacks, like the rigid and inexible structure which did not allow any integration of new sensor techniques. In the following section, we presented the features and concepts of the new Blast-o-Mat version 4, its distributed design and the XML based communication, which allows an easy integration of further intrusion detection sensors, like Nepenthes. Furthermore, the three main parts of the Blast-o-Mat system were explained: intrusion detection, notifying and handling of contaminated hosts. Moreover, we gave an in-depth view on the implementation and conguration of each of the dierent Blast-o-Mat modules (Snier, BlastServer, PortScan Sensor and Spam Sensor ), which form the complete distributed system. The Snier collects the necessary information for the PortScan and Spam detections sensors, to determine a hostile machine. In contrast to the Nepenthes sensor, the PortScan and Spam detection modules utilise a threshold based mechanism for detection. Information about the discovered contaminated machines is then transmitted to the BlastServer entity in terms of XML messages for further handling. The main steps of handling Blast-o-Mat events at the BlastServer can be summarized as follows: Determine the type of incident from the XML message. Extract additional information like time of event, IP address of hostile host and ports involved. Determine the network the hostile IP address belongs to. For example, VPN or administered host. Based on the subnet, determine the account and email address of the responsible person(s). Send out GPG signed warning/kick/block eMail. If a detected host utilises dynamically assigned IP addresses, the machine is temporarily disconnected after a congured time. Otherwise, it is immediately locked. If not already permanently disconnected, the host is locked after certain number of kicks. Finally, we presented the web interface, to visualize the actions taken by the Blasto-Mat and get a quick overview of the status of the dierent running modules, as well as, some statistical information. We concluded the chapter with a few results that were gathered during the second half of the diploma thesis. The results show that

100

5.7. Summary the Blast-o-Mat is a highly ecient mechanism to support network administrators of large scale networks with the handling of contaminated hosts. Additionally, it oers the possibility to be adjusted and extended in many ways to t the given network structure. Furthermore, the utilisation of the dierent intrusion sensors provided some interesting cognitions. For example, we noticed some contaminated hosts were massively sending eMails and were scanning for open ports simultanously. This concludes the utilisation of more than one spreading mechanism in todays malicious software.

101

Chapter 5. Blast-o-Mat

102

Chapter 6. Conclusion and Future Work

6.1. Introduction
In the previous chapters we introduced the Honeynet methodology to learn more about attack patterns and motives of dierent attackers. We presented the low-interaction Honeypot Nepenthes, and its exible modular structure, which allows it to be easily integrated into other security measures. Finally, we described the new automated notication and handling system at RWTH Aachen, called Blast-o-Mat. In the last chapter of the diploma thesis, we sketch some ideas on how the dierent concepts, that were presented, can be further extended and improved. The chapter is outlined as follows. The rst section illustrates some additional improvements for the Blast-o-Mat system, to further increase its eciency. Next, we present some ideas on how Honeynets can be used to gather more information on infected hosts and how low-interaction Honeypots, like Nepenthes, can be used as an application rewall. Finally, we conclude this thesis and give a summary of the results, we have obtained during the work on this thesis.

6.2. Future Work

6.2.1. Blast-o-Mat Extensions
Logle Sensor In the previous chapter we introduced the Blast-o-Mat system and described the various areas, where intrusion detection can take place. The current version implements two of the three presented methods. Namely, the monitoring of a SPAN-port and the use of Honeypot technology. Thus, it would be a great addition to the distributed system, to have a logle analysing Blast-o-Mat intrusion sensor. As a result, the Blast-o-Mat could also be eectively deployed in networks, with a large amount of log data originating from dierent sources and stored in centralized or various locations. This approach especially supports rewall systems that already utilise the syslog deamon, to log to a remote host and whose policy does not allow the installation of additional software running on the rewall host.

103

Chapter 6. Conclusion and Future Work To achieve the goal of a logle based sensor, a new event type needs to be created at the BlastServer, together with a new function to handle the incoming requests. The main diculty is to gather the needed sample lines that are transmitted with the warning eMails of the Blast-o-Mat to an oending host and serve as a proof, that the incident happened. To solve the problem there exist some dierent methods, of which we present three: The easiest approach would be to write all incident data, collected by the logle parsing sensor, directly to the Snier database. That would allow the Blast-o-Mat to utilise its common sample gathering method, implemented in the BlastHelper class, to collect the needed rows. The rather small drawbacks of this method are, that the database server needs to be reachable from the centralized logging host or whatever host a logle based sensor is running on and the sample lines have to be adjusted to t the database format. The second approach utilises its own database host for information storage. In this case, all data can be stored in a dierent format, which provides more customization. Then again, the Blast-o-Mat needs to be extended to access the additional database server and a new function for sample gathering needs to be implemented. The last presented method uses the XML event messages to submit the sample lines to the Blast-o-Mat server. In this case, the Document Type Denition needs to be extended to support the transmission of incident example rows. Therefore, we create a new element, called <Samples>. The new element holds all sample lines to be delivered, separated by a predened character. Additionally, we need to write a new function in the BlastServer to extract the submitted data. All three methods have their advantages and disadvantages. Therefore, it depends on the given infrastructure, network policy, and likings of the administrators, to determine which one to use. Another, more dicult task, is to support the dierent logging formats used by applications. Therefore, a method needs to be implements that allows to parse logles of various formats, like the one generated by IPTables. One possible solution is to use regular expressions to match and extract the needed information. Sliding Incident Window Currently, the PortScan and Spam intrusion detection sensors analyse the Snier database in regular congurable time periods. At RWTH Aachen, for example, we parse the information stored in the Snier database of the last three minutes, at three minute intervals. As a result, detection of infected hosts does not occur in realtime, but in the worst case, with a three minute delay. Therefore, a sliding window of a predened size, is more eective. For example, the PortScan module could generate an event, as soon as the number of distinct contacted host, within the sliding window, has reached the congured threshold. Thus, one does not have to wait for the three minute interval to be over. As a result, contaminated hosts are instantly detected and countermeasures can be immediately initiated to protect the network.

104

6.2. Future Work

6.2.2. Quarantine Honeynet

The current Blast-o-Mat version is capable of redirecting conspicuous hosts to an information website, to eectively inform the owner about the infection. During the time of the diploma thesis, we additionally analysed the logles of this webserver, the machines are redirected to. In this context, we accidently stumbled over the biggest incident discovered during the whole time of the diploma thesis that not only aected hosts of RWTH network, but also from dierent other service providers, such as NetCologne and Deutsche Telekom. On April 27th, 2006, we were monitoring an infected machine from the wireless network MoPS, which was redirected by the Blast-o-Mat to our quarantine webserver. For we were still performing tests on the BlastServer and to verify the correctness of the redirection script, we additionally watched the access and error logs of the webserver. During that time, we discovered frequent contacts of the contaminated host to a distant server that were lling our error logle. The following HTTP request was issued by the infected machine several times: GET /deuser/data.php?param=cmd&socks=0 HTTP/1.0. Therefore, we took a closer look at the server that was to be contacted by our contaminated machine and discovered more than 280MB data worth of customer credentials. All data was collected during a time period of three days. This data included passwords to web mail accounts (GMX, Hotmail, Yahoo, GoogleMail, web.de, etc.), eBay passwords, login information for several service providers (Acor, T-Online, NetCologne, etc.), and online banking data (DAB Bank, Volksbank Raieisenbank, Postbank, Sparkasse, etc.), such as account and Personal Identication Numbers (PIN) of many dierent customers. Altogether, we found more than 40.000 entries, with unique IP addresses. Moreover, we discovered about 26.000 rows containing the word bank and another 1.310 entries with the word pin=. In this context, we discovered 281 unique account numbers, 278 PIN numbers and additional 431 Transaction Numbers (TAN). Besides these highly critical information, we also found login information of RWTH students to the campus system, which for example allows the registration to examinations and seminars. As this was a very volatile situation, we immediately informed the DFN CERT about the incident. Further aected facilities and users were contacted by the DFN CERT. For example, the Bundeskriminalamt (BKA), who were ascertaining in a similar case, which might be linked to ours. Additionally, the Sparkasse CERT was informed, as several of their customers account numbers, PINs, and TANs were listed in the above mentioned logles. Finally, we examined the infected host that was detected by both the Blast-o-Mat PortScan sensor and the Nepenthes intrusion sensor. The analysis discovered two hidden les on the machine, that were not detected by the installed virus scanner:
C:\WINDOWS\system32\xcdkernl.sys C:\WINDOWS\system32\xcdmfree.dll 27.4.2006 13:14 6.61KB 27.4.2006 13:14 16.55KB HiddenfromWindowsAPI. HiddenfromWindowsAPI.

Additionally, we received the Norman Sandbox analysis from the Nepenthes sensor. Based on the dierent reports and virus scanner outputs, we concluded that the host was infected with a variant of the Goldun Trojan. This family of trojan horse programs steals user information entered on online web forms for authentication and uses Rootkit

105

Chapter 6. Conclusion and Future Work technology for cloaking purposes, as well. As a result of this incident, we continued to actively monitor the quarantine webserver logles. As shown in the case above, it can be of interest to not only disconnect contaminated hosts, to prevent other systems from getting infected, but also to analyse the conspicuous machine output, to discover if any critical data is transmitted to a remote system. For this reason, it would make sense to not only redirect HTTP trac to a special webserver, as it is done by the Blast-o-Mat, but to also place the conspicuous host into a quarantine Honeynet. This Honeynet should consist of a special DNS server, that resolves any requests to one single host, specially prepared with several logging facilities. This host could run a low-interaction Honeypot, like Nepenthes, but also some standard services, like an IRC server or a modied mailserver that stores incoming mails for further analysis (the vuln-smtp module could be used for this purpose, as well) to gather as much data from the infected host, as possible. The resulting information could help to successfully clean the contaminated machine and to discover such cases, like the one described above. Furthermore, it is possible to automatically release previously infected hosts from the quarantine Honeynet, if they have not been conspicuous for a certain online time. A Virtual Local Area Network (VLAN) could be used to build a quarantine Honeynet. As soon as a host is detected by the Blast-o-Mat, the VLAN tag for this machine is changed to the tag of the Honeynet. As a result, all trac is redirected. The major drawback of this concept is that it requires the network infrastructure to allow access to the switch port of each host and additionally the switch must support VLAN tagging of certain ports.

6.2.3. Honeynet-based Firewalls

As the low-interaction Honeypot Nepenthes is modular and, therefore, can be easily extended to new vulnerabilities, it would be an interesting eld of research to use it as some kind of rewall. The idea is to set up a Nepenthes host in front of an oered service, emulating vulnerabilities of the very same service. The Honeypot should be modied in such a way, that known exploit attempts are ltered out, before they even reach the destined application. That means, every connection, that is established to a public service, has to pass the Nepenthes machine at rst. Although, this approach does not prevent new software aws from being exploited, the vulnerability modules of Nepenthes can be quickly adjusted to new threats, as we have shown in chapter 4. As a result, one is able to protect the host of vulnerable applications from being compromised, as long as there are no new versions or patches available to x the security issue. Additionally, malicious software is collected, which can be further analysed to eciently clean already contaminated machines.

106

6.3. Conclusion

6.3. Conclusion
In this diploma thesis, we have introduced the concept of Honeynets as a research system to gain knowledge about an attackers motives, tools and techniques. A Honeynet is a network of Honeypots, which oer certain features especially attractive to intruders. These electronic baits are designed to lure attackers and inveigle them to compromise and misuse it. As a result, one is able to study the tactics and behaviour of the enemy. During the time of the thesis, our Honeynet was attacked and conquered several times. Two interesting incidents were presented in detail, as well as many dierent utilities that were involved, were thoroughly analysed. Although, no new vulnerabilities were discovered, we were still able to gain an insight view on attack patterns and misuse of machines in the area of phishing, unsolicited bulk eMail, and privilege escalation. On the contrary, we presented the low-interaction Honeypot Nepenthes, and how it can be used, to take an active part in securing large scale networks, like the campus network of RWTH Aachen. We described the modular and exible structure of Nepenthes and showed how it can be easily extended in several ways, thus, making it a valuable tool for many dierent elds of applications. We presented the vuln-exchangepop3 module as an example how to write new vulnerability modules for Nepenthes utilising a published Proof of Concept (PoC) code. Furthermore, several logging modules including the log-blastomat module which serves as an interface to the Blast-o-Mat system, were illustrated. In addition, we showed two new elds of application for Nepenthes, one in the area of password security (vuln-logssh) and the second one in the area of SPAM detection (vuln-smtp). Each provided interesting results that need to be further investigated in the future. Finally, we presented the new Blast-o-Mat version 4, which has proven to be a worthy successor of the previous release. Several new features, including Nepenthes as an intrusion detection sensor, were introduced. We described the three main parts of an automated notication and handling system: intrusion detection, owner notication and handling of infected hosts, and showed how each part is implemented in the Blast-o-Mat system. Furthermore, we explained the XML based intermodule communication, which allows an easy integration of further detection mechanisms, as it is shown in the future works chapter. Each module, participating in the Blast-o-Mat system, is build as a standalone program with its own conguration le, thus, they can operate in dierent locations of a network infrastructure. The distributed approach allows the system to be setup in many ways, depending on the given environment. At RWTH Aachen, we utilise two machines, one is connected to the SPAN-port of a centralized router and therefore holds the Snier module and currently also the BlastServer program. The underlying database, the web interface, as well as all three intrusion sensors run on the second machine, with no performance loss at all. Ultimately, we presented some of the outstanding results, that were achieved with the Blast-o-Mat system during the time of the diploma thesis. Moreover, we showed that the thresholds chosen for the PortScan detection module, were wisely elected, as no hosts were falsely suspected. Furthermore, Nepenthes proved to be a great enhancement to the distributed Blast-o-Mat system and, although, using only few sensor IP addresses, it was able to achieve the same quantitative detection ratio as the other sensor mechanisms. As a conclusion, we can say that all three

107

Chapter 6. Conclusion and Future Work intrusion sensors together form a great team in detecting and handling contaminated machines on a large scale network. In summary, we showed that both high and low-interaction Honeypots can be successfully applied to the rambling area of network security. The rst, provided a promising approach to learn more about attack patterns and attacker behaviour, whereas the latter delivered tremendous results in the area of intrusion detection. In the future, both approaches need to be developed further to gain more knowledge on the behaviour, tools, and techniques used by adavanced attackers, as well as, successfully ght criminals on the Internet.

108

Appendix A. Additional Tools

In this chapter, we present two additional tools, that were developed during the time of the diploma thesis.

ndFiles
The ndFiles utility was developed to facilitate the process of computer forensics on a compromised host. The main purpose of this tool is to eciently nd all les, that were created, modied or last accessed on a certain date. As a result, one is able to quickly determine which les to investigate further. If no date is provided to the tool, it displays all les of a given directory. Thus, it can be used as a substitute for the ls command, which in some cases might be trojaned. Additionally, the tool provides the possibility to compress all found data using gzip. Therefore, one can nd all les of a certain date, compress them in a single le and transfer it to another machine for further analysis. For example, the gathering of all logles in the /var/log directory of a Linux host, which is essential in evidence collection, can be accomplished, with the help of this tool, in one step. Figure A.1 shows a list of available command line options, that can be passed to the script. Parameter version help creationTime modiedTime accessTime directory gzip lename Description Show program version number and exit. Show this message and exit. Find les with creation date Year/Month/Day. Find les with modied date Year/Month/Day. Find les with accessed date Year/Month/Day. directory to search for les. Gzip result instead of displaying. Filename for gzipped le (+ .tar.gz).

Table A.1.: ndFiles command line options The utility is written in Python and can, although not tested yet, be used on both Linux and Microsoft Windows based operating systems. The major drawback of ndFiles is, that it needs a rather up to date version of Python installed, as it uses modules for option parsing and compression. On the other hand, the script language allows the

109

Appendix A. Additional Tools tool to be easily customized to t additional needs. The current available version of this utility is 0.1, as it has not been thoroughly tested yet. Future versions of this tool should also be capable of providing basic functionality without the presence of the above mentioned modules. So it can be executed on Honeypots running more outdated operating systems.

getHosts
The getHosts utility serves as a standalone alerting mechanism for machines running the low-interaction Honeypot Nepenthes, with the log-mysql module installed. The tool is capable of browsing the database tables for connections made to the Honeypot, belonging to certain IP address ranges. As a result, an eMail is sent to a predetermined address, containing the abuse contact and a few gathered log lines of a suspected host. MySQL settings IP address of the MySQL server. The name of the database where all input is stored. The username with write privileges for the previously dened MySQL database. The password for the user declared above. getHosts settings List of IP addresses or network ranges to look for, while browsing the log-mysql database tables. Denes the number of hours a database entry can be old, in order to still send out a warning eMail. Sender address of the warning eMails. eMail address all replies will be send to. Recipient address of the warning eMails. IP address of the mailserver. Port of the mailserver. Table A.2.: getHosts conguration The conguration le for the getHosts Python script is shown in table A.2. The tool currently checks for each dened IP address, if it occurs in one of the following database tables: nepenthes_connections, nep_download_hosts and nepenthes_cwsandbox. Thus, we can search for machines that connected to the low-interaction Honeypot, were used as a download host for malicious software or occurred in the analysis report of the CWSandbox. To speed up the detection process, the script utilises the rst two digit pairs of an IP address. For example, if one wants to nd all hosts of the following network range 128.7.0.0/16, instead of checking for each host, the tool searches for occurrences of 128.7. in the above mentioned tables. Furthermore, to minimize the number of entries to inspect, an additional attribute, named warned, was added to the database structure, to skip notication of hosts that have already been warned. Additionally, the conguration parameter HoursAgo further restricts the search. Although, the use of the IP address prex for detection might reveal more than the desired hosts, the tremendous speed up

MySQLHost MySQLDB MySQLUser MySQLPass Hosts HoursAgo mailFrom mailReplyTo mailTo smtpServer smtpPort

110

justies this rather small drawback. To obtain the abuse contact of a suspicious host, the Linux command whois is executed. The resulting output is then parsed to extract the appropriate eMail addresses. As we cannot be sure to retrieve a correct contact address for each host, outgoing mails are sent to a congured eMail address, to be approved and forwarded to the responsible persons by a network administrator. The message body contains both the abuse contact and a few sample log lines. The script is still in its development phase, thus, the searching for hosts occurring within the CWSandbox analysis report is not yet fully implemented. The tool is currently setup at the RWTH Aachen to check for hosts with IP addresses registered to the DFN. Up to now, we were able to detect three contaminated hosts with the help of this tool. Each responsible person was informed via eMail, but we did not receive any feedback, yet.

111

Appendix A. Additional Tools

112

Appendix B. Images

Figure B.1.: PHP script to send SPAM eMails

113

Appendix B. Images

Figure B.2.: PHP script to send phishing data to the attacker

Figure B.3.: Sebek data (40 minutes behind actual time)

114

Figure B.4.: SSH scanner startup script by Methadon

115

Appendix B. Images

Figure B.5.: Module: log-mail

116

nepenthes-addbf9ed2c98ba70f728a19b5154b559-winxirasdf.exe : [SANDBOX]contains a security risk - W32/Spybot.gen3 (Signature: W32/Spybot.AJYI) [General information] **Locates window "NULL [class mIRC]" on desktop. File length: 120832 bytes. MD5 hash: addbf9ed2c98ba70f728a19b5154b559. [Changes to lesystem] Creates le C:\WINDOWS\SYSTEM32\xagwxzyrxbce.exe. Deletes le 1. [Changes to registry] Creates value "Windrive service"="xagwxzyrxbce.exe" in key "HKLM\Software\Microsoft\ Windows\CurrentVersion\Run". Creates value "Windrive service"="xagwxzyrxbce.exe" in key "HKLM\Software\Microsoft\ Windows\CurrentVersion\RunServices". Creates key "HKCU\Software\Microsoft\OLE". Sets value "Windrive service"="xagwxzyrxbce.exe" in key "HKCU\Software\Microsoft\OLE". [Network services] Looks for an Internet connection. Connects to "218.38.xxx.xxx" on port 7000 (TCP). Connects to IRC Server. IRC: Uses nickname Qq-803400248826. IRC: Uses username ezkieyacagizle. IRC: Joins channel #n with password .n.. [Security issues] Possible backdoor functionality [Authenticate] port 113. [Process/window information] Creates a mutex uot2. Will automatically restart after boot (Ill be back...). [Signature Scanning] C:\WINDOWS\SYSTEM32\xagwxzyrxbce.exe (120832 bytes) : W32/Spybot.AJYI.

Figure B.6.: Analysis Output of the Norman Sandbox

117

Appendix B. Images

Figure B.7.: Blast-o-Mat Snier main loop

118

Figure B.8.: Blast-o-Mat PortScan detection stages

119

Appendix B. Images

Hallo, der Blast-o-mat, ein zur Identifizierung virenverseuchter Rechner aufgesetztes Eindringlings-Detektions-System der RWTH Aachen, hat Ihren Rechner als infiziert gemeldet. Bei dem Schdling handelt es sich um einen Virus oder Wurm, der sich direkt ber das Netzwerk verbreitet. Ihr Rechner ist auffllig geworden, da er sogenannte Portscans auf unten angegebenen Ports durchfhrt [7]. Ihr System wurde verseucht, weil wahrscheinlich die von Microsoft [1] verffentlichten Sicherheitshinweise vernachlssigt und die dort angegebenen Patches und Servicepacks nicht eingespielt wurden. Auch "schwache" bzw. nicht gesetzte Passwrter knnen die Ursache sein. Bitte nehmen Sie den Rechner UMGEHEND vom Netz und entfernen Sie den Virus mit einem geeigneten Werkzeug [2]. Spielen Sie ebenfalls die von Microsoft angegebenen Patches ein. Installieren Sie einen Virenscanner [3] bzw. stellen sicher, dass ein schon bei Ihnen installierter auf aktuellem Stand ist und regelmig automatisiert ein Update der Virenkennungen durchfhrt. Sollten Sie weitere Hilfe bentigen, steht Ihnen unser Helpdesk [4] gerne zur Verfgung. Auch eine Entsperrung eines evtl. gesperrten Accounts knnen die Mitarbeiter vom Helpdesk vornehmen. Weitere und aktuelle Informationen finden sie auf unserer Homepage [5]. Gruss, der Netzbetrieb der RWTH (Andreas Schreiber, Jens Hektor, Thomas Bttcher, Silvia Leyer) P.S. Diese Email wurde automatisch erstellt vom Blast-o-mat [6]. [1] http://www.microsoft.com/security/ [2] Geeignete Werkzeuge finden Sie zum Beispiel hier: http://www.sophos.de/support/disinfection/ http://securityresponse.symantec.com/avcenter/tools.list.html [3] http://www.rz.rwth-aachen.de/computing/sw/sophos/index.php [4] http://www.rz.rwth-aachen.de/kommunikation/betrieb/dialup/kontakt.php [5] http://www.rz.rwth-aachen.de/rztop/hilfe/sicherheit.php [6] Der Blast-o-mat ist eine Entwicklung der Abteilung Kommunikation des Rechen- und Kommunikationszentrums der RWTH Aachen. [7] Accounting Daten und Kontaktversuche zu anderen Rechnern:

Figure B.9.: Message body of a Blast-o-Mat warning eMail

120

Figure B.10.: Blast-o-Mat BlockMac.py script

121

Appendix B. Images

122

Bibliography
[Ale01] [All02] [All03] Andrei Alexandrescu. Modern C++ Design. 2001. Honeynet Alliance. The Google Hack Honeypot. 2002. http://ghh.sourceforge.net/, Accessed: 2006. The Honeynet Project & Research Alliance. Know Your Enemy: Automated Credit Card Fraud. 2003. http://www.honeynet.org/papers/profiles/cc-fraud.pdf. The Honeynet Project & Research Alliance. Know Your Enemy: Phishing. 2005. http://honeynet.org/papers/phishing/. The Honeynet Project & Research Alliance. Know Your Enemy: Tracking Botnets. 2005. http://www.honeynet.org/papers/bots/. Todd Atkins. SWATCH: The Simple WATCHer of Logles. http://swatch.sourceforge.net/, Accessed: 2006. George Bakos. Tiny Honeypot - resource consumption for the good guys. 2002. http://www.alpinista.org/thp/. Tod Beardsley. OS Fingerprinting through RTOs. 2002. http://www.planb-security.net/wp/ring.html, Accessed: 2006. Daniel J. Bernstein. SYN cookies. 1996. http://cr.yp.to/syncookies.html. Ivan Buetler. Linux ptrace Root Exploit. Compass Security AG, 2003. Carter Bullard. Audit Record Generation and Usage System. 2000. http://www.qosient.com/argus/argus.8.htm, Accessed: 2006. Edward Balas and Camilo Viecco. Towards a Third Generation Data Capture Architecture for Honeynets. 2005. CERT R . Advisory CA-2001-26 Nimda Worm. 2001. http://www.cert.org/advisories/CA-2001-26.html. Carlos Chaves, Lucio Franco, and Antonio Montes. Honeynet Maintenance Procedures and Tools. 2005.

[All05a]

[All05b]

[Atk] [Bak02]

[Bea02] [Ber96] [Bue03] [Bul00] [BV05] [CER01] [CFM05]

123

Bibliography [Che91] [Chu03] Bill Cheswick. An Evening with Berferd. 1991.

http://www.deter.com/unix/papers/berferd_cheswick.pdf.

Anton Chuvakin. An Overview of Unix Rootkits. iDefense Labs, 2003.

http://www.rootsecure.net/content/downloads/pdf/unix_rootkits_ overview.pdf.

[CL00] [Coh97] [Com06] [Cor03a]

David Caraballo and Joseph Lo. The IRC Prelude. 2000. http://www.irchelp.org/irchelp/new2irc.html. Fred Cohen. The Deception Toolkit. 1997. http://all.net/dtk/faq.html. Gerald Combs. WireShark. 2006. http://www.wireshark.org. Microsoft Corporation. TCP/IP. 2003. Explanation of the Three-Way Handshake via

http://support.microsoft.com/kb/172983/.

[Cor03b]

Microsoft Corporation. Microsoft Security Bulletin MS03-026. Microsoft Corporation, 2003. http://www.microsoft.com/technet/security/bulletin/ms03-026.mspx. Microsoft Corporation. Microsoft Security Bulletin MS04-031. 2004.
http://www.microsoft.com/technet/security/bulletin/ms04-031.mspx.

[Cor04a] [Cor04b]

Microsoft Corporation. Microsoft Security Bulletin MS04-044. Microsoft Corporation, 2004. http://www.microsoft.com/technet/security/bulletin/ms04-044.mspx. Maximillian Dornseif, Thorsten Holz, and Christian N. Klein. NoSEBrEaK - Attacking Honeynets. 2004. Wilhelm Dolle. Intrusion Detection und digitale Forensik am Beispiel von Rootkits. 2003. http://www.dolle.net/slides/Rootkits_Uni_Potsdam_2003.pdf. eEye Digital Security. .ida "Code Red" Worm. 2001.
http://www.eeye.com/html/research/advisories/AL20010717.html.

[DHK04] [Dol03]

[eDS01]

[FHW05] Felix Freiling, Thorsten Holz, and Georg Wicherski. Botnet Tracking: Exploring a Root-Cause Methodology to Prevent Distributed Denial-of-Service Attacks. Springer-Verlag, 2005. http://pi1.informatik.uni-mannheim.de/publications/show/83. [Fis04] [Fou] Dennis Fisher. MyDoom E-Mail Worm Spreading Quickly. 2004. http://www.eweek.com/article2/0,1895,1463599,00.asp. Python Software Foundation. The Python Programming Language. http://www.python.org, Accessed: 2006.

124

Bibliography [Fou03] [FrS05] Free Software Foundation. GNU Privacy Guard. 2003. http://www.gnupg.org/(en)/index.html. FrSIRT. phpAdsNew XML-RPC Library Remote Code Execution Vulnerability. 2005. http://www.frsirt.com/english/advisories/2005/0934. Bundesamt fr Sicherheit in der Informationstechnik. Denial of Service Attacken. http://www.bsi-fuer-buerger.de/abzocker/05_04.htm, Accessed: 2006. Fyodor. Remote OS detection via TCP/IP Stack FingerPrinting. 2002. http://www.insecure.org/nmap/nmap-fingerprinting-article.html, Accessed: 2006. Anti-Phishing Working Group. What is Phishing and Pharming. 2006. http://www.antiphishing.org/. Red Hat. Pluggable Authentication Modules. 2006. http://www.kernel.org/pub/linux/libs/pam/. Jens Hektor. Anti Spoong rules for Cisco-boxes. http://www.securityfocus.com/tools/1691, Accessed: 2006. Jens Hektor. Intrusion Detection, Notifying und Handling - Beitrag zu einem automatisierten Ansatz. 2006. Ralf Hofstetter. Honeypots mit dynamisch erzeugten Angriszielen zur Tuschung von potentiellen Angreifern. 2004. Diploma Thesis. Thorsten Holz. Learning More About Attack Patterns with Honeypots. 2005. Thorsten Holz. New Fields of Application for Honeynets. 2005. Diploma Thesis. Thorsten Holz and Frederic Raynal. Detecting Honeypots and other suspicious environments. 2005.

[fSidI]

[Fyo02]

[Gro06] [Hat06] [Hek] [Hek06] [Hof04] [Hol05a] [Hol05b] [HR05]

[HSBR99] S. Handelman, S. Stibler, N. Brownlee, and G. Ruth. New Attributes for Trac Flow Measurement. 1999. http://www.rfc-editor.org/rfc/rfc2724.txt, Accessed: 2006. [JLM] Van Jacobson, Craig Leres, and Steven McCanne. tcpdump. http://www.tcpdump.org, Accessed: 2006.

[KBH+ 06] Markus Koetter, Paul Baecher, Thorsten Holz, Felix Freiling, and Maximillian Dornseif. The Nepenthes Platform: An Ecient Approach to Collect Malware. Lecture Notes in Computer Science. Springer, 2006. [Kel06] [Ken96] Stefan Kelm. Honeypots und Honeywall in der Praxis. 2006. Malachi Kenney. Ping of Death. 1996.
http://www.insecure.org/sploits/ping-o-death.html.

125

Bibliography [KGO05] [Koh02] Sven Krasser, Julian Grizzard, and Henry Owen. The Use of Honeynets to Increase Computer Network Security and User Awareness. 2005. Jan Kohlrausch. Schutz vor Buer-Overow und Format-String Schwachstellen. 2002. http://www.cert.dfn.de/dfn/berichte/db093/kohlrausch-buffer.pdf. Christian Kreibich. Honeycomb - Automated IDS Signature Creation using Honeypots. http://www.cl.cam.ac.uk/~cpk25/honeycomb/, Accessed: 2006. Kaspersky Lab. Virus Enzyklopdie: Malware Typen. 2006.
http://www.viruslist.com/de/viruses/encyclopedia?chapter=152540403.

[Kre]

[Lab06] [Mas06]

Securma Massine. Exchangepop3 v5.0 remote exploit. 2006.

http://packetstormsecurity.org/0602-exploits/expl5.txt.

[McW02] Brian McWilliams. SQLsnake Worm Blamed For Spike In Port 1433 Scans. 2002. http://www.securityfocus.com/news/429. [Mil01] [Mox02] [Mue05] [NFS98] [Nor06] [oIS04] Toby Miller. Analysis of the KNARK Rootkit. 2001. http://www.ouah.org/tobyknark.html. Moxon. MoxQuizz. 2002.
http://developer.berlios.de/projects/moxquizz/, Accessed: 2006.

Sven Mueller. Planung und Realisierung eines Honeynet zur Analyse realer Angrie aus dem Internet. 2005. Diploma Thesis. Verizon NFS. NetFacade. 1998.
http://www22.verizon.com/fns/solutions/netsec/netsec_netfacade.html.

Norman. Norman Sandbox Information Center. 2006. http://sandbox.norman.no. Oce of Information Security. WU-FTP 2.6.0 Buer Overow. 2004.
http://www.infosec.uga.edu/soc/ips/attackEncyclopedia/docs/ 0x40502400.html.

[One00] [Par00] [Par03] [Pos81] [Pro00]

Aleph One. Smashing The Stack For Fun And Prot. 2000.
http://doc.bughunter.net/buffer-overflow/smash-stack.html.

Chris Parker. Using Swatch for Log Analysis. 2000.

http://www.linuxsecurity.com/content/view/117281/50/.

Keith Parkansky. How to Set up a Debian Linux Syslog Server. 2003. John Postel. Internet Control Message Protocol. 1981. http://www.networksorcery.com/enp/RFC/Rfc792.txt. The Honeynet Project. Know Your Enemy: Motives. 2000. http://www.honeynet.org/papers/motives/.

126

Bibliography [Pro01] [Pro02] [Pro03a] The Honeynet Project. Know Your Enemy: Revealing the Security Tools, Tactics, and Motives of the Blackhat Community. Addison Wesley, 2001. The Honeynet Project. Know Your Enemy: Passive Fingerprinting. 2002. http://project.honeynet.org/papers/finger/. The Honeynet Project. Know Your Enemy: Dening Virtual Honeynets. 2003. http://www.honeynet.org/papers/virtual/index.html. The Honeynet Project. Know Your Enemy: Sebek. 2003. http://www.honeynet.org/papers/sebek.pdf. The Honeynet Project. Know Your Enemy. 2005. http://www.honeynet.org/. The Honeynet Project. Know Your Enemy: GenII Honeynets. 2005. http://www.honeynet.org/papers/gen2/index.html. The Honeynet Project. Know Your Enemy: Honeywall CDROM Roo. 2005. http://www.honeynet.org/papers/cdrom/roo/index.html. Openwall Project. John the Ripper. 2006. http://www.openwall.com/john/. Niels Provos. Developments of the Honeyd Virtual Honeypot. 2006. http://www.honeyd.org/. Jerey Richter. Load Your 32-Bit DLL into Another Processs Address Space Using INJLIB. Microsoft Corporation, 1994. http://www.microsoft.com/msj/backissues86.aspx. Jonathan Rose. Loadable Kernel Module Rootkits deployed in a honeypot environment. 2003. Counterpane Internet Security. Security Alert: Microsoft RPC DCOM Worm. 2003. http://www.counterpane.com/alert-v20030811-001.html. SecurityFocus. 2004. phpMyAdmin Remote Command Execution Vulnerability.

[Pro03b] [Pro05a] [Pro05b] [Pro05c] [Pro06a] [Pro06b] [Ric94]

[Ros03] [Sec03]

[Sec04]

http://www.securityfocus.com/bid/11391/info.

[Sec06a]

SecurityFocus. Horde Help Viewer Remote PHP Code Execution Vulnerability. 2006. http://www.securityfocus.com/bid/17292/info. SecurityFocus. NewsPortal Remote PHP Script Code Injection Vulnerability. 2006. http://www.securityfocus.com/bid/18000/info.

[Sec06b]

127

Bibliography [Sec06c] SecurityFocus. Russcom Ping Remote Arbitrary Command Execution Vulnerability. 2006. http://www.securityfocus.com/bid/18090/info. SecurityFocus. SmartISoft phpListPro Cong.PHP Remote File Include Vulnerability. 2006. http://www.securityfocus.com/bid/17448/info. SecurityFocus. WarFTPD WDM.EXE Remote Buer Overow Vulnerability. 2006. http://www.securityfocus.com/bid/17803/info. VMWare Server. Free Virtualization for Windows and Linux Servers. http://www.vmware.com/server/, Accessed: 2006. Raul Siles. Sebek 3: tracking the attackers part one. 2006. http://www.securityfocus.com/infocus/1855. Raul Siles. Sebek 3: tracking the attackers part two. 2006. http://www.securityfocus.com/infocus/1858. Dr. Eugene Spaord and Gene Kim. Tripwire. http://www.tripwire.com/, Accessed: 2006. Ed Skoudis. Counter Hack - A Step-by-Step Guide to Computer Attacks and Eective Defenses. Prentice Hall PTR, 2002. Sophos. Sophos Virenlexikon. 1999.
http://de.sophos.com/security/analyses/w32kriz.html.

[Sec06d]

[Sec06e]

[Ser] [Sil06a] [Sil06b] [SK] [Sko02] [Sop99] [Spi02] [Spi03] [Sto90] [SW00] [Sym99]

Lance Spitzner. Honeypots, Tracking Hackers. 2002. Lance Spitzner. Honeypots: Denitions and Value of Honeypots. 2003. http://www.csd.uoc.gr/~gvasil/stuff/honeypots/honeypots.html. Cliord Stoll. The Cuckoos Egg. Pocket Books, 1990. Greg Sandoval and Troy Wolverton. Leading Web Sites under Attack. 2000. http://news.com.com/2100-1017-236683.html. Symantec. Symantec Decoy Server. 1999.
http://enterprisesecurity.symantec.com.au/Content/displaypdf.cfm? PDFID=760.

[Sym04a] Symantec. W32.Mumu.B.Worm. 2004.

http://www.symantec.com/security_response/writeup.jsp?docid= 2003-062615-5107-99.

[Sym04b] Symantec. W32.Sasser.B.Worm. 2004.

http://www.symantec.com/region/de/techsupp/avcenter/venc/data/de-w32. sasser.b.worm.html.

128

Bibliography [Sym05] Symantec. W32.Pin. 2005.

http://www.symantec.com/security_response/writeup.jsp?docid= 2003-011708-2030-99.

[Sys99]

Cisco Systems. Introduction to Internet. 1999.

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/introint. htm.

[Tal05a] [Tal05b] [Tal05c] [Tan03] [Tea] [VCH02]

Ryan Talabis. Honeypots: A Brief History of Honeypots. 2005.

http://www.philippinehoneynet.org/docs/Honeypot101_history.pdf.

Ryan Talabis. A Primer on Honeynet Data Capture Requirements. 2005. http://www.philippinehoneynet.org/papers.php. Ryan Talabis. A Primer on Honeynet Data Control Requirements. 2005. http://www.philippinehoneynet.org/papers.php. Andrew S. Tanenbaum. Computernetzwerke. Pearson Education, 2003. Netlter Core Team. Internet Protocoll Tables Project.
http://www.netfilter.org/projects/iptables/index.html, Accessed: 2006.

Franck Veysset, Olivier Courtay, and Olivier Heen. New Tool and Technique For Remote Operating System Fingerprinting. 2002. http://www.intranode.com/en/pdf/techno/ring-full-paper.pdf, Accessed: 2006. Anthony A. Verstraete. Data Communications Protocols In-Depth. 1998. http://www.smeal.psu.edu/misweb/datacomm/ID/ID_PROTO.HTM. George Wicherski. Medium Interaction Honeypots. 2006. http://www.pixel-house.net/midinthp.pdf. Carsten Willems. Automatic Behaviour Analysis of Malware. 2006. Diploma Thesis. Robert L. Ziegler. Linux-Firewalls: Konzeption und Implementierung fr Netzwerke und PCs. Markt+Technik Verlag, 2003.

[Ver98] [Wic06] [Wil06] [Zie03]

129