Web-Sicherheit

August 6, 2011

9 Tricks um ModSecurity zu umgehen

Filed under: Allgemein — sebastiankuebeck @ 16:35
Tags: , , , , , ,

ModSecurity ist wahrscheinlich die beliebteste Web-Application-Firewall (kurz WAF), zum einen weil sie als Open-Source-Projekt kostenlos zur Verfügung stellt und zum anderen, weil sie als Modul des Apache Webservers ausgeführt ist.  Vor einiger Zeit riefen die Schöpfer von ModSecurity zu einem Wettbewerb mit dem Ziel auf, ModSecurity zu umgehen. Dazu wurden vier Testseiten mit bekannten Schwachstellen durch ModSecurity abgesichert und die Teilnehmer mussten nun Zeigen, dass sie Die Schwachstellen trotz ModSecurity umgehen können.

In diesem Blog-Post werden nun neun erfolgreiche Umgehungstechniken beschrieben, die im Zuge dieses Wettberwerbs von den Teilnehmern eingesetzt wurden. Die 9 Wettberwerber, die ModSecurity erfolgreich umgingen, verwendeten im Wesentlichen eine oder eine Kombination der folgenden 6 Angriffstechniken:

Trick 1: Ausnutzen von Unterschieden in der Interpretation von Kommentaren in Datenbankkommandos

So zeigt Johannes Dahse eindrucksvoll, dass mit steigender Komplexität Tatsächlich die Sicherheit eines Systems sinkt. Hat man eine komplexe Webanwendung und sichert diese durch eine ebenfalls komplexe WAF ab, kommen oft neue Angriffsmöglichkeiten dazu, die es ohne WAF gar nicht gegeben hätte, und das geht wie folgt:

Die MySQL-Datenbank kennt drei Arten, Kommandos mit Kommentaren zu versehen

  1. Ausgehend vom Zeichen # bis zum Ende einer Zeile ist alles ein Kommentar
  2. Ausgehend von der Zeichensequenz -- gefolgt von einem Leer- oder Steuerzeichen (Tabulator, Newline etc.) bis zum Ende einer Zeile ist ebenfalls alles ein Kommentar.
  3. Alles, was zwischen den Zeichensequenzen /* und */ ist ebenfalls ein Kommentar. Es kann sich über mehrere Zeilen erstrecken und entspricht den mehrzeiligen Kommentaren in der Programmiersprache C [Anm: genauso wie C++, C#, Java etc.].

Johannes Dahse verwendete folgenden Text für seinen Angriff…

0 div 1 union#foo*/*bar
select#foo
1,2,current_user

…der die MySQL in folgender Form erreichte:

0 div 1 union select 1,2,current_user

Wie ist das also möglich?

Die Sache ist weit weniger misteriös wenn man sich vergegenwärtigt, dass ModSecurity Eingabedaten auch verändern kann. Die die Entsprechende Regel im Standardregelsatz von ModSecurity Kommentare anders interpretiert, als der Interpreter der MySQL, transformiert sie ein an sich ungültiges Kommando in ein gültiges, welches die MySQL dann anstandslos ausführt.

Trick 2: Aufteilen von Datenbankabfragen auf unterschiedliche Parameter

Vladimir Vorontsov teilt eingeschleuste Datenbankanfragen einfach auf unterschiedliche Parameter in der Eingabe auf, sodass die Regeln von ModSecurity nicht auf die einzelnen Bestandteile anwendbar sind (%27 entspricht dabei einem einfachen Hochkomma und das Pluszeichen einem Leerteichen):

FromDate=a1%27+or&ToDate=%3C%3Eamount+and%27

Das funktioniert natürlich nur, wen die zu schützende Anwendung die Bruchstücke weider richtig zusammensetzt.

Trick 3: Parameterverunreinigung

PT Research verwendete eine Technik namens HTTP Parameter Pollution das die Art und Weise ausnutzt, wie .NET mit mehreren Parametern mit dem selben Namen umgeht. Erhält .NET nämlich mehrere Parameter mit demselben Namen, setzt es die Inhalte durch Komma getrennt zusammen. Aus…

after=1 AND (select DCount(last(username)&after=1&after=1) from users where username='ad1min')

…wird daher einfach…

after=1 AND (select DCount(last(username), 1, 1) from users where username='ad1min')

…so ergeben die Bestandteile alleine keine gültige SQL-Injection-Signatur, setzt .NET die Parameter jedoch zu einem zusammen, wird daraus ein erfolgreicher SQL-Injection-Angriff.

Trick 4: Ausnutzen eines MySQL-Features, das Bedingte Ausführung in Kommentaren erlaubt

Ahmad Maulana verwendet wieder nicht abgeschlossene Kommentare (also wenn die Abschlussequenz */ nach /* folgt) in Kombination mit einem Feature der MySQL, das an sich dazu da ist, portablen SQL-Code zu schreiben, der auch auf anderen Datenbankprodukten läuft.

ToDate=1'UNION/*!0SELECT user,2,3,4,5,6,7,8,9/*!0from/*!0mysql.user/*-

Folgt nämlich ein Rufzeichen nach /* interpretiert die MySQL das als nicht standardkonformen SQL-Code, den nur die MySQL unterstützt und den der Autor vor anderen Datenbankprodukten verbergen will. Die MySQL fügt den Code jedoch in den umgebenen Text ein und führt das ganze anstandslos aus. Tatsächlich führt die MySQL also Folgendes aus – vervollständigt durch die Anwendung selbst:

'UNION SELECT user,2,3,4,5,6,7,8,9 from mysql.user -

Die Kommentarsequenzen dienen als Ersatz für Leerzeichen, wodurch die Regeln von ModSecurity nicht greifen.

Trick 5: SQL-Code an einer Stelle platzieren, die von ModSecurity nicht überprüft wird

Travis Lee hat sich erst gar nicht die Mühe gemacht, ModSecurity durch Codierungstricks zu täuschen, stattdessen hat er den SQL-Code in einem Cookie versteckt, der von ModSecurity gar nicht erst überprüft wird.

Cookie: ASP.NET_SessionId=c0tx0o455d0b10ylsdr03m55; amSessionId=14408158863; amUserInfo=UserName=YWRtaW4=&
Password=JyBvciAnMSc9JzEnLS0=; amUserId=1 union select username,password,3,4 from users

Dieser Trick funktioniert natürlich nur wenn sich die SQL-Injection-Schwachstelle durch einen Cookie-Inhalt ausnutzen lässt.

Trick 9: Tabulatoren anstelle von Leerzeichen

Georgi Geshev verwendet einen Trick aus der Mottenkiste, den ModSecurity allerdings offenbar noch nicht kennt: Er verwendete einfach Tabulatoren (%0b) anstelle von Leerzeichen. Das ist in SQL ausdrücklich erlaubt, wird aber von den ModSecurity-Regeln augenscheinlich nicht berücksichtigt:

http://www.modsecurity.org/testphp.vulnweb.com/listproducts.php?artist1%0bAND(SELECT%0b1%20FROM%20mysql.x)

Fazit

Das ModSecurity-Team hat die Regeln inzwischen den neuen Erkenntnissen aus dem Wettbewerb angepasst, man sollte jedoch nicht vergessen, dass das Absichern von SQL-Injection-Schwachstellen in der Anwendung selbst immer noch die sicherste Methode ist, eine Webanwendung zu schützen. In den meisten Fällen ist das bei weitem einfacher als die Regeln von ModSecurity zu analysieren und anzupassen. Letzteres bietet übrigens niemals hundertprozentigen Schutz und je wirksamer die Regeln sind desto häufiger muss man sich erfahrungsgemäß mit Falsch-Positiven herumschlagen.

2 Kommentare »

  1. […] dokumentiert werden, bleibt zu erwarten, dass die ausnutzbaren Lücken weniger werden. http://blog.spiderlabs.com/2011/07/modsecurity-sql-injection-challenge-lessons-learned.html .Am Ende ist aber saubere System-Architektur und gewissenhafte Implementierung die beste Strategie […]

    Pingback von WAF Evasion | No more cubes. — August 11, 2011 @ 21:29 | Antwort

  2. […] Research verwendete diese Technik, um die Web-Application-Firewall ModSecurity zu umgehen (siehe Trick 3). Wie zuvor beschrieben setzt ASP.NET Parameter mit demselben Namen zu einer durch […]

    Pingback von HTTP-Parameterverunreinigung, Teil 1 « Web-Sicherheit — August 26, 2011 @ 13:52 | Antwort


RSS feed for comments on this post. TrackBack URI

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

Bloggen auf WordPress.com.

%d Bloggern gefällt das: