Duizenden ESXi-servers besmet met ransomware maar hoe is nog altijd onbekend
De afgelopen weken raakten duizenden VMware ESXi-servers besmet met ransomware, maar de infectiemethode is nog altijd onbekend. Lange tijd werd gedacht dat de aanvallers een kwetsbaarheid aangeduid als CVE-2021-21974 zouden gebruiken, maar daar is nog altijd geen bewijs voor gevonden. Sterker nog, het lijkt erop dat de OpenSLP-implementatie van ESXi geen rol bij de aanvallen speelt.
ESXi, onderdeel van VMware's vSphere, is een 'bare metal hypervisor' voor het virtualiseren van besturingssystemen. De virtualisatiesoftware wordt direct op een server geïnstalleerd en kan vervolgens het gevirtualiseerde besturingssysteem laden. Bij de recente ransomware-aanvallen worden de configuratiebestanden op de ESXi-servers versleuteld, waardoor de aangemaakte virtual machines onbruikbaar zijn geworden.
In eerste instantie werd gedacht dat de aanvallers gebruikmaakten van CVE-2021-21974, waardoor remote code execution mogelijk is. Het beveiligingslek bevindt zich specifiek in de OpenSLP-implementatie van ESXi. SLP (Service Location Protocol) is een protocol waarmee netwerkapplicaties het bestaan, de locatie en configuratie van netwerkdiensten op het netwerk kunnen vinden. Naar aanleiding van de aanvallen adviseerde VMware om de OpenSLP-service op ESXi-servers uit te schakelen en beschikbare updates te installeren.
VMware kwam vervolgens met een FAQ waarin het stelde dat de aanvalsvector nog altijd onbekend is. Een week na de laatste update op 16 februari is daar geen verandering in gekomen. Securitybedrijf Censys deed eerder al onderzoek naar het aantal getroffen servers en besloot te kijken hoeveel van de getroffen ESXi-servers OpenSLP heeft draaien. Sinds de metingen op 15 februari begonnen bleek dat maximaal negen procent van alle getroffen servers per dag SLP hadden draaien.
"Gegeven het relatief lage aantal besmette servers dat ook SLP draait, is het waarschijnlijk dat andere kwetsbaarheden of toegangsmethodes bij deze aanvallen zij betrokken", aldus Censys. Ook VMware stelt dat. "Er is geen garantie dat de SLP-kwetsbaarheden degene zijn die gebruikt worden." Bij de laatste meting van eerder deze week telde Censys nog meer dan duizend besmette ESXi-servers. Organisaties worden dan ook opgeroepen om de laatste ESXi-updates te installeren.
Dan moet je weten bij welk minimaal patchlevel geen enkele server getroffen is.
Dan moet je weten bij welk minimaal patchlevel geen enkele server getroffen is.
Dan moet je weten bij welk minimaal patchlevel geen enkele server getroffen is.
Als die Censys lui nou even een lijst maken van de exacte versienummers en patchlevels van getroffen servers dan
kan iedereen bekijken of hij goed zit of dat hij zich door het installeren van een of andere upgrade of niet critical patch
juist vulnerable maakt.
Want bedenk GOED: het is NIET zo dat iedere volgende update het allemaal beter maakt. Updates introduceren ook bugs.
Hypervisorbeheer vanaf het windowsnetwerk is dodelijk.
Juist ja, de ene versie is niet kwetsbaar, een latere kan juist wel weer kwetsbaar blijken. (node.js bijv.)
A priori is alle code kwetsbaar tot het tegendeel is gebleken en dan kun je nog wat over het hoofd hebben gezien.
Een hacker probeert juist dat uit, wat nog niet eerder is geprobeerd of een variatie op iets dat eerder heeft gewerkt.
#obserwator
Juist ja, de ene versie is niet kwetsbaar, een latere kan juist wel weer kwetsbaar blijken. (node.js bijv.)
A priori is alle code kwetsbaar tot het tegendeel is gebleken en dan kun je nog wat over het hoofd hebben gezien.
Een hacker probeert juist dat uit, wat nog niet eerder is geprobeerd of een variatie op iets dat eerder heeft gewerkt.
#obserwator
Dan moet je weten bij welk minimaal patchlevel geen enkele server getroffen is.
Ik ken ESXi niet, maar ik weet wel dat het niet het beste is om als eerste elke nieuwe ceph versie te installeren.
Dan moet je weten bij welk minimaal patchlevel geen enkele server getroffen is.
Dan moet je weten bij welk minimaal patchlevel geen enkele server getroffen is.
De meeste malware/hacks gaan als eerste zichzelf onzichtbaar proberen maken. Vaak wordt hierbij het versienummer etc. aangepast.
Stelt dat v1.0 vulnerable is, en v2.0 veilig, dan kan een geïnfecteerde v1.0 server zichzelf als v2.0 voordoen. (Zodat je denkt dat alles OK is en je veilig bent.)
Op basis van de versienummers van reeds geïnfecteerde systemen, kan je niet veel zinnigs zeggen. Daarom is het belangrijk dat je weet welke versie vulnerable is, en dat kan je pas met zekerheid zeggen wanneer je de exploit vector kent.
Dan moet je weten bij welk minimaal patchlevel geen enkele server getroffen is.
Ik ken ESXi niet, maar ik weet wel dat het niet het beste is om als eerste elke nieuwe ceph versie te installeren.
Dan heb je ofwel een software leverancier die geen kwaliteit aflevert, ofwel gebruik jij de software op een niet-gesuporteerde manier.
Vandaag de dag wordt de impact van software patches automatisch voor alle gesupporteerde gebruiken op voorhand getest.
Een patch die slecht loopt is zo goed als 100% zeker te wijten aan een verkeerde setup of een fout in installatieprocedure. Vaak had het lezen van de release notes zelfs het issue kunnen voorkomen.
Hypervisorbeheer vanaf het windowsnetwerk is dodelijk.
Eerste vraag, is dit verschil bevestigd?
Tweede vraag, misschien is het dan aardig en kun je een aantal best-practices te delen voor de leken onder ons.
Derde vraag, is pipeline exploitation een optie?
Dan moet je weten bij welk minimaal patchlevel geen enkele server getroffen is.
Als die Censys lui nou even een lijst maken van de exacte versienummers en patchlevels van getroffen servers dan
kan iedereen bekijken of hij goed zit of dat hij zich door het installeren van een of andere upgrade of niet critical patch
juist vulnerable maakt.
Want bedenk GOED: het is NIET zo dat iedere volgende update het allemaal beter maakt. Updates introduceren ook bugs.
Daarnaast is het "best practice" wanneer je dat zo wil noemen dat de management, vsan, vmotion VLAN's achter een firewall zitten en het liefst ook niet gerouteerd zijn. Er is namelijk niks mis met VCenter op een ander segment en dat deze alleen maar via een jumphost of management doos te benaderen is. Daarnaast kan je ook heel mooi met host profiles werken waardoor je de firewall op de esx hosts ook volledig kan dichttimmeren. En het zelfde geldt ook voor je VC.
Kortom, wanneer je besmet raakt, heb je het gewoon niet op orde.
Als IT professional behoor je te weten hoe fatsoenlijk life cycle management eruit ziet. Ik zie hierboven een paar commentaren waarbij ik me afvraag of je je werk wel snapt als dat je reactie is. Ik ga er dan even vanuit dat je een IT professional bent als je sites zoals deze leest.
Hypervisorbeheer vanaf het windowsnetwerk is dodelijk.
Beetje rare diagnose, als ik zo vrij mag zijn. Er zijn meerdere wegen naar Rome. Misschien is de console wel gecompromitteerd, misschien is het via SSH gegaan omdat de hosts niet fatsoenlijk waren gehardened. Misschien was iemand wel zo snugger om z'n host rechtstreeks aan internet te hangen met het management interface. Ja dat is dom, maar je wilt ze de kost niet moeten geven, zoveel als dat er zijn. Of waar de remote management kaart van de server (iDRAC, ILO, IPMI) aan internet hangt en deze via een vulnerability toegang verschafte. Zoals gezegd, meerdere wegen naar Rome.
Sowieso vraag ik me dan even af wat "het windowsnetwerk" is. Ik zit toch al wel een tijdje in de IT maar dit begrip is mij vreemd. Ik ken wel een management LAN en een server LAN en meerdere VLANs om je verkeer te scheiden. Ik neem dan even aan dat je met "windowsnetwerk" een server VLAN bedoelt. Dan heb je gelijk als het vreemd zou zijn dat ESXi hosts van daaruit benaderbaar zijn. Dat zou niet mogen.
Tegelijkertijd zie ik zelfs bij grote internationale bedrijven dat de netwerk topologie bestaat uit wel 1 grote pool met daarin zo ongeveer alles. Als security professional gaan dan je haren wel overeind staan, kan ik je zeggen :)
Deze posting is gelocked. Reageren is niet meer mogelijk.
Information Security Officer (Operationele Techniek)
bij HHNK
Heb jij een passie voor informatiebeveiliging en wil je jouw expertise inzetten in een organisatie met impact? Solliciteer nu! Bij HHNK hechten we veel waarde aan de veiligheid van onze informatie en systemen. Met een breed scala aan operationele techniek (OT) voor onze taken, is het essentieel om deze veilig te houden.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.