Lessons Learned from the Latest Ransomware Attack on an ESXi Host

19 October 2021

Lisa Vaas’s report about a ransomware attack on a VMware ESXi infrastructure is worth a detailed analysis because it reveals some interesting details on the attackers intentions.

The attack happened very fast and targeted. Vaas cites the Sophos press release: “This is one of the fastest ransomware attacks Sophos has ever investigated, and it appeared to precision-target the ESXi platform”.(Vaas 2021; Sophos Ltd. 2021)

How got the attacker initial access to the network?

The attackers used an inadequately secured TeamViewer remote access to break into the company. The hijacked account “had domain administrator access credentials“.(Sophos Ltd. 2021)

The ransomware operator was not interested in the Active Directory

It is very remarkable that the attackers then focused on the ESXi server. If an attacker is able to hijack an account that is member of the domain administrators group, he has got the keys to the kingdom. An APT would then act very carefully to stay as long as possible undetected.

But the ransomware operator made the right decision. To stay undetected in a network for weeks or months requires technical skills that ransomware operators just lack. This was an economically sensible decision.

The course of events shows some shortcomings in security best practice

Working with TeamViewer in unattended mode without a second factor is bad enough in itself, but, connecting to an account with domain admin privileges under this terms, violates any best practice.

User account control is available since Windows Vista, so there is no need to work with permanent administrative privileges. Moreover, Microsoft makes clear that “There should be no day-to-day user accounts in the DA group with the exception of the local Administrator account for the domain”.(Microsoft 2021)

ESXi servers were transparently accessible in the network, with active shell enabled

„The investigators believe the ESXi Server on the network was vulnerable because it had an active Shell, a programming interface that IT teams use for commands and updates.“(Sophos Ltd. 2021)

The IT team was aware of active shell security issue. “This organization’s IT staff was accustomed to using the ESXi Shell to manage the server, and had enabled and disabled the shell multiple times in the month prior to the attack. However, the last time they enabled the shell, they failed to disable it afterwards. The criminals took advantage of this fortuitous situation when they found the shell was active.”(Brandt 2021)

Adoption of ESXi security best practice would have reduced the impact

Good security practice restricts the accessibility of critical systems like the ESIx host. This can be done by isolating the ESIx hosts in separate network segment and restricting administrative access from an admin segment. Or by configuring the ESXi firewall to allow only connections from dedicated systems.

A good starting point is the VMware guideline “Securing the ESXi Hypervisor”.(VMware Inc. 2020). The DoD VMware ESIx STIG (Security Technical Implementation Guide) gives more details.(Network Frontiers LLC 2018)

Rule SV-77743r1_rule of the VMware ESIx STIG deals with the active shell issue: “The system must terminate shell services after a predetermined period.” The DoD requests to use 600s as timeout.

What can we learn from this attack?

  • Operations security is indispensable.
  • “Defense in depth” must be applied to secure ESXi hosts.
  • Security best practice and hardening guides are available.
  • Security best practice must be implemented and followed.

Have a great day!

References

Brandt, Andrew. 2021. “Python Ransomware Script Targets ESXi Server for Encryption.” Sophos News (blog). October 5, 2021. https://news.sophos.com/en-us/2021/10/05/python-ransomware-script-targets-esxi-server-for-encryption/.

Microsoft. 2021. “Implementing Least-Privilege Administrative Models.” Microsoft Docs. July 29, 2021. https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models#securing-domain-admins-groups.

Network Frontiers LLC. 2018. “VMware VSphere ESXi 6.0 Security Technical Implementation Guide.” STIG Viewer | Unified Compliance Framework®. 2018. https://www.stigviewer.com/stig/vmware_vsphere_esxi_6.0/2019-01-04/.

Sophos Ltd. 2021. “Sophos Researchers Uncover New Python Ransomware Targeting an ESXi Server and Virtual Machines in an Ultra-High-Speed Attack.” Sophos Press Release. October 5, 2021. https://www.sophos.com/en-us/press-office/press-releases/2021/10/sophos-researchers-uncover-new-python-ransomware-targeting-an-esxi-server-and-virtual-machines.aspx.

Vaas, Lisa. 2021. “VMware ESXi Servers Encrypted by Lightning-Fast Python Script.” Threatpost. October 6, 2021. https://threatpost.com/vmware-esxi-encrypted-python-script-ransomware/175374/.

VMware Inc. 2020. “Securing the ESXi Hypervisor.” VMware Docs. February 24, 2020. https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-E9B71B85-FBA3-447C-8A60-DEE2AE1A405A.html.

Azurescape. The Next Break of the Azure Tenant Isolation

12 September 2021

On 9 September 2021 Ionut Arghire reported on Security Week that “Microsoft has patched an Azure Container Instances (ACI) vulnerability that could have allowed users to access the information of other Azure customers” (Arghire 2021). The vulnerability dubbed Azurescape was identified by the Palo Alto Networks Unit 42 Threat Intelligence team in the Azure Container-as-a-Service platform. For details about the attack refer to the Palo Alto Networks post (Zelivanky and Avrahami 2021).

The good news is that the vulnerability was not exploited so far. Microsoft stated on 8 September 2021 that their “investigation surfaced no unauthorized access to customer data” (MSRC Team 2021). Nevertheless, this is a really serious issue.

Firstly, it is the second break of tenant isolation that became public within a few weeks.

On 26 August 2021, the WIZ Research Team published a security flaw named ChaosDB in an Azure Cosmos DB feature that also allowed cross tenant access. The team states that a “series of misconfigurations in the notebook feature opened up a new attack vector we were able to exploit. In short, the notebook container allowed for a privilege escalation into other customer notebooks“ (Ohfeld and Tzadik 2021). For details on immediate actions and security best practices see the MSRC post (MSRC Team 2021).

Secondly, this shows that tenant isolation can be [easily] jeopardized.

To be clear, shared primary keys for access to cloud services like Cosmos DB are bad security practice. But I would have expected that more sophisticated means than stealing a primary access key are required to break tenant isolation (Ohfeld and Tzadik 2021).

Azurescape and ChaosDB show that we must re-evaluate the risk of using shared cloud services and prepare for the breach.

References

Arghire, Ionut. 2021. “Microsoft Warns of Information Leak Flaw in Azure Container Instances | SecurityWeek.Com.” Cybersecurity News. SecurityWeek. September 9, 2021. https://www.securityweek.com/microsoft-warns-information-leak-flaw-azure-container-instances.

MSRC Team. 2021. “Update on the Vulnerability in the Azure Cosmos DB Jupyter Notebook Feature.” Microsoft Security Response Center. August 27, 2021. https://msrc-blog.microsoft.com/2021/08/27/update-on-vulnerability-in-the-azure-cosmos-db-jupyter-notebook-feature/.

———. 2021. “Coordinated Disclosure of Vulnerability in Azure Container Instances Service.” Microsoft Security Response Center. September 8, 2021. https://msrc-blog.microsoft.com/2021/09/08/coordinated-disclosure-of-vulnerability-in-azure-container-instances-service/.

Ohfeld, Nir, and Sagi Tzadik. 2021. “ChaosDB: How We Hacked Thousands of Azure Customers’ Databases.” The WIZ Blog. August 26, 2021. https://www.wiz.io/blog/chaosdb-how-we-hacked-thousands-of-azure-customers-databases.

