Konkrete Kritik an CVSS4
Marc Ruef
Die Qualität von Vulnerability Scans analysieren
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:
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.
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.
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:
ID | Titel |
---|---|
10931 | VBulletin members2.php Cross Site Scripting Vulnerability |
11076 | YABB SE Reminder.PHP SQL Injection Vulnerability |
12767 | Moodle badges/external.php Cross-Site Scripting Vulnerability |
86410 | Apache Webserver /server-status Information Disclosure Vulnerability |
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.
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.
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.
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:
ID | Titel |
---|---|
12913 | PHP 5.5.x And 5.4.x Denial Of Service Vulnerability |
13481 | jQuery Prior to 3.4.0 Cross-Site Scripting Vulnerability |
19000 | MySQL Banner |
87329 | Apache HTTP Server Prior to 2.3.30 Multiple Vulnerabilities |
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:
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.
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.
Schritt | Derivativ | Scan | Exploiting |
---|---|---|---|
Verbindung aufbauen | ✓ | ✓ | ✓ |
Banner lesen | ✓ | ✓ | ✓ |
Ressource anfragen | ✓ | ✓ | |
Zusätzlichen Exploit-Code schicken | ✓ | ||
Antwort empfangen | ✓ | ✓ | |
Verbindung abbauen | ✓ | ✓ | ✓ |
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.
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.
Unsere Spezialisten kontaktieren Sie gern!
Marc Ruef
Marc Ruef
Marc Ruef
Marc Ruef
Unsere Spezialisten kontaktieren Sie gern!