Technik hinter dem Vulnerability Scanning
Marc Ruef | 18.02.2007

iDieser Beitrag stellt ein Transkript von Computec Radio, Folge 5: Technik hinter dem Vulnerability Scanning (http://www.computec.ch/download.php?view.862) dar. Die Audiofassung steht zum freien Download zur Verfügung./i

Als Vulnerability Scanning wird das vorwiegend automatisierte Vorgehen bezeichnet, aktiv nach Verwundbarkeiten in einem System zu suchen. Als Verwundbarkeit wird jegliche Konstellation bzw. Situation verstanden, die sich negativ auf die Sicherheit des Systems auswirken könnte. Vorwiegend wird Vulnerability Scanning über das Netzwerk betrieben, was damit als netzwerkbasiertes Vulnerability Scanning bezeichnet wird.

Die ersten Gehversuche bezüglich des automatisierten Findens von Sicherheitslücken wurde durch das Tool SATAN getan. Keine Angst, dabei handelt es sich nicht um ein antichristliches Gebilde. Viel mehr verbirgt sich hinter dem pompösen Akronym die Bezeichnung "Security Administrator Tool for analyzing Networks". Diese Software wurde ursprünglich von Dan Farmer und Wietse Venema im Jahr 1993 für Unix-Plattformen entwickelt. Sie legte den Grundbaustein für eine Reihe vergleichbarer und bisweilen sehr populärer Produkte.

Ein Vulnerability Scanner führt nach Möglichkeiten eine Interaktivität mit einem zu überprüfenden System durch. Dabei versucht er aktiv herauszufinden, ob beim Zielsystem irgendwelche Schwachstellen gegeben sind. Der freizügige Umgang mit exotischem TCP/IP-Verkehr, das Anbieten von potentiell gefährlichen Diensten oder das Nutzen veralteter Software-Versionen sollen so innert kürzester Zeit entdeckt werden.

Dabei kann grundsätzlich, so werde ich es in meinem nächsten Buch (http://www.amazon.de/dp/3936546495/) ausführlicher beschreiben, zwischen drei unterschiedlichen Analysetechniken differenziert werden. Die erste von ihnen versucht von einer Gegebenheit a auf die potentielle Schwachstelle Sa abzuleiten. Kann ein Vulnerability Scanner zum Beispiel den TCP-Port 80 als offen identifizieren, dies ist die Gegebenheit a, so nimmt er an, dass darauf ein Webserver angeboten wird. Die potentielle Schwachstelle Sa für Port 80 bestünde nun darin, dass standardmässig sämtliche Kommunikationen über diesen im Klartext, also ohne Verschlüsselung, stattfindet.

Derlei Ableitungen können sehr effizient sein, durchaus. Ihre Zuverlässigkeit ist jedoch eher bescheiden. Denn streng genommen müsste jeder offene Port im Sinne der Sicherheit als Gefahrenquelle verstanden werden. Denn an Port 80 müsste nicht zwingend ein Webserver gebunden sein. Viel mehr könnte sich dahinter eine unerlaubt eingebrachte Hintertür, eine sogenannte Backdoor, verbergen. Diese könnte dem Angreifer direkten Zugriff auf das System, welches er zuvor umfassend kompromittieren konnte, gewähren. Damit wäre also schon die Ableitung Sa2 definiert. Ob dem nun wirklich so ist, kann der Vulnerability Scanner aufgrund der bisher getätigten Auswertungen, eigentlich ja nur ein Portscan, noch nicht sagen.

Aus diesem Grund müsste er weitere Tests durchführen. Die zweite und deshalb zuverlässigere Methode des Vulnerability Scannings besteht also darin, nicht nur auf eine Schwachstelle abzuleiten, sondern diese effektiv auszumachen. Die Scanning-Software müsste nun weiterführend sämtliche bekannten Backdoors auf dem als offen identifizierten Zielport absuchen. Durch ein entsprechendes Application Mapping (http://www.computec.ch/download.php?view.857) zur Identifikation des genutzten Protokolls und dem weiterführenden Application Fingerprinting zur Identifikation der eingesetzten Software-Komponente, kann dieses Ziel erreicht werden. Kann keine bekannte Hintertür als installiert determiniert werden, erwiese sich die zuvor vorgetragene Ableitung als eher unwahrscheinlich bzw. falsch. Damit können False Positives, also das Identifizieren von nicht effektiv gegebenen Schwachstellen, verhindert werden. Genauso wird die Zuverlässigkeit auch in umgekehrter Weise erhöht. Denn auch False Negatives, also das Übersehen einer existenten Sicherheitslücke, können damit minimiert werden. Die Qualität der automatisierten Sicherheitsüberprüfung nimmt damit zu.

Einen Schritt weiter kann noch gegangen werden, wenn nicht nur die klare Identifikation einer Komponente zur Determinierung einer Sicherheitslücke herangezogen wird. Stattdessen wird die vermeintliche Schwachstelle direkt ausgenutzt. Hierbei spricht man von intrusiven Tests, bei denen ein realitätsnahes Exploiting durchgesetzt wird. Im Falle der erwarteten Backdoor auf dem Port 80 müsste nun also die vermeintlich identifizierte Kommunikationsmöglichkeit, wie sie das Remote-Control-Utility darbieten würde, umgesetzt werden können. Lässt sich mit diesem erweiterten Zugriff Einfluss auf das Zielsystem ausüben, ist die Sicherheitslücke mit absoluter Gewissheit als solche identifiziert worden. Bleibt eine erfolgreiche Backdoor-Kommunikation aus, handelt es sich wenigstens nicht um eine der bekannten Hintertüren. In diesem Fall wäre die Ableitung Sa2 widerlegt worden.

Vielleicht erstaunt es nun wenn ich an dieser Stelle behaupte, dass nur die allerwenigsten Vulnerability Scanner derartig umfassende Überprüfungen durchführen. Als Referenzlösung in diesem Bereich wird gut und gerne die ehemalls quelloffene Lösung Nessus, welche von Renaud Deraison entwickelt wird, genannt. Mit den mittlerweile über 10'000 Plugins, mit diesen werden die Tests durchgeführt, gilt Nessus als eines der besten Produkte auf dem Markt. Betrachtet man jedoch die jeweiligen Skripte im Detail, so fällt auf, dass die meisten von ihnen nur bis zum zweiten Schritt gehen. Nur vereinzelte Plugins nutzen effektiv eine vermeintliche Sicherheitslücke zwecks klarer Verifikation aus.

Die Folge davon ist, dass auch Nessus nur mehr schlechte Resultate zu liefern in der Lage ist. Viele Plugins stützen sich zum Beispiel auf einen abgefangenen Banner ab. Weist sich die Applikation auf Port 25 zum Beispiel als Sendmail aus, zeigt Nessus automatisch sämtliche Schwachstellen für diese SMTP-Implementierung an. Dass sich hinter diesem Port eigentlich ein Exim-Server verbirgt, ist den meisten Plugins egal. False Positives und False Negatives machen sodann das Mehr im zum Schluss ausgegebenen Report aus. Der Nutzen von Nessus und vergleichbaren Produkten sei deshalb, gerade wenn es um das Überprüfen individueller Software-Komponenten geht, dahingestellt.

Das Durchführen eines automatisierten Vulnerability Scannings - egal ob nun mit Nessus, GFI LANguard, ISS Internet Scanner oder einem vergleichbaren Produkt - ist in erster Linie dann sinnvoll, wenn man sich einen groben Überblick verschaffen möchte. In einem solchen Fall ist es durchaus von Nutzen, kann man sich auf die altbewährten Routinen abstützen und muss nicht sämtliche Auswertungs-Zugriffe von Hand durchführen. Spätestens dann, wenn es aber um das Finden komplett neuer Sicherheitslücken geht, die bis dahin noch nicht an die Öffentlichkeit getragen wurden, kommt man um das manuelle Durchführen von Tests nicht mehr herum.