auxiliary/admin/ldap/vmware_vcenter_vmdir_auth_bypass broken and unable to use custom domain

[shaaati]

Steps to reproduce

How'd you do it?

1. Read https://github.com/HynekPetrak/HynekPetrak/blob/master/take_over_vcenter_670.md
2. Try to use auxiliary/admin/ldap/vmware_vcenter_vmdir_auth_bypass in order to replicate what is written there.

I managed to find a vCenter installation that is vulnerable against exploit/linux/http/vmware_vcenter_analytics_file_upload. Following the guide of @HynekPetrak, I extracted the machine user and password from its local LDAP. With a bit of tinkering, I found that it is also possible to read the domain value if something else instead of the default "vsphere.local" is used. This should be enough to use the above-mentioned module.

Were you following a specific guide/tutorial or reading documentation?

See above.

Expected behavior

Be able to specify BIND_USER and BIND_PW for a non-anonymous ldap bind. Add a working administrative user to vCenter no matter what the domain value is.

Current behavior

The options BIND_DN and BIND_PW no longer exist. I guess that due to internal LDAP changes they are now called USERNAME and PASSWORD, which clashes with the options defined by the module itself.
I tried editing the module and changed every occurence of USERNAME to "ADD_USERNAME" and PASSWORD to "ADD_PASSWORD". This seemed to work (metasploit reports that the user has been added and a subsequent call to auxiliary/gather/vmware_vcenter_vmdir_ldap showed the newly created username), but somehow the web interface still reports "Invalid credentials". I suppose this might be due to the fact that the add_admin function uses the static value 'vsphere.local' in two places. It is however also possible that this is due to something entirely else.

Metasploit version

6.3.19-dev, freshly updated apt package on Kali Linux.

[github-actions]

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

[shaaati]

I suppose this is still open (although I can't validate because I no longer have access to the vulnerable instance).

[adfoster-r7]

I haven't replicated, but I can see how there might be issues here. I don't have access to a test env to fix the module though.

[shaaati]

I currently have another client with a vulnerable vCenter instance and stumbled upon the same problem.

This time the module worked after I had changed all occurrences of USERNAME and PASSWORD in the code.

I don't know why it didn't work last time. Maybe it is indeed an issue that the code assumes a static value of "VSPHERE.LOCAL". This time, my client uses this standard value.

I can try to create a pull request with my (rather trivial) fixes later on, but I suppose it would be more useful if someone with more knowledge of VMware LDAP has a look at this.

[adfoster-r7]

Thanks for taking a look, if you want to put up a PR that would be awesome! 💯

[HynekPetrak]

I'll do this week. I'm sorry been too busy

[HynekPetrak]

I'm done with the code change and will sumbit the PR later today.

[HynekPetrak]

@shaaati please test. You can download the proposed version of the module and replace your local one. Make backup!

[shaaati]

I tested the PR on Friday, the last day of my assignment, and it seemed to work fine. Since I didn't want to create another account on my client's system I used the same credentials as before and it worked up to the point where it said "user already exists".

@HynekPetrak I saw that you highlighted the code part where it checks for authentication alread being completed in your PR. I don't think this needs rework because it works for me. The instance I was testing this on was not vulnerable against the auth bypass.

One thing I found though is that the PR version of the module still uses the hard-coded "vsphere.local" part. I don't have an environment where I could test this on (actually, right now I have no test environment at all) but I think that this might still cause problems in Installations where they don't use the default domain name.

[HynekPetrak]

@shaaati the part I marked for rework I actually corrected prior your testing.

Regarding base_dn I would leave for future PR, as soon as I setup test environment in upcoming weeks. I suggest the current PR to go as is.