© astoria, Fotolia.com

Forensik muss sich nicht nur in abgeschirmten Laboren abspielen, nachdem alles vorbei ist. Manchmal ist auch am kontaminierten, aber lebenden Objekt mitzuvollziehen, was gerade passiert.

Die Aufgabengebiete eines Computer-Forensikers sind vielfältig, zu seinen häufigsten Aufgaben gehören aber bestimmt Post-Mortem-Analysen von Festplatten. Das liegt nicht zuletzt daran, dass es oft eine ganze Weile dauert, bis Anwender einen Vorfall, etwa einen Einbruch in einen Server, überhaupt entdecken. Wer dann kein geschultes Personal oder keinen Notfallplan hat, der genau festlegt, was in solchen Situationen zu tun ist, wird im besten Fall den Rechner ausschalten und einem Experten übergeben.

Es gibt jedoch auch Fälle, in denen dies explizit nicht gewünscht ist. Manchmal ist es wichtiger, herauszufinden, wer der freventliche Angreifer ist oder wie er vorgeht, als die Daten selbst zu schützen. Ein solcher Fall könnte bei einer Testinstallation vorliegen, die durch ihre Firewallregeln eigentlich keinen externen Zugriff erlauben soll. In dieser Situation ist die Spezialdisziplin der Live-Forensik gefragt. Sie findet am laufenden System, mitunter zeitgleich zum Angriff statt.

Offen oder verdeckt?

Es gibt eine Reihe von Fragestellungen der Forensik, die sich letztlich nur aus dem Kontext der Untersuchung heraus beantworten lassen. Dazu gehört die Überlegung, ob eine Ermittlung offen – und damit auch für den Angreifer ersichtlich – geführt werden soll oder ob dieser unter keinen Umständen davon etwas mitbekommen soll [1].

Forensisch untersuchte Computer verhalten sich in einigen Aspekten wie Teilchen der Quantenmechanik: Wer sie anschaut, ändert schon damit ihren Zustand. Ein »ps«-Kommando kann auch der Angreifer sehen, ein »find« über die komplette Festplatte nach verräterischen Dateien überschreibt im Regelfall die wertvollen »atime«-Records des Filesystems, die angeben, wann zuletzt ein Benutzer auf eine Datei zugegriffen hat. Aus dieser Erkenntnis folgt, dass sich ein System nicht vollständig ohne Spuren sichern lässt. Ist der Forensiker sich jedoch seiner Aktivitäten bewusst, kann er sie bei seiner Auswertung berücksichtigen.

Gelegentlich wiegt also das Interesse, die Vorgänge aufzuklären, schwerer als der Versuch, den Angreifer in Sicherheit zu wiegen. Dazu kommt die Erkenntnis, dass sowieso automatisierte Skripte und Programme die Mehrzahl aller Angriffe ausführen. Einen Angreifer in flagranti mit den Fingern an der Konsole zu erwischen ist eher unwahrscheinlich.

Schnelle Spurensicherung am Tatort

Am konkreten Tatort steht also zuerst die Frage an, ob Rücksicht auf Beweisbarkeit und minimale Spuren des Forensikers genommen werden soll. Ist dies der Fall, bietet es sich tatsächlich an, das System möglichst umgehend vom Netz zu trennen und mit Low-Level-Tools Abzüge der Festplatten und anderer für die Analyse wichtiger Komponenten (im Wesentlichen des Hauptspeichers) auf externe Sicherungsspeicher anzufertigen.

Für einen Low-Level-Dump kann sich »dd« eignen, nützlich sind hinreichend dimensionierte USB-Festplatten oder per Netzwerk ansprechbare Volumes. Einige Experten raten auch dazu, mit einem simplen »netcat« Daten auf ein im selben Netz eingebrachtes Sicherungssystem zu überspielen und dort zu speichern.

Bei der weiteren Betrachtung sollen diese Variante und die diversen Auswertungsverfahren und -werkzeuge jedoch ausgeklammert bleiben. Stattdessen stellt sich die Frage, wie sich möglichst umfangreiche Informationen über das laufende System herausfinden lassen.

