VMware waarschuwt: schakel OpenSLP op ESXi-servers uit tegen ransomware

VMware adviseert beheerders van virtuele machines om OpenSLP uit te schakelen op ESXi-servers. Via die feature wordt de afgelopen tijd ransomware verspreid. Dat gebeurt via een oude kwetsbaarheid waar al wel een patch voor is.

VMware waarschuwt in een advisoryblog dat beheerders van VMware-machines OpenSLP moeten uitzetten op ESXi-machines. Ook moeten gebruikers hun vSphere-componenten bijwerken naar recente versies, zegt het bedrijf.

Met het advies reageert het bedrijf op de ESXiArgs-ransomware, die de laatste weken de ronde doet. Beveiligingsbedrijven en -instanties, zoals in Nederland het Nationaal Cyber Security Centrum, waarschuwen voor die ransomware. Criminelen proberen ESXi-machines te infecteren met ransomware die ESXiArg wordt genoemd. Ze gebruiken daarvoor een kwetsbaarheid in OpenSLP, de Service Location Protocol-library die in de vSphere Client op ESXi-machines is geïnstalleerd. Daarin zit een kwetsbaarheid, CVE-2021-21972, waarmee het mogelijk is een remote code execution uit te voeren. Als gebruikers toegang kunnen krijgen tot een machine die via https-poort 443 benaderbaar is, kunnen ze de machine met ransomware infecteren.

VMware benadrukt dat de ESXiArg-ransomware niet gebruikmaakt van een moderne kwetsbaarheid zoals een zeroday, maar van een kwetsbaarheid waar ook al een patch voor bestaat. De slachtoffers zijn meestal beheerders die die patch nog niet hebben geïnstalleerd, hoewel die al in februari van 2021 is uitgekomen. "De meeste rapportages laten zien dat voornamelijk producten getroffen worden die de end of general support-status hebben bereikt", schrijft Vmware. Beheerders die om wat voor reden dan ook niet kunnen upgraden, kunnen ook een workaround volgen om niet kwetsbaar te zijn. Sinds 2021 staat de kwetsbare dienst bij ESXi-servers niet meer standaard aan.

Reacties (61)

Uitzetten:

1 Login to the ESXi hosts using an SSH session (such as putty)

2 Stop the SLP service on the ESXi host with this command:
/etc/init.d/slpd stop


Note: The SLP service can only be stopped when the service is not in use. Use the following command to view the operational state of Service Location Protocol Daemon:
esxcli system slp stats get


3 Run the following command to disable the SLP service:
esxcli network firewall ruleset set -r CIMSLP -e 0

To make this change persist across reboots:

chkconfig slpd off

To check if the change is applied across reboots:

chkconfig --list | grep slpd
output: slpd off

Kan ook simpel via de gui zie ik.

Via de GUI kan alleen op nieuwere versies. Wij hebben een server op ESXI 7.0 waar dit werkt. Echter op onze 6.5 en 6.7 servers moeten we dit met SSH uitschakelen.

Op onze 6.7 Build 17167734 komt de service wel in de lijst voor in de GUI. De 14320388 en lager ontberen deze.

Tijd om te upgraden naar 7 of misschien 8. Lijkt me niet verstandig om verder te draaien op 6.7 of zelfs 6.5 gezien de verlopen support.

Soms kun je niet door hw limitaties. Denk aan oudere storage. Even updaten is er dan vanuit de organisatie niet bij. Dan is het alleen een kostenpost.

Als dat zo is dan is waarschijnlijk je lifecycle management niet op orde of je directie zit op de centen.

Klopt. Ik heb het meermaals bij klanten gezien. Mkb tot zo'n 80 man is de financiele kant van it relatief hoog tot de business met allerlei security issues van dien.

Laten wij nou net in die MKB sector opereren. Er zit echt wel geld in het MKB, en genoeg bedrijven die gewoon willen investeren in IT. Er zijn er inderdaad bij die dat niet doen maar die nemen vaak ICT al niet serieus en zou het bijzonder zijn dat ze ons al inhuren.

In de klanten kring waar ik kom is er nog maar 1 klant die op 6.7 draait maar een upgrade staat gepland.

dan wordt je gehacked en zit je met een nóg hogere kostenpost. upgrade was dan goedkoper geweest.

Je kan ook de patch uit 2021 installeren

Deze methode werkt perfect! +3

Dit is de workaround voor het disablen van SLPD:
https://kb.vmware.com/s/article/76372