Zelivanky, Ariel, and Yuval Avrahami. 2021. “What You Need to Know About Azurescape.” Palo Alto Networks Blog (blog). September 9, 2021. https://www.paloaltonetworks.com/blog/2021/09/azurescape/.

Was können wir aus dem Kaseya-Supply-Chain-Angriff für die Cybersicherheitsstrategie ableiten?

17 Juli 2021

Die Analyse des Kaseya-Supply-Chain-Angriffs offenbart 3 Schwachstellen im Software- und Systemdesign von Lösungsanbietern:

  1. Ausführung mit administrativen Berechtigungen

SophosLabs hat den Ablauf auf dem Endpunkt im Detail analysiert.(1) Die Kommandos, die der Kaseya-Agent nach der Auslieferung der Malware ausführt, erfordern administrative Berechtigungen. Das bedeutet, dass der Agent mit administrativen Berechtigungen arbeitet.

Klartext: Jede Anwendung, die mit administrativen Berechtigungen ausführt werden muss, stellt ein Sicherheitsrisiko dar. Das Risiko erhöht sich drastisch, wenn die Anwendung ferngesteuert werden kann.

Gerade die Entwickler von Remote-IT-Management-Lösungen sollten sparsam mit administrativen Berechtigungen umgehen, damit die Angriffsfläche des Netzwerkes nicht vergrößert wird. Windows und Linux bieten Entwicklern Funktionen an, die einen weitgehenden Verzicht darauf ermöglichen.

Tipp: Die Nutzung von administrativen Berechtigungen sollte ein Auswahlkriterium bei der Produktauswahl sein.

  1. Antivirus-Ausnahmen

Der Kaseya-Agent erfordert zur korrekten Ausführung mehrere Antivirus-Ausnahmen.(2) Die Remote-Control-Komponente benötigt weitere Ausnahmen.(3) Die Ausnahmen müssen für jeden Endpunkt, auf dem die Software genutzt werden soll, definiert werden.

Klartext: Jede Antivirus-Ausnahme reduziert das Sicherheitsniveau des gesamten Netzwerkes. Das Risiko erhöht sich drastisch, wenn die Ausnahme auf allen Endpunkten erforderlich ist.

Die Analyse von SophosLabs zeigt, dass ohne die Ausnahmen der Angriff mit hoher Wahrscheinlichkeit selbst von klassischen Antimalware-Lösungen erkannt worden wäre.

Tipp: Das Zusammenspiel mit vorhandenen Sicherheitslösungen sollte ein Auswahlkriterium bei der Produktauswahl sein.

  1. Sichtbarkeit von IT-Management-Systemen in der DMZ

Das DIVD CSIRT berichtet am 4. Juli, dass zu Beginn des Angriffs 2.200 Kaseya VSA Server in den DMZ von Unternehmen sichtbar waren.(4)

Prinzipiell ist jedes Managementsystem in der DMZ, das für alle Internetteilnehmer sichtbar ist, ein Sicherheitsproblem. Wird in der Anwendungssoftware eine kritische Schwachstelle entdeckt, so beginnt ein Wettlauf gegen die Zeit.

Klartext: Die Sichtbarkeit von Managementsysteme in der DMZ ist auf die notwendigen externen Systeme einzuschränken. Vom Internet eingehende Verbindungen erhöhen das Risiko drastisch.

Tipp: Die notwenigen Kommunikationsverbindungen mit dem Hersteller sollten ein Auswahlkriterium bei der Produktauswahl sein. Ausgehende Punkt-zu-Punkt-Verbindungen (Server in der DMZ initiiert die Kommunikation) sind zu bevorzugen.

Tipp: Überprüfen Sie nach der Inbetriebnahme, ob der Systembetreiber die Anforderungen des Herstellers umgesetzt hat. Führen Sie die Prüfungen regelmäßig durch.

Fazit

Die hier identifizierten Schwachstellen müssen in die Cybersicherheitssstrategie eines Unternehmens einfließen: “The strategist must concentrate less on determining specific actions to be taken and far more on manipulating the structure within which all actions are determined.”(5)

Werden die identifizierten Schwachstellen bei Entwicklung, Auswahl und Betrieb von Softwareprodukten konsequent adressiert, so ändern sich die Rahmenbedingungen, in denen Cyberkriminelle agieren können. Die Widerstandsfähigkeit gegen Cyberangriffe wird dauerhaft erhöht.

Quellenangaben

1.         Loman M, Gallagher S, Ajjan A. Independence Day: REvil uses supply chain exploit to attack hundreds of businesses [Internet]. Sophos News. 2021 [zitiert 17. Juli 2021]. Verfügbar unter: https://news.sophos.com/en-us/2021/07/04/independence-day-revil-uses-supply-chain-exploit-to-attack-hundreds-of-businesses/

2.         Kaseya. Anti-Virus and Firewall Exclusions and Trusted Apps [Internet]. Kaseya. 2021 [zitiert 17. Juli 2021]. Verfügbar unter: https://helpdesk.kaseya.com/hc/en-gb/articles/229014948-Anti-Virus-and-Firewall-Exclusions-and-Trusted-Apps

3.         Kaseya. Antivirus Exclusion list for Remote Control components. [Internet]. Kaseya. 2021 [zitiert 17. Juli 2021]. Verfügbar unter: https://helpdesk.kaseya.com/hc/en-gb/articles/229008988-Antivirus-Exclusion-list-for-Remote-Control-components-

4.         Gevers V. Kaseya Case Update 2 [Internet]. DIVD CSIRT. 2021 [zitiert 17. Juli 2021]. Verfügbar unter: https://csirt.divd.nl/2021/07/04/Kaseya-Case-Update-2/

5.         Dolman EC. Pure strategy: Power and principle in the space and information age. London ; New York: Frank Cass; 2005. 218 S. (Cass series–strategy and history).

Wie hängt das zusammen? Der Cyber-Angriff auf die Colonial Pipeline, Network-Monitoring und Asset-Management?

11. Juni 2021

Es hat lange gedauert, bis die Ursache für den Cyber-Angriff auf die Colonial Pipeline bekannt wurde. Doug Olenik berichtet auf InfoRiskToday: “The investigation into the attack by security firm FireEye revealed last week that DarkSide gained initial access to Colonial through what Blount described as a “legacy VPN” that the company’s IT staff did not know existed.”(1)

Der CEO von Colonial Pipeline Co., Joseph Blount, sagte während eines Hearings am 8. Juni 2021 dazu: “I did reference earlier that the VPN was a legacy VPN we could not see, and it did not show up in any testing. That’s unfortunate.”(1)

Dass das VPN nicht mit Zwei-Faktor-Authentisierung abgesichert war, ist nicht ungewöhnlich, da es sich um einen „Legacy“ VPN-Zugang handelte, der außer von den Angreifern nicht mehr genutzt wurde. Der VPN-Zugang war zudem gut gesichert, da er bei Schwachstellen-Scans nicht gefunden wurde.

Die Antwort auf die Frage „Warum wurde das System, über den der VPN-Zugang erfolgte oder der VPN-Service nicht abgeschaltet?“ liegt nahe: Vermutlich ist in der IT kein Asset Management System vorhanden.

