Privilege Escalation in Automate Agent 2020.7 and Below
A Quick Summary
Before I get into great technical detail, here’s the security bug in a nutshell. In Automate versions 2020.7 and below, the Automate agent uses the C:\Windows\Temp\_LTUPDATE\ folder for processing updates without verifying signatures or changing permissions. A simple attack is to take that folder, which is read/write by everyone on a system, even standard users, is to change the permissions on the folder to be read only to system, and replace LabtechUpdate.exe with a malicious executable and the agent will run it after failing to download the proper LabtechUpdate.exe. This will run the executable as system.
How it was discovered
Shortly after installing Automate 2020.7 on my Automate server, I had an agent that failed to update. I did a whole lot of digging into this agent’s problem. In the end, this problem was unrelated to the found vulnerability, but it led me to digging into the update system.
The Problem
Pre-2020.8 Automate downloaded it’s updates to the C:\Windows\Temp\_LTUPDATE\ folder. It downloads one executable that self-unpacks several DLLs and EXEs, not to mention some CONFIG files.
Once unpacked, the update executable then runs Update.exe. All together a pretty simple and effective update system. The Agent is already always on, so it just takes the update request from the servers to kick off the process.
The folders permissions are all inherited from C:\Windows\Temp, which means “Everyone” gets full control over the folder. Which allows an attacker signed in, no matter what their permission levels are, to execute the attack.
Automate is a trusted platform that most AV’s know to mostly ignore. It is, by nature, a high powered, high trust system. So anything it does is less likely to get caught by antivirus software.
How to Exploit
Exploiting is absolutely trivial. Simply change the permissions on the temp folder to remove System’s rights to modify. The update will attempt to download, but fail. CWA will then run whatever executable is in the folder as long as it is named “LabtechUpdate.exe”
After changing the permissions, replace “LabtechUpdate.exe” with a malicious program and wait until the next Automate Agent update. Your executable will lie in wait until Automate decides it’s time to update, then it will pounce. A sufficiently advanced attacker could possibly even trick the system into believing it did a proper update, so no update failure will register in the Automate logs.
The Solution(s)
There are two primary, straight forward, solutions.
- Move the update process to a directory that does not give permissions to non admin users by default or modify the permissions of the _LTUPDATE folder to prevent non-admins from making changes to it.
- Verify the hashes of every update file in the process, including the DLLs and CONFIG file. Signature checking would also be smart for the EXEs and DLLs.
I recommended both solutions to this problem.
Connectwise’s Solution
After my report, Connectwise had the problem solved by the next major release, 2020.8. Which was good turn around. They did not, however, inform me that the problem was fixed. I discovered it myself when upgrading to 2020.9. As far as I can tell(and without feedback from CW it is hard to know for sure), the only mitigation put in place was that the update process went from being stored in C:\Windows\Temp\_LTUPDATE\ to C:\Windows\LTSVC\_LTUPDATE\. This does effectively solve the problem.
What I don’t know is if they added any additional hash or signature checks to the process in case permissions are ever broke for that folder. Or even a permissions check on that folder.
Additional Details
I filed for and was issued the CVE of CVE-2020-15838.
More details of the class of attack can be found here Hijack Execution Flow/Executable Installer File Permissions Weakness
The solution Connectwise chose to solve the problem was Restrict File and Directory Permissions