Met PowerCli kan je ook connecten met vCenter en dan dit draaien:
Get-VMHost | Get-VMHostService | Where key -EQ slpd | Where running -EQ true | Stop-VMHostService -Confirm:$False

En de services op manually zetten:
Get-VMhost | Get-vmhostservice | where-object {$_.key -eq "slpd"} | set-vmhostservice -policy "Off"

Mocht je een hele oude build hebben en dus niet via powercli slpd vinden en dus niet kunnen disablen dan kan je met posh-ssh en powercli een script maken om het te disablen op de hosts. Ik heb een script gemaakt mocht je die willen stuur even een pm.

[Reactie gewijzigd door Ben1988 op 7 februari 2023 16:32]

Ik draai een proxy vm op esxi. DIE is uiteraard via 443 berijkbaar. Ik neem aan dat niet het zelfde is? de ESXI omgeving zelf is niet via wan te bereiken uiteraard.

Als ik de eerste de beste proof of concept zo lees: https://github.com/horizo.../master/CVE-2021-21972.py dan denk ik van wel. Je kunt beter de updates van vorig jaar installeren of de vermelde workarounds uitvoeren, maar eventueel zou je ook het kwetsbare pad kunnen dichtgooien in je reverse proxy.

Voor zover ik kan zien lijkt het erop dat je gewoon een bestand kan uploaden, dat zonder enige path sanitisation wordt uitgepakt, en daarmee uitvoerbare bestanden op de server plaatst. Dit is geen buffer overflow of iets dergelijks waar een reverse proxy tegen gaat werken.

Die code probet https://<IP>/ui/vropspluginui/rest/services/uploadova . Als dat niet bij de ESXi zelf uitkomt, is er van een exploit geen sprake. @sIRwa3 heeft het over een proxy, ik lees daar niet in dat hij URLs rechtstreeks reverse proxiet naar z'n ESXi host.

Dank je voor de verduidelijking, idd reverse proxy wat ik draai, en de host is idd NIET op wat voor een manier ook via buiten te bereiken. Niet via reverse proxy ook niet eens via vpn.

Als je een reverse proxy draait, met vSphere client geinstalleerd. Ik heb zelf ook een reverse proxy draaien, maar op basis van Linux en open-vm-tools. Geen idee of het dan ook kwetsbaar is.

Edit: het gaat om ESXi's eigen webbased management interface.

[Reactie gewijzigd door CH4OS op 7 februari 2023 13:06]

Ik doe niets met vSphere. Ik kan oon niet updaten/upgraden omdat mijn hardware niet meer compatible is met nieuwere versies. Zit op 6.7 want 7ondersteunt mijn netwerk kaart al niet meer. Zit al een tijdje te denken om naar proxmox te gaan. Dit is een goeie laatste druppel Draai idd ook de open-vm-tools

Doen. Ik ben al van ESXi naar Proxmox overgestapt en wil nooit meer terug.

Idem hier

Wat is het voordeel van promox tegen over esxi?

Proxmox werkt gewoon op al mijn hardware, in tegenstelling tot ESXi.
Daardoor heb je altijd de meest recente software en updates - gratis.
En ook gratis is hun backup oplossing, Proxmox Backup Server.
Ik weet niet of ESXi het kan, maar in Proxmox kun je zowel volwaardige vm's draaien en ook containers (LXC).

Ah thanks voor je toelichting, ja het is mij ook opgevallen dat hardware vereisen erg hoog zijn geworden.

ik heb hier in mijn homelab de NUC's een tijdje geleden voorzien van Windows 11 Pro en hyperV aangezet. hier nu alle VM's op te draaien en dat gaat als een zonnetje

geen gedoe met drivers of hoog energieverbruik. alles werkt zoals het hoort en krijg de updates.

let wel: ik wil gewoon VM's draaien, het zal me een rotzorg zijn welke hypervisor er onder hangt als ik maar kan doen wat ik wil

Het is de ESXi host die op poort 443 bereikbaar moet zijn. De pakketten naar je VMs passeren enkel door de vSwitch code. Elke TCP/IP stack z'n eigen attack surface...

Wat is oud? Wat is de patch? Welke versies zijn kwetsbaar?
Lekker makkelijk om dat weg te laten, maar neigt naar klikbait ipv gewoon de details uit de CVE op te nemen.

The vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin. A malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server. This affects VMware vCenter Server (7.x before 7.0 U1c, 6.7 before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2 and 3.x before 3.10.1.2).

Ah, het gaat om de client voor het instellen van de ESXi host of het cluster zelf. Ik dacht even de VMware client die je in de VM kan installeren.

Dat noemt Vmware Tools.
Het gaat inderdaad over de HTML5 Web Client, maar als ik het goed begrijp niet de gewone Host Client, maar de vCenter Client.

Dus de titel van het artikel is eigenlijk verkeerd. Want het is niet ESXi die kwetsbaar is maar vCenter en het is ook daar op vCenter dat je iets met uitschakelen.

[Reactie gewijzigd door GoBieN-Be op 7 februari 2023 12:32]

Maw als je de patches deftig onderhoud, hoef je je geen zorgen te maken.
Beheerders die publieke services draaien op een VM en vervolgens niet patchen, hebben IMHO niet goed begrepen wat hun job inhoudt.

...die in de vSphere Client op ESXi-machines is geïnstalleerd

Zit het dan ook in de open-vm-tools voor Linux VM's? In de Linux VMs die ik heb draaien, heb ik namelijk de officiele vSphere client niet geinstalleerd. Op mijn Windows Server VM wel, maar die staat tegenwoordig uit. Vanavond maar even aan slingeren en OpenSLP uitschakelen.

Ben je niet in de war met VMware tools?

Ja, het ik dacht dat de VMWare tools bedoeld worden, maar dat is inderdaad niet zo.

De kwetsbaarheid zit hem in de hypervisor zelf, niet in VMware tools.

De slachtoffers zijn meestal beheerders die die patch nog niet hebben geïnstalleerd, hoewel die al in februari van 2021 is uitgekomen.

Op een gegeven moment wordt je naast slachtoffer dan ook zelf een soort van (mede)dader, als je patches zo lang uitstelt zonder mitigaties. Dat valt onder nalatigheid.

[Reactie gewijzigd door The Zep Man op 7 februari 2023 12:29]

Dat valt onder nalatigheid.

Zo kijk ik er idd tegen aan.
Je hebt een ruim een jaar de tijd gehad om het te patchen of andere maatregelen te nemen.

Ik ben ondertussen wel zover, dat de eigenaren van deze bedrijven (in Nederland) een behoorlijke boete mogen krijgen. Volgende is gewoon een cel straf.

Het is vandaag de dag zware nalatigheid, om je software een jaar lang niet te patchen. Met alle gevolgen van dien.

Celstraf voor het niet updaten van software ?? Ik vind dat mensen hier een celstraf moeten krijgen voor domme opmerkingen. Ja het is niet slim niet te updaten, maar soms is er een reden het niet te doen. Dat is al een reden dat gevangenis straf op niet updaten van software niet mogelijk is, nog afgezien dat dit praktijk niet uivoerbaar is.
Als ik de deur open laat staan betekend nog steeds niet dat je naar binnen mag. Dat de verzekering de schade misschien niet dekt is iets anders.

Celstraf voor het niet updaten van software ??

Niet voor het niet updaten van software. Mogelijk wel voor nalatigheid over de persoonsgegevens van een ander.

Ja het is niet slim niet te updaten, maar soms is er een reden het niet te doen. Dat is al een reden dat gevangenis straf op niet updaten van software niet mogelijk is, nog afgezien dat dit praktijk niet uivoerbaar is.

Als je mitigaties doorvoert (die bekend zijn), dan eens. Anders is het nog steeds nalatig.

Als ik de deur open laat staan betekend nog steeds niet dat je naar binnen mag. Dat de verzekering de schade misschien niet dekt is iets anders.

Als jij je ontfermt over iets van een ander met een wettelijke verplichting om dat goed te beschermen en je doet dat niet omdat je de deur open laat staan, dan ben je nalatig. Voor maatschappelijke schade door nalatigheid mag je inderdaad gestraft worden.

[Reactie gewijzigd door The Zep Man op 7 februari 2023 14:24]

Jij hebt het nu over het beschermen van persoon gegevens, Die je er voor het gemak even bij haalt om uw standpunt te versterken. In de discussie ging het om het niet patches van een exsi server en niet patchen van software in het algemeen. Dat nalatig verhaal van U dat is al prima in de wet vastgelegt en men kan daar tot bepaalde hoogte al aansprakelijk voor worden gesteld.

Jij hebt het nu over het beschermen van persoon gegevens,

Klopt. Zie ook de eerste zin van mijn post, die het relateert aan jouw argument.

Dat nalatig verhaal van U dat is al prima in de wet vastgelegt en men kan daar tot bepaalde hoogte al aansprakelijk voor worden gesteld.

Dat is niet prima vastgelegd, want het gebeurt nog te vaak. Zolang persoonlijke gegevensbescherming een kosten-batenanalyse blijft, zal het nooit adequaat beschermd worden en blijft de maatschappij opdraaien voor de kosten die de verantwoordelijke niet maakt.

Verder mag je 'je' zeggen tegen 'U'.

[Reactie gewijzigd door The Zep Man op 7 februari 2023 15:07]

Ik vind dat mensen hier een celstraf moeten krijgen voor domme opmerkingen.

Misschien komen de echte tweakers dan wel weer terug.

Er kan ook een hele goede reden zijn om legacy systemen nog te ondersteunen vanuit een bedrijf zelf. Bv. als de software alleen op HP/UX / AIX / Solaris / OpenVMS / windows 2000 server / etc. draait en men niet wil of kan upgraden. Het bedrijf is bv. failliet die de oorspronkelijke software leverde en het is een 24/7 systeem.

Meestal zijn het de damagers die vernieuwing tegenhouden, past niet in het budget en dan krijg ik mijn bonus niet. Of het is gewoon technisch niet te doen. Kun je beter helemaal op nieuw beginnen. En niemand die nog weet hoe de applicatie werkt. Hoog verloop van mensen om welke reden dan ook werkt ook meestal niet mee.

[Reactie gewijzigd door Hatseflats op 7 februari 2023 16:21]

Celstraf voor het niet updaten van software ??

Voor op gesteld, Ik heb het over bedrijven en is afhankelijk voor wat je het gebruikt en wat de impact is. Als die server(s) gehacked worden.

Software is heel belangrijk in onze samenleving. Zodanig, dat het zelfs maatschappij ontwrichten kan zijn, als dit gehacked wordt.
In deze context, vind ik het zelfs naïef om te zeggen: "Celstraf voor het niet updaten van software ?"

We werken ondertussen al meer dan 40 jaar met software, maar schijnbaar wilt het niet lukken om bedrijven er te te dwingen. Om basis beveiligingsmaatregelen te nemen. Zoals software tijdig te updaten of simpel weg niet aan internet te hangen.

Met alle gevolgen van dien. Zoals het lekken van persoonsgegevens of erger het uitschakelen/vernietigen van infrastructuur.

Vind je het niet eens tijd, dat we dit harder gaan aanpakken?
Boetes worden ingecalculeerd door bedrijven en verrekend met hun klanten. Celstraf kan je niet incalculeren.

Als ik de deur open laat staan betekend nog steeds niet dat je naar binnen mag. Dat de verzekering de schade misschien niet dekt is iets anders.

Zolang jij thuis geen (illegale) data dumps hebt van persoonsgegevens, zal het mij een worst wezen, dat jij je deur open laat staan. Je hebt ten slotte alleen je zelf en je familie er mee.

Als ik datadumps of backups al dan niet illigaal thuis hebt liggen van persoon gegevens is dit al strafbaar of ik die deur nu open heb of dicht.
Maar we hebben het specifiek op het niet updaten van software in dit geval een vmware Server met een kwetbaarheid. Op die server kan van alles staan, dat klopt, maar niets zegt dat daar persoons gegevens op staan. Die haal je er zelf nu even voor het gemak zelf even er bij.

Dit soort dingen strafbaar stellen is ook heel moeilijk. Niemand die dan nog zulke verandwoording zou willen hebben. Want waneer ben je nu strafbaar ? een uur na de update is uitgebracht. of twee weken ? of alleen pas naar een hack ? ligt het aan de test proceduren van een maand, de voorschriften van het bedrijf zelf ? Wie is dan dan eigenlijk de verantwoordelijke ? De uitvoerder die het wel wist maar de procedure volgt en het dus niet deed, de manager die de proceduren heeft opgesteld. of daar weer de chef van want die heeft opdracht gegeven een procedure te maken met voorwaarden die is opgesteld door een werkgroep.

Als ik datadumps of backups al dan niet illigaal thuis hebt liggen van persoon gegevens is dit al strafbaar of ik die deur nu open heb of dicht.