Dabei ist Asset Management ein Abfallprodukt des Network Monitoring, eine der Nice-to-Have-Funktionen, die man unbedingt bei der Einführung eines „Network Monitoring und Anomaly Detection“-Werkzeuges berücksichtigen sollte.

Im Rahmen der IMI (IT-Meets-Industry) stellen die anapur-Partner Nozomi Networks und PaloAlto Networks am 15. Juni in einer Product Challenge ihre Network Monitoring Werkzeuge vor. Wir werden beiden Partnern natürlich die Frage stellen, ob ihre Produkte die angeblich nicht-existenten Komponenten gefunden hätten und freuen uns auf die Produkt-Demo.

Im Anwenderinterview fragen wir Tobias Unglaube, der in der Bayer AG im Produktionsumfeld Network Monitoring eingeführt hat, ob die nice-to-have-Funktion „Asset-Management“ bei der Produktauswahl eine Rolle gespielt hat.

Zur Anmeldung zum Event geht es hier. Die Aufzeichnungen und Produkt-Demos der vergangenen Network-Monitoring-Events stellen wir für Teilnehmer bereit.

Falls Sie keine Zeit haben, würden wir uns freuen, wenn Sie uns 2 Fragen (Multiple Choice) beantworten würden. Die Auswertung veröffentlichen wir nach dem Event.

Frage 1: Warum beschäftigt sich meine Organisation mit Network Monitoring und Anomaly Detection?

Frage 2: Was ist für meine Organisation das wichtigste nice-to-have Feature bei einem Netzwerk Monitoring System?

Schönes Wochenende!

Referenzen

1. Olenick D. Colonial CEO at Senate Hearing Details Ransomware Attack [Internet]. Info Risk Today. 2021 [zitiert 9. Juni 2021]. Verfügbar unter: https://www.inforisktoday.com/colonial-ceo-at-senate-hearing-details-ransomware-attack-a-16836

Ransomware in der Automatisierungstechnik. RoSI in der Praxis.

6. Mai 2021

Nach der kurzen Einführung in die Theorie von RoSI nun ein Praxisbeispiel.

Szenario

Ein Unternehmen betreibt an 2 Standorten prozesstechnische Anlagen. Jede Anlage besteht aus 5 Teilanlagen. Insgesamt werden pro Standort 100 Workstations und 20 Server betrieben. Die Standorte sollen im Rahmen eines Digitalisierungsprojektes enger mit der Forschungs- Entwicklungsabteilung sowie den Produktionsplanungssystemen und der Office-Cloud vernetzt werden. Vorab führt das Produktionsmanagement eine Risikoanalyse durch.

Die Risikoanalyse ermittelt ein hohes Risiko in Bezug auf eine Malware-Infektion, die zu einem Stillstand an beiden Standorten führen könnte. Der Produktionsmanager schätzt, dass eine Infektion mit Ransomware im ungünstigsten Fall zu einem Produktionsausfall von 5 Tagen führen könnte. Ein Tag Produktionsausfall kostet das Unternehmen 200T€.

Die Geschäftsleitung macht klar, dass unter der geschätzten Auslastung für die nächsten 36 Monate ein Ausfall von max. 1,5 Tagen pro Jahr akzeptabel ist. Das ermittelte Risiko ist nicht akzeptabel ist. Die OT-Security erhält die Aufgabe, die wirtschaftlich beste Lösung zur Reduktion des Risikos um 70% (von 1Mio. € auf 300T€) zu ermitteln.

Damit sind die Randbedingungen für die RoSI-Betrachtung festgelegt:

KE: Die Kosten des Sicherheitsereignisses KE belaufen sich auf KE = 1 Mio. €.

SR%: Sicherheitsmaßnahme S soll das Risiko um SR% = 70% reduzieren.

KES: Die Kosten des Sicherheitsereignisses sollen reduziert werden auf KES <= 300T€

Design der Maßnahmen

Das Unternehmen setzt in der Produktion noch keine Antimalware-Lösung ein. Zur Risikoreduzierung werden 3 traditionelle Ansätze verfolgt, die auf Sicherheitslösungen beruhen, die vom Hersteller der Automatisierungslösung freigegeben sind.

Alt1: Antimalware-Lösung McAfee Endpoint Protection

Alt2: Antimalware-Lösung McAfee Endpoint Protection plus Microsoft AppLocker

Alt3: Antimalware-Lösung McAfee Endpoint Protection plus McAfee Application Control

Microsoft AppLocker ist eine Application-Directory-Allow-Listing-Lösung, die von vielen Herstellern von Automatisierungslösungen zur Grundhärtung der Systeme empfohlen wird. AppLocker ist seit Windows 7 in der Enterprise-Version des Betriebssystems verfügbar. McAfee Application Control ist eine system-basierte Application-Whitelisting-Lösung, die von vielen Herstellern von Automatisierungslösungen zum Schutz vor bekannter und neuer Malware empfohlen wird. Sie kann auch Crypto-Würmer wie WannaCry und NotPetya, die sich im Systemkontext von System zu System bewegen, abwehren.

Bewertung der Effektivität der Lösungsansätze

IT- und OT-Security führen eine Bewertung der Effektivität der verschiedenen systemtechnischen Ansätze durch. Daraus ergibt sich folgendes Bild:

Bewertung der Effektivität der Lösungen. Zum Vergrößern klicken.

Die klassische Antimalware-Lösung „pattern-based Antivirus“ hat mit 38% eine unzureichende Schutzwirkung, ebenso wie die Lösung „Application Directory Allow Listing“ und die Kombination aus AV.Trad und AWL.DIR.

Die „system-basierte Application-Whitelisting-Lösung“ kommt bereits sehr nahe (64%) an die geforderte Risikoreduzierung SR% = 70% heran.

Die Kombination aus AV.Trad und AWL.SYS kommt am nächsten an die geforderte Risikoreduzierung von 70% heran.

Die Details zur Bewertung stehen hier bereit.

Kostenbetrachtung

Die Kosten aller Lösungen wurden untersucht. Lizenz- und Betriebskosten wurden über einen Zeitraum von 3 Jahren betrachtet. Die Kosten für die Erstinstallation wurden berücksichtigt. Bei den Lizenzkosten wurden Lizenzstaffeln (101-250 Workstations und 26-50 Server) berücksichtigt. Preise wurden per Internet-Recherche ermittelt. Das Kostenmodell steht hier zum Download verfügbar.

RoSI

Die Berechnung von RoSI über 3 Jahre ergibt folgendes Bild:

RoSI der Lösungen im Vergleich. Zum Vergrößern klicken.

Alle Lösungen haben ein positives RoSI. Die Optionen Alt1: AV.Trad und Alt2: AV.Trad + AWL-DIR scheiden aus, da das Restrisiko KES deutlich höher ist als die geforderten 900T€

RoSI: Vergleich der Alternativen. Zum Vergrößern klicken.

Alternative Alt3: Antimalware-Lösung McAfee Endpoint Protection plus McAfee Application Control und McAfee Application Control führen zu einer ähnlichen Risikoreduktion. Alt3 hat jedoch deutlich höhere Kosten.

Für welche Lösung wird sich die Produktionsleitung entscheiden?

Dies ist der letzte Post aus der Ransomware/RoSI-Reihe. Mehr zu RoSI gibt es beim IMI Virtuellen Dialog „Costs and Benefits of Security“ am 11.05.2021. Neben praktischen Anwendungsbeispielen von ABB und Fortinet erweitere ich diese Analyse um eine moderne EDR-Lösung.

