Moderne IT-Infrastruktur ist vielfältig und schnelllebig. Darin den Überblick zu behalten, welche Komponenten Schwachstellen und Sicherheitslücken aufweisen könnten, ist schwierig. Die vollumfängliche manuelle Prüfung ist nicht mehr möglich, weshalb bei breitflächigen Analysen auf automatisierte Vulnerability Scanning Lösungen zurückgegriffen wird. Die durch sie zusammengetragenen Resultate können oftmals individuelle und komplexe Zusammenhänge nicht berücksichtigen, weshalb die Qualität der Resultate unterschiedlich ausfallen kann. Das Identifizieren dieser Qualität ist jedoch massgeblich, um mit den Resultaten weiterarbeiten zu können.

Die Analyse von Checks hilft dabei, ein Verständnis für deren Funktionsweise aufzubauen, um die erwartete Qualität ableiten zu können. Ein Security Check – und damit auch ein entsprechendes Scanning Plugin – kann sich auf drei unterschiedliche Mechanismen abstützen:

• Derivativ: Eine gewonnene Information wird als Grundlage gebraucht, um eine Eigenschaft abzuleiten. Typisches Beispiel ist das Banner-Grabbing, bei dem der Willkommens-Banner einer Applikation (z.B. ein Webserver) abgegriffen und ausgewertet wird. Wird dort eine alte Software-Version ausgewiesen, wird von der Existenz der entsprechenden Schwachstellen in eben dieser Version ausgegangen.
• Scanning: Durch einen spezifischen Zugriff kann eine Ressource identifiziert oder ein Verhalten provoziert werden. Hierbei handelt es sich noch nicht um die Ausnutzung der Schwachstelle. Dieser Mechanismus wird traditionell durch CGI-Scanner eingesetzt, durch die potentiell verwundbare Skripte auf Webserver-Installationen identifiziert werden können.
• Exploiting: Eine vermutete Schwachstelle wird konkret ausgenutzt und das Verhalten des Zielobjekts in invasiver Weise geprüft. Falls das Verhalten einer erfolgreichen Ausnutzung entspricht, wird die Schwachstelle als gegeben deklariert. Dies ist zum Beispiel der Fall, wenn Eingaben zu einer SQL-Injection führen und damit ein Mehr an Datenbankzugriffen erlangt werden kann.

Herstellerangaben in Plugins und Reports

Bei gewissen Produkten hilft der Hersteller bei der Erklärung, wie die Funktionsweise aufgebaut ist und mit welcher Qualität der Resultate gerechnet werden kann.

Qualitätsangabe durch Hersteller

Manche Hersteller weisen aus, wie hoch die Vertrauenswürdigkeit eines Checks ist. Dies wird oft als Accuracy oder Confidenciality betitelt. Dadurch wird eine einfache erste Ausgangslage geschaffen, um die Qualität beurteilen zu können.

Bei einer solchen Einstufung stellt sich natürlich immer die Frage, wie diese gemessen und erstellt wird. Hersteller tendieren dazu, ihre Resultate besser einzustufen, als sie wirklich sind. Anhand von Stichproben sollte untersucht werden, welches Qualitätsniveau erreicht werden kann und in welcher Form dieses kommuniziert wird. Qualys tendiert zum Beispiel dazu derivative Tests mit der Accuracy: poor auszuweisen.

Hinweise in Titel und Beschreibung

Das Erkennen von rein derivativen Checks kann anhand der Titel und Beschreibung dieser stattfinden. Sobald von der Erkennung von Versionsnummern oder der Identifikation von zig Schwachstellen (z.B. aus einem Patch heraus) möglich sind, muss von derivativen Mechanismen ausgegangen werden.

Manchmal wird in der Beschreibung des Texts explizit ausgewiesen, wie dieser Funktioniert. Zum Beispiel 105729 – EOL/Obsolete Software: Nginx Server Detected von Qualys:

The unauthenticated check tries to fetch the version from the version exposed in the Server: tag of a HTTP response

Hier geht also klar hervor, dass es sich um ein derivatives Plugin handelt, das die Informationen als nicht-authentisierter Benutzer vom Willkommens-Banner ableitet.

Checks, die auf Scans basieren, weisen im Titel oder der Beschreibung oftmals hinweise auf exponierte Komponenten – oder im Fall eines Webservers die exponierten Dateipfade – hin. Meist wird dann von Datei /cgi-bin/foo.cgi gefunden gesprochen statt von einer konkreten Schwachstelle. Einige Beispiele von Qualys:

Falls in einem weiteren Schritt ein erfolgreiches Exploiting stattgefunden hat, werden die Resultate in der Regel im Report festgehalten. Bei der Prüfung von Cross Site Scripting-Schwachstellen werden HTML-Ausgaben mit den injizierten Codefragmenten angezeigt und bei Directory Traversal die Inhalte der ausgelesenen Dateien dargestellt.

Funktionsweise ermitteln

Die grundlegende Qualität eines Checks lässt sich am besten beurteilen, wenn die Funktionsweise dessen in allgemeiner und konkreter Weise ermittelt wird. Hierzu gibt es verschiedene Ansätze, die im Folgenden diskutiert werden sollen.

Codeanalyse

Die einfachste, zuverlässigste und nachhaltigste Methode ist die Untersuchung des Codes eines Checks. Dies ist bei quelloffenen Lösungen ohne Probleme möglich. Als gutes Beispiel gilt hier seit bald 20 Jahren das kommerzielle Produkt Nessus der Firma Tenable.

Die Checks von Nessus werden als einzelne Plugins umgesetzt. Diese sind in NASL (Nessus Attack Scripting Language), einer an C angelehnten Skriptsprache geschrieben. Die Plugins können unkompliziert in einen Texteditor geladen, dort untersucht oder angepasst werden. Nmap verfährt hier ähnlich mit den in LUA geschriebenen NSE-Skripten, die im Standardpaket mitgeliefert werden oder eigenständig entwickelt werden können.

Die Kernkomponente von Nessus war ebenfalls jahrelang quelloffen, wurde dann aber aus kommerziellen Gründen nicht mehr als Quellcode herausgegeben. Ebenso gibt es einige vorkompilierte Bibliotheken, die mitgeliefert werden. Die Funktionsweise derer kann nicht ohne weiteres eingesehen werden.

Kommerzielle Produkte wie Qualys erheben für sich gar nicht den Anspruch, eine Transparenz dieser Art gewährleisten zu können. Es stehen keine Quellen, weder zur Kernkomponente noch zu den einzelnen Checks, zur Verfügung. Es werden gar aktiv Anstrengungen unternommen, um ein Analysieren (Reverse Engineering) der Komponenten zu erschweren.

Ableitung von Schwachstelle

Falls keine Möglichkeit besteht, Einblick in die Quellen eines Checks zu erhalten, kann in einem ersten Schritt die zu erwartende Funktionsweise von der zur prüfenden Schwachstelle abgeleitet werden.

Dabei gilt es zu bedenken, dass Vulnerability Scanner möglichst einfach und unkompliziert zu einem Resultat kommen wollen. Es ist deshalb nicht untypisch, dass ein Grossteil der Checks derivativer oder höchstens scannender Natur sind. Die Implementierung eines echten Exploitings ist aufwändig, fehlerbehaftet und risikoreich.

Gewisse Protokolle, Plattformen und Check-Klassen bieten sich an, rein derivativ umgesetzt zu werden. Typischerweise klassische Protokolle wie HTTP, SMTP und FTP. Diese sind sehr simpel gehalten, kommunizieren im Klartext und weisen normalerweise bei einer Verbindungsaufnahme die installierte Software aus. Das Auswerten dieses Willkommen-Banners lässt mittels einfachem Pattern Matching das Ausmachen von Produkt und manchmal gar Version zu.

Gewisse Vulnerability Scanner kommen mit Checks daher, die explizit veraltete Versionen ausmachen und diesen dann entsprechende Mängel anhaften. Einige Beispiele von Qualys:

Wenn bei einem Webserver ein Banner älter als 2.3.30 identifiziert wird, dann wird davon ausgegangen, dass dieser Check zutrifft.

Die Zuverlässigkeit eines solchen Checks muss auf drei Ebenen diskutiert werden:

• Wie gut ist die Ermittlung des Banners
• Wie korrekt sind die ermittelten Informationen
• Wie zuverlässig ist die Ableitung zur Schwachstelle

Banner können modifiziert werden, wie dies bei manchen Webserver-Implementierungen möglich ist. Oder es werden die für einen Check erforderlichen Informationen, wie zum Beispiel die installierten Patches, nicht ausgewiesen. In diesem Fall könnten fehlerhafte Ableitungen stattfinden. Derivative Checks sind deshalb sehr unzuverlässig.

Einen Schritt weiter als rein derivative Checks gehen Scan-Zugriffe. Hier werden effektiv Zugriffe durchgeführt, um die Existenz von Komponenten oder das Verhalten dieser zu ermitteln. Es findet dabei jedoch kein Exploiting statt, da dieses oftmals aufgrund seiner Komplexität und Invasivität mit entscheidenden Nachteilen verbunden ist.