Als jij een goede reden hebt om deze dumps te hebben, ben je niet strafbaar. EN moet jij er alles aan doen, om deze dumps te beschermen. DUs ook niet je deur open laten staan.

Die haal je er zelf nu even voor het gemak zelf even er bij.

Klopt, ik had ook de besturing van een kerncentrale kunnen gebruiken als voorbeeld of een ziekenhuis.
We weten niet wat voor data over dat soort servers gaan.

Dit soort dingen strafbaar stellen is ook heel moeilijk. Niemand die dan nog zulke verandwoording zou willen hebben.

Mooi toch, dan zijn er ook geen lekken meer. Doel bereikt.
Serieus, dit argument lees/hoor ik bij zo veel zaken. Eigenlijk nog een wonder dat er mensen werken...

Als een bedrijf zijn procedures op orde heeft en volgt en ook een auditor het jaarlijkse bevestigd (zie het als een APK keuring). Dan ben ik van mening, dat er geen straf op hoeft te staan. Maar dit type bedrijf, had nu ook geen last van deze bug. Sterker nog, die had waarschijnlijk een jaar geleden al geen last van deze bug.

Letop, ik maak er een probleem van. Omdat er al meer dan 1 jaar verschillende oplossingen waren. Voor het geval je toch de ESX interface aan internet moet hangen, zonder VPN of iets gelijks.

ja je hebt gelijk kan ik weer nou kan ik weer rustig verder.

Misschien moet hele wereld auto update wettelijk verplicht maken? Dat die optie niet langer uit te schakelen is. En dat de gebruikers niet langer verantwoordelijk moeten zijn.

Auto update is iets wat je in infrastructuur echt niet wilt hebben. Een bug in de patch en het hele bedrijf ligt op zijn gat.

Daar heb je een OTAP omgeving voor, automatische updates naar je O & T, 1 week later naar A en een week later naar P. Tenzij, de bug zodanig erg is, dat je dit moet versnellen. Maar dan ga je als nog eerst door je straat heen.

Gaat je O of T omgeving kapot, dan maak je gebruik van je Infrastructure as code en rol je het opnieuw uit.

In een perfecte wereld ja, in de praktijk mag je blij zijn als meer dan 50% van de omgevingen uberhaubt volledig geautomatiseerd is.

Je bent een knappe als je een MKB onderneming een OTAP straat aangesmeerd krijgt. Daar mag je al blij zijn dat je factuur zonder gezeur wordt betaald als MSP

ESXi heeft geen auto update op zich, tenzij je vCenter gebruikt maar dat is niet gratis. ESXi ("vCenter Server" - lang leve de marketing) wel.

Het is ook geen kwestie van ff een knopje drukken ofzo, je moet een depot downloaden en met wat commando's installeren.

Niettemin zou iedereen het allang gedaan moeten hebben ja want die patch is al jaren beschikbaar. En sowieso is de laatste versie (8.0) helemaal niet kwetsbaar.

[Reactie gewijzigd door GekkePrutser op 7 februari 2023 12:38]

Voor consumentensoftware, in veel gevallen wel. Zakelijke hardware en software lijkt me wel een héul slecht plan.. Buiten het feit dat licentiemodellen hier niet altijd op aangepast zijn, kom je ook in de knoei met compatibiliteit. Daarnaast vereist dit soort updates altijd een reboot van de hypervisor, lijkt me niet zo'n goed idee om dat ongecontroleerd automatisch midden op de dag te doen. Om nog maar niet te spreken over het algemene testbeleid van updates bij onze grote techreuzen, hoe vaak ik in de afgelopen jaren al niet een rotte update heb moeten herstellen en/of terugrollen..

Waarom zou je het niet gewoon afschermen van het internet? Dat lijkt mij stap 0.

Wat VMware eigenlijk adviseert is om nou eindelijk eens de updates te installeren die in veel gevallen al meer dan een jaar beschikbaar zijn. Dat openslp uitschakelen was alleen maar een mitigatie om de (als het goed is korte) tijd te overbruggen tussen het bekendworden van het lek en het patchen van de hosts. Er is geen enkel excuus te verzinnen om die patches nu nog niet geinstalleerd te hebben. Zelfs de zeer geplaagde 7.0u3 is inmiddels gewoon stabiel met inmiddels u3i (u3j is vorige week uitgekomen, dat is op dit moment de enige build waarvan je nog een excuus hebt om die niet te draaien)

Gebruikt VMware sinds vorige week voor tweede zelfde game op pc te spelen.