Vulnerability Scan Pt.2 – Grenzen und Chancen

Ich will versuchen den Artikel an dieser Stelle produktunabhängig zu halten, werde aber auch immer wieder auf nexpose Bezug nehmen da dies die Grundlage unseres Managed Vulnerability Scan Service (MVSS) stellt.

Kurzüberblick

Beim Vulnerability Scan (VS) handelt es sich um die automatische Suche nach bekannten Schwachstellen von IT-Systemen. Die Scans können dabei typischerweise mit und ohne Authentifizierung am System bzw. Service stattfinden. Prinzipiell kann man sagen, dass ein unauthentifizierter Scan weniger Ergebnisse zu Tage fördern kann als ein authentifizierter Scan. Je nach Risikofreude kann das System nach dem Erkennen potenzieller Schwachstellen versuchen aktiv diese Auszunutzen um so Code auszuführen (RCE) oder sich mehr Rechte zu verschaffen (privilege escalation) oder den Dienst zum Absturz zu bringen (DOS).

Viele Systeme bieten über den reinen Scan auch ein sogenanntes Vulnerability Management (VM) an. Die durch einen Scan gefundenen, potenziellen Schwachstellen werden hierbei um weitere Daten angereichert wie z.B. dem CVSS score, einer eigenen Einstufung des Risikopotenzials, konkreten Lösungsansätzen wie auch ein Tracking der Schwachstellen um z.B. zu verfolgen, ob Schwachstellen durch einen bestimmten Patch auch geschlossen wurden bzw. ob und warum ein bestimmtes Risiko evtl. sogar als akzeptabel eingestuft wurde.

Wie kann mich ein VS bzw. VM unterstützen?

In erster Linie ist ein Vulnerability Scan ein Werkzeug zur Qualitätssicherung und unterstützt die Administratoren beim Patchen und teilweise bei der Konfiguration der Systeme und sollte im Verbund mit einem Patchmanagement betrieben werden. Letzten Endes ist eine gut gepatchte Systemlandschaft ein wichtiger Teil des Grundschutzes. Zusätzlich kann der Scan noch Hinweise bis hin zu konkreten Handlungsanweisungen bezüglich der Konfiguration der gescannten Systeme liefern. Ein Beispiel hierfür wäre ein Linux System das ICMP redirects erlaubt. Hierfür liefert nexpose konkrete Anleitungen, wie dieses Feature auf dem betroffenen System deaktiviert werden kann. Ein anderer Hinweis könnte ein Mangel im Regelwerk des Paketfilters oder der WAF sein in dem ein Scan z.B. unerwartet auf Ressourcen zugreifen kann, die eigentlich nicht erreichbar sein sollten oder eine SQL Injection erfolgreich ist, obwohl die WAF eigentlich davor schützen sollte.

Jeder Fund wird dabei mit einer Kritikalität bemessen. Diese setzt sich aus der Bewertung des Fundes selbst als auch aus der Kritikalität des betroffenen Systems zusammen. Derartige Einstufungen können den Administratoren bei der Priorisierung ihrer Aufgaben helfen.

Wie bei allen Automaten müssen die Ergebnisse immer ganzheitlich betrachtet werden. So kann die eigene Systemlandschaft einen Fund in seinem Risikopotenzial sowohl verstärken wie aber auch schwächen. Der oben angesprochene ICMP redirect bezog sich auf ein System in einer DMZ, in der sich lediglich ein staging und ein development System des gleichen Produktes befand. Der Paketfilter, der die DMZ von anderen Netzen abschottet hätte eventuell auftretende ICMP redirects verworfen. Unter diesem Aspekt ist der Fund deutlich weniger risikobehaftet ,als wenn der Paketfilter ICMP redirects erlauben würde. Da die redirects aber dennoch keinen Mehrwert lieferten und letzten Endes niemandem bewusst war, dass und vorallem warum die Funktionalität aktiviert wurde, hat man als Ergebnis des Scans dieses Feature auf dem betroffenen System wie von nexpose beschrieben deaktiviert.

Was soll gescanned werden?

Alles 😉 — Spaß beiseite, wie bei Pentests gibt es auch hier immer wieder ähnliche Bestrebungen bestimmte Systeme / Anwendungen von den Scans auszunehmen. Meist reden wir hier von Systemen, die in wichtige Geschäftsprozesse eingebunden sind und Störungen oftmals katastrophale Folgen haben. Jetzt will sich natürlich niemand dafür verantworten müssen, dass bei einer Routine-Überprüfung die Firma lahmgelegt wurde und im schlimmsten Fall ein nicht zu verachtender wirtschaftlicher oder gar Personenschaden entstanden ist. Auf der anderen Seite: was, wenn man in einer kontrollierten Situation genau diese Verwundbarkeit findet bevor jemand anderes darauf stößt?

