Intransparente Scanner und False Positives
Marc Ruef | 10.11.2008

Kurz nachdem ich im Data Becker-Verlag als Co-Autor das Buch Hacking Intern (http://www.amazon.de/dp/381582284X) veröffentlicht hatte, habe ich mit der Übersetzung des Buchs Network Intrusion Detection (http://www.amazon.de/dp/3826650441/) von Stephen Northcutt und Judy Novak aus dem Englischen begonnen. Ich mochte das Buch, welches ich selbst vor meiner Übersetzungsarbeit mindestens drei Mal durchgelesen habe (zwei Mal auf Deutsch und einmal auf Englisch), wirklich sehr.

Dabei kann ich mich noch sehr gut daran erinnern, wie die Autoren ausdrücklich darauf hinwiesen, dass gerade im Bereich der elektronischen Erkennung die Transparenz eine ungemein wichtige Rolle spielt. Ein entsprechendes Intrusion Detection-System kann nur dann effektiv und effizient betrieben werden, wenn dessen Funktionsweise offengelegt ist: Indem die jeweiligen Rules/Pattern verstanden oder gar angepasst werden, kann eine umfassende Lösung erreicht werden. Blackbox-Systeme, bei denen man keines der beiden Dinge machen kann, widersprechen dem eigentlichen Ziel der Sicherheitsüberwachung.

Dieses Paradigma aus der elektronischen Einbruchserkennung kann und muss genauso auf den Bereich der Sicherheitsüberprüfungen übernommen werden. Auch hier ist man, will man gewisse Dinge möglichst effektiv analysieren, auf unterschiedliche Software-Produkte angewiesen. Durch Scanner wie nmap oder Nessus können eine Vielzahl an Informationen automatisiert zusammengetragen und ausgewertet werden.

Bei unseren webbasierten Tests ziehen wir ebenfalls N-Stealth (http://www.nstalker.com/products/) zurate. Hierbei handelt es sich um einen Web-Scanner, der ursprünglich durch den Brasilianer Felipe Moniz geschrieben wurde. Die neueste Version der Software kommt mit einigen herausragenden Funktionalitäten daher. So wird ein umfassendes Crawling des Webservers vorgenommen und auf der Basis dieses Mappings die einzelnen Test-Module dem Zielsystem angepasst (z.B. dynamische Allokation von zu prüfenden Objekten). Ich bin sehr zufrieden mit dem Produkt, welches natürlich noch punktuell verbessert werden kann. Schlussendlich bietet es aber etwas, was man sich schon vor 10 Jahren sehnlichst herbeigewünscht hat.

In einem meiner Penetration Tests wies ich sodann üblicherweise die unliebsam unterstützten HTTP-Methoden des Webservers aus. Darunter gehören klassische Methoden wie HEAD, POST, PUT, DELETE, OPTIONS, TRACE und TRACK (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html). Aber auch Erweiterungen aus WebDAV, zum Beispiel PROPFIND und MOVE, konnte ich nebenbei im Rahmen des N-Stealth Scans als unterstützt ausmachen. Dies, und andere, weitaus kritischere Probleme, teilte ich dem Kunden mit. Mit der Abgabe unseres Reports war er sogleich darum bemüht, die eben genannten Probleme zu beheben.

Nach der Umsetzung bat er mich, wenigstens kurz zu prüfen, ob nun die HTTP-Methoden korrekt gesetzt sind. Da ein solcher Re-Check eigentlich jeweils Teil eines neuen Projekts ists und nicht in der initialen Prüfung enthalten ist, habe ich nur kurz im Hintergrund N-Stealth angeworfen und auf die Resultate gewartet. Noch immer wurden mir PROPFIND & co. als "supported" ausgewiesen. In einem kurzen Mail wies ich den Kunden darauf hin, dass er das Problem wohl noch nicht richtig adressiert hätte.

In seiner Antwort bat er um konkrete Hilfestellung, wie die Konfigurationseinstellungen unter Apache auszusehen hätten. HTTP-Methoden können dabei sowohl innerhalb einer .htaccess-Datei als auch in der httpd.conf deaktiviert werden. Ebenso wies er mich darauf hin, dass in seinen manuellen Tests mittels Telnet die beanstandeten Methoden nur noch ein 403 Forbidden (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) liefern würden. Also machte ich mich daran, nachdem ich die Konfigurationsmöglichkeiten dokumentiert hatte, die Unterstützung der HTTP-Methoden manuell zu verifizieren.

Zu meinem Erstaunen lieferten, abgesehen von einer speziellen Form von OPTIONS, alle kritischen Methoden nur noch ein 403 Forbidden zurück. Das System war also eigentlich gehärtet. Aber wieso meldete mir N-Stealth noch immer, dass sie unterstützt seien? Um der Sache auf den Grund zu gehen, habe ich einen erneuten Scan initiiert und diesen mittels Wireshark mitgeschnitten. Ich wollte sehen, ob die Anfragen der Scanning-Software irgendwie anders waren, weder meine manuellen Zugriffe.

Zu meinem Erstaunen wurden die exakt gleichen Anfragen verwendet, die zu den exakt gleichen Resultaten - nämlich dem gewünschten Forbidden - führen sollten. Es schien, als hätte N-Stalker irgendein Problem bei der Auswertung von HTTPS-Webservern. Da die Test-Prozeduren weder im Detail einsehbar noch im Report umfassend dokumentiert waren, musste ich also zuerst langwierig eine Netzwerkanalyse einspannen, um dem Mysterium auf den Grund zu gehen. Ich schrieb sofort ein Email an die Entwickler und informierte meinen Kunden über die unschöne Ungenauigkeit.

Uneingeschrenkte Transparenz bleibt sehr wichtig, um Software und ihre Funktionsweise verstehen zu können. Letzteres ist unabdingbar, um im Sicherheitsbereich intelligent agieren zu können. Und irgendwie führt mich diese ganze Geschichte zu einem meiner alten Grundsätze, den ich ursprünglich eher selbstironisch postuliert hatte, zurück:



"Traue nie einer Software, die Du nicht selber in schlechtem Stil programmiert hast."