Gruppieren von Schwachstellen in Reports 
Marc Ruef | 10.08.2009

Eine Sicherheitsüberprüfung ist im Grunde nichts Spezielles: Im Rahmen der Analyse werden sämtliche gefundenen Schwachstellen und Sicherheitslücken dokumentiert. Bei einem Web Application Penetration Test sind dies typischerweise Cross Site Scripting und SQL-Injection Schwachstellen, die unbedingt adressiert werden müssen, um ein annehmbares Mass an Sicherheit erreichen zu können.

Der Kunde erhält nach Abschluss der Prüfungen ein Reportdokument, welches alle gefundenen Schwachstellen dokumentiert. Bei einer Vielzahl an Findings wird dabei gerne eine Tabellenstruktur verwendet, um die Einträge und ihre Eigenschaften einfacher finden zu können. Je nach Anzahl der geprüften Systeme und der gefundenen Schwachstellen kann ein Report mehrere Dutzend oder gar Hundert Seiten lang ausfallen.

Werden breitflächige Sicherheitsüberprüfungen auf eine Vielzahl an Systemen durchgeführt, ist das Reporting eine nicht zu unterschätzende Herausforderung. Der Kunde will sich schliesslich nur ungern durch 600 Seiten technische Details wühlen, um die wichtigen Informationen zu finden. Hilfsmittel wie Statistiken und Übersichtstabellen (z.B. die kritischsten oder meistverbreiteten Fehler) sind bei solchen Projekten sehr geschätzt.

Eine einfache Möglichkeit der Reduktion der Reportgrösse besteht im Gruppieren von Schwachstellen. Wird zum Beispiel im Rahmen eines Netzwerkscans ein Route-Traceing mit den verschiedenen Protokollen (ICMP, UDP und TCP) durchgeführt, kann anstelle eines separaten Eintrags für jeden traceroute-Zugriff ein allgemeiner Eintrag mit dem Titel "Route-Traceing erfolgreich" erstellt und in den Details die Hinweise auf das dedizierte Verhalten der einzelnen Protokolle gegeben werden. Anstelle von drei Einträgen ist damit nur noch einer erforderlich. Bei 150 Systemen können dann schnell mal 300 Einträge gespart werden (jenachdem sind das ein paar Dutzend Seiten).

Die Diskussion des Gruppierens muss aber ebenfalls an anderer Stelle geführt werden. Und zwar tritt es immerwieder auf, dass Webserver ihre eigene Implementierung bei den Standardfehlerseiten ausweisen (einfach zu Prüfen durch eine Eingabe wie http://www.apache.org/404test.html). Typischerweise zeigt Apache den eigenen Namen und die Versionsnummer im Footer der spartanischen Fehlerseiten an (Beispiel (http://www.computec.ch/_images/newspost_images/apache_gibt_implementierung_preis.png)). Diese Information ist für einen Angreifer interessant, da sie in das Application Fingerprinting (http://www.computec.ch/news.php?item.266) miteinbezogen und damit produktspezifische Angriffe vorbereitet werden können.

Nicht nur Apache weist diese Eigenart auf. Gleiches Verhalten kann beim Microsoft IIS (Beispiel (http://www.computec.ch/_images/newspost_images/iis_gibt_implementierung_preis.png)) und bei vielen anderen Webserver-Implementierungen beobachtet werden. Es stellt sich nun die Frage, ob dies gänzlich unterschiedliche Fehler sind oder ob es sich immer um das gleiche Problem handelt:

* Es spricht dafür, dass es das gleiche Problem ist, (1) weil die Grundcharakteristik identisch ist: "Ein Angreifer kann mit der Durchsicht von Fehlerseiten die eingesetzte Webserver-Implementierung anhand eines Vermerks in der Ausgabe in Erfahrung bringen." Die Schwachstelle könnte entsprechend den Titel "Webserver Fehlerseite gibt Implementierung preis" lauten. Dieses Finding ist sodann sowohl Apache als auch Microsoft IIS und den anderen Implementierungen zuzuweisen.

centerSchwachstelle Produkt A = Schwachstelle Produkt B/center

* Doch es gibt grundlegende Argumente, die gegen eine Zusammenfassung zu einem generischen Problem sprechen. Als erstes tritt das Problem bei den unterschiedlichen Produkten (1) gänzlich anders auf. (1a) Die Position der Preisgabe ist eine andere und (1b) die zu suchende Zeichenkette unterscheidet sich ebenso. Das Exploit wird damit zu einem gewissen Grad individuell. (2) Ebenso der Vorgang, diese Probleme zu beheben. Vertritt man diesen Standpunkt, müssten also unterschiedliche Schwachstellen mit produktbezogenen Titeln wie "Apache Webserver Fehlermeldung gibt Implementierung preis" oder "MS IIS Webserver Fehlermeldung gibt Implementierung preis" genutzt werden.

center(Exploiting A ≠ Exploiting B) ⇒ (Schwachstelle Produkt A ≠ Schwachstelle Produkt B)/center

Das Zusammenfassen der soeben beschriebenen Problematik hilft nicht direkt dabei, einen Report kürzer zu machen. Schliesslich fallen keine Findings weg, sie werden lediglich in Bezug auf ihren Titel und ihre Dokumentation vereinheitlicht. Der Vorteil besteht in erster Linie darin, dass eine statistische Auswertung der gefundenen Fehler über verschiedene Kunden, Projekte, Netzwerke und Hosts hinweg die Vergleichbarkeit gewährleisten kann. Werden gleichwertige Findings verwendet, können Aussagen wie "In Zone A geben B Webserver ihre Implementierung preis" gemacht werden. Werden die Fehler nicht zusammengefasst, kann dies in einem ersten Schritt ausschliesslich für die einzelnen Produkte getan werden: "In Zone A geben X Apache Webserver und Y Microsoft IIS Webserver ihre Implementierung preis." Erst in einem zweiten Schritt müssen die produktspezifischen Einträge zu einem generischen Eintrag zusammengefasst werden, was sich jenachdem nicht einfach gestaltet (Ab wann handelt es sich wirklich um das gleiche Problem);

centerSchwachstellengruppe X = {Schwachstelle A, Schwachstelle B, ...}/center

Ein Report sollte möglichst granular und individuell die einzelnen Informationen erfassen. Aus diesem Grund ist es anzuraten, einzelne Schwachstellen für Fehler in verschiedenen Produkten vorzuziehen (vor allem bei zielgerichteten Penetration Tests). Die Normalisierung dieser Daten zwecks statistischer Auswertung hat auf einer Metaebene zu erfolgen (vorzugsweise bei breitflächigen Vulnerability Scans). So sollten alle Findings mit dem Titel "Produkt X Fehlerseite gibt Implementierung preis" gruppiert und ausgewertet werden. Der Aufwand des Reportings steigt damit an, kann jedoch sowohl die Bedürfnisse des Auditoren (möglichst viele Details) als auch jene des Kunden (möglichst weiterverwertbare Daten) befriedigen.