Microsoft: ransomware wordt verspreid via gerepareerde bug in ESXi-hypervisor

Microsoft waarschuwt dat een kwetsbaarheid in de ESXi-hypervisor wordt misbruikt om ransomware te verspreiden. Met de bug is het mogelijk om volledige adminrechten te krijgen op ESXi-vm's. VMware-eigenaar Broadcom heeft inmiddels een patch voor de bug uitgebracht.

Microsoft beschrijft de kwetsbaarheid in een blogpost. Die draait om de ESXi-hypervisor, een baremetalhypervisor die onderdeel is van VMwares vSphere. De kwetsbaarheid, CVE-2024-37085, maakt het mogelijk om volledige adminrechten te krijgen op een hypervisor door alleen een Active Directory-groep aan te maken die ESX Admins heet. Dat werkt ook als een aanvaller de rechten nog niet heeft.

De bug werd al in juni van dit jaar gerepareerd, nadat Microsoft die eerder ontdekte en via een responsibledisclosureprocedure aan VMware-eigenaar Broadcom doorgaf. Dat bedrijf bracht op 25 juni patch ESXi 8.0 Update 3 uit en beschreef een mitigatiemethode. Toch zegt Microsoft dat de kwetsbaarheid nu actief wordt misbruikt voor het verspreiden van ransomware.

Microsoft heeft het over 'talrijke aanvallen'. Die worden uitgevoerd door meerdere ransomwaregroeperingen. Microsoft noemt in ieder geval Storm-0506, Storm-1175, Octo Tempest en Manatee Tempest als voorbeeld. Dat zijn geen landgerelateerde groepen, maar wel bekende bendes achter grote ransomware. Microsoft zegt dat die groepen ransomware als Akira en Black Basta verspreiden, maar ook LockBit. In het algemeen zegt Microsoft dat ransomwarebendes op steeds grotere schaal virtuele machines aanvallen.

Reacties (52)

[Wildfire]

Meer dan een maand later en nog steeds zijn er dus bedrijven die hun updatebeleid niet op orde hebben... zeker met bugs waarvan de kans op misbruik hoog is moet er echt gepatched worden om misbruik te voorkomen.

Ja, ik weet dat bedrijven niet zomaar willen updaten i.v.m. kans op andere problemen maar zeker voor zoiets als dit moet er binnen een maand toch echt wel iets te regelen zijn...

[jeffreytigch]

Een paar reacties verderop wordt aangegeven dat Veeam (nog) niet werkt met de meest recente update. Dat lijkt mij een valide reden om nog niet te updaten.

Een gemiste update is niet (direct) een kwetsbaarheid.

[Wildfire]

Zonder te patchen is er ook een mitigatie beschikbaar, lijkt me dan toch ook wel te kunnen? Helemaal niets doen lijkt me geen optie in dit soort situaties.

Ik ben benieuwd of er n.a.v. dit bericht er nu links en rechts wel acties ondernomen gaan worden.

[Reactie gewijzigd door Wildfire op 1 augustus 2024 09:35]

[Blokker_1999]

En zo zijn er wel meer combinaties die nog altijd niet zijn gecertificeerd. Wij kunnen ook niet verder op onze Nutanix clusters bijvoorbeeld.

[Wafeltje]

De update is alleen uit in de 8.x branche, terwijl de bug ook in 7.x zit. Even updaten is dus niet altijd een optie. @S-1-5-7 geeft aan dat Veeam nog niet compatible is met 8.zoveel, dus kun je geen backups maken.

Voor 7.x moet je dus de workaround implementeren, mits je ook voldoet aan de andere voorwaarden (voor de bug) die hierboven genoemd worden.

[S-1-5-7]

Zover ik begrijp moet het voor de aanvaller mogelijk zijn om groepen in de AD aan te maken om deze kwetsbaarheid uit te buiten. Als een aanvaller dit kan heb je meer problemen dat alleen een kwetsbaarheid in ESXi.

Daarnaast is Veeam nog niet compatible met versie 8.0 U3. De Veeam gebruikers moeten de kwetsbaarheid mitigeren door bepaalde instellingen aan te passen in de config.

[tvtech]

ik draai al wel de Vcenter 8.0.3 icm Veeam 12.1.2.172 en dat werkt wel gewoon. Kreeg na de update wel een warning overigens

[S-1-5-7]

Hoe weet je dat alles 'gewoon' werkt? Vertrouw je hierbij volledig op de melding dat je back-up succesvol is gemaakt of heb je bijvoorbeeld ook gecontrolleerd of het herstellen van een back-up werkt? Daarnaast zijn er nog een tal van andere functionaliteiten die mogelijk niet (goed) kunnen functioneren.

