Azure Connected Machine Agent Elevation of Privilege Vulnerability: Console Popup

It Is Not a Bug, It Is a Feature

During the installation of the latest version of the agent (1.48), a console popup was observed. Using Process Monitor (procmon) to identify the process responsible for the popup did not yield a result. Assuming the popup may be present during the installation process, a reinstall was attempted. During the reinstallation, the popup appeared again due to the new feature which created a new scheduled task azcmagent. Curious if the popup would flash again when an MSI repair was initiated, Mandiant’s msi_search.ps1 script was used to identify the MSI file in the C:\Windows\Installer\ directory that belonged to Azure Connected Machine Agent. Once identified, the repair functionality was triggered using the command msiexec /fa C:\Windows\Installer\[filename].msi. After the repair functionality triggered the popup, it was investigated if a low-privileged user could also trigger the repair operation. This functionality is usually restricted to privileged users. However, the investigations indicated otherwise in this case.

Ironically, Microsoft introduced a bug while it was supposed to be a feature. The auto-upgrade feature was later implemented in the September release version 1.56.

Description

Azure Arc installer version 1.48 created a scheduled task azcmagent to trigger every day. The installer created the scheduled task with execution time between 01:00 and 02:00 server time. Investigating the MSI with Orca confirmed that it was a CustomAction defined as shown below:

"[%ComSpec]" /c [System64Folder]SCHTASKS.EXE /CREATE /F /SC DAILY /ST 01:[RANDOMMINUTE] /TN azcmagent /TR "[System64Folder]WindowsPowerShell\v1.0\powershell.exe -File '[INSTALLFOLDER]azcmagent_check_updates.ps1'" /RU SYSTEM

While creating the scheduled task, a conhost.exe pop-up was presented for a few milliseconds. Having read Mandiant’s blog as part of the literature review, we wanted to verify if it was a similar console popup bug. To determine the installer name, msi_search.ps1 script by Mandiant was used.

Initiating the repair functionality forced the MSI installer to create a new scheduled task. The scheduled task executable schtasks.exe required the file C:\Windows\SysWOW64\en-US\schtasks.exe.mui for executing. A low-privileged user could use an opportunistic exclusive lock on that file. Once the lock was triggered, the conhost.exe popup did not terminate anymore. The extended time allowed a low-privileged user to reliably escalate their privileges.

Proof of Concept

• Execute the msi_search.ps1 script and locate the MSI installer filename. Once located, set an oplock to add an exclusive lock on the file:

SetOpLock.exe C:\Windows\SysWOW64\en-US\schtasks.exe.mui x

• Execute a repair to trigger the repair function:

msiexec /fa C:\Windows\Installer\<filename>.msi

• Once the opportunistic lock is triggered, a conhost.exe popup with the title c:\windows\SysWOW64\SCHTASKS.EXE is presented.
• Right-click on the title bar and select properties.
• Click on the legacy console mode hyperlink in the Options tab of the properties window.
• Select Internet Explorer as the browser and click on OK.
• In the Internet Explorer window, press Ctrl+O and click on the Browse option in the dialog box.
• In the top bar of the dialog box, enter the name of an arbitrary executable, here cmd is used which opens a command prompt window as the NT AUTHORITY\SYSTEM user.