There was a new VMware Security Advisory (VMSA-2024-0003) that was published this week that affects the deprecated VMware Enhanced Authentication Plug-in (EAP) and as part of the remediation, per VMware KB 96442, there are instructions on how to uninstall the EAP plugin from desktop systems that had it installed.
I also noticed there were also questions from the community about disabling the EAP download itself, which is available as a hyperlink from the vSphere UI login page as shown in the screenshot below.
Having spent some time exploring and customizing the vSphere UI login page back in 2015, I knew there were a few ways of either blocking and/or removing the download URL all together, so I figure I would put together the list of options depending on what users were comfortable with.
Disable "Use Windows session authentication" from vSphere UI:
The EAP plug-in is to used in-conjunction with the "Use Windows session authentication" check-box that is available in the vSphere UI. If you wish to disable the functionality all together, thanks to Reddit user r/always_salty, who shared the trick earlier this week by using the sso-config.sh utility to disable Windows Auth completely by running the following command on the vCenter Server Appliance (VCSA):
sso-config.sh -set_authn_policy -winAuthn false -t vsphere.local
Note: The use of this command has been updated in VMware KB 96442 but was not there originally, so I suspect they may have saw it from Reddit (as I did as well).
Redirect EAP download URL to localhost:
While you can uninstall EAP plug-in and disable Windows Auth completely, the download URL is still visible for anyone on a Windows desktop (does not show up if you are on a Linux or macOS system when opening the vSphere UI). If you take a closer look, you will see that the URL to the EAP plugin is not actually hosted on the VCSA but rather on VMware's website. One easy trick that you can use is to simply update the /etc/hosts file on the VCSA to redirect the hostname vsphereclient.vmware.com to localhost (127.0.0.1), so that when the user clicks on the link, it will not go any where. To do so, login to VCSA and add the following entry to the /etc/hosts file:
127.0.0.1 vsphereclient.vmware.com
Note: Alternatively, if you have the ability to block a specific URL within your organization, this would be a more scalable option that can be managed by your networking team rather than making changes to the individual VCSA.
Change EAP download URL:
Redirecting the EAP download URL to localhost is a nice trick, but it does not actually change the URL string itself, which is visible when you hover or right click on the link. If you wish to change the URL, then we need to modify the following section below in /usr/lib/vmware-sso/vmware-sts/webapps/ROOT/resources/js/websso.js
// builds a complete url for the CIP plugin
var createCompleteUrl = function createCompleteUrl() {
var url = 'http://vsphereclient.vmware.com/vsphereclient/' +
'VMware-EnhancedAuthenticationPlugin-' +
cipBuildVersion +
'.exe';
return url ;
};
and change the url variable to your desired url.
// builds a complete url for the CIP plugin
var createCompleteUrl = function createCompleteUrl() {
var url = 'http://no.eap.download.for.you';
return url ;
};
When you open a new session to the vSphere UI login page, you will now see that URL has been replaced with the one you have configured.
Note: Modifications to the default websso.js entries are not persisted upon patching and upgrades and this would need to be re-applied if you are updating VCSA.
Remove the EAP download URL:
If we wanted to take this one step further and simply prevent the EAP download URL to ever show up, then we can use the existing code that prevents the URL from showing up when it detects you are on a Linux or macOS system and make a small adjustment in /usr/lib/vmware-sso/vmware-sts/webapps/ROOT/resources/js/websso.js
if (this._VersionStr != null || !isVCLogin()) {
$('#footer').html('');
} else {
if (!isMac && !isLinux) {
var cspDownloadLink = createCompleteUrl();
$('#downloadCIPlink').attr('href', cspDownloadLink);
$('#downloadCIPlinkBox').show();
}
}
to basically negate default and ONLY display it if it detects you have both a macOS and Linux system, which is basically impossible as it would only detect one or the other, but this small tweak of removing the "!" would make it such that it will never display the EAP download URL for any client system regardless of OS.
if (this._VersionStr != null || !isVCLogin()) {
$('#footer').html('');
} else {
if (isMac && isLinux) {
var cspDownloadLink = createCompleteUrl();
$('#downloadCIPlink').attr('href', cspDownloadLink);
$('#downloadCIPlinkBox').show();
}
}
When you open a new session to the vSphere UI login page, you will now see that EAP URL that used to be rendered is no longer showing up for any client browser:
Note: Modifications to the default websso.js entries are not persisted upon patching and upgrades and this would need to be re-applied if you are updating VCSA.
“ Alternatively, if you have the ability to block a specific URL within your organization, this would be a more scalable option that can be managed by your networking team”
speaking of networking team, I was hoping for a solution based on NSX ALB haha 🙂
IIRC, NSX-T also has this capability but never used myself but I know most organizations have ways to manage allow/deny endpoints using various technologies, so figure I mention that
Honestly, if VMware knows this installer creates problems. Why not remove it from their own site so the download doesn't work. Kind of irresponsible of them in the first place...
Someone just shared that it looks like it may have been removed. Not in front of computer to check
excellent point actually. It also shows how we sometimes try to overengineer our life 🤣
Nope, looks like the download, at least for 6.7 is still there (e.g. http://vsphereclient.vmware.com/vsphereclient/VMware-EnhancedAuthenticationPlugin-6.7.0.exe)
Our organization is using PAM solution which does not expose Windows AD privileged accounts passwords to users who use these privileged accounts on jump hosts to login to vSphere Client using the EAP and Windows Session authentication. The users cannot know the passwords, as these are managed and auto rotated by PAM.
How to login to vSphere Client with Windows session authentication, if we now have to uninstall the EAP?
By following William's earlier post https://williamlam.com/2018/05/changes-to-vsphere-client-login-ui-customizations-in-vsphere-6-7.html for how to do this in vCenter 8 (there is only a ROOT.war file now), I ended up with this:
cp /usr/lib/vmware-sso/vmware-sts/webapps/ROOT.war /usr/lib/vmware-sso/vmware-sts/webapps/ROOT.war.bak
mkdir /root/ROOT
cp /usr/lib/vmware-sso/vmware-sts/webapps/ROOT.war /root/ROOT/
cd /root/ROOT
unzip ROOT.war
rm ROOT.war
vim resources/js/websso.js
(for vCenter 8U2a I had to edit line 321-324 or line 306, depending on what I wanted to do)
zip -r /root/ROOT.war index.jsp META-INF resources WEB-INF
cp /root/ROOT.war /usr/lib/vmware-sso/vmware-sts/webapps/ROOT.war
cd /root/
rm /root/ROOT -rf
rm /root/ROOT.war
reboot
I'm running v8.0.0.10100 Build number: 20920323 & 8.0.2.00100
Build number: 22617221 on several dev vcsa,
the path to the websso.js was /var/lib/sso/webapps/ROOT/resources/js/websso.js
Just an FYI... The websso.js in 8.0.2 is located in /var/lib/sso/webapps/ROOT/resources/js/websso.js
I used the option to remove and found the line to edit was line 306. Worked great! No more footer.
Have you rebooted after you changed the file? My suspicion is that the file will be owerwriten from the ROOT.war file /usr/lib/vmware-sso/vmware-sts/webapps/ROOT.war, but I don't really know how the java/tomcat thing (re)deploys applications. I have a comment further up where I unpacked the ROOT.war, edited it (line 306 yes for 8U2a for removing it) and re-zipped the files (and rebooted). That at least stayed persistent after a reboot. Would love to know if your edit stays persistent Eric, after a new reboot.
Excellent point and I'm glad you asked. I have a lab that is 8.0.2 that I first tested this on to validate. I had not rebooted. I just did this and found the footer is still not visible. To make sure, I logged into a jumpbox and opened a new InPrivate browser and the footer is still not visible. So, short of a patch over-writing this, it works through a reboot.
Thanks.
Great, thanks for checking.
I can also confirm my way of extracting the ROOT.war file, editing the websso.js and repackage works fine. Just did a reboot of on our test-environment and still no link.
Hope VMware removes it in 8U3 or makes it a configurable option to hide it.
Are the vCenter versions 7.0 and above affected or this only affects vCenters 6.7 and below ?
I can't seem to find the download link at the bottom of their /ui pages before you login.
Thanks !
What about other IWA clients such as RV Tools or PowerCLI?
Thankyou for posting this William. It was me that posted on VMTN 🙂
I also raised a support ticket, and asked if switching AD auth to LDAPS (which is best practise anyway) would close the vulnerability, but they were unable to confirm. The additional Q&A for this advisory (which is typically failing to load atm due to a 502 error) wasn't entirely clear on this point either.
Do you happen to know if it does?
Instead of the logic hack to the if statement, just add false to it to make it clearer that it's hacked to disable it:
if (false && !isMac && !isLinux) {
https://vsphereclient.vmware.com/vsphereclient/VMware-EnhancedAuthenticationPlugin-6.7.0.exe --> finnally Blocked.
Will Vmware develop a new authentication Plugin? For me it was Useful.