Qualys Scans - Kritische Betrachtung

Qualys Scans

Kritische Betrachtung

Marc Ruef
Marc Ruef
Stefan Friedli
Stefan Friedli
Lesezeit: 14 Minuten

Im Sinne der Wirtschaftlichkeit ist die Sicherheitsbranche darum bemüht, die sicherheitstechnischen Überprüfungen weitestgehend zu automatisieren. Erste umfassende Bestrebungen konnten im Bereich der Netzwerküberprüfungen beobachtet werden. Dan Farmer und Wietse Venema zeigten erstmals im Jahr 1995 mit SATAN, dass sich repetitive Arbeiten in diesem Bereich geschickt automatisieren lassen sollten. Darauf folgte das von Renauld Deraison entwickelte Nessus-Framework, welches mit einer Vielzahl an Plugins und Erweiterungen aufwarten sollte (leider unterliegt Nessus seit Ende 2005 ab Version 3.0 nicht mehr der GPL).

Ebenfalls waren und sind kommerzielle Anbieter, neben Tenable Network Security mit Nessus, um den Verkauf derartiger Vulnerability Scanner bemüht. Symantec NetRecon war zwischen 2000 und 2002 ein sehr effizientes Tool. Direkter Konkurrent war der ISS Internet Scanner, der aufgrund einer sehr teuren Auditor Lizenz nur von wenigen Sicherheitsfirmen breitflächig eingesetzt werden konnte.

Qualys, die kommerzielle Lösung

Erweiterte Akzeptanz bei grösseren Firmen erlangte in den letzten Jahren die kommerzielle Lösung QualysGuard Vulnerability Management. Mit dem modularen Multi-Tier-Modell lassen sich verschiedene Netzwerksegmente durch die einzelnen Agents prüfen und die übersichtlichen Resultate auf einer zentralen Management Console moderieren. Durch das vollständige Automatisieren wiederholender Prüfungen kann so das Qualitätsmanagement im Netzwerkbereich erheblich erleichtert werden. Zwar kann man das auch dank des Client/Server-Modells von Nessus weitestgehend durchsetzen. Qualys macht das alles halt aber ein bisschen schicker und designtechnisch besser optimiert.

Das QualysGuard Dashboard

Einige unserer Kunden setzen Qualys punktuell ein, um alle paar Wochen allgemeine Tests durchzuführen. Damit lässt sich in etwa die Entwicklung im Netzwerk beobachten (halten sich die Administratoren an die Vorgaben). Dennoch setzen viele noch immer auf unser Fachwissen, um gerade individuelle Analysen durchführen zu können. Im Rahmen eines weltweiten netzwerkbasierten Security Audits bat ein grosser Kunde aus dem Finanzumfeld darum, dass wir ihre Qualys-Daten als Grundlage unserer eigenen Prüfungen nutzen sollten. Einerseits um Zeit zu sparen, andererseits um eine Verdichtung der Qualität erreichen zu können.

Ausgangslage eines XML-Imports

Wir pflegen ein eigens entwickeltes Datenbankmodell einzusetzen, um die Daten unserer Analysen normalisiert verarbeiten zu können. Sodann setzten wir uns daran, unsere Datenbank dahingehend zu erweitern, dass die Qualys-Daten miteinbezogen werden konnten. Qualys ist in der Lage Reports in verschiedenen Formen zu generieren:

Wir entwickelten einen Parser für die XML-Ausgaben, um die Daten effizient in unserer relationalen Datenbank ablegen zu können. Leider ist die Struktur der XML-Exports alles andere als geschickt gewählt. So ist zum Beispiel ein wildes Durcheinander bei der Codierung von Sonderzeichen zu beobachten. Vielerorts wird mit CDATA-Abschnitten gearbeitet, dann aber dennoch auf HTML-Entitäten gesetzt. Andererorts wird darauf verzichtet. Um einen einheitlichen Import durchzuführen, müssen diese Spezialfälle bekannt sein und individuell adressiert werden. Das Umsetzen des Parsers gestaltete sich gerade wegen solcher Details als verhältnismässig aufwendig.

Reportqualität

Die Inhalte der Qualys Reports werden gerne aufgrund ihres Umfangs und der Qualität gelobt. Doch auch hier mussten Inkonsistenzen festgestellt werden. In den Feldern DIAGNOSIS, CONSEQUENCE und SOLUTION werden die Eigenschaften der gefundenen Schwachstellen modular dokumentiert. Nicht selten sind aber die beiden letztgenannten Felder leer oder mit einem nichtssagenden N/A versehen. Und dies, obschon sowohl eine Konsequenz als auch eine Lösung hätte dokumentiert werden können. Bestes Beispiel für diese Nachlässigkeit ist ID 38062 (VNC Banner), die gar alle drei Felder leer lässt und nur den Test-Output dokumentiert. Andere Banner-Probleme werden hingegen teilweise oder umfassend beschrieben.

