Backdoors

Im Rahmen eines Angriffs haben Angreifer Zugriff auf eines meiner Systeme erlangt. Dies könnte z.B. durch einen SSH Angriff passiert sein. Angreifer installieren an dieser Stelle oft sog. Backdoors. Diese erlauben einen erneuten Zugriff auf das System ohne dass erneut eine Schwachstelle ausgenutzt werden muss oder z.B. ohne dass sich die Angreifer darauf verlassen müssen, dass der Account mit dem schwachen Passwort noch existiert.

Was ist eine Backdoor?

Eine Hintertür stellt einen alternativen Mechanismus für den entfernten Zugriff dar - also parallel zur regulären Authentifikation. Eine Backdoor kann im einfachsten Fall ein neuer Account mit einem von den Angreifern gewähltes Passwort sein. Dies ist relativ leicht durch den Administrator festzustellen. Aufwendigere Backdoors sind erheblich schwieriger festzustellen und zu schließen.

Backdoors können sehr unterschiedlichen implementiert werden. Oft werden neue Dienste installiert oder aber bestehende Dienste manipuliert - z.B. indem die Programm-Binaries ausgetauscht werden. Alternativ reicht es manchmal auch eine kleine, aber relevante Änderung in der Konfiguration vorzunehmen, damit der legitime Dienst selbst zur Backdoor wird. Weiterhin ist es möglich eine Backdoor in den Daten der Benutzer zu hinterlassen. Dies kann z.B. mit einem neuen Eintrag in der authroized_keys Datei im SSH-Verzeichnis der Benutzers passieren oder durch Manipulation eines Benutzer-Skriptes. Eine Reihe von Beispielen und Vorschläge, wo nach Backdoors gesucht werden sollte, sind [1] und [2] zu entnehmen.

Wo liegt das Problem?

Im Rahmen der Reaktion auf einen Sicherheitsvorfall muss das System nach der Spurenaufnahme wieder bereinigt werden. Dabei kann unterschiedlich vorgegangen werden. Entweder man begnügt sich damit, die vom Angreifer zurückgelassenen Dateien zu löschen und etwaige Manipulation rückgängig zu machen, oder das betroffene System wird von Grund auf neu installiert. Letzteres ist deutlich aufwendiger, wird aber in der Regel empfohlen. Aufgrund von Zeitmangel und fehlenden Ressourcen wird aber meistens nur gelöscht, was vom Angreifer vorgefunden wurde.

Problematisch ist bei der Bereinigung, dass nicht unbedingt klar ist, ob wirklich eine Backdoor vorhanden ist. Vielleicht hat man sie nur noch nicht gefunden! Gewiefte Angreifer hinterlassen eventuell auch mehrere Backdoors, so dass man auch nach dem Löschen einer Backdoor noch nicht beruhigt schlafen kann. War die ausgenutzte Schwachstelle längere Zeit öffentlich erreichbar, steigt die Wahrscheinlichkeit, dass unterschiedliche Gruppen von Angreifern Zugriff auf das System erlangt haben. Diese können wiederum voneinander unabhängige Backdoors installiert haben. Das Kernproblem ist hier, dass man nicht beweisen kann, dass keine Backdoor vorhanden ist. Es ist lediglich klar, dass eine existiert, wenn man diese gefunden hat!

Pragmatisches Vorgehen

Die einschlägigen Leitfäden (z.B. [3] und [4]) raten aufgrund der Risiken zur Neuinstallation von Originalmedien. In der Praxis wird dies aber nicht so oft getan wie man vermutet. Oft wird einer oder mehrere dieser Gründe genannt: Folgende Maßnahmen erschweren den Angreifern die unbemerkte Nutzung einer möglichen Backdoor:

Backdoors können sehr unterschiedlich aussehen und sind teilweise sehr schwer zu finden. Ob wirklich jede Manipulation gefunden wurde, kann nie mit absoluter Sicherheit festgestellt werden - sogar nach einer Neuinstallation können Backdoors in Backups oder den Daten der Benutzern verbleiben. Da die Angreifer in der Regel aber auch etwas mit dem kompromittierten System vor haben, ist die Lage nicht so ernst, wie sie vielleicht auf dem ersten Blick erscheint. Wenn Sie Ihr Netzwerk unter Kontrolle haben und die Logdaten auch auswerten, werden die Angreifer auffallen.


[1] Andreas Bunten: Kompromiss nach Kompromittierung?, <kes> Die Zeitschrift für Informations-Sicherheit, Ausgabe 4, August 2011

[2] Andreas Bunten: 99 Backdoors on my UNIX Host, Tagungsband des Frühjahrsfachgesprächs der German UNIX User Group, März 2012 (lokale Kopie)

[3] First Responders Guide to Computer Forensics, Carnegie Mellon Software Engineering Institute, CERT Training and Education, März 2005

[4] Karen Scarfone, Tim Grace, Kelly Masone: Computer Security Incident Handling Guide, National Institute of Standards and Technology, Special Publication 800-61 Revision 1, März 2008