Viele Vulnerability Scanner weisen generische Checks für das Ermitteln von typischerweise verwundbaren Skripten auf. Diese Aufgabe wurde früher durch sogenannte CGI-Scanner erledigt, die verschiedene URLs durchprobiert haben. Sobald ein Statuscode die Existenz der Schwachstelle vermuten lässt, wird davon ausgegangen, dass die Datei und somit die durch sie eingeführte Schwachstelle gegeben ist.

Ähnlich wie beim rein derivativen Ansatz ist die Anzahl von potentiellen False-Positives nicht zu vernachlässigen. Denn nur weil eine Komponente existiert und/oder sie sich so verhält, wie man es erwarten würde, heisst es noch lange nicht, dass die Schwachstelle ebenfalls verbleibt. Eine Komponente könnte aktualisiert oder mit einem Patch korrigiert worden sein, wobei dieses Detail durch den reinen Scan-Zugriff nicht ermittelt wird.

Nur in seltenen Fällen wird ein umfangreiches Exploiting durchgesetzt. Dieses ist zeitaufwändig, invasiv und deshalb risikobehaftet. Handelsübliche Vulnerability Scanner führen solche Tests praktisch nie durch. Erst erweiterte aktive Scanner (z.B. Burp Suite von Portswigger) oder Exploiting-Frameworks (z.B. MetaSploit oder ATK – Attack Tool Kit) stützen sich konsequent auf dieser Möglichkeit ab.

Zugriffsverhalten

Ein Ansatz, der in der Literatur keine Beachtung findet, ist die Analyse des Timing-Verhaltens. Als Grundregel gilt, dass ein Check umso länger dauert, desto komplexer er ist. Dies ist einerseits auf die Zunahme von Arbeitsschritten zurückzuführen. Es kann aber auch mit der Belastung von Ressourcen (z.B. erforderlich Taktzyklen, Bearbeitung von RAM) zusammenhängen.

Leider lassen die drei Methoden keine Zuweisung von typischen Zeitwerten zu. Jeder Check muss für sich untersucht werden. Dennoch ist absehbar, dass die Prüfung einer einzelnen Schwachstelle mit den drei unterschiedlichen Varianten mit verschiedenen Timing-Verhalten daherkommen wird. Hierbei kann auch die Rhythmik eine offenbarende Rolle übernehmen.

Alternativ oder ergänzend kann die Rhythmik und das Volumen der Zugriffe untersucht werden. Eine simple Abfrage eines Willkommens-Banners benötigt weniger Datenvolumen, als ein zusätzliches Einspielen des Exploit-Codes und Auslesen der erfolgreichen Rückgabe. Die folgende Tabelle illustriert die Zunahme dieser Komplexität.

Dabei ist zu berücksichtigen, dass komplexe Protokolle, Kompression, Retransmissions und Piggyback-Mechanismen zu einer verzerrten Wahrnehmung führen können. In diesem Fall müssen also weitreichende Untersuchungen angestrebt werden, um zu einer Konklusion kommen zu können.

Fazit

Vulnerability Scanner sind aus umfangreichen Sicherheitsüberprüfungen nicht mehr wegzudenken. Durch die mit ihnen gegebene Automatisierung wird ein Mehr an Effizienz und Abdeckung gewährleistet. Diese führt aber stets das Risiko von fehlerhaften Resultaten mit. Das Bestimmen der Vertrauenswürdigkeit eines Produkts bzw. der durch dieses generierten Resultate hilft dabei herauszufinden, ob und inwiefern mit diesern weitergearbeitet werden kann.

Dabei kann das Verhalten der Software bzw. der einzelnen Checks untersucht werden. Hierbei kann zwischen derivativen Checks, Scans und Exploiting unterschieden werden. Der Titel und die Beschreibung eines Checks gibt oft Hinweise darauf, welcher Ansatz zum Tragen kommt. Im Idealfall kann der Quelltext des Checks untersucht werden, um Klarheit schaffen zu können.

Wo immer dies nicht möglich ist, kann versucht werden das Verhalten der Zugriffe zu analysieren. Das Timing, die Rhythmik und das Datenaufkommen können Indizien liefern, um entsprechende Ableitungen anstellen zu können.

Über den Autor

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

• https://nmap.org/
• https://nmap.org/book/nse.html
• https://portswigger.net/burp
• https://www.computec.ch/projekte/atk/
• https://www.metasploit.com/
• https://www.qualys.com/
• https://www.tenable.com/
• https://www.tenable.com/products/nessus