VMware meldt dat recente update voor kritiek vCenter-lek onvoldoende is
VMware kwam vorige maand met een beveiligingsupdate voor een kritieke kwetsbaarheid in vCenter, waardoor servers op afstand zijn over te nemen. Het bedrijf laat nu weten dat die update onvoldoende is en heeft een tweede update uitgebracht om het probleem volledig te verhelpen. VCenter is een oplossing voor het beheer van virtual machines en gevirtualiseerde servers. Kwetsbaarheden in de oplossing zijn in het verleden geregeld gebruikt voor het uitvoeren van aanvallen.
Vorige maand liet VMware weten dat de implementatie van het DCERPC-protocol binnen vCenter een heap-overflow kwetsbaarheid bevat. Door het versturen van speciaal geprepareerde netwerkpakketten kan een aanvaller met toegang tot een vCenter-server code op het systeem uitvoeren. De impact van het beveiligingslek (CVE-2024-38812) is op een schaal van 1 tot en met 10 beoordeeld met een 9.8.
Het probleem werd gedemonstreerd tijdens een hackwedstrijd in China genaamd Matrix Cup, die afgelopen juni plaatsvond. Vervolgens kwam VMware op 17 september met patches, maar in een update van het beveiligingsbulletin laat VMware nu weten dat de eerste patch ontoereikend was. Organisaties worden dan ook opgeroepen de nu uitgebrachte update te installeren om zo volledig beschermd te zijn.
Reacties (12)
22-10-2024, 12:13 door
Anoniem
Je ZOU toch mogen verwachten dat juist virtualisatie software zo goed mogelijk dicht is getimmerd?
Ik zie steeds vaker dit soort kwetsbaarheden in netwerk of virtualisatie apparatuur.
Dat is een trend die ik niet leuk vind...
Ik zie steeds vaker dit soort kwetsbaarheden in netwerk of virtualisatie apparatuur.
Dat is een trend die ik niet leuk vind...
22-10-2024, 13:38 door
Anoniem
Door Anoniem: Je ZOU toch mogen verwachten dat juist virtualisatie software zo goed mogelijk dicht is getimmerd?
Ik zie steeds vaker dit soort kwetsbaarheden in netwerk of virtualisatie apparatuur.
Dat is een trend die ik niet leuk vind...
Des te meer redenen om het vcenter in een apart vlan te hebben draaiend onder Linux zonder windows werkplekken en alleen toegankelijk via https of sshIk zie steeds vaker dit soort kwetsbaarheden in netwerk of virtualisatie apparatuur.
Dat is een trend die ik niet leuk vind...
Door Anoniem:
Door Anoniem: Je ZOU toch mogen verwachten dat juist virtualisatie software zo goed mogelijk dicht is getimmerd?
Ik zie steeds vaker dit soort kwetsbaarheden in netwerk of virtualisatie apparatuur.
Dat is een trend die ik niet leuk vind...
Des te meer redenen om het vcenter in een apart vlan te hebben draaiend onder Linux zonder windows werkplekken en alleen toegankelijk via https of sshIk zie steeds vaker dit soort kwetsbaarheden in netwerk of virtualisatie apparatuur.
Dat is een trend die ik niet leuk vind...
Je hebt blijkbaar al een tijdje gen vcenter meer gebruikt?
VCenter is een appliance gebaseerd op Linux, het is al jaren geen installatie meer op Windows.
22-10-2024, 14:41 door
_R0N_
Door Anoniem: Je ZOU toch mogen verwachten dat juist virtualisatie software zo goed mogelijk dicht is getimmerd?
Ik zie steeds vaker dit soort kwetsbaarheden in netwerk of virtualisatie apparatuur.
Dat is een trend die ik niet leuk vind...
Ik zie steeds vaker dit soort kwetsbaarheden in netwerk of virtualisatie apparatuur.
Dat is een trend die ik niet leuk vind...
Gebruikers willen steeds meer kan en doet en al die extra features zorgen ook voor extra kwetsbaarheden.
Het lijkt me sterk dat iemand werkstations heeft in hetzelfde vlan als waar vcenter zit, alleen mogelijk in een knutselclub of zo.
Zitten je werkstations wel in hetzelfde vlan dan ben je gewoon af.
De enige manier waarop dit te misbruiken zou moeten zijn is wanneer je uit je VM uitbreekt naar de hypervisor en zo in het management vlan terecht komt. dat lijkt me niet heel eenvoudig, al komen dat soort vulnerabilities de laatste tijd wel steeds vaker voor.
22-10-2024, 15:03 door
Anoniem
Door Anoniem: Je ZOU toch mogen verwachten dat juist virtualisatie software zo goed mogelijk dicht is getimmerd?
Ik zie steeds vaker dit soort kwetsbaarheden in netwerk of virtualisatie apparatuur.
Dat is een trend die ik niet leuk vind...
Ik zie steeds vaker dit soort kwetsbaarheden in netwerk of virtualisatie apparatuur.
Dat is een trend die ik niet leuk vind...
vCenter is geen virtualisatie software! Het is BEHEER software voor een virtualisatie platform.
Hier kun je virtuele machines aanmaken, verwijderen, verplaatsen, hun parameters aanpassen, e.d.
Dit is dus NIET iets waar je externe klanten die bij je virtuele servers moeten komen ooit mee te maken hebben.
Het beste zet je het hele management netwerk voor je hosts inclusief vCenter op een apart netwerk wat niet direct aan internet zit. Die benader je dan via een beter dichtgetimmerde VPN router of jumphost.
22-10-2024, 15:25 door
Anoniem
Door _R0N_:
Gebruikers willen steeds meer kan en doet en al die extra features zorgen ook voor extra kwetsbaarheden.
Het lijkt me sterk dat iemand werkstations heeft in hetzelfde vlan als waar vcenter zit, alleen mogelijk in een knutselclub of zo.
Zitten je werkstations wel in hetzelfde vlan dan ben je gewoon af.
De enige manier waarop dit te misbruiken zou moeten zijn is wanneer je uit je VM uitbreekt naar de hypervisor en zo in het management vlan terecht komt. dat lijkt me niet heel eenvoudig, al komen dat soort vulnerabilities de laatste tijd wel steeds vaker voor.
Dat soort vulnerabilities komen de laatste tijd helemaal niet voor want het kan niet op een level 1 hypervisor (physiek gescheiden). Level 2 misschien wel op een HyperV host want daar ligt windows onder. Daar kan je alles verwachten,Door Anoniem: Je ZOU toch mogen verwachten dat juist virtualisatie software zo goed mogelijk dicht is getimmerd?
Ik zie steeds vaker dit soort kwetsbaarheden in netwerk of virtualisatie apparatuur.
Dat is een trend die ik niet leuk vind...
Ik zie steeds vaker dit soort kwetsbaarheden in netwerk of virtualisatie apparatuur.
Dat is een trend die ik niet leuk vind...
Gebruikers willen steeds meer kan en doet en al die extra features zorgen ook voor extra kwetsbaarheden.
Het lijkt me sterk dat iemand werkstations heeft in hetzelfde vlan als waar vcenter zit, alleen mogelijk in een knutselclub of zo.
Zitten je werkstations wel in hetzelfde vlan dan ben je gewoon af.
De enige manier waarop dit te misbruiken zou moeten zijn is wanneer je uit je VM uitbreekt naar de hypervisor en zo in het management vlan terecht komt. dat lijkt me niet heel eenvoudig, al komen dat soort vulnerabilities de laatste tijd wel steeds vaker voor.
23-10-2024, 10:48 door
Anoniem
Alternatief voor mgt vlan is de vSphere firewall te activeren en alleen je beheer jumpboxen toegang te geven tot ssh en https.
23-10-2024, 11:34 door
Anoniem
Door Anoniem: Alternatief voor mgt vlan is de vSphere firewall te activeren en alleen je beheer jumpboxen toegang te geven tot ssh en https.
ssh en https is al lang genoemd hier. Ik meen (gebruik vmware al een tijd niet meer) dat het met deze firewall alles of niets is voor een bepaalde interface en dat een specifieke port niet kan worden geselecteerd. Daarnaast vind ik het ook onverstandig om geen apart vlan te gebruiken. Ik zou ook geen AD gebruiken voor de credentials. Wij gebruiken rsa keys met passphrase om in te loggen. Ik weet niet of dat met vcenter ook kan.
23-10-2024, 14:00 door
Anoniem
Door Anoniem:
Dat soort vulnerabilities komen de laatste tijd helemaal niet voor want het kan niet op een level 1 hypervisor (physiek gescheiden). Level 2 misschien wel op een HyperV host want daar ligt windows onder. Daar kan je alles verwachten,
Dat soort vulnerabilities komen de laatste tijd helemaal niet voor want het kan niet op een level 1 hypervisor (physiek gescheiden). Level 2 misschien wel op een HyperV host want daar ligt windows onder. Daar kan je alles verwachten,
Je hebt zeker je cursus maar half gesnapt ?
'hypervisor' en 'fysiek gescheiden' sluit elkaar uit . Een hypervisor is er nu juist om NIET fysiek gescheiden hardware (CPU, disk,ram, nic ) te verdelen onder OSen.
'fysiek gescheiden' noemen we gewoon 'cluster'. Of 'twee servers' als ze helemaal niet gekoppeld zijn.
Je hebt 'type 1' hypervisors - daarin draait de hypervisor op bare metal.
En 'type 2' hypervisors , waarin er een OS op bare metal draait, en binnen dat OS de hypervisor .
Overigens is ook Hyper-V een type 1 hypervisor, net als vmware esxi , Xen , KVM e.a.
Vmware esxi is ook (hoofdzakelijk) een linux kernel , met vmware's hypervisor-extras . KVM natuurlijk ook.
vmware workstation/fusion, parallels, qemu zijn type-2 hypervisors.
23-10-2024, 16:24 door
Anoniem
Door Anoniem:
Je hebt zeker je cursus maar half gesnapt ?
'hypervisor' en 'fysiek gescheiden' sluit elkaar uit . Een hypervisor is er nu juist om NIET fysiek gescheiden hardware (CPU, disk,ram, nic ) te verdelen onder OSen.
'fysiek gescheiden' noemen we gewoon 'cluster'. Of 'twee servers' als ze helemaal niet gekoppeld zijn.
Je hebt 'type 1' hypervisors - daarin draait de hypervisor op bare metal.
En 'type 2' hypervisors , waarin er een OS op bare metal draait, en binnen dat OS de hypervisor .
Overigens is ook Hyper-V een type 1 hypervisor, net als vmware esxi , Xen , KVM e.a.
Vmware esxi is ook (hoofdzakelijk) een linux kernel , met vmware's hypervisor-extras . KVM natuurlijk ook.
vmware workstation/fusion, parallels, qemu zijn type-2 hypervisors.
Hyper-V noemen ze een type 1 hypervisor. Nou ik zie ze hier draaien met een enorme footprint en dikke GUI met native applicaties ipv webbased. Het is gewoon windows en live migreren doen ze niet want dat werkt problematisch (vaak Missing permissions. An Incorrect Authentication Protocol).Door Anoniem:
Dat soort vulnerabilities komen de laatste tijd helemaal niet voor want het kan niet op een level 1 hypervisor (physiek gescheiden). Level 2 misschien wel op een HyperV host want daar ligt windows onder. Daar kan je alles verwachten,
Dat soort vulnerabilities komen de laatste tijd helemaal niet voor want het kan niet op een level 1 hypervisor (physiek gescheiden). Level 2 misschien wel op een HyperV host want daar ligt windows onder. Daar kan je alles verwachten,
Je hebt zeker je cursus maar half gesnapt ?
'hypervisor' en 'fysiek gescheiden' sluit elkaar uit . Een hypervisor is er nu juist om NIET fysiek gescheiden hardware (CPU, disk,ram, nic ) te verdelen onder OSen.
'fysiek gescheiden' noemen we gewoon 'cluster'. Of 'twee servers' als ze helemaal niet gekoppeld zijn.
Je hebt 'type 1' hypervisors - daarin draait de hypervisor op bare metal.
En 'type 2' hypervisors , waarin er een OS op bare metal draait, en binnen dat OS de hypervisor .
Overigens is ook Hyper-V een type 1 hypervisor, net als vmware esxi , Xen , KVM e.a.
Vmware esxi is ook (hoofdzakelijk) een linux kernel , met vmware's hypervisor-extras . KVM natuurlijk ook.
vmware workstation/fusion, parallels, qemu zijn type-2 hypervisors.
Over huiswerk gesproken. VMWare ESXi heeft helemaal geen LInux kernel en is er ook niet op gebaseerd. Het is een closed source VMkernel met Busybox (wel open source) voor console commands. ESX had altijd een service console (redhat linux kernel) voor toegang tot de VMkernel die er bij ESXi niet in zit.
23-10-2024, 19:29 door
Anoniem
Door Anoniem:
Door Anoniem:
Je hebt zeker je cursus maar half gesnapt ?
'hypervisor' en 'fysiek gescheiden' sluit elkaar uit . Een hypervisor is er nu juist om NIET fysiek gescheiden hardware (CPU, disk,ram, nic ) te verdelen onder OSen.
'fysiek gescheiden' noemen we gewoon 'cluster'. Of 'twee servers' als ze helemaal niet gekoppeld zijn.
Je hebt 'type 1' hypervisors - daarin draait de hypervisor op bare metal.
En 'type 2' hypervisors , waarin er een OS op bare metal draait, en binnen dat OS de hypervisor .
Overigens is ook Hyper-V een type 1 hypervisor, net als vmware esxi , Xen , KVM e.a.
Vmware esxi is ook (hoofdzakelijk) een linux kernel , met vmware's hypervisor-extras . KVM natuurlijk ook.
vmware workstation/fusion, parallels, qemu zijn type-2 hypervisors.
Hyper-V noemen ze een type 1 hypervisor. Nou ik zie ze hier draaien met een enorme footprint en dikke GUI met native applicaties ipv webbased. Het is gewoon windows en live migreren doen ze niet want dat werkt problematisch (vaak Missing permissions. An Incorrect Authentication Protocol).Door Anoniem:
Dat soort vulnerabilities komen de laatste tijd helemaal niet voor want het kan niet op een level 1 hypervisor (physiek gescheiden). Level 2 misschien wel op een HyperV host want daar ligt windows onder. Daar kan je alles verwachten,
Dat soort vulnerabilities komen de laatste tijd helemaal niet voor want het kan niet op een level 1 hypervisor (physiek gescheiden). Level 2 misschien wel op een HyperV host want daar ligt windows onder. Daar kan je alles verwachten,
Je hebt zeker je cursus maar half gesnapt ?
'hypervisor' en 'fysiek gescheiden' sluit elkaar uit . Een hypervisor is er nu juist om NIET fysiek gescheiden hardware (CPU, disk,ram, nic ) te verdelen onder OSen.
'fysiek gescheiden' noemen we gewoon 'cluster'. Of 'twee servers' als ze helemaal niet gekoppeld zijn.
Je hebt 'type 1' hypervisors - daarin draait de hypervisor op bare metal.
En 'type 2' hypervisors , waarin er een OS op bare metal draait, en binnen dat OS de hypervisor .
Overigens is ook Hyper-V een type 1 hypervisor, net als vmware esxi , Xen , KVM e.a.
Vmware esxi is ook (hoofdzakelijk) een linux kernel , met vmware's hypervisor-extras . KVM natuurlijk ook.
vmware workstation/fusion, parallels, qemu zijn type-2 hypervisors.
Leer nou 's wat type 1 of type 2 is.
Met al je bla bla blijft het een type 1 hypervisor, zolang de hypervisor functie (ook) in kernel mode op de bare metal draait.
En ga maar lekker excuses verzinnen waarom KVM-op-Linux dan wel een 'echte type 1 hypervisor' is - (wat het inderdaad is) , draaiend als volledige Linux kernel .
Over huiswerk gesproken. VMWare ESXi heeft helemaal geen LInux kernel en is er ook niet op gebaseerd. Het is een closed source VMkernel met Busybox (wel open source) voor console commands. ESX had altijd een service console (redhat linux kernel) voor toegang tot de VMkernel die er bij ESXi niet in zit.
Correct op esxi . Ik was erin getrapt omdat de (busybox) shell, utilities, , gcc, ELF etc erg herkenbaar op lijken.
Maar inderdaad is het de vmkernel volgens vmware/broadcom een eigen posix-compatibele kernel .
Uiteindelijk ook een full blown Unix kernel-met-hypervisor (alleen geen Linux origine)
24-10-2024, 10:58 door
Anoniem
Door Anoniem:
Leer nou 's wat type 1 of type 2 is.
Met al je bla bla blijft het een type 1 hypervisor, zolang de hypervisor functie (ook) in kernel mode op de bare metal draait.
En ga maar lekker excuses verzinnen waarom KVM-op-Linux dan wel een 'echte type 1 hypervisor' is - (wat het inderdaad is) , draaiend als volledige Linux kernel .
Over huiswerk gesproken. VMWare ESXi heeft helemaal geen LInux kernel en is er ook niet op gebaseerd. Het is een closed source VMkernel met Busybox (wel open source) voor console commands. ESX had altijd een service console (redhat linux kernel) voor toegang tot de VMkernel die er bij ESXi niet in zit.
Correct op esxi . Ik was erin getrapt omdat de (busybox) shell, utilities, , gcc, ELF etc erg herkenbaar op lijken.
Maar inderdaad is het de vmkernel volgens vmware/broadcom een eigen posix-compatibele kernel .
Uiteindelijk ook een full blown Unix kernel-met-hypervisor (alleen geen Linux origine)
VMkernel is POSIX-achtig, maar niet in compliance! en dus geen UNIX maar vertoont wel kenmerken zoals Loadable modules. Er zijn mensen die zeggen dat het een verbouwde LInux is (omdat het bv ook Linux drivers laadt) en dat vmware dus de GPL schendt maar niemand heeft VMware ooit aangeklaagt. Er zijn wel discussies geweest tussen Alan Cox (Linux kernel hacker) en iemand van vmware.Door Anoniem:
Door Anoniem:
Je hebt zeker je cursus maar half gesnapt ?
'hypervisor' en 'fysiek gescheiden' sluit elkaar uit . Een hypervisor is er nu juist om NIET fysiek gescheiden hardware (CPU, disk,ram, nic ) te verdelen onder OSen.
'fysiek gescheiden' noemen we gewoon 'cluster'. Of 'twee servers' als ze helemaal niet gekoppeld zijn.
Je hebt 'type 1' hypervisors - daarin draait de hypervisor op bare metal.
En 'type 2' hypervisors , waarin er een OS op bare metal draait, en binnen dat OS de hypervisor .
Overigens is ook Hyper-V een type 1 hypervisor, net als vmware esxi , Xen , KVM e.a.
Vmware esxi is ook (hoofdzakelijk) een linux kernel , met vmware's hypervisor-extras . KVM natuurlijk ook.
vmware workstation/fusion, parallels, qemu zijn type-2 hypervisors.
Hyper-V noemen ze een type 1 hypervisor. Nou ik zie ze hier draaien met een enorme footprint en dikke GUI met native applicaties ipv webbased. Het is gewoon windows en live migreren doen ze niet want dat werkt problematisch (vaak Missing permissions. An Incorrect Authentication Protocol).Door Anoniem:
Dat soort vulnerabilities komen de laatste tijd helemaal niet voor want het kan niet op een level 1 hypervisor (physiek gescheiden). Level 2 misschien wel op een HyperV host want daar ligt windows onder. Daar kan je alles verwachten,
Dat soort vulnerabilities komen de laatste tijd helemaal niet voor want het kan niet op een level 1 hypervisor (physiek gescheiden). Level 2 misschien wel op een HyperV host want daar ligt windows onder. Daar kan je alles verwachten,
Je hebt zeker je cursus maar half gesnapt ?
'hypervisor' en 'fysiek gescheiden' sluit elkaar uit . Een hypervisor is er nu juist om NIET fysiek gescheiden hardware (CPU, disk,ram, nic ) te verdelen onder OSen.
'fysiek gescheiden' noemen we gewoon 'cluster'. Of 'twee servers' als ze helemaal niet gekoppeld zijn.
Je hebt 'type 1' hypervisors - daarin draait de hypervisor op bare metal.
En 'type 2' hypervisors , waarin er een OS op bare metal draait, en binnen dat OS de hypervisor .
Overigens is ook Hyper-V een type 1 hypervisor, net als vmware esxi , Xen , KVM e.a.
Vmware esxi is ook (hoofdzakelijk) een linux kernel , met vmware's hypervisor-extras . KVM natuurlijk ook.
vmware workstation/fusion, parallels, qemu zijn type-2 hypervisors.
Leer nou 's wat type 1 of type 2 is.
Met al je bla bla blijft het een type 1 hypervisor, zolang de hypervisor functie (ook) in kernel mode op de bare metal draait.
En ga maar lekker excuses verzinnen waarom KVM-op-Linux dan wel een 'echte type 1 hypervisor' is - (wat het inderdaad is) , draaiend als volledige Linux kernel .
Over huiswerk gesproken. VMWare ESXi heeft helemaal geen LInux kernel en is er ook niet op gebaseerd. Het is een closed source VMkernel met Busybox (wel open source) voor console commands. ESX had altijd een service console (redhat linux kernel) voor toegang tot de VMkernel die er bij ESXi niet in zit.
Correct op esxi . Ik was erin getrapt omdat de (busybox) shell, utilities, , gcc, ELF etc erg herkenbaar op lijken.
Maar inderdaad is het de vmkernel volgens vmware/broadcom een eigen posix-compatibele kernel .
Uiteindelijk ook een full blown Unix kernel-met-hypervisor (alleen geen Linux origine)
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
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.
