aus dem Netzwerk Insider Juli 2021
In letzter Zeit hört man immer wieder von kleineren und größeren Hacks, bei denen Daten entwendet oder verschlüsselt werden. Aber wie brechen die Hacker in die Systeme ein? Die Antwort lautet oftmals: längst bekannte Sicherheitslücken, für die in vielen Fällen bereits Patches verfügbar sind. Nur wurden diese Patches nicht eingespielt.
Doch wie erhält man in seiner Umgebung einen Überblick über die vorhandenen Schwachstellen, insbesondere, wenn die Systeme von verschiedenen Verantwortlichen betrieben werden? Der Einsatz von aktiven Schwachstellenscannern ist hier ein gängiger Weg. Allerdings gibt es durchaus Grenzen.
Aktive Schwachstellenscanner – wo sind die Grenzen?
Die Funktionsweise und der sinnvolle Betrieb von Schwachstellenscannern wurde bereits im Netzwerk Insider vom Juni 2019 erläutert. Eine der zentralen Methoden dabei ist, dass der Scanner aktive falsch formatierte Netzpakete an ein Ziel schickt, um Schwachstellen auszunutzen und klar erkennbare Antworten zu provozieren. Bei gängigen Systemen wie Windows- oder Linux-Servern ist das wenig problematisch, da die Netzprotokoll-Stacks der gängigen Betriebssysteme robust sind und mit fehlerhaften Paketen umgehen können. Und in den wenigen Fällen, in denen „fehlerhafte“ Pakete einen Ausfall verursachen können, werden die zugehörigen Tests nur nach expliziter Aktivierung ausgeführt.
Doch nicht alle Geräte im Netz nutzen verbreitete oder aktuelle Betriebssysteme. In vielen Fällen sind die eingesetzten Stacks nicht robust und gehen von korrektem Traffic aus. Ein einfacher, manipulierter „Ping“ oder ein falsch formatiertes Paket kann zu unvorhergesehenen Konsequenzen führen:
- Im besten Fall passiert gar nichts.
- Eventuell stürzt ein Netz-Dienst ab und wird automatisch neu gestartet.
- Im schlimmsten Fall stürzt das gesamte System ab und ist nur durch einen harten Reset wieder in einen funktionsfähigen Zustand zu bringen.
Bei kritischen Servern oder Anwendungen ist das schon schlimm genug und kann zu großen finanziellen Schäden und zu Reputations-Schäden führen. Aber in anderen Bereichen, zum Beispiel im klinischen Umfeld oder in Produktionsstraßen, können auch Menschen zu Schaden kommen. Man stelle sich vor, bei einem regelmäßigen Scan in einem Krankenhaus stürzt eine Herz-Lungen-Maschine ab!
Eine weitere Einschränkung besteht darin, dass in segmentierten Netzen Schwachstellen auf Layer 2 schwerer zu erkennen sind. Ein „einfacher“ Scan auf Layer 3 sieht diese Lücken nicht. Stattdessen kommen eine oder mehrere der folgenden Funktionen zum Einsatz:
- Scans mit Login-Daten
- Einsatz von Agenten
- Nutzung von Satelliten-Scannern
Für exotische Systeme bleibt hier nur die dritte Option, und diese kann je nach Lizenzierungsmodell sehr kostspielig werden.
In Anbetracht dieser Einschränkungen stellt sich die Frage, ob es ein weiteres Werkzeug gibt, das hier unterstützen kann. Die Antwort: Ja, aber…
Grundlagen von passiven Schwachstellenscannern
Ein mögliches Werkzeug sind passive Schwachstellenscanner. Im Gegensatz zu ihren aktiven Verwandten setzen passive Schwachstellenscanner auf die Analyse des Netzverkehrs ohne aktiven Eingriff in die Kommunikation. Sofern also der Verkehr der zu überprüfenden Geräte für den passiven Scanner sichtbar ist, kann dieser etwaige Schwachstellen erkennen.
Der erste Gedanke könnte hier sein: Damit der Scanner den Traffic sieht, muss er doch im gleichen Netz wie das zu überwachende Gerät sein und dann ist der Vorteil gegenüber aktiven Scannern in den jeweiligen Netzen nicht mehr so ausschlaggebend. Die Kritik ist durchaus berechtigt, aber moderne Netzinfrastrukturen bieten auch deutlich elegantere Ansätze.
Weiterleitung von Traffic zu einem passiven Schwachstellenscanner
Zum einen können an den betroffenen Switches Mirror-Ports eingerichtet werden, die den Traffic bestimmter Ports an einen anderen Port am Switch übertragen. In virtuellen Umgebungen können die virtuellen Switches auch diese Funktionalität bereitstellen (siehe Abbildung 1).
Dabei ist man allerdings auf einen Switch beschränkt und die Zuweisung ist statisch. Insbesondere wenn der Scanner als virtuelle Maschine (VM) eingesetzt wird, kann es sein, dass er im Rahmen einer Ressourcenoptimierung auf einen anderen Host und damit an einen anderen Switch-Port verschoben wird.
Alternativ kann eine Technologie wie Cisco RSPAN (Remote Switch Port Analyzer) eingesetzt werden, bei der der Traffic von Ports auf verschiedenen Switches an einen definierten Port an einem anderen Switch weitergeleitet wird. Die Beschränkung auf einen Switch entfällt damit, doch das Ziel ist immer noch ein definierter physischer Port. Eine VM-Migration bleibt demnach eine Herausforderung.
Die dritte Möglichkeit besteht im Einsatz einer Technologie wie ERSPAN (Encapsulated RSPAN). Die grundlegende Idee ist analog zu RSPAN, doch anstelle eines Ziel-Ports wird eine Ziel-IP-Adresse angegeben. Damit ist das Ziel unabhängig vom Switch-Port, mit dem der passive Scanner verbunden ist. Definiert man als Ziel-IP die IP-Adresse des passiven Scanners, erhält er die gewünschten Daten, unabhängig vom Standort. Besonders in großen Umgebungen ist das attraktiv. Diese Möglichkeit ist in Abbildung 2 dargestellt.
Auch hier gibt es etwas zu beachten: Die Pakete werden durch einen GRE-Tunnel (Generic Routing Encapsulation) transportiert. Das heißt, dass der Scanner die GRE-Pakete „auspacken“ muss. Die gute Nachricht: Gängige passive Schwachstellenscanner sind dazu in der Lage. Die schlechte Nachricht: Man muss es dem Scanner beibringen. Neben den eigentlich zu überwachenden IP-Adressen müssen auch die Quell-Adressen für den oder die GRE-Tunnel einbezogen werden. Die Konfiguration ist nicht aufwändig, doch man muss es im Hinterkopf behalten.
Nun ist der Scanner theoretisch fertig konfiguriert. Wie werden jetzt Schwachstellen gefunden? Welche Einschränkungen gibt es?
Funktionsweise des passiven Scanners
Jetzt muss der Scanner „nur noch“ potentielle Schwachstellen aus dem Traffic erkennen. Wie wird das umgesetzt? Indem alle Pakete überprüft werden. Die primäre Informationsquelle: Versions-Strings beim Verbindungsaufbau und Datenaustausch. Damit werden teilweise auch Betriebssysteme identifiziert. Antwortet zum Beispiel ein Webserver mit einer Apache-Versionsnummer, die Schwachstellen beinhaltet, werden diese angezeigt. Fehlerhafte Antworten auf falsch formatierte Anfragen können ebenfalls Informationen zu potentiellen Schwachstellen liefern. Es ergeben sich damit folgende Schwachstellen von passiven Schwachstellenscannern:
- Die Inhalte der Pakete können bei gefälschten Betriebssystems- oder User-Agent-Strings falsche Informationen liefern. Sollte ein System seine wahre Identität konsequent verschleiern, fällt dies dem passiven Schwachstellenscanner evtl. nicht auf.
- Da nur durch aktive Verbindungen Schwachstellen erkannt werden können, kann es bei selten genutzten Diensten lange Zeit dauern, bis Schwachstellen gefunden werden.
- Werden Daten zum Beispiel mit TLS verschlüsselt, kann der Scanner wenig ausrichten.
Fazit
Sowohl aktive als auch passive Schwachstellenscanner haben ihre Vor- und Nachteile. Prinzipiell ergänzen sich diese beiden Funktionsweisen sehr gut, und der kombinierte Einsatz ist in Umgebungen sinnvoll, in denen manche Systeme auf gar keinen Fall von einem aktiven Scanner überprüft werden dürfen. Für eine bessere Sichtbarkeit können bei einigen Produkten die Ergebnisse des passiven Scanners in einen aktiven Scanner importiert werden. In großen Umgebungen gibt es auch zentrale Managementsysteme, die verschiedene aktive und passive Schwachstellenscanner koordinieren können und die gesammelten Informationen kombiniert darstellen. Damit ist der Einsatz nicht auf eine gewisse Umgebungsgröße festgelegt, sondern kann sehr genau an die eigenen Anforderungen angepasst werden.