Den aktuellen Systemzustand erkunden

Eine gewisse Systematik ist nützlich, um keine Details zu übersehen [2]. Es ist oft sehr verlockend, einer scheinbar heißen Spur nachzugehen, aber ärgerlich, wenn sich diese hinterher als falsch herausstellt. Wer also eine Liste von Prozessen untersucht, etwa mit dem Befehl

ps gauxwww

sollte diese Liste auch speichern und komplett bearbeiten. Das Kommando zeigt alle Prozesse und alle Aufrufargumente mit allen Optionen an. Ähnliches lässt sich bereits mit einem kleinen Shellskript bewerkstelligen, das aus »/proc« Daten ausliest (siehe Listing 1). Individuelle Erweiterungen lassen sich in solche Skripte schnell und einfach einbauen. Dies ist gerade dann nützlich, wenn etwa dem »ps«-Kommando nicht mehr zu trauen ist.

01 #!/bin/sh
02 
03 cd /proc
04 for p in [0-9]*
05 do
06     proc=$(cat $p/cmdline)
07     user=$(ls -ld $p | cut -d  -f3)
08 
09     echo "$user $p $proc"
10 done

Ein guter Sanity-Check besteht darin, das Ergebnis durch ein ähnliches Werkzeug wie das ebenfalls oft installierte »pstree« zu überprüfen. Forensiker bedenken aber außerdem, dass Programme in der Lage sind, ihre Argumentliste »argv[]« per Programm zu ändern (siehe Listing 2).

01 /*
02    Übersetzen mit
03    gcc -o changecommand changecommand.c
04    Wartet drei Sekunden, ändert dann seine
05    Kommandozeile, wartet erneut drei Sekunden
06    und terminiert. Die angegebenen Kommandos
07    werden nicht ausgeführt, sie sollen nur
08    den Administrator erschrecken, der das
09    ps-Kommando ausführt.
10 */
11 
12 void overwrite(char *arg, char *new) {
13     char w;
14 
15     while (*arg)
16     {
17         if (*new)
18             w = *new++;
19         else
20             w = 0x00;
21         *arg++ = w;
22     }
23 }
24 
25 int main(int argc, char **argv)
26 {
27     char a0[] = "/bin/rm";
28     char a1[] = "-fr";
29     char a2[] = "*";
30 
31     usleep(3000000);
32 
33     overwrite(argv[0], a0);
34     overwrite(argv[1], a1);
35     overwrite(argv[2], a2);
36 
37     usleep(3000000);
38 
39     return 0;
40 }

Zum Kern vorstoßen

Gegen Kernel-Rootkits jedoch ist eine solche einfache Methode zwangsläufig machtlos. Rootkits modifizieren bereits den Kernel so, dass dieser erst gar nicht die Informationen über bestimmte Prozesse im »/proc«-Filesystem oder über andere Informationsmechanismen bereitstellt [3]. Andererseits ist es oft erstaunlich, wie unvorsichtig viele Angreifer dabei sind, ihre Spuren zu verschleiern. Einen Versuch ist es allemal wert.

Neben Prozessen sind auch Netzwerkverbindungen sehr interessant. Sie lassen erkennen, von welcher Adresse aus sich der Angreifer auf das untersuchte System verbindet – und wo das Einfallstor ist. Zunächst gilt es erneut, einen Überblick zu gewinnen. Mit »netstat –ip -pan« zeigt Linux – Manipulationen am Kommando oder dem Kernel einmal außer Acht gelassen – alle lokalen IP-Sockets, deren Protokoll (TCP oder UDP) und eventuell einen Kommunikationspartner bei verbundenen Sockets an (siehe Listing 3). Nach dem Status, der besonders für TCP-Verbindungen von Bedeutung ist, zeigt das Tool auch die Prozess-ID und den Beginn der Kommandozeile an, sofern Root den Befehl absetzt.