Er zal wel een goede rede zijn dat Veeam de versie nog niet ondersteunt welke nota bene al op 25 juni is uitgekomen. Wellicht werken er zaken niet of zijn niet alle testen succesvol afgerond. Ik zou zelf nooit op goed geluk dit type update installeren terwijl die niet officieel wordt ondersteund.

[tvtech]

Nee, dat heb ik nog niet gecontroleerd, goed punt.
Het lastige van dit soort updates is dat ze allemaal als critical worden omschreven en ik niet altijd tijd heb om allerlei afhankelijkheden te controleren. Wat uiteraard wel zou moeten. Je moet altijd weer een afweging maken of het nodig is. Bij deze update van Vcenter heb ik dat niet gedaan, ik had niet gerealiseerd dat het een nieuwe versie is tov een patch.

Overigens zitten de esxi hosts gelukkig niet in onze ad. De vorige hosts, geïnstalleerd door een leverancier waar we gelukkig geen zaken meer mee doen, zaten dat wel. En we hadden 2 virtuele dc’s. Toen de hele boel een keer uit moest vanwege werkzaamheden aan de stroomvoorziening hadden we toch een aardig probleem want ook de vm’s waren niet opgezet met auto power on. Dus geen inlog op de hosts mogelijk. Pas na ongev een half uurtje konden we nog met een lokale inlog er weer in.

[LigeTRy]

Ook moet de ESX Machine domain joined zijn, iets wat sowieso niet aangeraden wordt.

[nelizmastr]

Ik ken niemand die een ESXi machine in het domein hangt, vCenter daarentegen…. en dat is net zo gevaarlijk.

Met de huidige prijzen en koers van Broadcom leveren we geen Vmware meer in nieuwe deployments. Ze bekijken het daar maar

[d3x]

niemand met AD, je hebt dan ook geen kennis in je groep die wat 100en aantallen ESXI servers heeft? allemaal lekker met local accounts zonder enige controle wie wat doet en wanneer? dacht het niet
ja de basis deploys staan overal, zijn dan ook de eerste waar al die CVE steeds allemaal van toepassing zijn met alle open deuren en massa rechten....

[smartsys]

Je gebruikt dan toch een separaat beheer domein en niet je domein waar al je eindgebruikers inzitten?

Ik denk dat VMware met de relatief lage risico index een eerlijke inschatting maakt.

Kleine niet-domein joined en netwerk technisch gesegmenteerde omgevingen lopen geen risico op misbruik van dit issue.

[Blokker_1999]

Tsjah, en bij ons daalt de licentiekost net voor Vmware. You win some, you lose some.

En ik geloof dat de ondersteuning voor domain join ging verdwijnen.

[nelizmastr]

Bij ons en klanten waar wij aan resellen zijn er gevallen van een verhogingsfactor van 3x en dat blijkt ook niet ongewoon. In jullie geval snap ik dan dat je niet naar andere opties kijkt, 't blijft wel een van mijn favoriete hypervisors, maar ja, met 3x de prijs kun je het niet meer verkopen.

En natuurlijk goed als het klopt dat domain join eruit gaat. Dat is al op vele platformen gebleken qua security de zwakste schakel te zijn.

[Mellow Jack]

Dat had je toch wel aan zien komen? Het begon al jaren geleden met het aanbieden van iets als VCF. Toentertijd werd door VMware al aangegeven dat de komende jaren licentie aanpassingen zouden komen die vooral impact heeft op kleinere partijen.

[killah]

Meeste klanten die ik ken doen juist een domainnjoin om named account gebruiken en is.de locale root account achter slot en grendel om toch een juiste logging te hebben wie wat doet ivm splunk of een ander logging pakket.

[downtime]

Zover ik begrijp moet het voor de aanvaller mogelijk zijn om groepen in de AD aan te maken om deze kwetsbaarheid uit te buiten. Als een aanvaller dit kan heb je meer problemen dat alleen een kwetsbaarheid in ESXi.

Staar je niet blind op alleen externe aanvallers. Een aanval kan ook van binnenuit komen van iemand die wel groepen in AD kan aanmaken maar geen rechten in ESXi mag hebben.

[d3x]

malicious insider is sowieso altijd een probleem.... wat je ook mogen doen. daar kan je alleen tegenop om vele infra delen te splitsen kwa echte mensen met specifieke rechten en rules

[JasperE]

En de gebruiker moet toegang hebben tot het IP adres van de ESX server die in een afgeschermd management-vlan zou moeten zitten wmb

[TheOnlyDino]

Hier wil ik toch een op reageren.
Het is geen kwetsbaarheid, maar een design fout van VMWare van jaren terug.
Voor het aanmaken van de groep heb je toch ook rechten nodig op de Active Directory.
Je moet namelijk een groep kunnen aanmaken en daar accounts aan toe kunnen voegen.
Als een hacker al toegang heeft tot je Active Directory en de (Domain Admin/Account Operator) rechten heeft verkregen, heb je toch ook een ander probleem.
Dan kan een hacker al je Domain Joined windows server overnemen en er mee doen wat ze willen.

