Anbieter zum Thema
„XML External Entity“-Lücke in ModSecurity
ModSecurity ist ein gutes Beispiel dafür, dass WAFs zwar durchaus eine Maßnahme sind, um die Ausnutzung von Sicherheitslücken in Webanwendungen zu verhindern. Allerdings können sie auch selbst Sicherheitslücken enthalten. So wurde im Jahr 2013 eine „XML External Entity“-Anfälligkeit in der Version 2.7.2 identifiziert.
Die Schwachstelle entsteht dadurch, dass die XML-Bibliothek libxml2 das Einbinden externer Dateien erlaubt. Die Abbildung zeigt, wie eine normale XML-Anfrage verarbeitet wird. Hierbei untersucht die Web Application Firewall die XML-Anfrage, parst diese und leitet sie weiter an den Apache-Server.
Dieser antwortet nun wie gewohnt auf die Anfrage. Erhält der Server jedoch zum Beispiel folgende Anfrage, dann wird auf eine externe Datei verwiesen:
<?xml version=“1.0“ encoding=“ISO-8859-1“ß><!DOCTYPE foo[<!ENTITY xxe SYSTEM “file:///dev/random” >]><foo>&xxe;</foo>In diesem Fall ist es die externe Anwendung /dev/random zur Generierung von Zufallsdaten. Die libxml2-Bibliothek versucht nun, auf diese Datei zuzugreifen. Sie erhält aber keine Antwort, da /dev/random ein Pseudo-Device ist, das Zufallszahlen mit Hilfe von User-Eingaben generiert. Da nichts eingegeben wird, werden sämtliche Zugriffe blockiert.

Dementsprechend entsteht ein Deadlock, wie in dieser Abbildung dargestellt. Durch diesen Deadlock warten nun alle Prozesse einschließlich des Apache-Prozesses von ModSecurity auf eine Antwort von /dev/random. Da Apache aber mehrere Clients gleichzeitig bearbeitet, erstellt der Server in diesem Fall einen weiteren Prozess.
Die Anfrage wird nun solange geschickt, bis Apache die maximal mögliche Anzahl an Prozessen erreicht hat. Danach stürzt Apache ab und reagiert nicht mehr auf Anfragen. Daraus wird deutlich, dass Sicherheitssoftware zwar nützlich ist, aber selbst Anfälligkeiten enthalten kann.
Security Software sollte also generell auf Schwachstellen hin geprüft werden. Bekannte Methoden hierfür sind beispielsweise Threat Modeling, statische Quellcode-Analyse, Penetration Testing und dynamische Analysen (bspw. Fuzzing). Erst durch einen umfassenden Security Test Process wird der Patch-Aufwand nach Auslieferung von Sicherheitsprodukten minimiert.
Über die Autoren
Prof. Dr. Hartmut Pohl ist Geschäftsführender Gesellschafter der softScheck GmbH in Köln, Valeri Milke ist als Consultant bei softScheck tätig, Sascha Böhm arbeitet beim gleichen Unternehmen als Junior Consultant.
(ID:42524255)