01 Proto Recv-Q Send-Q Local Address           Foreign Address         State      PID/Program name
02 tcp        0      0 192.168.1.33:3306       0.0.0.0:*               LISTEN     26914/mysqld
03 tcp        0      0 0.0.0.0:5432            0.0.0.0:*               LISTEN     26675/postmaster
04 tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN     2298/master
05 tcp        0      0 192.168.1.33:3306       10.20.30.40:3382        VERBUNDEN  26914/mysqld
06 tcp        0      0 192.168.1.33:3306       10.20.30.40:3383        VERBUNDEN  26914/mysqld
07 tcp        0      0 192.168.1.33:3306       10.20.30.40:3385        VERBUNDEN  26914/mysqld
08 tcp        0      0 192.168.1.33:5432       10.20.30.50:34821       VERBUNDEN  6413/postgres: demo
09 udp        0      0 127.0.0.1:1043          127.0.0.1:1043          VERBUNDEN  26675/postmaster

Netzwerkzentrale

An der Ausgabe lässt sich auch ablesen, wie gut das System gesichert ist: Das im Beispiel gezeigte ist offenbar ein Datenbankserver mit zwei RDBMS-Installationen, eine mit MySQL, eine mit PostgreSQL. Nimmt MySQL am TCP-Port 3306 explizit nur Verbindungen auf dem konfigurierten Interface mit der IP 192.168.1.33 entgegen, lauscht PostgreSQL auf jedem Interface nach Verbindungsanfragen (»SYN«-Paketen) für seinen Port 5432. Hat ein System nur ein echtes Interface, ist dies weitgehend egal, sind aber in der Umgebung Firewall-Regeln etwa mit »iptables« gesetzt, so kann dies einen Unterschied ergeben [4].

Belastbare Indizien

Das »netstat«-Kommando erhält in Listing 3 explizit den Parameter »-n«, um zu verhindern, dass das DNS die IP-Adressen in Namen auflöst. Dies bietet sich an, weil dadurch kein unnötiger und verdächtiger Netzverkehr zum Nameserver entsteht. Wer im Rahmen der Live-Analyse parallel auch das Netzwerk überwacht, weiß diesen Umstand zu schätzen. Im Zweifelsfall lassen sich die IP-Adressen auch später noch in Namen auflösen; es kommt nur selten vor, dass diese Informationen allzu flüchtig sind.

Mehr Informationen über die IP-Adressen zeigen die Kommandos »whois« und »traceroute« an. Der erste Befehl fragt eine von mehreren zentral im Internet betriebenen Datenbanken ab, in der Registrierungsdaten des Netzbereichs hinterlegt sind. Diese Angaben haben oft hohe Glaubwürdigkeit und sind von Angreifern ohne Zusammenarbeit mit Internet-Service-Providern vergleichsweise schwer zu fälschen. Die Verlässlichkeit der Angaben schwankt freilich mit dem Land oder der Region, aus der sie stammen.

Weltweite Verstrickungen

Nicht zuletzt sollte der Forensiker beachten, dass der Ausgabepunkt einer TCP- oder UDP-Verbindung nicht mit dem Standort des Angreifers übereinstimmen muss. Oft nutzen diese nämlich andere gekaperte Systeme als Sprungbrett für ihre Machenschaften. Besondere Vorsicht ist angeraten, wenn die Verbindung von einem System ausgeht, dass netzwerktechnisch nahe dem eigenen System steht. Eine kurze Liste von Zwischenstopps in der Ausgabe von »tcpdump Zieladresse« offenbart dies.

Wer ausschließen kann, dass es sich dabei um einen regulären Anwender handelt, hat einen starken Hinweis darauf, dass sich der Angreifer bereits in die Nähe vorgearbeitet hat. Aus demselben Subnetz heraus ist es viel einfacher, etwa Passwörter oder Zugangskennungen abzuhören als aus dem Internet.

Kombiniert der Forensiker die gewonnenen Erkenntnisse aus der Prozessanalyse und den Netzverbindungen, stellt sich als Nächstes die Frage, was ein Schadprogramm eigentlich tut.

Spurensuche

