Test: Googles Skipfish

Seite 3: Auswertung

Inhaltsverzeichnis

Unterm Strich kann Skipfish bei der Konstellation IIS 7.5 und Screwturn nicht glänzen. Hervorzuheben ist allerdings, dass der brutale Wörterbucheinsatz selbstständig die URI /wiki/ gefunden hat und dadurch ohne manuelle Hilfe dieses untersuchen konnte.

Bei der Untersuchung des Apache Servers mit CGI-Scripten, für die die Wörterbuchfunktion auf pures Lernen begrenzt wurde, schneidet Skipfish etwas besser ab. Es werden nur 47 Ergebnisse mit erhöhtem Risiko, 6 mit geringem Risiko, eine Warnung und 65 Bemerkungen angezeigt, was auch nur 83 MB beansprucht. Mit den klassischen Perl-generierten HTML-Formularen weiß Skipfish interessanterweise nicht umzugehen. Daher werden auch die gelernten Schlüsselworte nicht als Eingabe für die Formularfelder probiert. Der Scanner erkennt allerdings richtig, dass die Formulare nicht gegen Cross Site Request Forgery (CSRF) geschützt sind.

Sowohl unter der Kategorie "Interesting File" als auch unter "Incorrect or missing MIME type" wird eine URL gelistet, bei der tatsächlich eine Fehlkonfiguration des Servers zur Anzeige eines CGI Scripts im Quellcode führt, anstatt seine Ausführung auszulösen. Dieses Ergebnis ist der Kombination aus Dateinamen und Endungen (in diesem Fall einer leeren Endung) zu verdanken.

Die Untersuchung des Druckers lieferte übrigens keine Ergebnisse, da wir den Scan nach 18 Stunden abbrechen mussten, weil immer noch kein Ende in Sicht war. In solchen Situationen stört, dass Skipfish seinen Report über die bisherigen Erkenntnisse erst nach dem regulären Ende des Durchlaufs oder beim vorherigen Beenden mit Control-C ins Verzeichnis schreibt. Während des Laufs hat man keine Möglichkeit herauszufinden, ob und was das Tool bereits gefunden hat.

Die Stärke von Skipfish ist das Entdecken von vergessenen Daten sowie das Provozieren von unerwartetem Verhalten auf den Servern. Die Permutation der Schlüsselwörter und Datei-Erweiterungen sowie gelernter Elemente sind einem Fuzzer sehr ähnlich, was sich natürlich auf die resultierenden Datenmengen ähnlich auswirkt.

In großen Rechenzentren, wie denen von Google, die eine sehr heterogene Landschaft von Web Applikationen beherbergen, welche auf nahezu unbegrenzte Rechnerressourcen und Netzwerkbandbreite zurückgreifen können, kann der Einsatz sicherlich schon heute zur Entdeckung von unerwarteten Funktionen und Inhalten führen.

Hat man allerdings direkten Zugriff auf das Dateisystem der Web-Server, ergibt der Einsatz von Skipfish weniger Sinn – insbesondere wenn er über eine Internet-Verbindung erfolgt. Die übertragenen Datenmengen des Scanners entsprechen fast einem vollständigen Abbild des Dateisystems, sodass man die Skripte und Dateien einer Anwendung besser in aller Ruhe und mit bekannten Mitteln direkt vor Ort analysiert.

Der Report von Skipfish ist zwar sehr übersichtlich, die aufgeführten Probleme erfordern jedoch einiges an Interpretationsarbeit.

Für den professionellen Gebrauch ist Skipfish in seiner momentanen Form nur sehr bedingt geeignet. Die auf jeden Fall fällige Überprüfung der Testergebnisse artet wegen der Meldungsflut sehr schnell zur Sysiphus-Arbeit aus. Zudem sind gemeldete Probleme wie "Incorrect or missing charset", "Incorrect caching directives" oder "Incorrect or missing MIME type" sehr abstrakt und alles andere als eindeutig. Selbst erfahrene Pen-Tester müssen oft erstmal Recherchieren, worin das Problem nun eigentlich besteht. Mit diesem Hintergrund ist Skipfish für den weniger professionellen Anwender oder für den schnellen "Test für Zwischendurch" überhaupt nicht geeignet und führt vermutlich eher ungerechtfertigt zu Panik als zur Beruhigung.

Der Einsatz der Wörterbuchfunktion verbietet sich in vielen Einsatzszenarien schon allein wegen der anfallenden Datenmengen und der daraus resultierenden Last für die Zielsysteme. Eine ausgewachsene Java-basierte Business-Web-Anwendung würde einem Skipfish-Scan mit minimalem Wörterbuch wahrscheinlich nicht standhalten, da CPU- und Hauptspeicherbedarf das System vorher zum Stillstand bringt. Auch Firewalls mit komplexeren Inspektionsmodulen oder IDS/IPS Systeme würden die Empfänger ihrer Log-Meldungen in extremen Datenmengen ertränken oder schlicht den Dienst quittieren. (dab)