No fix KrbRelay VMware style

TL;DR

The VMware Enhanced Authentication plugin that is offered as part of VMware vSphere’s seamless login experience for the web console contains multiple vulnerabilities relating to Kerberos authentication relay.

The first vulnerability, CVE-2024-22245, is a Kerberos relay vulnerability where a malicious public website can communicate with the Enhanced Authentication Plugin (EAP) and request arbitrary Kerberos service tickets on behalf of the user visiting the malicious site.

The second, and is logged under CVE-2024-22250, is a session hijack vulnerability where local users can request Kerberos tickets from other users during authentication to the VMware vSphere web console.

Unfortunately, VMware have decided not to fix the issue as they deem the enhanced authentication plugin as no longer supported, even though the vSphere 7 product line that uses the plugin remains supported until April 2025.  The general recommendation is to simply remove the enhanced authentication plugin from all client devices.

We were disappointed that VMWare took 5 months to advise clients to uninstall the plugin. This could have been achieved so much faster.

The VMware advisory can be found here VMSA-2024-0003 (vmware.com)

VMware Enhanced Authentication Plugin

EAP can be installed by enterprises wishing to support seamless SSO experience when using the vCenter web administration console.  When installed, the plugin registers a URL handler for the vmware-plugin:// scheme and a relaying service that enables support for handling multiuser scenarios.

Figure 1. Enhanced Authentication Plugin offered during vCenter login

During authentication to vCenter using the “Use Windows session authentication” checkbox, the login page generates a random session ID and initiates a request to the registered URL scheme:

vmware-plugin://csd/?sessionId=1234567890&appName=ui&version=2016

This will trigger a helper process to launch to facilitate requesting Kerberos tickets from the browser login page to a simple WebSocket based API hosted by the helper process.

CVE-2024-22245

A malicious website can also trigger the same authentication flow that the typical vCenter login page uses.  EAP will notify the end user that a website is trying to communicate with the plugin which the user must accept, but an unsuspecting user who accepts the request is then vulnerable to attack.

Figure 2. Popup dialog indicating the website is communicating with the plugin.

A malicious website can then request Kerberos tickets for any service within the victims Active Directory network as the victim user.

After one simple WebSocket command to initialize the connection is made, a second command can then be sent to request any Kerberos service ticket.

Figure 3. WebSocket command used to request Kerberos ST’s.

The helper process will then obtain the requested service ticket and respond with a valid AP-REQ response that can be forwarded to services that are enabled for Kerberos authentication, including services such as Azure seamless SSO that do not require line of sight to on-premises hosts.

Figure 4. Kerberos AP-REQ returned that can be forwarded to the target service to authenticate.

CVE-2024-22250

The second vulnerability is related to weak permissions set on the VMware EAP log file stored within the ProgramData folder.  During the initialisation of a new login session, the helper agent will log the random session ID generated by the vCenter login page.

Because the log file is configured to allow any local user to read the file, an automated script can be setup to read from the log file and listen for new session ID’s.

Once a new session ID is logged, the same WebSocket commands can be used as demonstrated above during exploitation of CVE-2024-22245 to request arbitrary service tickets on behalf of users within other sessions.  The attacker can then access Kerberos related services configured within the Active Directory network as the hijacked user from the other session.

Figure 5. Python script setup to listen for new sessions and hijack the user.

Unlike the first CVE, this one does not require an interaction with a suspicious website.  The attacker simply waits for the authentication to occur to a legitimate vCenter login page to hijack the user session.

Disclosure

Disclosure was a somewhat cumbersome experience.  There was circa 6 weeks delay from the time of disclosure before VMware confirmed that there was a problem even though the initial disclosure emails contained simple POC’s for both issues.  In some cases, a basic understanding of risks around requesting arbitrary SPN’s seem to be missing altogether.  It’s also frustrating that VMware took 126 days to essentially publish a no fix disclosure.  This could have been disclosed a lot sooner.

I am somewhat disappointed that a no fix will be made, therefore the only option for customers still running vSphere 7 is for the complete removal of the enhanced authentication plugin from endpoint devices.  Unfortunately, this does mean that you will no longer be able to perform SSO based authentication to the vSphere v7 web console and will be forced to upgrade to the v8 product line even though v7 is still supported if you still wish to leverage SSO.

17/10/2023 – Initial disclosure to VMWare.

18/10/2023 – Investigation started and case VSRC-20590 assigned.

27/10/2023 – VMware request recording of POC, and specific configuration settings and versions.

31/10/2023 – Recordings provided, and additional reproduction steps provided.

15/11/2023 – Follow up email sent to VMware to determine if they have managed to reproduce the issues.

15/11/2023 – VMware responded, indicating that they have not reproduced the issue yet and will respond soon.

16/11/2023 – Additional information requested from VMware on Kerberos based registry keys, Smartcard settings (WTF), and browser settings.

16/11/2023 – A frustrated response indicating that all registry keys are default, and the issue is not related to the browser but the enhanced authentication plugin that provides SSO to the browser during vCenter authentication.  Additional clarification was also provided on the significance of being able to request any SPN’s within the domain, including ones that are unrelated to vCenter authentication.

01/12/2023 – VMware finally reproduce the issue.  VMware indicate that the enhanced authentication plugin is no longer supported, despite the 7 series of vSphere still supported until April 2025.

01/12/2023 – Guidance given to VMware of potential fixes that wont leave customers vulnerable until general support ends in 2025.

09/01/2024 – VMware indicate they will not be ready for disclosure after the 90 days disclosure terms and request a 30-day extension.  Extension provided.

12/02/2024 – VMware asked for an update since the 30-day extension had now lapsed.

12/02/2024 – VMware respond with a planned disclosure date of 20/02/2024.

20/02/2024 –  VMware published advisory.