Dient es nur als Sprungbrett für weitere Angriffe? Dann sollte ein unbekannter Prozess einen Eintrag in der Socket-Liste hinterlassen haben. Hört es vielleicht bestimmte Daten im Netzverkehr ab? Dann wäre ein Netzwerkinterface in den Promiscous Mode gegangen. Dies erzeugt im Kernel-Ringbuffer typischerweise einen Audit-Eintrag [5]. Er lässt sich mit dem Aufruf »dmesg« anzeigen:

device eth0 entered promiscuous mode
audit(1408381411.504:2): dev=eth0 prom=256 old_prom=0 auid=4267295
device eth0 left promiscuous mode
audit(1408381413.144:3): dev=eth0 prom=0 old_prom=256 auid=4297295

Was aber tun, wenn offenbar ein Prozess läuft, aber unklar ist, was er tut? Zunächst ist es günstig, das Programm an sich zu sichern. Mittels »ps gauxwww« oder durch einen Blick in »/proc/PID/cmdline« lässt sich das Executable zumeist lokalisieren. Was aber, wenn der Angreifer ein Werkzeug gestartet und danach sofort wieder gelöscht und auf der Festplatte überschrieben hat?

Solange das Programm noch läuft, besteht Hoffnung: Ebenfalls in »/proc/PID/exe« hält der Kernel einen virtuellen Symlink auf das Executable vor, selbst wenn der Angreifer es im Dateisystem gelöscht hat. Sichert das Untersuchungsteam diese Datei an einem verlässlichen Ort, sind später genauere Analysen möglich.

Stochern im Datenmüll

Einfach, aber oft effektiv ist es, sich das Binary selbst einmal näher anzusehen. Der Befehl »strings -a Binärdatei« forscht in Files nach druckbaren Zeichen. Sollte sich das Schadprogramm etwa mit FTP- oder Webservern verbinden, die ein Passwort verlangen, gäbe es die Möglichkeit, dass dies als Klartext im Programmcode verborgen ist. Ein Schuss Intuition vom Schlage Sherlock Holmes gehört allerdings dazu, die digitalen Brotkrumen vom Binärmüll zu trennen. Viel Zeit hingegen muss mitbringen, wer mit den Tools der Binutils, etwa die Symboltabellen auslesen möchte (das geht mit »nm«) oder gar den Maschinencode disassemblieren will (hier hilft »objdump« etwas weiter). Zumeist ist dieses Verfahren nur den ganz harten Fällen vorbehalten.

Wir gehen rein!

Für das ultimative Echtzeiterlebnis stehen auch Kommandos bereit, die auf vielen Linux-Systemen installiert sind – oder zumindest sein sollten. Ein laufender Prozess lässt sich einfach beobachten. Root darf nämlich den Systemaufruf »ptrace()« auf jeden Prozess anwenden. Hat er das getan, erhält sein Programm jedes Mal eine Nachricht, wenn der überwachte Prozess einen Systemaufruf tätigt [6]. Das passiert häufig. Mit »strace -p PID« klinkt sich der Forensiker in den Prozess über seine ID ein.

In der ersten Zeile in Listing 4 hängt sich »strace« an den Prozess 3076. Nach einer Weile geht auf Socket 6 eine Verbindung von 192.168.104.23 mit TCP-Port 63207 ein (Zeile 4). Der Kernel erteilt ihr Deskriptor 9, von dem der Prozess später lesen kann. Der Prozess öffnet die Datei »/etc/hosts«, gibt ihr das Handle 20 (Zeile 8) und liest sie dann aus (Zeilen 10 und 11). So ist recht gut nachzuvollziehen, was ein Prozess tut.

01 # strace -p 3076
02 Process 3076 attached - interrupt to quit
03 select(24, [5 6 10 21 22 23], [], [5 6 10 21 22 23], {37, 288000}) = 1 (in [6], left {35, 300000})
04 accept(6, {sa_family=AF_INET, sin_port=htons(63207), sin_addr=inet_addr("192.168.104.23")}, [16]) = 9
05 getpeername(9, {sa_family=AF_INET, sin_port=htons(63207), sin_addr=inet_addr("192.168.104.23")}, [16]) = 0
06 geteuid32()                             = 103
07 getuid32()                              = 103
08 open("/etc/hosts", O_RDONLY)            = 20
09 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fdd000
10 read(20, "127.0.0.1tlocalhost.localdomaint"..., 4096) = 748
11 read(20, "", 4096)                      = 0
12 close(20)                               = 0