Eine hingegen interessante Designentscheidung ist in Bezug auf die Klassifizierung der Findings getroffen worden. Schwachstellen werden unterschiedlich eingeordnet:

Im ersten Fall weist Qualys darauf hin, dass der Fehler nicht direkt verifiziert werden konnte (z.B. durch eine Ausnutzung). Damit wird quasi die Zuverlässigkeit des Tests angegeben. Das zusätzliche Rating von 1 bis 5 gibt den Schweregrad des Fehlers an. Diese Zweidimensionalität halte ich dennoch für ungeschickt: Die Severity und die Accuracy eines Findings hat nichts direkt miteinander zu tun. In unserer Datenbank trennen wir diese Felder und weisen die Accuracy je nach Exploiting-Vorgehen mit einem Prozentwert aus (z.B. Banner-Grabbing ist 60 % und das Erstellen einer Reverse-Shell mittels einem Pufferüberlauf ist 100 %).

Kategorie Farbe Beschreibung
SERVICE Blau Erkennung von offenen Ports/Diensten (Portscan und Application Mapping)
INFO Blau Allgemeine Informationen zu Diensten (Enumeration)
PRACTICE Gelb Vermutete Schwachstellen (Banner-Grabbing und Application Fingerprinting)
VULN Rot Verifizierte Sicherheitslücken (effektiv ausgenutzt)

Zusätzliche Klassen von Qualys sind SERVICE und INFO (beide blau). Dazu gehören Auswertungen, wie ICMP-Ping Zugriffe, allgemeine Informationen zu SSL-Zertifikaten oder das Auslesen der Uptime eines Hosts mittels TCP Timestamp Optionen. Es ist fragwürdig, warum eine erweiterte Analyse des Verhaltens eines Zielsystems nicht auch als Schwachstelle gewertet und mit einer niedrigen Severity versehen wird. Die Möglichkeit eines Banner-Grabbings ist für uns eindeutig eine Schwachstelle (Konfigurationsfehler) und keine allgemeine Information. Jede Herausgabe von Informationen zu einem System muss als Schwachstelle – jedoch nicht zwingend als Sicherheitslücke – gewertet werden.

Da wir in unserer Datenbank ebenfalls die Daten der verschiedenen Nessus-Plugins enthalten haben, lassen sich direkte Vergleiche von Einstufungen unterschiedlicher Quellen durchführen. Qualys klassifiziert Banner-Grabbing wie gesagt als SERVICE/1 (niedrigste Einstufung). Nessus pflegt das Risk als None oder Low auszuweisen (da NASL-Plugins durch jedermann geschrieben werden können, gibt es dort seit jeher ein hohes Mass an Inkonsistenz). Wir hingegen empfinden ein Banner-Grabbing als Medium, da es als direkte Grundlage für weitere Auswertungen oder produktspezifische Angriffe herhalten kann. Die Diskussion von Gegenmassnahmen, in den meisten Fällen das Deaktivieren des Banners, erscheint zwingend angeraten zu sein.

Qualys Nessus scip AG
None Low
1
2 Low Medium
3 Medium
4 High High
5 Serious
Emergency

Probleme bei den Analysen

Viele der Findings von Qualys wurden auf der Basis von Bannern zusammengetragen (gelb). Die Qualität solcher Analysen ist sehr fragwürdig. In anderen Fällen hat Qualys scheinbar einen effektiven Test durchgeführt (rot), der zum verlässlichen Resultat geführt haben soll. Jedoch finden sich nirgends im Internet irgendwelche Hinweise dazu, wie die besagte Schwachstelle verifiziert oder ausgenutzt werden kann. Qualys verfügt eventuell über Insider-Informationen. Da die Lösung und mit ihr die Checks nicht quelloffen ist, kann nicht herausgefunden werden, wie Qualys zum Resultat kommt. Man muss dem einfach vertrauen oder es pauschal als False-Positiv abtun. Ein Problem, das bei professionellen Lösungen einfach nicht vorkommen darf.

Zu technischen Problemen kommt es mitunter, wenn sich gewisse Plugins auf Namensauflösungen verlassen. Werden beispielsweise bei Reverse-Lookups falsche Hostnamen zurückgegeben und auf diese erneut ein DNS-Lookup angesetzt, kann dies zu Scans falscher Systeme führen. Selbstverständlich ist dies ein Problem der Nameserver-Administratoren der jeweiligen Zielumgebung. Im Rahmen von professionellen Vulnerability Assessment Projekten dürfen solche Fehler jedoch nicht vorkommen. Solche Fehler kommen normalerweise nur bei kleineren Tools und Entwicklungen von Hobbyprogrammierern vor.