Viel Erfolg mit RoSI!

Ransomware in der Automatisierungstechnik. Was ist RoSI?

5. April 2021

Bevor ich weiter auf das Thema Ransomware in der Automatisierungstechnik eingehe, ist eine kurze Einführung in RoSI erforderlich.

Die Return-on-Security-Invest-Methode (RoSI)(1,2) erlaubt analog zur Return-on-Invest-Methode (RoI) eine Bewertung der Wirtschaftlichkeit von IT-Sicherheitsmaßnahmen.

Der RoI zeigt das Verhältnis von erwartetem Gewinn G aus einer Investition und dem dafür eingesetzten Kapital (Kosten) K in einem bestimmten Zeitraum an. Im einfachsten Fall ist der Gewinn G gleich dem Umsatz U, der aus der Investition generiert wird, minus den Kosten K für die Investition: G = U – K

Damit ergibt sich RoI = G / K = U – K / K

Ist der RoI größer Null, so ist die Investition rentabel.

Die Übertragung des RoI-Konzeptes auf IT-Sicherheitsmaßnahmen ist nicht ohne Anpassung möglich. Christian Dreyer machte das Dilemma klar: „Es gibt keinen positiven Nutzen von Sicherheitsinvestitionen. Investitionen in Informationssicherheit vermeiden lediglich Wertabflüsse. Das ist die Crux der ganzen Sache.“ Zitiert aus Stöwer, Wirtschaftlichkeitsbetrachtungen zu IT -Sicherheitsinvestitionen.(3)

Ein Sicherheitsereignis E erzeugt Kosten KE. Da die Kosten KE nicht geplant sind, verringern sie den Gewinn G des Unternehmens. Durch eine Sicherheitsmaßnahme S wird versucht, die Kosten KE des Sicherheitsereignisses um SR% zu verringern. S vermeidet also Kosten KV = KE x SR%. Mit Maßnahme S sind Toolkosten TS verbunden.

RoSI setzt die vermiedenen Kosten KV in Bezug zu den Toolkosten TS:

RoSI = ( KV – TS ) / TS

Solange RoSI einen Wert > 0 hat ist die Sicherheitsmaßnahme S “rentabel”.

Beispiel

Die erwarteten Kosten eines Sicherheitsereignisses werden auf KE = 1,5 Mio. € geschätzt.

Die Sicherheitsmaßnahme S reduziert die Kosten um SR% = 60%. => KV = 900 T€.

Die Toolkosten belaufen sich auf TS = 100 T€.

RoSI = ( KV – TS ) / TS = (900 T€ – 100 T€) / 100 T€ = 800%

Fakten zu RoSI

  • Nach Implementierung der Sicherheitsmaßnahme S reduzieren sich die Kosten KE des Sicherheitsereignisses auf KES = KE – KV.
  • Der Gewinn G des Unternehmens reduziert sich dauerhaft um die Toolkosten TS der Maßnahme S.
  • KE = TS + KES + RoSI
  • RoSI = KV – TS
RoSI

Wann kommt RoSI zum Einsatz?

RoSI sollte spätestens beim Design von risiko-reduzierenden Maßnahmen zum Einsatz kommen. Wurde ein Sicherheitsrisiko identifiziert, das über der Risikotragfähigkeit einer Organisation liegt, so sollten geeignete Maßnahmen ergriffen werden, um das Risiko unter diesen Wert zu reduzieren. Prinzipiell kann damit SR% bestimmt werden.

RoSI Ziele

RoSI dient dazu, verschiedene Sicherheitsmaßnahmen oder -lösungen, die das Risiko um SR% reduzieren können, miteinander zu vergleichen. Das Vergleichskriterium sind die Toolkosten TS. Die Toolkosten sollten über einen Zeitraum von 3 Jahren betrachtet werden. Primäres Ziel ist, eine Lösung zu finden, die RoSI optimiert, also die Toolkosten zu minimieren.

Toolkosten umfassen mindestens die Anschaffungskosten und die Kosten für die Implementierung und den Betrieb der Lösung. Hat die Lösung Auswirkungen auf die Produktivität der Mitarbeiter, so sollten zusätzlich Opportunitätskosten berücksichtigt werden. Zudem sollten Effektivitätsverluste berücksichtigt werden.

Die Implementierungskosten umfassen alle Kosten, die für das Roll-Out der Lösung im Unternehmen erforderlich sind. Ist eine Ramp-up-Phase notwendig, so sollten die Kosten mindestens über die Ramp-Up-Phase plus 3 Jahre betrachtet werden.

Eine Ramp-Up-Phase über mehrere Jahre muss im Detail geplant werden. Bereits im ersten Jahr sollte ein möglichst großer Teil (z.B. 80%) des geplanten Sicherheitsgewinns SR% erzielt werden, damit der erwartete Schaden von Beginn an effektiv reduziert werden kann.

Die Betriebskosten umfassen alle Kosten zur Wartung der Lösung, die Kosten für den Betrieb der Lösungsinfrastruktur und die Personalkosten zum Betrieb der Lösung.

In den Kosten sollten Effektivitätsverluste berücksichtigt werden:

  1. Der geplante Sicherheitsgewinn SR% wird in der Regel nicht erzielt. Das kann technische und organisatorische Ursachen haben. Auf jeden Fall sinkt die Effektivität der Lösung, damit KV und somit RoSI. Dies sollte bereits bei der Auswahl einer Lösung berücksichtigt werden.
  2. Die Effektivität von Sicherheitsmaßnahmen sinkt über die Zeit. Angriffswerkzeuge werden verbessert; neue Schwachstellen werden entdeckt, die die Wirksamkeit der Sicherheitsmaßnahme reduzieren. Ausnahmen müssen zugelassen werden, damit die Produktivität nicht sinkt. Unter Umständen muss nach wenigen Jahren eine weitere Sicherheitslösung implementiert werden, um das Risiko wieder auf den Wert SR% zu reduzieren, was wiederum die Kosten erhöht.

Wichtig! Die Planung und Vorbereitung von Security-Projekten dauert bei Verwendung von RoSI länger, da viele Fragen vorab beantwortet werden müssen, die im Normalfall erst während der Implementierung geklärt werden. Der Vorteil ist, dass die Erfolgsaussichten steigen und teurere Lessons Learned vermieden werden können.

Mehr zur Effektivität von Application Whitelisting Lösungen und RoSI im nächsten Post.

Referenzen

  1. ENISA. Introduction to Return on Security Investment [Internet]. 2012 [zitiert 21. März 2021]. Verfügbar unter: https://www.enisa.europa.eu/publications/introduction-to-return-on-security-investment
  2. Sonnenreich W. Return On Security Investment (ROSI): A Practical Quantitative Model [Internet]. Verfügbar unter: http://infosecwriters.com/text_resources/pdf/ROSI-Practical_Model.pdf
  3. Stöwer M. Wirtschaftlichkeitsbetrachtungen zu IT- Sicherheitsinvestitionen [Internet]. 2010 [zitiert 21. März 2021]. Verfügbar unter: https://docplayer.org/61999306-T-i-s-p-community-meeting-2010-koeln-03.html

Ransomware in der Automatisierungstechnik. Das muss nicht sein!

28. März 2021