Aus den Systemaufrufen lassen sich alle Dateien heraussuchen, die Prozesse geöffnet haben. Weil dies jedoch äußerst mühsam ist, zeigt das Tool »lsof« alle offenen Deskriptoren an [8]. Wegen der Fülle an Informationen ist auch hier eine Filterung angebracht. Die Option »-p PID« präsentiert eine Übersicht der Dateihandles, die der angegebene Prozess geöffnet hat. So lassen sich Dateien, verwendete Shared Libraries, Devices oder sogar Handles auf gemeinsam genutzten Speicher erforschen. Hier zahlt sich das Datei-Paradigma von Unix aus. Mit ihm findet der Forensiker Konfigurationsdateien von Schadcode, zusätzlich genutzte Bibliotheken oder Data-Dumps, in denen diese Programme Passwörter vor dem Hochladen an einen Server horten.

Für das Kommandozeilentool gibt es sogar eine bequeme grafische Oberfläche namens »glsof« (Abbildung 2). Arbeitet der Forensiker direkt am untersuchten System, ist das Werkzeug eine praktische Alternative, ist er jedoch übers Netz per X11 oder anderen Terminalclients verbunden, erzeugt der Einsatz zu viele verräterische Spuren im Netzwerk-Log.

Den umgekehrten Weg geht »fuser«: Wem eine Datei verdächtig vorkommt, der kann damit herausfinden, welcher Prozess darauf zugreift. So zeigt »fuser -v /usr/lib/libcrypto.so.0.9.8« an:

USER        PID ACCESS COMMAND
/usr/lib/libcrypto.so.0.9.8:
demo       6149 ....m kded
demo       9742 ....m kio_imap4

Die vorgestellten Werkzeuge zur Datei- oder Prozessanalyse können nun wieder übernehmen und weitere Querverbindungen zutage fördern. Das Kommando arbeitet nicht nur auf einzelnen Dateien, sondern untersucht ganze gemountete Partitionen, wenn es zusätzlich den Parameter »-m Gerät« erhält.

Das Pendant zur Kernelschnittstelle ist das Überwachen der Netzwerkinterfaces. Werkzeugkästen wie Wireshark enthalten viele Tools, um Netzverkehr aufzuzeichnen und zu visualisieren (siehe Abbildung 1). So lassen sich einzelne Pakete in einem ansonsten zerstückelten Datenstrom von Wireshark wieder zusammensetzen. Auch so ließe sich eine Passwortübertragung sichtbar machen – der Angreifer wäre mit seinen eigenen Waffen geschlagen [7].

Abbildung 1: Der Netzwerkmonitor Wireshark erlaubt die Überwachung von Netzwerkinterfaces. Das Tool listet jedes Paket in einer Zeile im oberen Fensterdrittel auf, ganz unten sind die Binärdaten zu erkennen.

Abbildung 2: Offene Dateien zeigt »lsof« an, hier in der grafischen Variante »glsof«. So findet der Forensiker Hinweise darauf, an welchen Files sich ein Schadprogramm zu schaffen macht oder wo es Daten ablegt.

Puzzle mit vielen Teilen

Wer sich auf seinem Linux-System auskennt, dem bleibt wenig verborgen. Eine Vielzahl von Systemdiagnose-Werkzeugen lässt sich auch zur Live-Forensik verwenden. Viele Aktivitäten von Angreifern werden so nachvollziehbar. Die Entscheidung, solche Untersuchungen durchzuführen, sollten sicherheitsbewusste Admins aber bereits vorher treffen. Im Eifer des Gefechtes ist der Adrenalinpegel hoch – schlechte Voraussetzung für eine Operation am offenen Herzen.