Eine allgemeingültige Antwort kann hier niemand guten Gewissens liefern, denn auch hier hängt die Antwort von vielen Faktoren innerhalb der eigenen Systemlandschaft ab. Handelt es sich z.B. um ein geclustertes System, können in abwechselnden Intervalen alle Knoten außer dem aktiven gescanned werden. Gibt es die Möglichkeit ein identisches Testsystem zu scannen? Systeme, gerade die Wichtigen, komplett außen vor zu halten sollte aber eine red flag darstellen, denn hier liegt offensichtlich ein gewaltiges Risikopotenzial vor und letzten Endes muß damit gerechnet werden, dass jeder einzelne Exploit, den der Scanner mitbringt auch im Arsenal eines potenziellen Angreifers vorzufinden ist.

Wenn möglich, sollten Systeme auch mit und ohne vorgelagerte Schutzsysteme gescanned werden, um so die Wirksamkeit der Systeme zu testen und eine vollumfängliche Sicht auf die eigene Landschaft zu erhalten. Ist dies nicht möglich oder auf Grund der dadurch steigenden Komplexität nicht vertretbar, sollte man davon ausgehen, dass kein Schutz vorhanden ist und die Systeme gegenüber dem Scanner unreglementiert exponieren.

Authentifiziert oder unauthentifiziert?

Ein unauthentifizierter Scan bietet lediglich die Sicht aus dem Netzwerk heraus und schließt von vornherein bestimmte Module aus. So wurde der bereits erwähnte ICMP redirect nur entdeckt, da es sich hier um einen authentifizierten Scan handelte. Nach dem Login wurde die Konfiguration des Systems nach sicherheitsrelevanten Einstellungen durchforstet. Bei einem unauthentifizierten Scan wäre dieser „Fehler“ nicht aufgedeckt worden. Ein weiteres Beispiel sind Webanwendungen, bei denen eine Vielzahl von Formularen erst nach einer erfolgreichen Authentifizierung zur Verfügung stehen und somit auch erst nach der Authentifizierung der Scan eine gewisse Breite erreichen kann.

VS zur Erhöhung der Sichtbarkeit

Viele IT-Landschaften sind auch von einer gewissen Dynamik geprägt und ein genaues Inventar ist mit manuellen Mitteln oft unmöglich zu erheben. Zu schnell kann hier ein neuer Webserver eines Entwicklers, eine Arbeitserleichterung eines Administrators oder ein Projekt unterhalb des normalen Radars auftauchen.

Ein Scan auf komplette Netzbereiche, anstatt gezielter Systeme, kann die Einsicht in die eigene Landschaft erhöhen und nebenbei nicht nur unbekannte Systeme, sondern auch unbekannte Einfalltore in Form von schlecht gewarteten oder unzureichend konfigurierten Systemen bzw. Services zu Tage fördern. Dies gibt den Administratoren die Möglichkeit schnell und gezielt zu handeln.

VS als sanity check der Architektur

Ist das System installiert bzw. hat man die Account-Daten im Rahmen eines SaaS erhalten, erwartet einen nun der eigentliche Aufwand: das Eintragen und Klassifizieren der sogenannten Assets. Klar, das ist erstmal eine ziemlich dröge Fleißarbeit, gibt einem aber auch die Chance aus einem neuen oder einfach nur anderen Blickwinkel auf seine Architektur zu schauen.

Stellt man im Rahmen der Bestückung z.B. fest, dass innerhalb eines Subnetzes ein bunter Strauß unterschiedlicher Risikoklassen auftaucht, sollte man die Konstellation innerhalb dieses Netzes deutlich unter Augenschein nehmen, da die Kompromittierung eines weniger kritischen Systems den Angriffsvektor auf ein höher kritisches System im gleichen Netz stark verbreitern kann, da ab hier der zentrale Schutz eines Paketfilters oder Application Layer Gateways umgangen wird.

Die Thinking Objects bietet im Rahmen ihres MVSS auch die Möglichkeit Systeme von extern, also aus dem Internet heraus zu scannen. Wird bei der Auswahl der Assets hier festgestellt, dass man auf Systeme zugreift, die sich nicht in einer externen DMZ befinden, gibt es auch hier Anlass die Architektur noch einmal genau in Augenschein zu nehmen, da ein System, welches sich einem hohen Risiko (Internet) ausgesetzt sieht und nach einer erfolgreichen Kompromittierung, eine eventuell unreglementierte Gefahr für Systeme mit deutlich geringerem Risiko darstellt.

Fazit

Automatische Scans der eigenen Landschaft können eine Bereicherung des eigenen Werkzeugkastens sein. Vorallem kombiniert mit einem Vulnerability Management, das einem über den reinen Befund auch noch weitere Daten über Risiko, Mitigation oder Behebung liefert.

Der wahre Aufwand steckt allerdings im Befüllen des Systems mit den Assets, dem Klassifizieren der Assets in Risikoklassen, der Auswahl der Scanzeiten, Systeme, Ausnahmen und dem Tracken der bzw. dem Beheben von gefundenen Schwachstellen.

Im Gegensatz zu Firewalls und Proxies bietet ein VS keinen zusätzlichen Schutz per se, kann aber im Rahmen der Qualitätssicherung die Robustheit der eigenen Landschaft erhöhen und die Angriffsfläche minimieren.

Sehen Sie sich auch unser Video zum Thema „Managed Vulnerability Scan Service – Ablauf“ an:

Weitere Videos rund um die Themen IT-Security finden Sie auf unserem Youtube-Kanal.