Abbildung 1: Das grafische Frontend des "Web Application Attack and Audit Framework" listet in der mittleren Spalte die als Plugins realisierten Sicherheitsscans auf.

Wenn Kolumnist Charly unter Mühen eine kleine, aber feine Webseite gebastelt hat, will er sie mit einem Securityscanner auf Schwachstellen prüfen. Unter den vielen Hackertools fällt seine Wahl auf W3AF.

Penetrationstest sind eigentlich eine Aufgabe für Spezialisten, die ihre Tools nicht nur bedienen können, sondern die möglichen Sicherheitslücken und Angriffsmethoden verstehen und von Fall zu Fall ausprobieren. Der Grundsatz: Feure keine Breitseiten aufs Ziel, sondern sondiere verwundbare Punkte vorsichtig und wähle einen Angriff passend aus.

An geeigneten Tools mangelt es nicht. Allerdings sind Metasploit [1] und Open VAS [2] überdimensioniert, wenn ich nur prüfen möchte, ob ich in meine neue Webseite versehentlich einen Fehler eingebaut habe, der sie anfällig für Cross Site Scripting oder SQL-Injection macht. Für solch kleine Checks nehme ich lieber das “Web Application Attack and Audit Framework” [3] zur Hand.

Modularer Aufbau

W3AF ist modular angelegt und lässt sich komplett per Skript steuern. Zum interaktiven Arbeiten bringt das Tool eine Textoberfläche und ein GUI (Abbildung 1) mit. Alle Aktionen, die W3AF auslösen kann, sind in Python-Plugins verpackt. Das Paket liefert sie in sechs Gruppen aufgeteilt aus, die in der zweiten Spalte des Screenshots alphabetisch sortiert zu sehen sind. Sinnvollerweise beginnt man mit den Plugins in der Gruppe »discovery« . Sie forschen das Zielsystem aus, erkunden die URL-Struktur und versuchen die Versionsnummern der Server-seitigen Software zu ermitteln.

Ich lasse W3AF auf ein Testsystem los, auf dem eine längst veraltete Version von WordPress läuft – das Tool erkennt sie einwandfrei. Einige Discovery-Plugins sind betriebssystemspezifisch, etwa die Dotnet-Versionserkennung. Wenn ich weiß, dass auf dem Zielsystem Linux läuft, deaktiviere ich diese Plugins schon vor dem ersten Scan mit einem Klick, um Zeit zu sparen.

Abbildung 1: Das grafische Frontend des “Web Application Attack and Audit Framework” listet in der mittleren Spalte die als Plugins realisierten Sicherheitsscans auf.

Ein gegnerisches IDS narren

Hege ich den Verdacht, dass auf der Gegenseite ein Intrusion-Detection-System lauert, versuche ich, es mit der »evasion« -Gruppe zu verwirren. W3AF kodiert dann Zeichen und URLs um, wandelt beispielsweise »foo.asp« in »%uFF66oo.asp« um. Die Gruppe »audit« versammelt Plugins, die Schwachstellen aktiv auszunutzen versuchen. Die Waffensammlung umfasst Injection-Code für LDAP und SQL sowie Plugins für XSS oder Formatstring-Lücken. Auch hier erwartet W3AF vom Admin, dass er für das Zielsystem geeignete Plugins wählt.

Schließlich sind auch noch Brute-Force-Angriffe möglich. Sie versuchen Kombinationen aus Benutzernamen und Passwort zu erraten, ähnlich wie es das Konsolentool John the Ripper vormacht. Leichte Passwörter erlegt W3AF in Windeseile. Meine WordPress-Opferinstallation, die mit dem Passwort »secret« eher mies gesichert ist, leistet ganze 25 Sekunden Widerstand.

In dem kleinen Scharmützel gewinnt W3AF genau das Gelände, das ich hoffte zu besetzen: Ich erlange schnell den Überblick, wo eine Webseite sicherheitstechnisch noch Verbesserungsbedarf aufweist. In Konkurrenz zu den großen Panzerbataillonen mit ihren umfangreichen Exploit-Datenbanken steht der W3AF-Scanner natürlich nicht.