De oplossing is al bekend bij ervaren VMWare beheerder.

[Rolfie]

Veel bedrijven hebben echter specifieke rechten gegeven aan bijvoorbeeld om groepen aan te maken. Bijvoorbeeld door de servicedesk, je hoeft dus niet een hacker te zijn.

[Qwerty-273]

Of nog beter, de meeste bedrijven hebben in hun self service pakket vast ook een optie waar een eindgebruiker een groep kan aanvragen met een automagische workflow er achter. Zolang daar de naam vrij ingegeven kan worden, en je niet aan een stugge naming convention vast zit, dan kan elke eind gebruiker zo een ESX Admins groep aanmaken.

Dan heb je als aanvaller genoeg aan elke gephishde credentials.

[S-1-5-7]

Dat het 'by design' is maakt het niet dat het geen kwetsbaarheid is...

[Slavy]

Een kwetsbaarheid is per definitie niet een bug.

[blorf]

Een bug kan onbedoeld een deur openzetten. Dat lijkt mij een kwetsbaarheid, maar in dit geval speelt de manke Windows permissie-hierarchie een rol. In principe kun je alle kwetsbaarheden als designfout zien.

[Mellow Jack]

Een design fout is naar mijn mening iets wat onbedoelde consequenties heeft. Een kwetsbaarheid is breder. tijdens een ontwikkel traject kan je bewust kwetsbaarheden accepteren. Misschien omdat het risico op misbruik laag is, misschien omdat het teveel geld/tijd kost etc

In dit geval kan je bijv. stellen dat het mogelijk is dat ze dit zo hebben gelaten omdat een klant netwerk segmentatie moet toepassen en gebruik moet maken van een PAM oplossing. Niet dat dit daadwerkelijk zo is maar ik kan me er iets bij voorstellen

[JasperE]

Dan ga je voorbij aan het feit dat een nieuw aangemaakte niet eerder bestaande groepsentity in AD automatisch rechten toegewezen krijgt in ESX . Ongeacht de SID van die groep. Het manke aspect zit wat mij betreft in die laatste twee punten en niet bij Microsoft

[Jerie]

Andersom: een kwetsbaarheid is altijd een bug, maar een bug is niet per definitie een kwetsbaarheid. Een bug kan bekend zijn bij de maker of niet. Een kwetsbaarheid idem. Een bug en/of kwetsbaarheid kan met opzet zijn; dan noemen we het (in geval van kwetsbaarheid) een backdoor.

Indien deze bug bekend was bij VMware/Broadcom dan had men dit zsm. moeten oplossen.

[Roy23]

Je hoeft geen administrator te zijn om een groep te maken in een active directory. Met de "create group object" permissie heb je al voldoende rechten om een groep genaamd "ESX Admins" aan te maken.

[Zackito]

Zonder directe AD koppeling lijkt me dit waardeloos toch? Moet je sowieso niet willen ivm beveiliging.

[Reactie gewijzigd door Zackito op 1 augustus 2024 15:07]

[nullbyte]

Hier wil ik toch een op reageren.
Het is geen kwetsbaarheid, maar een design fout van VMWare van jaren terug.

Het is wel een kwetsbaarheid, daar is het CVE nummer van CVE-2024-37085. Dit is een feit, geen mening.

Het NCSC heeft ook een advisory voor deze kwetsbaarheid.
https://advisories.ncsc.nl/advisory?id=NCSC-2024-0269

[Reactie gewijzigd door nullbyte op 2 augustus 2024 09:27]

[smartsys]

Ik denk niet eens dat het een design fout is. Het is een "feature", welke dus gewoon uit te schakelen is die het werk van beheerders makkelijker maakt.

[Flappie]

Dit werkt alleen als de ESXi hypervisor ook in Active Directory hangt.
Vraag mij af hoeveel dat gebruikt wordt.

Meeste organisaties zullen hun vCenter eventueel aan AD gekoppeld hebben.

[Reactie gewijzigd door Flappie op 1 augustus 2024 09:26]

[RobbieB]

in ieder geval nog vaak genoeg om er voor te zorgen dat Microsoft nu zelf aan de bel trekt.

[Marve79]

Dat hoor ik wel vaker bij bedrijven als er een security patch uitkomt die downtime met zich meebrengt. Ja dat geldt voor ons niet want dan moet je dit of dat hebben en dat is bij ons niet dus we hoeven niet te patchen. En dan een week later wordt de CVE geupdatet en dan blijkt er toch ineens wat meer aan de hand.

Dus het devies is gewoon patchen en niet steeds redenen zoeken om het niet te hoeven doen.

