entwickler.com

Ob die Einträge im fiktiven HTTP-Proxy-Logfile in About Security #40 Hinweise auf einen Angriff sind oder nicht und ob ein eventueller Angriff erfolgreich war, lässt sich allein aus dem protokollierten URL nicht erkennen. Wie man Angriffe erkennt, erfahren Sie in dieser Folge.

Wurde ein verdächtiger URL gefunden, lautet die erste Frage, ob der jeweilige HTTP-Request vom Web-Proxy abgewiesen oder weitergeleitet wurde. Die entsprechende Information ist Bestandteil des HTTP-Proxy-Logfiles. Bei einem abgewiesenen Request ist die Sache erledigt. Wurde der Request weitergeleitet, geht die Analyse weiter: Wurde er vom Webserver beziehungsweise der betreffenden Webanwendung verarbeitet und beantwortet oder nicht? Die Antwort auf diese Frage liefern die Logfiles des Webservers und der Webanwendung.

Im Folgenden werden noch einige der verdächtigen Einträge aus dem Beispiel in About Security #40 betrachtet.

Schwachstellen in Webanwendungen

In Zeile 3 wurde versucht, eine SQL-Injection-Schwachstelle auszunutzen, um die Authentifizierung zu umgehen. Steht fest, dass das betroffene Skript keine solche Schwachstelle enthält, sind keine weiteren Aktionen notwendig. Bestehen Zweifel, kann ein eventuell vorhandenes Logfile der Webanwendung weiterhelfen: Ist dort ein entsprechender fehlgeschlagener Authentifizierungsversuch vermerkt, war der Angriff erfolglos. Steht kein Logfile zur Verfügung oder enthält ein vorhandenes Logfile keinen entsprechenden Eintrag, muss die Webanwendung auf eine SQL-Injection-Schwachstelle untersucht werden. Als erster Test kann dazu ein entsprechender Parameter, zum Beispiel te'st, übergeben werden, um einen SQL-Fehler zu provozieren. Zwar könnte in diesem Fall auch der Parameter ' OR 1=1 -- aus dem URL übernommen werden, dies könnte jedoch zu unerwünschten Nebenwirkungen führen (siehe z.B. hier). Außerdem sollte grundsätzlich nie ein verdächtiger URL zum Testen aufgerufen werden.

Wird eine SQL-Injection-Schwachstelle gefunden, sollte davon ausgegangen werden, dass der Angreifer erfolgreich war und das betreffende System kompromittiert ist. Die dann notwendigen Maßnahmen sollten vorab in einer Sicherheitsrichtlinie festgelegt worden sein. Die Entwicklung so einer Security Policy wird ab About Security #53 beschrieben.

Ob der Cross-Site-Scripting-Angriff in Zeile 7 möglich war, kann über einen einfachen Test geprüft werden. Als id wird %3Cscript%3Ealert%28%2CTest%2C%29%3C%2Fscript%3E übergeben, was dekodiert <script>alert('Test')</script> entspricht. Erscheint die Alertbox, ist das System für Cross-Site Scripting anfällig.

Um eine weitere Ausnutzung gefundener Schwachstellen zu verhindern, muss die Webanwendung entsprechend geändert werden. Ist dies nicht möglich, können die jeweils gefährlichen Zeichen auch durch den HTTP-Proxy ausgefiltert werden. Dies hat den Nebeneffekt, dass die Belastung des Webservers bzw. der Webanwendung sinkt, da sie nur noch harmlose Anfragen erhalten.

Einschleusen von Code

Ob der sehr lange Parameter in Zeile 5 einen Pufferüberlauf ausgelöst hat, kann in den Logfiles des Webservers, der Webanwendung und deren Betriebssystemen geprüft werden. Kam es tatsächlich zu einem Pufferüberlauf, ist zu prüfen, ob Code eingeschleust wurde, d.h. ob der übergebene Parameter Shellcode enthielt.

Die Angriffsversuche der Würmer Code Red (Zeile 6) und Nimda (Zeile 8) stellen nur eine Gefahr dar, wenn der Webserver verwundbar ist. Entsprechende Systeme sollten 2006 extrem selten sein. Interessanter ist die Frage, wie beim Auftauchen eines neuen Wurms reagiert wird. Es müssen laufend die entsprechenden Informationsquellen überwacht werden, um frühzeitig Gegenmaßnahmen einzuleiten. Dazu gehört zum Beispiel eine Anpassung der Regeln des HTTP-Proxy und/oder des Paketfilters, eine Aktualisierung des eingesetzten Virenscanners bzw. von dessen Daten oder das Installieren verfügbarer Patches für bekannt gewordene Schwachstellen.

Besteht der Verdacht, dass ein Angriff erfolgreich war und Code eingeschleust wurde, müssen sofort entsprechende Maßnahmen eingeleitet werden. Dabei sind zwei zum Teil im Widerspruch zueinander stehende Ziele zu verfolgen: Das betroffene System soll schnellstmöglich wieder einsetzbar sein, während gleichzeitig möglichst keine Spuren des Angriffs vernichtet werden sollen. Die notwendigen Maßnahmen werden das Thema eines zukünftigen Features sein.

HTTP Response Splitting

Um die Auswirkungen des HTTP-Response-Splitting-Angriffs in Zeile 12 zu ermitteln, müssen die Logfiles aller beteiligten Systeme kontrolliert werden: Entspricht die Antwort auf den HTTP-Request dem erwarteten Ergebnis oder wurde etwas anderes zurückgegeben? Außerdem kann das betroffene Skript geprüft werden. Ist die Beseitigung einer gefundenen Schwachstelle nicht möglich, kann eventuell die in About Security #20 beschriebene Gegenmaßnahme angewandt werden. Weitere Erklärungen zu den Beispielen 4, 9 und 10 aus About Security #40 finden Sie im Forum, wo Sie außerdem über das Feature diskutieren können.

Einen Schutz vor Angriffen bieten auch Intrusion-Detection- beziehungsweise Prevention-Systeme, die ab der nächsten Folge vorgestellt werden.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Logfiles"

• About Security #37: Logfiles – Welche Daten speichern?
• About Security #38: Logfiles – Wie auswerten?
• About Security #39: Paketfilter-Logfiles manuell auswerten
• About Security #40: HTTP-Proxy-Logfiles manuell auswerten, 1
• About Security #41: HTTP-Proxy-Logfiles manuell auswerten, 2