Früher wurden Sicherheitslücken von wenigen Interessierten häufig per Zufall gefunden. Heute (re)agieren sowohl auf der Angreiferseite als auch an der Front der Unternehmen institutionalisierte Maschinerien und Abläufe.
Sicherheitslücken werden heute gefunden, verkauft, genutzt und publiziert. Daraus entsteht ein Advisory, ein Eintrag in der CVE-Datenbank und meist ein Patch, der eingespielt werden muss. Diese Prozesse haben einen ganz eigenen Rhythmus und erzeugen in der Regel Zugzwang bei jenen Unternehmen, welche die betroffenen Produkte und Technologien einsetzen. Sicherheitslücken stellen deshalb IT-Infrastrukturbetreiber und ihre Administratoren vor Herausforderungen, da deren Beurteilung Expertise benötigt und das Schliessen von Lücken nicht selten auch ein Risiko für die Verfügbarkeit der Systeme darstellt. Bedenkt man allerdings, dass die meisten erfolgreichen Angriffe von Sicherheitslücken Gebrauch machen, die schon mehr als zwei Monate bekannt sind, bleibt das Schliessen von Lücken umso unerlässlicher. Insbesondere, da sich Angriffe auf bekannte Lücken problemlos mit Frameworktools wie Metasploit automatisieren und durch nicht versierte Angreifer nutzen lassen.
Was nun?
Wie sollen nun Systemverantwortliche auf die Flut der Sicherheitslücken reagieren? Unverzüglich und sofort zu reagieren hat den Vorteil, die Lücke schnellstmöglich zu schliessen. Gleichzeitig sind Unterbrüche innerhalb der Betriebszeiten nicht immer möglich. Und es besteht immer auch ein Risiko, ein laufendes System durch eine Änderung zu beschädigen, also einen Ausfall zu verursachen. Verzögertes Reagieren auf eine exponierte Sicherheitslücke kann allerdings hohe Risiken hervorrufen und bis zum Datenabfluss sensitiver Informationen, Reputationsschäden oder finanziellen Verlusten führen. War die Lücke zum Zeitpunkt des Angriffs bekannt und existierte eine Gegenmassnahme, müssen sich Systemverantwortliche dem Vorwurf der groben Fahrlässigkeit stellen.
Vulnerability Management als Prozess
Das Erkennen, Beurteilen und Schliessen von Sicherheitslücken ist Teil des Vulnerability Management-Prozesses. Dessen Ausgestaltung kann sich von Unternehmen zu Unternehmen unterscheiden. Trotzdem gibt es einige grundlegende Fragen, welche erfahrungsgemäss helfen, zielorientiert und wirtschaftlich reagieren zu können. Im Kern sollten immer folgende Aktivitäten einbezogen weden:
- Bewusstsein für die kritischen Geschäftsprozesse und deren zugrunde liegende Systeme
- Erkennen von Schwachstellen
- Beurteilen von Schwachstellen
- Beurteilen der Relevanz für die betriebenen Systeme
- Anwenden von Massnahmen
NIST publiziert zum Thema folgende Informationen: https://csrc.nist.gov/publications/detail/sp/800-40/rev-4/final
Der vorliegende Artikel stellt keinen Anspruch an Vollständigkeit. Die Reaktion sollte der Bedrohung und dem Fall jeweils individuell angemessen erfolgen. Als Anschauungsbeispiel soll uns das mittlerweile gut dokumentierte Beispiel der «SMBGhost»-Lücke (CVE-2020-0796) dienen. Dabei handelt es sich um eine Lücke in einem verbreiteten Fileshare-Protokoll, welches nicht in erster Linie als «genutztes Produkt» in Erscheinung tritt, aber für nahezu alle Windows-basierten Umgebungen essentiell ist.
Nachfolgend ein paar grundlegende Schritte und Gedankengänge, welche generisch für jede Einschätzung einer Sicherheitslücke hinzugezogen werden können:
Vorab: Übersicht behalten
Es lohnt sich, über die eigenen Technologien und Produkte, im Sinne eines gepflegten Asset Managements, ein Inventar (CMDB) zu führen. Für die eingesetzten Systeme sollten regelmässig die Fachpresse sowie die Supportseiten der Hersteller konsultiert werden. Zeichnet sich eine neue Bedrohung in Form eines Advisories ab, stellt sich die Frage, ob und wie reagiert werden muss.
Für das besagte Beispiel gehen wir davon aus, dass wir ein Netzwerk mit Microsoft Active Directory und Windows Clients betreiben.
Step one: Um was geht's genau?
Als erstes gilt es, Informationen über die Lücke zu sammeln. Folgende Informationsquellen können zur Einschätzung dienen:
- Hersteller Advisories: Enthalten in der Regel verlässliche Eckdaten (CVSS-Score), wenige Informationen zur Beschreibung der Lücke und Schritte zur Mitigation. Für unser Beispiel ist dies folgender MS-Artikel: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0796.
- CVSS-Score: Kategorisiert die Lücke nach allgemeinen aber aussagekräftigen Eckdaten. Aus diesen Informationen lässt sich ohne tiefe Kenntnisse sehr schnell ein Bild der Bedrohungslage erstellen (https://nvd.nist.gov/vuln/detail/CVE-2020-0796).
- CVE-Eintrag: Der CVE-Eintrag dokumentiert die Lücke und deren Entwicklung mit wertvollen und umfassenden Informationen weiterer Quellen (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0796).
- Berichte von Sicherheitsforschern: Gehen häufig technisch sehr tief und tragen zum Verständnis und zum Erarbeiten von Schutzmassnahmen bei.
- Fachpresse: Liefert meist reichhalte Infos in kurzer und prägnanter Form und zeichnet sich durch die Aktualität aus (https://www.heise.de/security/meldung/Achtung-Sicherheitspatch-gegen-kritische-SMBv3-Luecke-jetzt-verfuegbar-4681993.html).
Step two: Wie kritisch ist die Lücke?
Besonders gefährlich an der Lücke ist, dass nicht nur aus dem Internet erreichbare Computer gefährdet sind. Durch die Möglichkeit der wurmartigen Ausbreitung von einem einzelnen Rechner aus könnte das ganze Netzwerk «in einem Rutsch» befallen werden.
https://www.balbix.com/app/uploads/CVSS-Score-Metrics-Blog.png
Der CVSS-Score liegt bei 10.0 (Höchstwert). Der CVSS-Attack-Vector zeigt folgendes Muster: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. AV:N steht für Attack-Vector Network und beschreibt, dass die Lücke aus der Ferne ausgenutzt werden kann, ohne Zugang zum verwundbaren System. PR:N (Privilegies required: none) sagt aus, dass dies ohne Rechte am System erfolgen kann. UI:N (User Interaction: none) beschreibt, dass es keine Hilfe eines Benutzers zum Ausnutzen der Lücke benötigt.
Die Fachpresse schreibt, dass es sich um eine Lücke im SMB-Protokoll handelt: «…die steckt im SMBv3-Protokoll und kann von entfernten Angreifern zur anschließenden Ausführung von Programmcode auf verwundbaren Systemen missbraucht werden. Admins sollten ihre Systeme jetzt zügig aktualisieren.». Dieses wird in Windows-Netzwerken integral eingesetzt, auch auf Systemen mit hohem Schutzbedarf wie Domain-Controllern.
Step three: Bin ich überhaupt betroffen?
Als nächstes muss geprüft werden, ob angreifbare Systeme vorhanden sind, und ob diese dem Angriffsvektor auch tatsächlich ausgesetzt sind. Ein Management-Interface einer Appliance, welches in einer isolierten Netztwerkzone-Zone liegt, ist für einen Angreifer schwerer zu erreichen als ein öffentlich erreichbares Webfrontend. Weiter sollte geprüft werden, welche Vorbedingungen ein Advisory voraussetzt, um eine Lücke auszunutzen.
An unserem Beispiel: SMB ist bei jedem Windowsclient ab Werk aktiv, zumindest zur Bereitstellung der administrativen Freigaben (c$). In aktuellen Versionen ist auch eine Firewall aktiv, welche den TCP-Port 445 schützt, sofern die Firewall nicht anderweitig umkonfiguriert wurde. Weiter ist SMB auf allen Domaincontrollern aktiv, da SMB für die Verarbeitung von Gruppenrichtlinien verwendet wird (SYSVOL, NETLOGON). Wir können also davon ausgehen, dass wir in unserem Beispiel betroffen sind.
Step four: Wie dringlich ist das Schliessen der Lücke?
Eine Einschätzung der Dringlichkeit auf Basis der bis jetzt gewonnen Erkenntnisse sollte nun durchgeführt werden. Die Frage heisst: Wie zeitnah muss die Lücke geschlossen werden? Es gibt in der Tat Schwachstellen mit weitreichendem Schadenspotenzial. Wenn diese aber bedingt durch Kapselung oder Vorbedingungen schwer auszunutzen sind, können sie trotzdem im geordneten Patchlauf geschlossen werden. Bei anderen Lücken muss sofort reagiert werden. Die Einschätzung ist für Ungeübte keine leichte Aufgabe. Ein paar Indikatoren oder Marker, auf die in Advisories oder der Fachpresse geachtet werden sollte, seien hier genannt (nicht abschliessend):
- Es existiert bereits Exploit-Code, um die Lücke auszunutzen
- Von der Lücke ist bekannt, dass sie schon ausgenutzt wird.
- Es existieren Übertragungskanäle (z. B. Benutzer mit Zugang zu E-Mail oder Internet), die das Einholen einer Infektion ermöglichen und/oder begünstigen.
Am Beispiel: Die Möglichkeit der lateralen Verbreitung sowie das Hochrisikotarget «Domaincontroller» erhöhen die Notwendigkeit, zügig auf die Lücke zu reagieren. Lädt ein Benutzer Malware-Code aus dem Netz oder erhält ein präpariertes E-Mail, kann sich die Malware ohne Hindernisse (keine Rechte nötig, Infektion aus der Ferne) im Netzwerk verbreiten.
Step five: Wie hoch ist das Risiko zum Schliessen der Lücke und wie hoch sind die Kosten?
Es sollte immer auch eine Kostennutzenabschätzung gemacht werden, wie hoch das Risiko ist, die Lücke zu schliessen. Ein anschauliches Bespiel ist das Löschen eines Brandes, bei dem das Löschwasser mehr Schaden verursacht als der Brand selbst. Einige Systeme brauchen mehr Vorbehandlung oder Vorlauf und es kann auch zu Schaden eben durch das Einspielen eines Sicherheitsupdates kommen. Allerdings ist weniger die Frage, ob ein System gepatcht wird, sondern eher wann. Normale Wartungsprozesse haben häufig sauber durchexerzierte Massnahmen zum Schutz von Daten und Systeme integriert, wozu in der Regel auch ein Zeitfenster für den Rollback und ein Test- und Freigabeprozedere gehören. Kann das Update also bis zum nächsten Patchlauf hinausgezögert werden oder ist unmittelbares Handeln notwendig? Wenn ja, mit welchen Massnahmen können potenzielle Negativauswirkungen vermindert oder verhindert werden?
Bei unserem Beispiel: Aufgrund der bis jetzt gewonnen Erkenntnisse dürften wir den Patch nicht mit gutem Gewissen vernachlässigen oder später installieren. Die SMB-Ghost-Lücke kann mittlerweile durch das Einspielen eines Patches oder Cumulative Updates geschlossen werden. Ein Patch kann z. B. per WSUS oder SCCM zuerst an eine Testgruppe ausgerollt und getestet werden. Zeigt sich dies unbedenklich, kann der Patch dann automatisiert und zeitnah auf die ganze Infrastruktur ausgerollt werden. Von daher kann man, natürlich unter Berücksichtigung situativer Anforderungen, die Lücke schliessen (lassen).
Im Nachgang
Einige Lücken entwickeln sich. Es kommt gelegentlich vor, dass eine Lücke erkannt und vom Hersteller geschlossen wird. Erst einige Zeit später erscheint öffentlich verfügbarer Exploit-Code. Spätestens dann aber müssen auch die letzten, hintersten und widerwilligsten Systeme gepatch sein. Wurde ein Update nicht unverzüglich eingespielt, ist es wichtig, die Fachpesse im Auge zu behalten und etwaige Meldungen zu berücksichtigen. Eine Schwachstelle gewinnt in der Risikoeinschätzung enorm an Gewicht, wenn Sie aktiv ausgenutzt werden kann. Insbesondere dann, wenn die breite Masse dies tun kann.
Wiederum am Beispiel: Nachfolgend ein Auszug, der ca. ¼ Jahr nach dem Bekanntwerden der Lücke von heise.de publiziert wurde:
«Die Lücke betrifft die Windows 10- und Windows Server-Versionen 1903 und 1909. Nutzer, die das Update bislang nicht eingespielt haben, sollten dies jetzt unbedingt nachholen: Bei GitHub wurde – wenn auch noch verbesserungswürdiger – Proof-of-Concept-Code zum Ausnutzen der Sicherheitslücke veröffentlicht.», (heise.de https://www.heise.de/security/meldung/Jetzt-patchen-Exploit-Code-fuer-aeltere-Windows-SMBv3-Luecke-veroeffentlicht-4777619.html).
Reflektion
Auch sollte ein kurzes Resumée gezogen werden, wie auf die Lücke reagiert wurde. Welche Entscheidungen waren zielführend, welche eher nicht? Welche Fehler wurden gemacht und warum? Bei Reaktionen auf Vorfälle, Krisen und Bedrohungen sind häufig Entscheidungen zu fällen, welche naheliegend erscheinen. Nicht selten zeigt sich aber im Nachgang, dass «der gesunde Menschenvestand», also eine natürlich und auf den ersten Blick zielführend erscheinende Lösung, gar keine so gute Wahl war. Komplexe Problemstellungen lassen sich häufig nicht auf Anhieb durch Überlegung sondern leider erst anhand der Erfahrung des Vergangenen analysieren. Umso wichtiger ist es, jene wertvollen Erkenntnisse aus den gewonnenen Erfahrungen zu ziehen und zu dokumentieren.
