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.