No fix KrbRelay VMware style

TL;DR TL的;博士

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.
VMware vSphere 的 Web 控制台无缝登录体验中提供的 VMware 增强身份验证插件包含多个与 Kerberos 身份验证中继相关的漏洞。

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.
第一个漏洞 CVE-2024-22245 是一个 Kerberos 中继漏洞，恶意公共网站可以与增强身份验证插件 （EAP） 通信，并代表访问恶意站点的用户请求任意 Kerberos 服务票证。

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.
第二个漏洞（记录在 CVE-2024-22250 下）是一个会话劫持漏洞，本地用户可以在对 VMware vSphere Web 控制台进行身份验证期间向其他用户请求 Kerberos 票证。

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.
遗憾的是，VMware 决定不修复此问题，因为他们认为不再支持增强型身份验证插件，尽管使用该插件的 vSphere 7 产品线在 2025 年 4 月之前仍受支持。 一般建议是简单地从所有客户端设备中删除增强的身份验证插件。

We were disappointed that VMWare took 5 months to advise clients to uninstall the plugin. This could have been achieved so much faster.
我们感到失望的是，VMWare 花了 5 个月的时间建议客户卸载插件。这本来可以更快地实现的。

The VMware advisory can be found here VMSA-2024-0003 (vmware.com)
可在此处查看 VMware 公告：VMSA-2024-0003 （vmware.com）

VMware Enhanced Authentication Plugin
VMware 增强型身份验证插件

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.
希望在使用 vCenter Web 管理控制台时支持无缝 SSO 体验的企业可以安装 EAP。 安装后，该插件会为 vmware-plugin：// 方案注册一个 URL 处理程序和一个中继服务，以支持处理多用户方案。

Figure 1. Enhanced Authentication Plugin offered during vCenter login
图 1.vCenter 登录期间提供的增强型身份验证插件

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:
在使用“使用 Windows 会话身份验证”复选框对 vCenter 进行身份验证期间，登录页面会生成一个随机会话 ID，并启动对已注册 URL 方案的请求：

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.
这将触发一个帮助程序进程启动，以便于从浏览器登录页面向帮助程序进程托管的基于 WebSocket 的简单 API 请求 Kerberos 票证。

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.
恶意网站还可以触发典型 vCenter 登录页面使用的相同身份验证流程。 EAP 将通知最终用户网站正在尝试与用户必须接受的插件进行通信，但接受请求的毫无戒心的用户很容易受到攻击。

Figure 2. Popup dialog indicating the website is communicating with the plugin.
图2.弹出对话框，指示网站正在与插件通信。

A malicious website can then request Kerberos tickets for any service within the victims Active Directory network as the victim user.
然后，恶意网站可以作为受害者用户请求受害者 Active Directory 网络中任何服务的 Kerberos 票证。

After one simple WebSocket command to initialize the connection is made, a second command can then be sent to request any Kerberos service ticket.
在发出一个简单的 WebSocket 命令来初始化连接后，可以发送第二个命令来请求任何 Kerberos 服务票证。

Figure 3. WebSocket command used to request Kerberos ST’s.
图3.用于请求 Kerberos ST 的 WebSocket 命令。

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.
然后，帮助程序进程将获取请求的服务票证，并使用有效的 AP-REQ 响应进行响应，该响应可转发到启用了 Kerberos 身份验证的服务，包括不需要本地主机视线的 Azure 无缝 SSO 等服务。

Figure 4. Kerberos AP-REQ returned that can be forwarded to the target service to authenticate.
图4.返回的 Kerberos AP-REQ，可转发到目标服务进行身份验证。

CVE-2024-22250 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.
第二个漏洞与存储在 ProgramData 文件夹中的 VMware EAP 日志文件上设置的弱权限有关。 在初始化新登录会话期间，帮助程序代理将记录 vCenter 登录页面生成的随机会话 ID。

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.
由于日志文件配置为允许任何本地用户读取该文件，因此可以设置一个自动脚本来从日志文件中读取并侦听新的会话 ID。

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.
记录新的会话 ID 后，在利用 CVE-2024-22245 期间，可以使用相同的 WebSocket 命令代表其他会话中的用户请求任意服务票证。 然后，攻击者可以作为其他会话中被劫持的用户访问 Active Directory 网络中配置的 Kerberos 相关服务。

