Tag Archives: VMWare

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.

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

Is Micro-Segmentation the new universal remedy?

28 May 2015

On Saturday, I blogged about globally defined service accounts and their impact on the attack surface. In my opinion, rigorous avoidance of globally defined service accounts, combined with the concept of trusted administration zones, is an effective means to boost IT security.

In the past month I was involved in discussions about a network segmentation, which is a common means to increase IT security. The relatively new and less spread micro-segmentation technology is hailed as universal remedy.

Let me quote briefly from the VMWare white paper ‘Data Center Micro-Segmentation, A Software Defined Data Center Approach for a ”Zero Trust” Security Strategy’:

“Micro-segmentation of the data center network can be a huge help to limit that unauthorized lateral movement”

That’s true, but if you use globally defined service accounts for administration of the systems in segmented networks, the ‘huge help’ will be considerably lower. This is because e.g. the Active Directory services are working on network layers where segmentation has no impact.

The old rule still applies: Isolated security measures do not necessarily increase the overall security level.

But the combination of network segmentation with strict avoidance of globally defined service accounts and trusted administration zones will make the difference.

Have a good day!