Vor einigen Tagen schaute ich mit das KnowBe4 Webinar „Now That Ransomware Has Gone Nuclear, Avoid Becoming the Next Victim?“ (1) an. Der erste Teil über das Ransomware Business war sehr informativ. Folie „Defenses“ brachte die ganze Ransomware-Diskussion auf den Punkt:

Von den weiteren Details zu den Abwehrmaßnahmen war ich eher enttäuscht. Das Webinar vermittelte den Eindruck, dass die Anbieter von IT-Security-Lösungen keine Strategie zum Umgang mit Ransomware haben. Philipp Blom bringt es in seinem Buch „Das große Welttheater“ (2) auf den Punkt:

„Die Protagonisten handeln und planen in der Annahme, dass die Gegenwart so ist, wie sie nun einmal ist, dass keine wirkliche Alternative besteht und dass deswegen nichts anderes übrigbleibt, als eben weiterzumachen wie bisher, nur mit noch mehr Energie und Entschlossenheit, immer weiter hinein, immer schneller, immer mehr.“

Im CISA Ransomware Guide (3) von 2020 findet man nahezu alle Vorschläge, die Javvad Malik von KnowBe4 in seinen Folien im Abschnitt Defenses zeigt. Die CISA geht im Abschnitt „Ransomware Infection Vector: Precursor Malware Infection“ einen entscheidenden Schritt weiter und empfiehlt:

“Use application directory allowlisting on all assets to ensure that only authorized software can run, and all unauthorized software is blocked from executing.
Enable application directory allowlisting through Microsoft Software Restriction Policy or AppLocker.”

Wie funktionieren Application-Directory-Allowlisting-Lösungen?

Das Schutzkonzept von Application-Directory-Allowlisting-Lösungen, auch Directory-Whitelisting-Lösungen genannt, ist bestechend einfach: Anwendungen dürfen nur gestartet werden, wenn Sie in bestimmten Verzeichnissen installiert sind.

Die einfachste Allowlist besteht aus 2 Verzeichnissen, c:\windows\system32 und c:\programme. Microsoft Word, installiert in „C:\Programme\Microsoft Office“ darf gestartet werden; die Ausführung eines PowerShell-Scripts, das ein bösartiges Word-Dokument im Homeverzeichnis eines Anwenders speichert, wird blockiert, da das Homeverzeichnis nicht in der Whitelist verzeichnet ist.

Application-Directory-Allowlisting-Lösungen blockieren Angriffe bereits in der Exploitation Phase der Cyber-Kill-Chain; die Installation des Schadprogramms wird verhindert.

Software Restriction Policies (SRP) sind seit Windows XP in der Professional-Version, AppLocker ist seit Windows 7 in der Enterprise-Version von Windows verfügbar. Beide können zentral über Group Policies administriert werden. Im Hintergrund überwacht der Dienst Anwendungsidentität (AppIdSvc) die Objektausführung.  

Lösungsanbieter im Umfeld Prozessautomatisierung sind sehr konservativ, wenn es um Systemprogramme geht, die in die Programmausführung eingreifen. Ein Anbieter legt im Detail fest, welche IT-Security Produkte in welcher Version mit seinen Produkten zertifiziert sind. Das garantiert dem Systemintegrator und Betreiber die Unterstützung im Fall von Problemen. Interessanterweise sehen einige der bekannten Lösungsanbieter AppLocker als grundlegende Härtungsmaßnahme an:

Hersteller Erklärung des Herstellers zum Einsatz von AppLocker
Siemens Grundlegende Sicherheitseinstellung für SIMATIC IPCs (4)
Schneider
Electric 		Akzeptiert die Nutzung von AppLocker (6), referenziert auf
die Essential Four (Vorgänger der Essential Eight (5)) des Australian Cyber
Security Centre.
ABB Automatisch konfiguriert in MicroSCADA Pro SYS600 und DMS600 Umgebungen (7)
Rockwell Whitelisting mit AppLocker ist Critical Control (8). Vorgefertigte AppLocker Policies sind
zum Download verfügbar.
Herstellerinformationen zu AppLocker

Hinweis: Diese Zusammenstellung ist nicht vollständig. Fragen Sie den Hersteller ihrer Automatisierungslösung, ob er Application-Directory-Allowlisting mit AppLocker oder SRP unterstützt.

Wie wirksam sind Application-Directory-Allowlisting-Lösungen?

Application-Directory-Allowlisting-Lösungen schützen vor Angriffen, die eine Benutzerinteraktion erfordern. Dazu gehören etwa als Dokumente und Anhänge getarnte Schadprogramme, Drive-by-Downloads oder PuP (Potentially unwanted Programs). Da die Lösungen nicht mit Erkennungsmustern arbeiten, sinkt die Effektivität nicht über die Zeit. Damit ist auch ein Schutz gegen neuartige Malware wie Purple Fox (9) gewährleistet.

Was reduziert die Effektivität von Application-Directory-Allowlisting-Lösungen?

Arbeitet der Anwender mit permanenten administrativen Berechtigungen, so besteht die Möglichkeit, dass sich die Schadware in ein erlaubtes Verzeichnis, etwa c:\windows\system32 kopiert. Damit könnte die Malware gestartet werden.

Wo bieten Application-Directory-Allowlisting-Lösungen keinen Schutz?

Bei jeder Art von Malware, die im Systemkontext und ohne Benutzerinteraktion arbeitet. Dazu gehören Crypto-Würmer wie WannaCry und NotPetya. Pro Jahr werden wenige Schwachstellen in Windows-Systemfunktionen gefunden, die Wurm-Potenzial haben. Sofern in ihrem Produktionsumfeld eingehende Netzwerkverbindungen mit Microsoft-Protokollen erforderlich sind, sollten Application-Whitelisting-Lösungen zum Einsatz kommen.

Was kostet die Einführung der Lösung?

AppLocker ist in der Enterprise-Version von Windows enthalten. Die Installation und der Betrieb im Automatisierungsumfeld ist einfach, da kaum Modern Apps eingesetzt werden, die im Userkontext installiert sind. Das Rollout der Lösung kann mit Group Policies durchgeführt werden, sofern ein Active Directory vorhanden ist. Daher ist mit sehr geringen Betriebskosten und somit einem großen RoSI zu rechnen. Mehr zu RoSI (Return on Security Invest) im nächsten Post.

Sollte AppLocker auch im Enterprise Umfeld genutzt werden

Die CISA Empfehlung ist klar. Im Enterprise-Umfeld ist mit den Modern Apps mit deutlich erhöhtem Aufwand zu rechnen, da diese im User-Kontext arbeiten. Lösungen wie Goto-Meeting, die das Herunterladen und Ausführen eines Programms im Userkontext erfordern, funktionieren nicht, können jedoch durch geeignete AppLocker Regeln lauffähig gemacht werden. Prinzipiell sollten solche Programme nicht verwendet werden, da sie ein erhebliches Sicherheitsproblem bilden. Im Enterprise-Umfeld ist mit einem deutlich schlechteren RoSI zu rechnen.

Mehr zu RoSI und Application Whitelisting im nächsten Post.

Referenzen

1.            Malik J. Now That Ransomware Has Gone Nuclear, How Can You Avoid Becoming the Next Victim? [Internet]. Data Breach Today. 2021 [zitiert 28. März 2021]. Verfügbar unter: https://www.databreachtoday.eu/showOnDemand.php?webinarID=3007

2.            Blom P. Das große Welttheater. Von der Macht der Vorstellungskraft in Zeiten des Umbruchs. 2020.

3.            CISA Cyber Security and Infrastructure Security Agency. Ransomware Guide [Internet]. Publications Library. 2020 [zitiert 8. Oktober 2020]. Verfügbar unter: https://www.cisa.gov/sites/default/files/publications/CISA_MS-ISAC_Ransomware%20Guide_S508C.pdf

4.            Siemens AG. Empfohlene Sicherheitseinstellungen für IPCs im Industrieumfeld [Internet]. Industry Online Support International. 2019 [zitiert 2. Dezember 2020]. Verfügbar unter: https://support.industry.siemens.com/cs/document/109475014/empfohlene-sicherheitseinstellungen-f%C3%BCr-ipcs-im-industrieumfeld?dti=0&lc=de-WW

5.            Australian Cyber Security Center. Essential Eight Explained | Cyber.gov.au [Internet]. Australian Signals Directorate. 2020 [zitiert 19. Juni 2020]. Verfügbar unter: https://www.cyber.gov.au/publications/essential-eight-explained

6.            Schneider Electric. How can I… Reduce Vulnerability to Cyberattacks? [Internet]. 2019. Verfügbar unter: https://download.schneider-electric.com/files?p_enDocType=Technical+leaflet&p_File_Name=STN+-+How+can+I+reduce+vulnerability+to+cyberattacks+v3+Feb2019.pdf&p_Doc_Ref=STN+v2#page75

7.            ABB. MicroSCADA Pro Cyber Security Deployment Guideline [Internet]. 2016 [zitiert 2. Dezember 2020]. Verfügbar unter: https://docplayer.net/37555936-Microscada-pro-cyber-security-deployment-guideline.html

8.            Rockwell Automation. Rockwell Automation Customer Hardening Guidelines. Document ID: PN767 [Internet]. 2010 [zitiert 2. Dezember 2020]. Verfügbar unter: https://rockwellautomation.custhelp.com/app/answers/answer_view/a_id/546987/loc/en_US#__highlight

9.            Montalbano E. Purple Fox Malware Targets Windows Machines With New Worm Capabilities [Internet]. threatpost. 2020 [zitiert 26. März 2021]. Verfügbar unter: https://threatpost.com/purple-fox-malware-windows-worm/164993/

CVE-2021-21972 – Kritische Schwachstelle in vSphere Client. Was hätte Peter F. Drucker dazu gesagt?

6. März 2021

Am 23. Februar 2021 veröffentlichte VMware(1) die Schwachstelle CVE-2021-21972(2) im vSphere HTML 5 Client. Bei CVE-2021-21972 handelt es sich um eine kritische Schwachstelle, vergleichbar mit Schwachstelle CVE-2019-19781 im Citrix Application Delivery Controller, die 2020 im Angriff auf die Uni-Klinik Düsseldorf verwendet wurde.

Schwachstelle CVSS V3 Vektor
Kritische Schwachstelle AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H Definition
CVE-2021-21972 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H VMware vSphere RCE
CVE-2019-19781 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H Citrix Application Delivery Controller RCE, Uni-Klinik Düsseldorf, 2020

Die Ausnutzung einer kritischen Schwachstelle führt zum vollständigen Verlust der Integrität des Systems (I:High), den ich höher bewerte als den vollständigen Verlust der Verfügbarkeit oder der Vertraulichkeit. Der vollständige Verlust der Integrität hat zur Folge, dass der Angreifer unerkannt und unbemerkt beliebige Änderungen am System vorzunehmen. Das kann in der Prozessindustrie, wie das Beispiel Triton(3) zeigt, zu Explosionen führen.

CVE-2021-21972 ist wie CVE-2019-19781 eine Remote-Code-Execution-Schwachstelle. RCE-Schwachstellen ermöglichen dem Angreifer, beliebigen Code im Systemkontext, also mit den höchsten Berechtigungen, auszuführen.

In beiden Fällen ist die Access Complexity AC:Low. Der Angreifer benötigt nur wenig Knowhow zur Durchführung des Angriffs. Steht das betroffene System in der DMZ, so kann prinzipiell jeder der ca. 4 Mrd. Internetteilnehmer mit wenig Aufwand einen Angriff starten und das System übernehmen.

Eine kritische Schwachstelle sollte also umgehend nach ihrer Veröffentlichung gepatcht werden. Ist dies nicht möglich, so sollten direkt risiko-reduzierende Maßnahmen ergriffen werden, um einem Verlust der Integrität vorzubeugen. Sind weder Patches noch risiko-reduzierende Maßnahmen bekannt, so sollte der Zugriff vom Internet auf das betroffene System deaktiviert werden.

vSphere Client-Systeme in Region Kassel

vSphere Client-Systeme in Region Kassel, Quelle: Shodan

Im Fall CVE-2019-19781 dauerte die Bereit-stellung des Patches einen Monat. Zudem wurde die Schwachstelle bereits vor der Veröffentlichung in Angriffen genutzt.
CVE-2019-19781 war also ein Zero-Day-
Exploit. Das ist bei CVE-2021-21972 nicht der Fall. VMware(1) veröffentlichte mit der Schwachstelle Patches und Workarounds. Workarounds sind notwendig in der Zeit bis der Patch ausgerollt und aktiviert ist. Damit konnten die ca. 6.500 betroffenen vSphere Clients, die direkt vom Internet erreichbar sind, effizient geschützt werden. Da bereits am Tag nach der Veröffentlichung ein Exploit(4) verfügbar war mussten die Systeme umgehend gepatcht werden. Und IT-Abteilungen haben dies schnell, effizient und mit viel persönlichem Einsatz getan.

Die große Frage ist: Warum sind diese vSphere Client-Systeme überhaupt vom Internet erreichbar? Kritische Systeme wie die Managementsysteme für eine VMware-Infrastruktur sollten nie vom Internet erreichbar sein. Das gilt nicht für den Citrix Application Delivery Controller. Dessen Aufgabe ist die sichere Bereitstellung von internen Ressourcen für Anwender, die vom Internet zugreifen. Im Fall VMware haben wir Probleme geschaffen, die wir bei Veröffentlichung einer neuen Schwachstelle mit großer Effizienz lösen. Hierzu sagt Peter F. Drucker(5):

“There is surely nothing quite so useless as doing with great efficiency what should not be done at all.”

Ist CVE-2021-21972 ein Einzelfall? Leider nicht. Nur zwei Beispiele:

  • Stand 6.3.2021 listet Shodan 1,265,880 Systeme mit offenem SMB Port, obwohl WannaCry 2017 solche Systeme für den Zugriff auf interne Computernetzwerke nutzte.
  • Shodan listet 3,974,926 Systeme, die per RDP erreichbar sind, obwohl CVE-2019-0708 (BlueKeep) mit hohem Aufwand weltweit gepatcht wurde um Angriffe von WannaCry-Ausmaßen zu verhindern.

In beiden Fällen müssen wir die Frage stellen: Ist das notwendig? Wie viele IT-Experten, die wir dringend für Digitalisierungsprojekte benötigen, arbeiten an der Lösung von IT-Problemen, die nicht existieren sollten? Können wir uns eine derartige Verschwendung von Expertise leisten?

Peter F. Druckers Veröffentlichung “Managing for Business Effectiveness” aus dem Jahr 1963 ist wieder top aktuell.

Schönes Wochenende.

Quellen

  1. VMSA-2021-0002 [Internet]. VMware. [zitiert 25. Februar 2021]. Verfügbar unter: https://www.vmware.com/security/advisories/VMSA-2021-0002.html
  2. NIST Information Technology Laboratory. NVD – CVE-2021-21972 [Internet]. NIST National Vulnerability Database. 2021 [zitiert 5. März 2021]. Verfügbar unter: https://nvd.nist.gov/vuln/detail/CVE-2021-21972
  3. Sobczak B. SECURITY: The inside story of the world’s most dangerous malware [Internet]. 2019 [zitiert 11. Mai 2019]. Verfügbar unter: https://www.eenews.net/stories/1060123327
  4. Klyuchnikov M. Unauthorized RCE in VMware vCenter [Internet]. PT SWARM. 2021 [zitiert 6. März 2021]. Verfügbar unter: https://swarm.ptsecurity.com/unauth-rce-vmware/
  5. Drucker PF. Managing for Business Effectiveness. Harvard Business Review [Internet]. 1. Mai 1963 [zitiert 6. März 2021]; Verfügbar unter: https://hbr.org/1963/05/managing-for-business-effectiveness

Are your Security Self-Services Secure?

27 January 2021

In the Fox IT blog post “Abusing cloud services to fly under the radar“[1], Wouter Jansen reports on a threat actor who got illegal access to the networks of high-tech and aviation companies and stayed undetected for more than 3 years. The post gives a great introduction to the MITRE ATT&CK framework, absolutely recommendable.

In section Initial access we read: “From this portal it was possible to launch the web-based VPN. The VPN was protected by two-factor authentication (2FA) by sending an SMS with a one-time password (OTP) to the user account’s primary or alternate phone number. It was possible to configure an alternate phone number for the logged in user account at the company portal” (my emphasis).

This describes a well-known issue with self-services: Once successfully authenticated against the company network a second factor often can be changed without enhanced authentication. Self-Services are designed with best user experience and responsiveness in mind, IT security often plays a subordinate role.

From my point of view, exchange of the second factor should always be approved by a line manager or his proxy. This may take a while, but it makes life much harder for an attacker. In addition, the likelihood of detection goes up.

Here is some food for thought: Are your security self-services designed with security in mind?

Have a great week!

References

  1. Jansen W. Abusing cloud services to fly under the radar [Internet]. Fox-IT International blog. 2021 [zitiert 26. Januar 2021]. Verfügbar unter: https://blog.fox-it.com/2021/01/12/abusing-cloud-services-to-fly-under-the-radar/

BSI: Hackerattacke auf Uniklinik Düsseldorf wäre verhinderbar gewesen

16. Januar 2021

Am 11. Januar 2021 berichtete RP Online[i], die „Hackerattacke auf Uniklinik Düsseldorf wäre verhinderbar gewesen“. Laut RP Online sagte der Präsident des BSI auf einen Kongress zur inneren Sicherheit, der Hackerangriff „hätte schon mit dem einfachen Grundschutz des BSI verhindert werden können“. Der Bericht wurde auf LinkedIn am 12.1.2021 geteilt und kommentiert.

Hat das BSI recht? Hätte die Vorgehensweise nach BSI Grundschutz den Angriff verhindert?

Welche Schwachstelle wurde von den Angreifern für den initialen Zugriff genutzt?

Heise Online[ii] berichtet am 22.9.2020, dass vermutlich die Shitrix bezeichnete Schwachstelle CVE-2019-19781 zum Einstieg ins das Netzwerk der Uniklinik verwendet wurde. CVE-2019-19781 ist eine Schwachstelle in den Citrix Produkten Citrix Application Delivery Controller, Citrix Gateway und Citrix SD-WAN WANOP Appliance. Diese Citrix-Produkte werden zur Absicherung des externen Zugriffs auf das private Netzwerk einer Organisation eingesetzt. Sie werden in der Internet-DMZ betrieben und sind in der Regel für alle Internetteilnehmer sichtbar und damit von diesen angreifbar.

Laut Citrix[iii] handelt es sich bei CVE-2019-19781 um eine Remote-Code-Execution-Schwachstelle (RCE). Der Access-Vector[iv] ist CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, die Severity ist 9.8.

Die folgende Tabelle zeigt die zeitliche Entwicklung von der Schwachstelle bis zum Patch.

16.12.2019 Citrix veröffentlicht mitigierende Maßnahmen[v] für CVE-2019-19781, da die Schwachstelle bereits in Angriffen genutzt wurde.
17.12.2019 Citrix veröffentlicht die Schwachstelle[iii].
18.12.2019 Warnung[vi] des BSI, Risikostufe 3.
27.12.2019 Veröffentlichung in der NIST NVD Datenbank[iv].
11.1.2020 Veröffentlichung des ersten Exploit EDB-ID 47901[vii] in der Exploit Datenbank.
13.1.2020 Update Warnung[viii] des BSI, Risikostufe 4.
19.1.2020 Citrix veröffentlich die ersten korrigierten Programmversionen.
24.1.2020 Für alle Programmversionen sind Patches vorhanden.

Citrix berichtet[iii] am 17.12.2019, dass „Exploits of this issue on unmitigated appliances have been observed in the wild. Citrix strongly urges affected customers to immediately upgrade to a fixed build OR apply the provided mitigation which applies equally to Citrix ADC, Citrix Gateway and Citrix SD-WAN WANOP deployments.” Damit handelte es sich bei CVE-2019-19781 um eine Zero-Day-Schwachstelle. Hier ist Eile geboten. Deshalb ist es nicht ungewöhnlich, dass Citrix bereits einen Tag vor der Schwachstelle mitigierende Maßnahmen[v] veröffentlicht hat.

Welche Optionen hat man in derartigen Szenarien?

Option Patchen/Mitigieren

Das Australien Cyber Security Centre (ASCS) macht im Abschnitt System Patching des “Australian Government Information Security Manual”[ix] klare Vorgaben:

Security Control: 1144; Revision: 9; Updated: Sep-18; Applicability: O, P, S, TS; Priority: Must Security vulnerabilities in applications and drivers assessed as extreme risk are patched, updated or mitigated within 48 hours of the security vulnerabilities being identified by vendors, independent third parties, system managers or users.

CVE-2019-19781 hat Severity 9.8, die Ausnutzung der Schwachstelle führt zum vollständigen Verlust der Integrität des Systems. Damit fällt die Schwachstelle in diese Kategorie. Da kein Patch verfügbar war, müssen die von Citrix am 16.12.2020 veröffentlichten mitigierenden Maßnahmen spätestens am 19.12.2019 umgesetzt sein.

Im BSI Grundschutz, Edition 2020[x] vermisst man im Abschnitt OPS.1.1.3: Patch- und Änderungsmanagement diese klaren Hinweise. OPS.1.1.3.A1 gibt folgenden Hinweis: „Patches und Änderungen SOLLTEN nach Wichtigkeit und Dringlichkeit klassifiziert und entsprechend umgesetzt werden.“

