Am 17. Dezember 2019 ist für die Produkte Citrix Gateway und Citrix Application Delivery Controller (ADC) des Herstellers Citrix eine sehr unangenehme Schwachstelle gemeldet worden [1]. Es war praktisch ein Klassiker: Durch speziell präparierte Anfragen per HTTP/HTTPS an die auf den Komponenten laufende Web-Anwendung kann ein Angreifer auf interne Verzeichnisse der Systeme zugreifen und so z.B. eigenen (Schad-)Code ausführen. Damit kann der Angreifer eine wesentliche Komponente im Bereich der Internet-DMZ praktisch übernehmen. Der Angreifer könnte aus dieser Position nun auch die Sitzungen der Nutzer kompromittieren und auf die weitere Infrastruktur zugreifen. Das ist der GAU einer jeden Web-Anwendung, speziell aber einer Web-Anwendung, die eigentlich für den sicheren Zugriff von außen über nicht oder eingeschränkt vertrauenswürdige Netze (insbesondere das Internet) gedacht ist. Es kam aber noch schlimmer, denn Mitte Januar 2020 kam die Information, dass auch die Citrix SD-WAN WANOP Appliance betroffen ist und damit eine Komponente, über die naturgemäß ein weitgehender Zugriff auf interne Ressourcen der jeweiligen Institution möglich ist.
In einem solchen Moment muss natürlich das Schwachstellenmanagement der betroffenen Institution unmittelbar eingreifen. Sobald die Information hinsichtlich einer Schwachstelle vorliegt (entweder über eine Meldung oder über die systematische und regelmäßige Prüfung von einschlägigen im Internet verfügbaren Datenbanken), muss zunächst geprüft werden, ob man überhaupt von der Schwachstelle betroffen ist und wie kritisch die Schwachstelle einzustufen ist.
Dann muss untersucht werden, ob ein Patch für die Schwachstelle bereits vorliegt, und wenn ja, ob der Patch auch tatsächlich zeitnah eingespielt werden könnte. Ist dies der Fall und der Patch erfolgreich installiert, dann kann durchgeatmet und der Sachverhalt zunächst zu den Akten gelegt werden. In der Praxis kommt es z.B. aber leider auch vor, dass zwar ein Patch für das Betriebssystem verfügbar ist, aber für eine Anwendung, die auf dem System läuft, seitens des Herstellers noch keine Freigabe für das Einspielen des Patches vorliegt und so eine schnelle Installation des Patches auf eigenes Risiko durchgeführt werden müsste oder eben verschoben wird.
Bei dem hier betrachteten Beispiel gab es zum Zeitpunkt der Meldung der Schwachstelle aber leider keinen Patch. Es muss in dieser Situation dann sofort geprüft werden, ob der Hersteller einen Workaround zur Verfügung gestellt hat, und wenn ja, wie tragfähig der Workaround ist. Wenn der Workaround die Schwachstelle vollumfänglich abdeckt und zeitnah umgesetzt werden kann, ist die Lage wieder deutlich entspannter. Im hier betrachteten Beispiel der Citrix-Schwachstelle gab es zwar sehr schnell auch eine Beschreibung, wie bösartige Anfragen per zusätzlich zu installierender Policy auf den Systemen gefiltert werden können [2]. Jedoch funktionierte der Workaround nicht immer. Es war in diesem Fall dann erst ein Software-Update der betroffenen Systeme notwendig [3].
Nach Bekanntwerden einer Schwachstelle ist es nur eine Frage der Zeit, bis Hacker entsprechende Angriffswerkzeuge angepasst bzw. entwickelt haben, die die Schwachstelle ausnutzen (Exploit) und diese dann auch einsetzen. Das war auch bei der betrachteten Citrix-Schwachstelle sehr schnell der Fall. Mitte Januar 2020 gab es die ersten Meldungen [4]. Der Schaden kann hier immens gewesen sein. Am 27.01. hat Citrix dann endlich Patches für die betroffenen Systeme bereitgestellt. Für alle betroffenen Institutionen ist die Herausforderung, die Patches nun schnellstmöglich zu installieren.
Im betrachteten Beispiel hat es also mehr als einen Monat gedauert, bis die Patches zur Verfügung standen. Es gibt in der Praxis auch durchaus nicht wenige Fälle, in denen eine Schwachstelle nicht ohne Weiteres durch einen Patch beseitigt werden kann, weil beispielsweise ein komplettes Redesign einer Software erforderlich wäre oder weil der Hersteller das betroffene Produkt nicht mehr unterstützt. Denken Sie nur an die Vielzahl von aktuell noch produktiven Systemen mit Windows XP in der Industrial IT. Es kommt also durchaus häufiger vor, dass man für einen gewissen unter Umständen recht langen Zeitraum notgedrungen mit einer Schwachstelle leben muss.
An dieser Stelle ist es für das Schwachstellenmanagement wichtig, dass eine Schnittstelle zum Risikomanagement besteht. Dabei wird zunächst analysiert, welcher Schaden durch das Ausnutzen der Schwachstelle möglich ist, und die Wahrscheinlichkeit eines Schadensereignisses wird abgeschätzt. Dann wird untersucht, ob und mit welchem Aufwand ergänzende Sicherheitsmaßnahmen eingesetzt werden können, um insbesondere ein höheres Risiko zu mindern und im besten Fall zu minimieren. Wenn Workarounds direkt auf den von der Schwachstelle betroffenen Systemen nicht oder nur unzureichend möglich sind, könnten z.B. bei einer Web-Anwendung über entsprechende Policies auf einer Web Application Firewall (WAF) oder durch schärfere Firewall-Regeln und / oder Policies für ein Intrusion Prevention System (IPS) das Ausnutzen der Schwachstelle vielleicht sogar verhindert werden. Außerdem kann für Systeme mit Schwachstellen eine temporäre erweiterte Netzsegmentierung (z.B. über Mikrosegmentierung [5]) in Betracht gezogen werden. Das Schwachstellenmanagement muss also auch mit dem Change Management und mit der Erstellung und Pflege von Sicherheitskonzepten verzahnt werden.
Außerdem könnte für Systeme mit bekannten Schwachstellen das Security Monitoring verstärkt werden, indem die betroffenen Systeme in eine zentrale Protokollierung (Log Management, LM) oder sogar in ein Security Information and Event Management (SIEM) aufgenommen werden und ggf. das Log Level erhöht bzw. die Policy auf dem SIEM verfeinert wird. Auf diese Weise könnte wenigstens schneller festgestellt werden, ob versucht wird, die Schwachstelle auszunutzen. Außerdem sind die Logs von LM- oder SIEM-Systemen für Troubleshooting und forensische Analysen essentiell. Die Prozesse für das Schwachstellenmanagement und für die Behandlung von Sicherheitsvorfällen sind sich naturgemäß ausgesprochen ähnlich. Eine Schwachstelle, die ausgenutzt wird, wird automatisch zum Sicherheitsvorfall.
„Nach der Schwachstelle ist vor der Schwachstelle“, d.h. die nächste Schwachstelle wartet schon. Es wäre auch nicht das erste Mal, dass bei einem Software-Update plötzlich eine Sicherheitslücke wieder da ist, die man eigentlich für geschlossen hielt. Daher ist es durchaus üblich, zumindest Teile der IT regelmäßig und oft automatisiert über einen Schwachstellen-Scanner auf bekannte Schwachstellen zu prüfen. Bei der Einführung einer neuen Anwendung bzw. eines neuen IT-Systems oder bei einem Major Change sollten ebenfalls möglichst tiefgehende Schwachstellen-Scans durchgeführt werden. Hier ist die Grenze zu Penetration Tests, bei denen systematisch neben bekannten Angriffsmustern auch kreativ neuartige Angriffe durchgeführt werden, fließend. Penetration Tests sind spätestens bei erhöhtem Schutzbedarf oder bei im Netz exponierten Systemen, speziell Web-Anwendungen, dringend zu empfehlen.
Selbstverständlich werden solche Techniken auch von den Herstellern der Anwendungen / Systeme eingesetzt, um Schwachstellen noch vor der Auslieferung der Produkte zu erkennen und zu beseitigen. Security by Design ist hier das wichtige Schlagwort. Aber auch wenn der Hersteller nach den Regeln der Kunst im Entwicklungsprozess die Informationssicherheit im Systementwurf, in der Implementierung und im Test berücksichtigt, bleibt die Wahrscheinlichkeit von Schwachstellen in den allermeisten Fällen deutlich größer als Null. Software ist und bleibt leider meist nicht fehlerfrei. Viele Fehler stellen nun einmal Schwachstellen dar. Trotzdem bleibt es besonders wichtig, als Kunde bei Ausschreibungen auch vom Hersteller nachweislich Security by Design zu fordern.
Das Schwachstellenmanagement ist also ausgesprochen komplex, vielschichtig und muss im gesamten Lebenszyklus einer IT-Komponente von der Entwicklung bis zur Maintenance, von der Planung und Beschaffung bis hin zur Außerbetriebnahme berücksichtigt werden. Man kann das Schwachstellenmanagement durchaus als Kunst bezeichnen, bei der über das Risikomanagement auf immer neue Herausforderungen schnell und kreativ reagiert und zwischen Wunsch und machbarer Wirklichkeit der Informationssicherheit balanciert werden muss.
Verweise
[1] Siehe z.B. https://support.citrix.com/article/CTX267027 und https://nvd.nist.gov/vuln/detail/CVE-2019-19781
Siehe https://support.citrix.com/article/CTX267679
[2] Siehe https://support.citrix.com/article/CTX269189
[3] Siehe z.B. https://www.bsi.bund.de/DE/Presse/Pressemitteilungen/Presse2020/Citrix_Schwachstelle_160120.html
[4] Siehe „Moderne Zonenkonzepte erfordern Mikrosegmentierung“, aus „Der Netzwerk Insider“, April 2019, verfügbar unter https://www.comconsult.com/moderne-zonenkonzepte-erfordern-mikrosegmentierung/