Author Archives: Klaus Jochem

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

Your Ransomware Strategy 2021: Prevention or Bow to the Inevitable?

1 January 2021

This morning I read the transcript of the Threatpost webinar ” What’s Next for Ransomware”.[1] Becky Bracken hosted the webinar some weeks ago, panelists were Limor Kessem (IBM Security), Allie Mellen (Cyberreason) and Austin Merritt (Digital Shadows). The discussion focused on incident response:

“While IT departments will undoubtedly lead efforts to shore up defenses against attacks, including backups, patching, updating and employee-awareness training, our panel of experts agree that preparing a critical-response plan which includes the entire organization — from the executives on down the org chart — is the best way to minimize cost, damage and downtime.”

Having a well-crafted and trained incident response plan in place is, from my point of view, an indispensable means to recover from all kind of cyber-attacks. But is it “the best way to minimize cost, damage and downtime” in the case of Ransomware?

Response plans come into play when a ransomware attack is detected. But during the time until detection, the ransomware may cause damage to the network and the data. Once detected, incident response kicks in by taking appropriate actions to

  • containing the attack,
  • investigating the network for yet undetected instances of the ransomware,
  • repairing the already done damage, etc.

This is close to Gartner’s[2] approach to defend ransomware, so industry standard. But is this reactive approach the best way to minimize the economic impact of an attack?

The Cyber Security and Infrastructure Security Agency (CISA) describes in its Ransomware Guide[3] a more preventive approach. Backup, patching, cyber-hygiene, awareness training and cyber incident response plan are the building blocks. In addition, CISA recommends to “Use application directory allowlisting on all assets to ensure that only authorized software can run, and all unauthorized software is blocked from executing”.[3] This is a clear step towards prevention of attacks. Since ransomware comes from external sources e.g., through internet, e-mail, usb-devices, it commonly is not part of the allow-list, thus blocked.

The Department of Homeland Security (DHS) goes one step further in its 2016 published paper “Seven Strategies to Defende ICS”.[4] The first strategy is “Implement Application Whitelisting” because it “can detect and prevent attempted execution of malware uploaded by adversaries”.

Finally, the Australian Cyber Security Centre (ACSC) recommends Application Whitelisting as Number One of Essential Eight[5][6] strategies to prevent malware delivery and execution.

Neither Gartner nor the experts in the Threatpost webinar mentioned preventive controls to deal with ransomware. DHS and ACSC recommend them as central part of a cyber-security strategy.

From my point of view, application whitelisting is a must have to minimize the economic impact of an attack. If execution of malware is prevented, the costs to cleanup and recover from a ransomware attack are minimized.

The baseline security costs are for certain increased because application whitelisting solutions must be managed like any other application. This holds even if the Windows built-in tools AppLocker or Software Restriction Policies are used. But this will be balanced by the fact that application whitelisting will prevent also zero-day malware or PUA from execution.

CISA and ACSC provide useful hints on dealing with ransomware without big invest in new tools. It makes sense to take them into account when revising your security roadmap for 2021.

Happy New Year!

And have a great weekend.


[1] Bracken B. What’s Next for Ransomware in 2021? [Internet]. threatpost. 2020 [zitiert 1. Januar 2021]. Verfügbar unter: https://threatpost.com/ransomware-getting-ahead-inevitable-attack/162655/

[2] Sakpal M, Webber P. 6 Ways to Defend Against a Ransomware Attack [Internet]. Smarter with Gartner. 2020 [zitiert 1. Januar 2021]. Verfügbar unter: https://www.gartner.com/smarterwithgartner/6-ways-to-defend-against-a-ransomware-attack/

[3] Cyber Security and Infrastructure Security Agency. Ransomware Guide [Internet]. CISA 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] U.S. Department of Homeland Security. Seven Strategies to Defend ICSs [Internet]. DoD’s Environmental Research Programs. 2016 [zitiert 13. Oktober 2020]. Verfügbar unter: https://www.serdp-estcp.org/serdp-estcp/Tools-and-Training/Installation-Energy-and-Water/Cybersecurity/Resources-Tools-and-Publications/Resources-and-Tools-Files/DHS-ICS-CERT-FBI-and-NSA-Seven-Steps-to-Effectively-Defend-Industrial-Control-Systems

[5] Australian Cyber Security Center. Strategies to Mitigate Cyber Security Incidents [Internet]. 2017 [zitiert 1. Dezember 2020]. Verfügbar unter: https://www.cyber.gov.au/acsc/view-all-content/publications/strategies-mitigate-cyber-security-incidents

[6] Australian Cyber Security Center. Essential Eight Explained [Internet]. [zitiert 1. Dezember 2020]. Verfügbar unter: https://www.cyber.gov.au/acsc/view-all-content/publications/essential-eight-explained

The Eternal Battle over Active Directory between OT and IT

29 October 2020

On October 13th I moderated the anapur Virtual Dialog “Network Monitoring and Anomaly Detection”. During the breaks, some participants from industry talked about a really concerning issue: IT, IT-Security and GRC groups in their companies urge them to integrate their so far isolated production active directories in the corporate directory.

I have been involved in these discussion for 10 years and I never changed my answer:

Don’t do it!

This integration is dangerous. Active Directory simplifies lateral movement once an attacker created a foothold in your network. And it simplifies the distribution of malware through login scripts. Remind the Norsk Hydro attack from March 2019: Divisions with high vertical integration were more affected from LockerGoga than the Alumina production.

In their paper “Seven Strategies to Defend ICSs” from December 2016, DHS ICS-CERT, FBI and NSA provide a very clear active directory strategy:

Never share Active Directory, RSA ACE servers, or other trust stores between corporate and control networks.

For details see chapter 5, “Manage Authentication”.

Hope this helps in discussions with IT, IT-Security and GRC.


In his poem Ulysses, Alfred Tennyson brings it to the point:

Tho‘ much is taken, much abides;
and though we are not now that strength
which in old days moved earth and heaven;
that which we are, we are;
one equal temper of heroic hearts,
made weak by time and fate,
but strong in will to strive, to seek, to find.
And not to yield.

The Boothole Vulnerability – Need to Panic?

23 August 2020

CVE-2020-10173 (aka BootHole(1)) got much attention in the media in the past weeks  because this flaw in GRUB 2 may be used to tamper the boot process. But the worst is yet to come. “This flaw also allows the bypass of Secure Boot protections.”(2)

From the description in the NIST NVD we learn: “In order to load an untrusted or modified kernel, an attacker would first need to establish access to the system such as gaining [a] physical access, [b] obtain the ability to alter a pxe-boot network, or have [c] remote access to a networked system with root access.”(2)

Options [b] and [c] do not really matter. Once an attacker gets the opportunity to modify the network boot capabilities of your system, or has root access to your system, the game is over. In this case, exploiting BootHole is rather counterproductive because the probability of detection goes up.

Fedora32 EFI Partion

Fedora EFI Partition

But BootHole becomes a serious issue if an attacker gets physical access (option [a]) to an unpatched system. These so-called Evil Maid attacks work even on secured Linux systems because the EFI (FAT) partition is easy to modify after the computer is booted from a Linux Live System.

In the case, you followed the industry best practices and secured the BIOS of your computer with a password, the attacker must extract the hard disk and run the change on another system. This is not uncommon when it comes to espionage, terrorism, or sabotage.

But the group of persons in focus of such activities is already vulnerable against Evil Maid attacks. So, the additional risk that stems from BootHole is neglectable. No need to panic!

Nevertheless, install the patch as soon as possible. And secure the BIOS of your computer with a password.

Dell Vostro Laptop with Fedora32/EFI

Dell Vostro Laptop with Fedora Linux/EFI

But the best advice is: Don’t leave your devices unattended. Even the hotel safe is no safe place.

My preferred solution to Evil Maid attacks, the lightweight version, is Fedora Linux on a micro SD-Card.

Have a great week.


References

  1. Eclypsium. There’s a Hole in the Boot [Internet]. Eclypsium. 2020 [cited 2020 Aug 18]. Available from: https://eclypsium.com/wp-content/uploads/2020/08/Theres-a-Hole-in-the-Boot.pdf
  2. NIST Information Technology Laboratory. NVD – CVE-2020-10713 [Internet]. NATIONAL VULNERABILITY DATABASE. 2020 [cited 2020 Aug 23]. Available from: https://nvd.nist.gov/vuln/detail/CVE-2020-10713

CIS Password Policy Guide – A Quantum Leap in User Experience and Security

8 August 2020

The Password Policy Guide(1) published by the Center for Internet Security (CIS) on 29 July 2020 drowned in the omnipresent noise of vulnerabilities and data breaches.

Wrongly, because the CIS guide puts an end to the commonly accepted practice of complex passwords, namely those that are easy to crack but hard to remember.

The guide recommends:

  • The use of passphrases because users will select longer, more-secure passwords.
  • Event-based password expiration with an annual change as a backstop.
  • And the use of password managers.

Especially for password managers the guide recommends:

Use of these should be actively encouraged for use with password-only authentication systems (especially if the user needs to manage access to multiple of these systems)”

And, where “feasible, using MFA instead of just a master password to gain access to the Password Manager is preferred”

Yubikey for MFA and KeePassXC

For some months now I mainly work on a Linux desktop. Unfortunately, I often must switch to Windows because of Word and Powerpoint. So, I use KeePassXC to allow easy switching between the operating systems.

My cloud account is secured with Yubikey, and so is my KeePassXC database. Works fine on Windows and Linux.

To boost user experience and password security, please give the CIS Password Policy Guide the attention it deserves.

Have a great weekend.


References

  1. White Paper: CIS Password Policy Guide [Internet]. Center for Internet Security. [cited 2020 Aug 8]. Available from: https://www.cisecurity.org/white-papers/cis-password-policy-guide/.

The most important questions to ask in a firewall rule assessment

25 June 2020

Regular firewall rule assessments are basic IT/OT security housekeeping procedures. Security staff challenges every rule after well-known industry best practice like ANY Computer or ANY Port rules, bi-directional rules, use of unsecure protocols like ftp, telnet, smb, not used rules, etc.

Nervennahrung for firewall assessment. Own work.

Picture 1: Nervennahrung for firewall rule assessments

Compliance to industry best practice can be achieved with a plain checklist. Thus the check can be automated to a far extent. The nerve-racking work starts afterwards, when each finding is discussed with the users.

But, in general, the security staff does not challenge the rule itself. Or it’s direction. Or the ports used.

These questions are asked after the rule has passed the best practice checks. No automation possible. They require in-depth knowledge of the services accessed through the firewall, and, they belong to the nerve-racking category. But it’s worth to ask these questions because

The best firewall rule is the one that not exists.

You must not care of such rules in the case of a security incident, no regular review required, no discussion with users. Entrepreneurs should be interested in cleaning up the rule base because it saves costs, and increases security.

More about this in the next post.


Picture credits

Picture 1: Vienna 2020. Own work