Ein anderer interessanter Effekt musste beobachtet werden. Und zwar führt Qualys gewisse Mapping- und Auswertungs-Zugriffe auf Router durch, die das definierte Zielnetzwerk nur tangieren. Die Resultate dieser Analysen tauchen dann ebenfalls in den Rohdaten und Reports auf, was zu Verwirrung führen kann. Zudem könnte es zu technischen oder juristischen Problemen führen, wenn unbeabsichtigt Objekte angegangen werden, die nicht im abgesteckten Umfang des Projekts enthalten sind.

Statistischer Vergleich

Im Rahmen des genannten Projekts wurden 186 erreichbare Hosts in 75 Zonen geprüft. Dabei wurden 165 offene Ports identifiziert (114 TCP-Ports und 51 UDP-Ports). Insgesamt wurden durch uns 129 unterschiedliche Schwachstellen dokumentiert. Diese konnten wir den einzelnen Systemen als 2027 Schwachstellen (100%) zuweisen. Qualys konnte davon lediglich 1861 Schwachstellen (91.81%) identifizieren. Und Nessus liegt weit abgeschlagen bei 1030 Schwachstellen (50.81%). Die Zählung lässt auf den ersten Blick den Schluss zu, dass Qualys relativ gute Arbeit geleistet hat. Dabei gilt es jedoch zu bedenken, dass insgesamt 84 False-Positives (4.51%) durch Qualys zusammengetragen wurden und diese nachträglich manuell quergeprüft und eliminiert werden mussten.

Produkt Identifikationsquote
scip AG 100 % ±0 %
Qualys 91.81 % -8.19 %
Nessus 50.81 % -49.19 %

Zudem gilt es zu berücksichtigen, dass eine kritische Schwachstelle, die durch Qualys nicht gefunden wurde (z.B. Pufferüberlauf als High), weitaus schlimmere Auswirkungen haben kann, weder wenn ein zu vernachlässigender Schönheitsfehler nicht identifiziert werden konnte (z.B. Ping-Möglichkeit als Low). Um einen reellen Vergleich anzustreben, werden den einzelnen Schwachstellen je nach ihrer Einstufung eine Gewichtung zugewiesen. Unsere Skala weist die Einstufungen Low, Medium und High auf. Entsprechend wurde Low der Wert 1, Medium wurde 2 und High wurde 3 zugewiesen. Aufgrund dieser Gewichtung entspricht das Gesamtgewicht des Tests 471’576 Punkten (100%). Das durch Qualys ermittelte Gewicht liegt dann nur noch bei 213’780 Punkten (45.33%) und Nessus kann das Gewicht von 122’220 Punkten (25.91%) zusammentragen. Damit scheint offensichtlich, dass eine professionelle Analyse dennoch manuelle Prüfungen zur Eliminierung von False-Positives und zum Auffinden individueller Probleme erfordert.

Produkt Identifikationsqualität
scip AG 471’576 100%
Qualys 213’780 45.33%
Nessus 122’220 25.91%

Fazit

Das Fazit ist, dass Qualys zur Zeit eine der professionellsten Lösungen seines Bereiches und des kommerziellen Sektors bereitstellt. Vor allem der Komfort automatisierter und wiederkehrender Analysen vermag zu überzeugen. Dennoch kränkelt auch Qualys wie jede andere Scanning-Lösung daran, dass sie aufgrund der Automatisierung das eine oder andere False-Positive generiert und nicht mit individuellen Produkten (z.B. eigens entwickelte Applikationen) umgehen kann. Die Checks von Qualys können nur das erkennen, wofür sie geschrieben wurden. Da die Testabläufe nicht offengelegt sind, kann nicht (ohne aufwendiges Reverse Engineering) nachvollzogen werden, wieso Qualys zu einem spezifischen Resultat kommt. Wer eine umfassende Sicherheitsüberprüfung möchte, sollte sich also nach wie vor nicht auf eine automatisierte Lösung wie Qualys verlassen. Die Qualität einer manuellen und zielgerichteten Prüfung durch einen erfahrenen Penetration Tester lässt sich damit sowohl heute als auch in absehbarer Zukunft nicht erreichen.

QualysGuard Vulnerability Management Vorteile (Pros):

QualysGuard Vulnerability Management Nachteile (Cons):

Update 11. April 2011 11:20

Aktualisierung einiger externer Links und Layout des Vergleichs der Identifikationen.

Über die Autoren

Marc Ruef

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)

Stefan Friedli

Stefan Friedli gehört zu den bekannten Gesichtern der Infosec Community. Als Referent an internationalen Konferenzen, Mitbegründer des Penetration Testing Execution Standard (PTES) und Vorstandsmitglied des Schweizer DEFCON Group Chapters trägt er aktiv zum Fortschritt des Segmentes bei.

Links

Sie wollen die Sicherheit Ihrer Firewall prüfen?

Unsere Spezialisten kontaktieren Sie gern!

×
Konkrete Kritik an CVSS4

Konkrete Kritik an CVSS4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentisierung

Voice Authentisierung

Marc Ruef

Bug-Bounty

Bug-Bounty

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv