UnrealIRCd ist ein Open-Source-IRC-Server (Internet Relay Chat), der auf der ganzen Welt sehr verbreitet ist und deshalb von Hackern gern als lohnendes Angriffsziel ins Visier genommen wird. Am 12. Juni 2010 postete ein Mitglied des Server-Support-Teams die folgende Nachricht in der Mailing-Liste:

„Ich möchte Ihnen hiermit mitteilen, dass die unrealircd-Website und der ftp-Server kompromittiert wurden und dass das Tarball-Release 3.2.8.1 durch eine mit einer Backdoor versehene Kopie ersetzt wurde.“

Ein Unbekannter hatte also heimlich den offiziellen Download-Tarball durch eine Version mit einer absichtlich eingebauten Hintertür ersetzt, die es Hackern ermöglichte, beliebigen Code auf dem Server auszuführen. Der Austausch musste irgendwann im November des Vorjahres erfolgt sein, sodass die Sicherheitslücke bei ihrer Entdeckung bereits mehr als sechs Monate existierte. Der Bericht über diesen Defekt ist in der CVE-Datenbank unter CVE-2010-2075 zu finden.

Es muss schlimm gewesen sein für die Entwickler, als die Sache ans Licht kam. Ohne selbst einen Fehler gemacht zu haben, waren sie für böswillige Zwecke ausgenutzt worden. Obwohl die Entwickler das Thema Sicherheit sehr ernst nahmen, wurden ihre Vorsichtsmaßnahmen und gegenseitigen Kontrollen vollständig umgangen.

Es gibt absolut keine Beweise oder auch nur Hinweise, dass der Angriff von einem der Entwickler der Software aufgezogen wurde. Wahrscheinlich nutzten die Angreifer eine Schwachstelle in der Konfiguration des Download-Servers, um die offizielle Tarball-Datei durch ihre eigene, korrumpierte Version zu ersetzen. Dennoch weist dieser Angriff einige Parallelen zu Insider-Attacken auf. Diese basieren häufig auf Sicherheitslücken, die absichtlich in den Code eingebaut wurden, und die Angreifer sind in der Regel sehr darauf bedacht, ihre Absichten durch Verschleierung ihrer Editierungen zu verbergen.

Wie lassen sich Insider-Attacken aufdecken?

Bild 1: Beispiel für eine Command-Injection-Warnung.

Bild 1: Beispiel für eine Command-Injection-Warnung. Grammatech

Nach Überlegungen, wie Insider-Attacken aufgedeckt werden können, stattete Grammatech sein Codesonar 4 mit neuer Funktionalität zum Detektieren solcher Angriffe aus. Somit ist ein Blick zurück auf den betreffenden Code äußerst lehrreich, um zu untersuchen, wie man die Sicherheitslücke mit einem statischen Analysetool hätte aufdecken können.

Code-Defekte, die einem Angreifer die Verarbeitung beliebiger Befehle gestatten, bezeichnet man in der Regel als Code-Injection-Fehler. Lässt man den Code von Codesonar untersuchen, wird deshalb eine Command-Injection-Warnung erzeugt (Bild 1).

Auf den ersten Blick sieht der Code eigentlich harmlos aus. Der Defekt wird in Zeile 1436 beim Aufruf von DEBUG3_LOG gemeldet. Wer keinen Grund hat an der Unschädlichkeit dieses Codes zu zweifeln, wird hier kaum etwas Verdächtiges erkennen.

Bild 2: Detailliertes zweites Makro.

Bild 2: Detailliertes zweites Makro. Grammatech

Doch das Infofenster rechts unten in Bild 1 zeigt, dass DEBUG3_LOG ein Makro ist. Erweitert man die Definition des Makros (Bild 2), erkennt man, dass es ein weiteres Makro mit der Bezeichnung DEBUG_DOLOG_SYSTEM benutzt, das wiederum zum Aufruf von „system()“ erweitert wird.

Jetzt ist die Absicht klar: Ist die Bedingung erfüllt, wird der in readbuf befindliche String an system() übergeben, und dort als Prozess mit den gleichen Privilegien ausgeführt, die auch der Server besitzt. Die nächste Frage lautet: Wie kann die Bedingung erfüllt werden? Es geht dabei um einen Vergleich der ersten zwei Zeichen des Strings mit DEBUGMODE3_INFO. Dieses Makro erweitert sich zu der Zeichenfolge „AB“. Ein Angreifer kann diese Stelle also ausnutzen, indem er einen String wie etwa „AB; rm –rf /“ sendet. Das „AB“ ergibt einen Fehler, doch der zweite Befehl versucht, alle Dateien im Stammverzeichnis zu löschen.

Der Command Injection Checker ist ein neues Feature in Version 4 von Codesonar und nutzt die Taint-Analysis-Funktionalität des Tools. Die Taint-Analyse verfolgt den Weg potenziell gefährlicher Informationen von ihren Ursprüngen (Taint-Quellen) bis zu den Stellen, an denen sie Schaden anrichten können (Taint-Senken). Abhängig von der Herkunft der Information und der Art, wie das Programm installiert ist, gibt es verschiedene Taint-Arten. Dabei müssen einige Arten nicht einmal bösartig sein. Im obigen Beispiel handelt es sich um „Network Taint“, also um eine Variante, die für einen Server dieser Art wohl am gefährlichsten sein dürfte. Weitere Taint-Arten sind beispielsweise File System, Environment, Clock oder DNS Record.

Die rote Unterstreichung in der Warnungsliste weist darauf hin, dass der Wert potenziell verfälscht ist. Zusätzlich wird der Taint-Typ angezeigt, sobald der Mauszeiger über das zugehörige Token bewegt wird.

 

Themen auf der nächsten Seite: Visualisierte Analysen des Laufwegs verfälschter Daten sowie binäre Analysen zum Aufdecken von Attacken.

Seite 1 von 212