Ransomware gangs are loving this dumb but deadly make-me-admin ESXi vulnerability

Do you have your VMware ESXi hypervisor joined to Active Directory? Well, the latest news from Microsoft serves as a reminder that you might not want to do that given the recently patched vulnerability that has security experts deeply concerned. CVE-2024-37085 only carries a 6.8 CVSS rating, but has been used as a post- …

[Throatwarbler Mangrove]

A relief for Microsoft . . .

They're involved, but it's not their fault for once.

The comment about AD authorization being a chicken-and-egg problem is certainly well-known . . . to anyone who's ever had to recover any directory-joined environment. Obviously, one needs local credentials to bootstrap the VMware environment if the AD servers have gone down, and many orgs keep at least one physical domain controller around for just this reason.

Also, aren't KnowBe4 the ones who hired a North Korean hacker? Maybe they should get their own house in order before dispensing advice.

[Version 1.0]

Re: A relief for Microsoft . . .

A potential solution to so many problems would be for Microsoft to hire a North Korean hacker, offering the hacker US residency and $200,000 a year once Microsoft is no longer having any hacking risks. That sounds expensive but imaging how happy we would all be if malware and user hacking was eliminated in the Microsoft operational user world.

Let's eliminate "Windows" (too easy to open) and move to a new "Lockedcastle" operating system.

[Throatwarbler Mangrove]

Re: A relief for Microsoft . . .

One hopes that an organization the size of Microsoft has a dedicated "red team" continuously doing penetration testing and generally looking for vulnerabilities.

Right?

[stiine]

Re: A relief for Microsoft . . .

Except that their 'red team' is just people that were picked from the dross that coded the bugs in the first place.

[veti]

Re: A relief for Microsoft . . .

You think one solitary Nork hacker could singlehandedly secure all Microsoft platforms?

The price you suggest would be bargain of the century for such a feat.

[Nate Amsden]

by design

Noted someone in another forum dig up esx 4.1 guide(the last version of esx I was excited about), and saw this group setup is specifically how you would assign admin access, on that initial implementation of AD support.

For me, another nothing burger, as a Linux person, have never had my hosts connected to AD. I did run AD for a few years for vcenter 5, but once we switched it to 6.5, wemt with ldap auth against OpenLDAP which we used in Linux already(and killed the windows domain). ESXi hosts only using local auth. Almost never have to login directly to a host anyway, most things are done through vcenter.

[Roland6]

Re: by design

From the article and the linked MS piece it seems AD is doing exactly as it was intended, also ESX is also doing as expected, it trusts AD, so if AD says this user is a member of the ESX administrators group… It seems the core mitigation is to create the “ESX Admin” group in AD and change the permissions so only specific user(s) can change permissions and add users to the group.

Suspect we need to look at other AD security groups, as I doubt ESX is the only product to use AD in this way…

[Anonymous Coward]

Re: by design

AD groups have a protected attribute containing GUIDs that mark them as privileged. Applications should not be relying on string names of groups.

[Casca]

Re: by design

Good for you...

[chivo243]

this is why...

ESX without AD while AD runs on ESX? Always, always have one MS Domain Controller running on a physical box, one shop had a low end proliant doing that service. Well worth the price +€1000 or so...

[Dimmer]

Re: this is why...

But… but …. It is so much easer. Next week we are going to add it to our firewall and our vpn!

Said in jest, but some people really do this.

[Anonymous Coward]

Re: this is why...

Some VPNs only sell virtual appliances these days.

If you're an VMware shop, I would suggest installing a 2 machine cluster of proxmox (or any other non Broadcom product) for your dns, directory services, and remote access servers.

[chivo243]

Re: this is why...

One place I worked did have their voip server virtual, but they decided that everybody has a cell phone, so internal lines could go down wee bit, and save money.

[david 12]

as I doubt ESX is the only product to use AD in this way

It's a technically naive way of using AD, so it's the kind of thing expected from technically naive users -- specifically including in that group cross-platform users and developers, no matter how sophisticated their understanding of security on their native platform.

And it demonstrates two fails, one on each side.

On the MS side, somebody has left AD partly unlocked -- a non-admin user can create an AD group. That's like leaving your house "partly" unlocked.

On the ESXi side, they've used "group name" as a security ID. That's not how AD works.

[Nate Amsden]

Maybe it's just an AD thing, though I suspect many orgs especially smaller ones don't have non admin users that can create security groups. At least I've never heard that as being a practice anywhere I worked at, though I freely admit I'm no AD expert by any means.

Otherwise, how is this any different from mapping a group in LDAP (in my case, OpenLDAP) to an admin group in vCenter? or any other app? That is what most apps do. Though usually you define what group name you want to use.

So in my case for example if you happen to be in the "ops-prod-vmware" LDAP group, that will map you to full admin access in vCenter on the production cluster. Seems like a perfectly normal thing to do. ESXi was just lazy in that they picked some arbitrary name and said here use this.. I have seen comments from others saying there is a setting or two you can use to change the default, but I assume that setting is not visible in the UI ( you may have to go to the advanced settings to find it).

[david 12]

As I've read, you can 'change the default' but the default is also still true even after you've created a new additional "default".

Regarding the groups, it's not normally group names that give you special powers: it's the attributes assigned to that group. And given the nature of the problem as described, even the trivial security of starting with a custom OID, instead of a custom name, would have helped.

[Anonymous Coward]

Non admins typically can't create groups unless they have been delegated access.

There may be ways to indirectly create groups if not careful. In an Exchange environment you may give people the ability to create distribution lists, which is an AD group.

I see some people saying that they use other LDAP implementations, not AD. Since it is just a group name would the same problem exist with other LDAP authentication providers?

There is a similar issue with Citrix Netscalers if you integrate them with an external authentication source such as AD. By default if you create an account called nsroot in the external source, you can log into the appliance with it. It overrides the local nsroot account and you get root privilege . This default behaviour can be disabled in the Netscaler configuration.

[Nate Amsden]

ok, so perhaps the issue is more that ESXi my recognize a mailing list distribution group as an access level group and grant admin access based on that? Which seems strange to me I would have expected if esxi requests the group membership, given it is a server, that AD would return just the security groups not distribution lists as that is a different type of object. But in any case sounds like a more advanced AD thing, and if that behavior was critical then the AD admins should know about that already, and set things accordingly when they link up ESXi or anything else that authenticates against AD.

I believe in the org I am with there are no users that are allowed to make distribution lists, I have regular discussions with the IT folks and they have frequently mentioned user's requests to have a new distribution group which then IT then evaluates and performs the actions as needed. I think I recall discussions like that at prior companies as well going back to 2008 if not earlier. I assume there were cases where some users could manage existing distribution lists(perhaps their own group's or something).

Per another user's comment I use LDAP with my Netscalers as well and was not aware of that nsroot thing, for me I just needed to provide named "admin" accounts for PCI purposes so am using the LDAP to authenticate for those passwords, then I had to "map" each user to admin role using a local user account(the local user password isn't used, though still must be defined).