Da nun wieder ein Hacking-CTF zu ende ist, werde ich hier mal meine (kleine) Ausarbeitung über ModSecurity und PHP beim
iCTF (Mitte 2005) veröffentlichen (
Heise berichtete) veröffentlichen.
Abwehrmassnahmen - modSecurity
Um mehr Informationen über die Webzugriffe auf den Apache zu bekommen, wurde das Modul
modSecurity installiert und mit einem Logging-Regelwerk versehen. Da die Direktive "Kein Blocken sondern Patchen" bestand, wurden die Fähigkeiten von modSecurity nur teilweise benutzt. Dennoch half modSecurity zum einen während dem Wettkampf und zum anderen bei der späteren Auswertung der Zugriffe auf den Webserver.
Das Regelwerk kann man in mehrere Bereiche unterteilen:
- Erkennung von Standard-Angriffen wie z.B. SQL-Injection
- Warnen falls eine Flag an einen Client geschickt wurde (Flagdetection)
- Erkennen von Scans (z.B. durch Nessus oder nmap)
Erkennung von Standard-Angriffen
Neben den integrierten Analyse-Modulen wurden für den Wettbewerb noch einige andere Regeln zusammengestellt. Eine gute Einstiegsquelle dafür ist die Liste der konvertierten Snort Rules (leider nicht mehr online verfügbar) sowie das modSecurity-Kapitel vom
Apache Security Buch und natürlich die "largest collections of modsecurity rules and signatures on the Internet" von
gotRoot. Das komplette modSecurity-Regelwerk für den Wettbewerb wird hier allerdings nicht freigegeben.
Flagdetection
Die Flagdetection erwies sich als sehr nützlich, erfordert aber eine Analyse der Botzugriffe um Angriffe von Botzugriffen zu unterscheiden. Da diese Analyse während des Wettbewerbs nicht durchgeführt wurde, gab es leider teilweise Fehlalarme.
Insgesamt gingen ab Konfiguration der Flagdetection 376 Flags über den Apache von uns aus nach draußen. Davon waren zwei Flags vorsätzlich erzeugte Fake-Flags. Die Flagdetection wurde leider nicht sofort angeschaltet sondern erst ab 06:55:37. D.h. alle Angaben bezgl. der Anzahl ausgehender Flags über den Webserver beinhalten nicht die Anzahl ausgehender Flags vor diesem Zeitpunkt.
Konfigurationsanweisung um ausgehende Flags zu erkennen:
CODE:
SecFilterScanOutput on
SecFilterSelective OUTPUT "MTN"
Beispiel für eine Flagdetection-Warnung (short-Format):
CODE:
[Fri Jun 10 06:55:44 2005] [error] [client 10.8.1.233] mod_security: Warning. Pattern match "MTN" at OUTPUT [hostname "10.7.1.3"] [uri "/~estore/cgi-bin/debug.php"]
Beispiel für eine Flagdetection-Warnung (long-Format):
CODE:
========================================
Request: 10.8.1.233 - - [10/Jun/2005:06:55:44 --0700]
"GET /~estore/cgi-bin/debug.php HTTP/1.1" 200 10987
Handler: cgi-script
----------------------------------------
GET /~estore/cgi-bin/debug.php HTTP/1.1
Host: 10.7.1.3
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cache-Control: max-age=0
mod_security-message: Warning. Pattern match "MTN" at OUTPUT
HTTP/1.1 200 OK
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
Erkennen von Scans
Die Regeln zum Erkennen von Scans erwiesen sich leider als nicht ausreichend. Kein Team hat einen Webserverscan mit
nmap oder
Nessus gemacht. Allerdings fand sich beim Durchschauen der Logs Zugriffe von einem weiteren Scanner:
Nikto. Dieser wurde leider durch die Regeln nicht erfasst.
Auswertung
Durch das AuditLog von modSecurity wird die Auswertung der Webangriffe wesentlich erleichtert. Zwar loggt Apache standardmässig schon viel im access-log mit, allerdings muss man zur Analyse von HTTP-Angriffen per POST schon den aufgezeichneten Traffic durchsehen.
Ein Beispiel für einen Angriff über POST – access-log:
CODE:
10.3.1.1 - - [10/Jun/2005:08:31:40 -0700] "POST /~contact/cgi-bin/contact_query.pl HTTP/1.1" 200 708 "-" "libwww-perl/5.803"
und der Eintrag zu demselben Angriff im Auditlog:
CODE:
Request: 10.3.1.1 - - [10/Jun/2005:08:31:40 --0700] "POST /~contact/cgi-bin/contact_query.pl HTTP/1.1" 200 708
Handler: cgi-script
----------------------------------------
POST /~contact/cgi-bin/contact_query.pl HTTP/1.1
Connection: close
Host: 10.7.1.3
User-Agent: libwww-perl/5.803
Content-Type: application/x-www-form-urlencoded
Content-Length: 106
106
<strong>identity=mysql%20-u%20corpdbuser%20-pbasstard%20-D%20corpdb%20-e%20'select%20*%20from%20employees'&debug=1</strong>
HTTP/1.1 200 OK
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html
Es ist ersichtlich, dass die wichtige Information (hier fett hervorgehoben) erst im Auditlog sichtbar wird. Dadurch kann ein Angriff nicht mehr durch Verwenden von POST und Cookies versteckt werden.
Leider wurde die Option alle Requests zu loggen erst später genutzt (Aktivierung um 08:01:29).
Probleme bei der Analyse entstanden dadurch, dass der Server zur Live-Entwicklung und Testen verwendet wurde – Zugriffe vom eigenen Team mussten rausgefiltert werden und Entwicklungsfehlermeldungen machten das Lesen der Logs schwerer.
[...NEXT]
26c3