[TheGabeMan]

Mwah zo makkelijk is t niet altijd. Nu moet ik zeggen bij VMware security patches is het vaak wel relatief safe. Maar wij hebben inmiddels toch een 8-tal andere systemen die eerst met die versie gecheckt moeten worden in het lab om te kijken of alles nog werkt zoals gehoopt.

[Bor]

Vmware kent helaas ook kritieke lekken. Van "vaak wel relatief safe" is geen toepassing helaas, zeker niet wanneer je uitgaat van een zero trust architectuur. Het komt helaas ook voor dat CVE's achteraf worden update met meer info over het lek waarbij er toch meer aan de hand blijkt zoals @Marve79 aangeeft. Dat zie je met enige regelmaat bij vrijwel alle producenten.

[TheGabeMan]

Ik bedoelde met "relatief safe", dat het patchen van build x naar build y, binnen dezelfde major versie (upd 1, upd 2) zelden issues geeft naar randproducten.

[wica]

Dus iemand heeft ooit zoiets in ESX geschreven en is door verschillende controles heen gekomen.

if member in "ESX Admins":
you_are_root

Sorry dat ik het zeg, maar dit soort "bugs" mogen toch echt niet meer voorkomen in 2024 en vind dat de eigenaar van vmware, toch met een goede verklaring mag komen.
En vooral een uitleg, hoe ze gaan voorkomen, dat dit soort bugs nog voorkomen.

[Noppie1991]

Dit is een ontwerpkeuze geweest en 1 die niet per definitie verkeerd is. Alleen systeembeheerders zouden immers groepen aan mogen maken in het AD. Dat hier omheen wordt gescript door IT waarbij er makkelijk een groep kan worden aangemaakt door een gebruiker is veel kwalijker en kan naar mijn inziens VMware weinig aan doen.

[Th3SkullR34p3r]

Jammer genoeg ondanks de vele vulnerabilities, zijn er nog veel bedrijven dat geen best practices volgen en de hypervisors niet isoleren van de rest van het netwerk om dit soort aanvallen te beperken. Sterker nog, in deze tijd vind je nog altijd veel vSphere appliances en ESXi appliances publiek bereikbaar.

[Bor]

De mitigatie methode / work around is gelukkig simpel en snel te implementeren voor degene die nog niet heeft gepatched zo te zien. Een reboot is niet eens nodig

Patchen is natuurlijk altijd de enige echt goede oplossing maar een mitigerende maatregel kan wellicht wat tijd kopen.

To workaround the issue, change the following ESXi advanced options:

• Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd from true to false
• Config.HostAgent.plugins.vimsvc.authValidateInterval from 1440 to 90
• Config.HostAgent.plugins.hostsvc.esxAdminsGroup from "ESX Admins" to ""

Note: The ESX Admins group will be added to the host with Admin privileges once the host is added to Active Directory. It is recommended to change these settings after joining the domain. These settings take effect within a minute, and no reboot is required.

[rvdvalk]

Waarom wordt er nergens in jullie artikel genoemd dat het om domain joined hosts gaat?

[Bor]

Er zijn inmiddels ook Microsoft XDR detecties zo te lezen:

Microsoft Defender XDR detections

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alerts can indicate associated threat activity:

• Suspicious modifications to ESX Admins group

The following alerts might also indicate threat activity related to this threat. Note, however, that these alerts can be also triggered by unrelated threat activity.

• New group added suspiciously
• Suspicious Windows account manipulation
• Compromised account conducting hands-on-keyboard attack

Microsoft Defender for Identity

The following Microsoft Defender for Identity alerts can indicate associated threat activity:

• Suspicious creation of ESX group

[Dennisb1]

Sinds wanneer zou je überhaupt een ESXi host direct koppelen aan het AD?

[Bor]

Wanneer je gebruik wilt maken van AD gebaseerde authenticatie rechtstreeks vanuit ESXi. Daar zijn absoluut use cases voor hoewel je het niet heel vaak tegenkomt.

[Dennisb1]

Naar mijn inziens regel je dit ten alle tijde vanuit vCenter, maakt het beheer ook zoveel eenvoudiger.

Als je maar 1 host hebt kan ik mij daar nog iets bij voorstellen wellicht.

[Bor]

Niet elke deployment gebruikt vCenter en ook dan kan je kiezen voor AD gebaseerde authenticatie zodat je geen lokale accounts hoeft te managen.

[TheGabeMan]

Back in the old days vonden we dat handig. Toen was ook vCenter nog op Windows. Versie 4.x

[d3x]

als je een handvol mensen hebt die overal wat rechten hebben en die op zowat alles van infrastructuur her en der bezig zijn met een server rakje niet.

maar probeer eens wat verder te denken dan je neus lang is aub...