Test: Googles Skipfish

Seite 2: Interpretionsarbeit

Inhaltsverzeichnis

Für die Untersuchung des Apache-Webservers wurde versuchsweise die Wörterbuchfunktion ausgeschaltet. Es war Skipfish aber weiterhin gestattet, neue Wörter während des Scan-Vorgangs zu lernen, was 304 neue Einträge zur Folge hatte. Dies reduzierte die Laufzeit dann auf 20 Minuten, in denen knapp 300.000 HTTP-Anfragen gestellt wurden, welche mit 232 MB Netzwerkverkehr zu Buche schlugen.

Generell liefert Skipfish vergleichsweise viele Ergebnisse und legt diese im angegebenen Verzeichnis als HTML, JavaScript mit JSON und rohen Datendateien ab. Den Report kann man dann in einem Browser mit JavaScript betrachten oder die Rohdaten selbst auswerten. Der Anteil der Fehlalarme ist leider deutlich höher als bei zum Vergleich eingesetzten Tools wie Nikto oder der Burp Suite. So werden gerne mal reguläre ASCII-Textdateien als JSON-Antwort ohne XSSI-Schutz (Cross Site Script Inclusion) interpretiert. Besonders großen Wert legt Skipfish auf korrekte MIME-Type und Zeichensatz Antworten vom Server. Jede Abweichung wird mit einem Ergebnis der Klasse "erhöhtes Risiko" quittiert, wobei wiederum nur ein Teil tatsächlich zutreffen.

Die Möglichkeit Verzeichnisinhalte aufzulisten, würdigt Skipfish bei keinem der getesteten Ziele mit einem Ergebniseintrag. Auch dem Inhalt der robots.txt-Datei, welcher gerade für die Identifikation interessanter Bereiche des Server wichtig sein kann, wird keine weitere Beachtung geschenkt und dem Anwender als "Interesting File"-Ergebnis zur eigenen Interpretation überlassen.

Die Ausbeute der vier Stunden andauernden Untersuchung des IIS 7.5 mit dem Screwturn-Wiki sind 8 Ergebnisse mit hohem Risiko, 264 mit erhöhtem Risiko, 55 mit geringem Risiko, 123 Warnungen und 254 Anmerkungen. Die Gesamtmenge an Daten auf der Festplatte beläuft sich auf 851 MB und der Webbrowser sollte ein Gigabyte freien Arbeitsspeicher zur Verfügung haben, damit man die Ergebnisseite auch betrachten kann.

Alle drei gemeldeten SQL-Injection auf dem Typo3-System stellten sich bei manueller Prüfung als Fehlalarme heraus.

Leider stellen sich die 8 wichtigsten Ergebnisse – alles angebliche Integer-Überläufe in HTTP-GET-Parametern, als Falschmeldungen heraus. Bei der nächsten Klasse von Ergebnissen, "Interessante Server Meldungen", werden HTTP 404 Fehler (Ressource nicht gefunden) und HTTP 500 Fehler (interner Serverfehler) vermischt, so dass man alle 130 angezeigten Ergebnisse einzeln durchgehen müsste. Da der IIS bei "HTTP 500" eine generische Fehlermeldung zeigt, um dem Angreifer keine zusätzlichen Informationen zu geben, müsste man die verbliebenen Anfragen einzeln in Korrelation mit den Webserver-Log-Daten setzen oder erneut manuell testen. Ein Blick in die Server-Logs zeigt allerdings, dass sich dieser Aufwand nicht lohnen würde, da es sich immer um den selben Fehler handelt und dieser keine Relevanz für die Sicherheit hat. Dass Falschmeldungen keine Ausnahmen sind, zeigte sich auch bei einer späteren Analyse eines Typo3-Systems, bei dem Skipfish vor kritischen SQL-Injection-Lücken warnte.

Als Besonderheit ist anzumerken, dass Skipfish das Vorhandensein eines IPS erkennt und unter "Warnungen" aufführt. Im Test bemerkte es die HttpRequestValidationException, welche von ASP.NET bei allzu offensichtlichen SQL-Injection- oder Cross-Site-Scripting-Angriffen erzeugt wird, und zu einem HTTP 500 Fehler führt.