Schwachstellen-Test am Beispiel der Web Application Firewall ModSecurity

Auch Sicherheitssoftware ist unsicher

Seite: 5/5

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.

Ergänzendes zum Thema
Weiterführende Literatur

BSI:

Sicherheit von Webanwendungen (Bonn, 2006)

Intermoves GmbH: Web-Applikation Firewall – Grundlagen und Marktübersicht (2013)

OWASP: Best Pratices Guide WAF (2008)

Trustwave: ModSecurity Open Source Web Application Firewall (Chicago, 2013)

Provozierter XML-Deadlock
Provozierter XML-Deadlock
(Bild: SoftScheck)

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)