Das SOLLTEN ist hier irritierend. SOLLTE bedeutet im Sinne des Grundschutzes, „dass eine Anforderung normalerweise erfüllt werden muss, es aber Gründe geben kann, dies doch nicht zu tun“. Das ist bei CVE-2019-19781 nicht angemessen, da Citrix bereits von “Exploits in the Wild” berichtet hatte. Hier ist ein MÜSSEN im Sinne des Grundschutzes erforderlich.

Folgt man der Einstufung „Risikostufe 3“ in der BSI Warnung von 18.12.2019, so würde man aus meiner Sicht nicht umgehend mitigierende Maßnahmen ergreifen.

Option Firewall mit IPS (virtuelles Patchen)

Nextgen Firewalls mit IPS (Intrusion Prevention System) können gerade bei Zero-Day-Schwachstellen über die Möglichkeit des virtuellen Patchens Cyberangriffe abwehren. Der Firewall entdeckt im Datenstrom Versuche, die Schwachstelle CVE-2019-19781 auszunutzen und blockt diese.

IPS hätte in diesem Fall mit hoher Wahrscheinlichkeit den Angriff nicht verhindert. Checkpoint hat etwa erst am 9.1.2020 ein passendes IPS Muster bereitgestellt, Fortinet am 13.1.2020

Option Application Whitelisting

Die betroffenen Citrix –Systeme können als virtuelle Appliance oder als Anwendung auf einem Linux-System (Bare-Metal) betrieben werden.

Im Fall der Appliance ist Application Whitelisting nicht möglich, da der Betreiber keine Zusatzsoftware installieren kann.

In einer Bare-Metal-Umgebung kann der Systemverantwortliche eine Application Whitelisting-Lösung einsetzen. Da Linux-Server als sicherer wahrgenommen werden als Windows-Server, wird häufig auf zusätzliche Sicherheitslösungen verzichtet.

Application Whitelisting hätte die Übernahme des Citrix Systems in der Bare-Metal-Umgebung mit hoher Wahrscheinlichkeit verhindert, da bei der Übernahme des Systems Code eingeschleust und ausgeführt wird.

Option System von Netzwerk trennen

Liefert der Hersteller weder Patches noch Hinweise auf mitigierende Maßnahmen, so ist die Trennung vom Netzwerk eine mögliche Option. Systemverantwortliche, IT-Manager und IT-Security-Manager sollten diese Option immer vorbereiten und trainieren. Das Risiko aus dem Verlust des Remotezugriffs auf Dienste muss in Relation zu dem Risiko gesetzt werden, das sich durch die Einschränkungen im Betrieb der kritischen Infrastruktur (Universitätsklinik) für die Bevölkerung ergibt.

Wichtig! Systemverantwortliche müssen vorab vom Management autorisiert werden, die Trennung durchzuführen, und dürfen nicht zögern, die Trennung durchzuführen.

Zusammenfassung

Mit Patchen/Mitigieren, Vorgehensweise nach ASCS, hätte die Uniklinik Düsseldorf den Angriff mit hoher Wahrscheinlichkeit verhindern können.

Nach BSI Grundschutz hängt es aus meiner Sicht ausschließlich von der Einschätzung des Systemverantwortlichen ab, ob die mitigierenden Maßnahmen mit der gebotenen Geschwindigkeit umgesetzt werden. Für den Betrieb einer kritischen Infrastruktur ist diese Vorgehensweise zu unverbindlich. Der Angriff hätte aus meiner Sicht durch BSI Grundschutz nicht verhindert werden können.

Die Option System vom Netzwerk trennen hätte den Angriff sicher verhindert.

Firewall IPS hätte den Angriff wahrscheinlich nicht verhindern können, da die Muster zur Exploit-Erkennung zu spät bereitstanden.

Die Option Application Whitelisting hätte den Angriff nur in der Bare-Metal-Umgebung verhindern können.

Haben Sie sich schon mit der Option System vom Netzwerk trennen beschäftigt? Insbesondere in kritischen Infrastrukturen? Über ein Feedback würde ich mich sehr freuen.

Schönes Wochenende.

[i] RP ONLINE. Bundesamt für IT-Sicherheit: Hackerattacke auf Uniklinik Düsseldorf wäre verhinderbar gewesen [Internet]. RP ONLINE. 2021 [zitiert 16. Januar 2021]. Verfügbar unter: https://rp-online.de/nrw/staedte/duesseldorf/uniklinik-duesseldorf-hackerattacke-waere-laut-bsi-verhinderbar-gewesen_aid-55626401

[ii] von Westernhagen O. Uniklinik Düsseldorf: Ransomware „DoppelPaymer“ soll hinter dem Angriff stecken [Internet]. Heise Online Security. 2020 [zitiert 16. Januar 2021]. Verfügbar unter: https://www.heise.de/news/Uniklinik-Duesseldorf-Ransomware-DoppelPaymer-soll-hinter-dem-Angriff-stecken-4908608.html

[iii] Citrix. CVE-2019-19781 – Vulnerability in Citrix Application Delivery Controller, Citrix Gateway, and Citrix SD-WAN WANOP appliance [Internet]. Support Knowledge Center. 2019 [zitiert 16. Januar 2021]. Verfügbar unter: https://support.citrix.com/article/CTX267027

[iv] NIST National Vulnerability Database. NVD – CVE-2019-19781 [Internet]. NATIONAL VULNERABILITY DATABASE. 2020 [zitiert 16. Januar 2021]. Verfügbar unter: https://nvd.nist.gov/vuln/detail/CVE-2019-19781

[v] Citrix. Mitigation Steps for CVE-2019-19781 [Internet]. Support Knowledge Center. 2019 [zitiert 16. Januar 2021]. Verfügbar unter: https://support.citrix.com/article/CTX267679

[vi] Bundesamt für Sicherheit in der Informationstechnik. BSI – CERT Bund -Meldungen – CB-K19/1093 [Internet]. Service. 2019 [zitiert 16. Januar 2021]. Verfügbar unter: https://www.bsi.bund.de/SharedDocs/Warnmeldungen/DE/CB/2019/12/warnmeldung_cb-k19-1093.html

[vii] Project Zero India. Citrix Application Delivery Controller and Citrix Gateway – Remote Code Execution (PoC) [Internet]. Exploit Database. 2020 [zitiert 16. Januar 2021]. Verfügbar unter: https://www.exploit-db.com/exploits/47901

[viii] Bundesamt für Sicherheit in der Informationstechnik. BSI – CERT Bund -Meldungen – CB-K19/1093 Update 2 [Internet]. 2020 [zitiert 16. Januar 2021]. Verfügbar unter: https://www.bsi.bund.de/SharedDocs/Warnmeldungen/DE/CB/2020/01/warnmeldung_cb-k19-1093_update_2.html

[ix] Australian Cyber Security Centre. Australian Government Information Security Manual [Internet]. 2019 [zitiert 16. Januar 2021]. Verfügbar unter: https://www.cyber.gov.au/sites/default/files/2019-04/Australian%20Government%20Information%20Security%20Manual%20(APR19)_0.pdf

[x] Bundesamt für Sicherheit in der Informationstechnik. IT-Grundschutz-Kompendium [Internet]. Reguvis Fachmedien GmbH; 2020 [zitiert 16. Januar 2021]. Verfügbar unter: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium/IT_Grundschutz_Kompendium_Edition2020.pdf