Figure 5. Python script setup to listen for new sessions and hijack the user.
图5.Python 脚本设置，用于侦听新会话并劫持用户。

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.
与第一个 CVE 不同，这个 CVE 不需要与可疑网站进行交互。 攻击者只需等待对合法 vCenter 登录页面进行身份验证，即可劫持用户会话。

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.
披露是一个有点麻烦的经历。 从披露时间到现在大约有 6 周的延迟，直到 VMware 确认存在问题，尽管最初的披露电子邮件包含针对这两个问题的简单 POC。 在某些情况下，似乎完全缺少对请求任意 SPN 的风险的基本理解。 同样令人沮丧的是，VMware 花了 126 天才发布无修复披露。 这本可以更早地披露。

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.
我有点失望，不会进行任何修复，因此对于仍在运行 vSphere 7 的客户来说，唯一的选择是从端点设备中完全删除增强的身份验证插件。 遗憾的是，这确实意味着您将无法再对 vSphere v7 Web 控制台执行基于 SSO 的身份验证，并且如果您仍希望利用 SSO，即使 v7 仍受支持，也将不得不升级到 v8 产品线。

17/10/2023 – Initial disclosure to VMWare.
2023 年 10 月 17 日 – 向 VMWare 首次披露。

18/10/2023 – Investigation started and case VSRC-20590 assigned.
2023 年 10 月 18 日 – 调查开始并分配了案件 VSRC-20590。

27/10/2023 – VMware request recording of POC, and specific configuration settings and versions.
2023 年 10 月 27 日 – VMware 请求记录 POC，以及特定的配置设置和版本。

31/10/2023 – Recordings provided, and additional reproduction steps provided.
31/10/2023 – 提供录音，并提供额外的复制步骤。

15/11/2023 – Follow up email sent to VMware to determine if they have managed to reproduce the issues.
2023 年 11 月 15 日 – 跟进发送给 VMware 的电子邮件，以确定他们是否设法重现了问题。

15/11/2023 – VMware responded, indicating that they have not reproduced the issue yet and will respond soon.
2023 年 11 月 15 日 – VMware 做出了回应，表示他们尚未重现该问题，并将很快做出回应。

16/11/2023 – Additional information requested from VMware on Kerberos based registry keys, Smartcard settings (WTF), and browser settings.
2023 年 11 月 16 日 – 请求 VMware 提供有关基于 Kerberos 的注册表项、智能卡设置 （WTF） 和浏览器设置的其他信息。

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.
2023 年 11 月 16 日 – 一个令人沮丧的响应，表明所有注册表项都是默认的，问题与浏览器无关，而是与在 vCenter 身份验证期间向浏览器提供 SSO 的增强身份验证插件有关。此外，还进一步阐明了能够请求域内任何 SPN（包括与 vCenter 身份验证无关的 SPN）的重要性。

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.
2023 年 1 月 12 日 – VMware 终于重现了该问题。VMware 表示，尽管 vSphere 7 系列在 2025 年 4 月之前仍受支持，但不再支持增强型身份验证插件。

01/12/2023 – Guidance given to VMware of potential fixes that wont leave customers vulnerable until general support ends in 2025.
2023 年 12 月 1 日 – 向 VMware 提供潜在修复指南，这些修复程序在 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.
2024 年 9 月 1 日 – VMware 表示，在 90 天的披露期限后，他们无法准备好进行披露，并要求延长 30 天。提供扩展。

12/02/2024 – VMware asked for an update since the 30-day extension had now lapsed.
2024 年 12 月 2 日 – VMware 要求更新，因为 30 天的延期现已失效。

12/02/2024 – VMware respond with a planned disclosure date of 20/02/2024.
2024 年 12 月 2 日 – VMware 做出回应，计划披露日期为 2024 年 2 月 20 日。

20/02/2024 –  VMware published advisory.
20/02/2024 – VMware 发布了公告。

原文始发于pentestpartners：No fix KrbRelay VMware style