★且听安全★-点关注，不迷路！

★漏洞空间站★-优质漏洞资源和小伙伴聚集地！

公众号前面分析的 VMware Workspace ONE Access 漏洞：

CVE-2022-22957 VMware Workspace ONE Access JDBC注入导致RCE

QCyber，公众号：且听安全漏洞空间站上线啦！！CVE-2022-22957 VMware Workspace ONE Access JDBC注入导致RCE

CVE-2022-22954 VMware Workspace ONE Access SSTI漏洞

QCyber，公众号：且听安全【最新漏洞预警】CVE-2022-22954 VMware Workspace ONE Access SSTI漏洞

5月18日 VMware 官方又通报了 VMware Workspace ONE Access 和 VMware vRealize Automation 等多个产品存在授权问题漏洞，该漏洞源于处理身份验证请求时 UI 中的错误。远程攻击者可以实现绕过身份验证过程并获得对应用程序的管理访问权限：

下面将分析与复现的过程分享大家。

环境搭建可以参考前面的分析文章。既然是认证绕过漏洞，首先分析一下 VMware Workspace ONE Access 的登录过程：

登录过程抓包如下：

当我们尝试修改 HOST 头的取值后再发送请求，会发现在日志文件 `/opt/vmware/horizon/workspace/logs/horizon.log` 中捕获到如下异常：

从报错信息可以看出，在认证过程中尝试向提供的 HOST 发送 HTTP 请求，因为 `Test` 解析不到地址而抛出了异常。

程序采用 Spring 框架，认证请求的 URL 为 `/auth/login/embeddedauthbroker/callback` 。对应的代码位于 `com.vmware.horizon.service.controller.auth.LoginController#doLoginEmbeddedAuthBrokerCallback` ：

从报错信息可以看出，整个认证调用栈非常长，我们根据调用栈直接在 JAR 包 `local-password-auth-adapter-0.1.jar` 存在 `login` 的关键位置打上断点`com.vmware.horizon.adapters.local.LocalPasswordAuthAdapter#login` ：

`login` 函数尝试提取请求参数，然后传递给 `authenticate` 进行认证，这里关注提取参数 `endpoint` 的过程，进入 `getLocalUrl` 函数：

private String getLocalUrl(HttpServletRequest request) {        if (null == request) {            return null;        } else {            try {                return (new URL(SSLConst.HTTPS, request.getServerName(), request.getServerPort(), request.getContextPath() + "/API/1.0/REST/auth/local/login")).toString();            } catch (MalformedURLException var3) {                log.error("Failed to create URL: " + var3.getMessage(), var3);                return null;            }        }    }

构造了一个 HTTPS 的请求，其中的主机名通过 `request.getServerName` 直接从 HOST 头获取，显然我们可以进行伪造。再回来查看 `authenticate` 函数：

构造 POST 请求通过 `execute` 进行发送，并且直接根据请求返回的状态码判断是否认证成功，如果返回 200 就认为认证成功，因为请求的主机名可以通过 HOST 头进行伪造，所以我们可以手动构造一个恶意 HTTPS 服务对请求始终返回 200 ，从而实现认证绕过。

首先构造一个 HTTPS 服务器，需要添加合法证书，我们可以直接在互联网上寻找一个合法的 HTTPS 服务 （对所有请求都返回 200 ）：

显示认证绕过，但是在响应包中并没有发现有效的 Cookie 信息，查看日志：

报错信息提示用户不存在，进一步分析发现 HTTPS 请求通过认证后，还会调用函数 `lookupUserByAuthnAdapterResponse` 对用户名进行检查：

所以请求提供的用户名必须是存在的，修改后发送请求，最终绕过认证获取到了合法 Cookie ：

CVE-2022-22972 漏洞产生的原因是系统在认证过程中尝试将账号密码信息通过 HTTPS 发送到另一个服务进行认证，但是仅仅从 HOST 头来提取认证主机地址，并且简单通过返回状态码是否为 200 来判断是否认证通过，从而导致可以伪造 HTTPS 服务来实现认证绕过。在漏洞复现过程中，并不需要自己去构造 HTTPS 服务，可以在互联网上寻找一个存在合法证书，并且对 URL 请求始终返回 200 的 HTTPS 服务。同时在调试过程中发现，默认状态下还要对提交的用户名进行检查，所以在构造请求时还必须保证用户名是真实存在的。

结合 CVE-2022-22957 可以构造一条匿名 RCE 的利用链。可以参考：

CVE-2022-22957 VMware Workspace ONE Access JDBC注入导致RCE

QCyber，公众号：且听安全漏洞空间站上线啦！！CVE-2022-22957 VMware Workspace ONE Access JDBC注入导致RCE

有兴趣获取完整漏洞分析过程的小伙伴，请加入我们的漏洞空间站-致力于打造优质漏洞资源和小伙伴聚集地！

由于传播、利用此文档提供的信息而造成任何直接或间接的后果及损害，均由使用本人负责，且听安全团队及文章作者不为此承担任何责任。

★且听安全★-点关注，不迷路！

★漏洞空间站★-优质漏洞资源和小伙伴聚集地！