During a recent penetration testing engagement, I came across a particularly interesting web application called RLM, running on the non-standard port 5054, which naturally caught my eye. After a bit of poking around, I was able to identify a critical vulnerability which allowed me to execute code on the server, eventually leading to full domain compromise.
Regrettably, despite my best efforts, the vendor has refused to issue patches as they do not believe these findings to be vulnerabilities (see vendor response below).
In the interest of responsible disclosure, the details are as follows:
Vendor: Reprise Software (//www.reprisesoftware.com)
Product: RLM
Version Affected: 12.2BL2 and earlier
Description:
"RLM provides all the features you need and expect from an enterprise-class license manager, yet it is familiar and easy to administer, either on premises or in the cloud."
Unfortunately, the RLM web app running on port 5054 allows attackers to specify an arbitrary license file on the server to read and modify. Exploiting this vulnerability in the web interface provided by rlm.exe, can result in information leakage or remote code execution via upload of malware.
An XSS (reflected) vulnerability also exists in the license editor and is described later in the article.
Attackers can use the RLM web interface to read and write data to any file on disk as long as rlm.exe has access to it. By default, RLM's web server running on port 5054, does not require authentication.
To achieve remote code execution, this vulnerability can be used to write malware to either:
The following example will write the ConfigureProfile.bat reverse shell to the user startup folder %APPDATA%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\. This attack does not require administrative access and can be used to execute code if RLM is running as a low-privilege user.
In order to find rlm.exe's user context and a writeable Start Menu Startup folder, we can use the web-based diagnostics tool: //TARGET:5054/goforms/diagnostics
A diagnostics text file will be generated in a user-specified location, which can be read using the web-based license editor:
The following Empire reverse shell will be written to C:\Users\Bob\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\ConfigureProfile.bat:
The malware contents are passed via lfdata and the target path is specified by lf:
ConfigureProfile.bat will execute when the user Bob logs in again. Combining this attack with a denial of service attack could expedite a fresh login or reboot.
If rlm.exe is running with elevated privileges, it may be better to write the shell to %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup\ instead.
A cross-site scripting vulnerability exists in the lf parameter of the /goform/edit_lf_get_data URL in RLM's web interface.
RLM does not enforce POST for this URL and the payload can also be passed with a GETrequest.
The payload is passed via the lf parameter either through POST or GET:
Vendor was contacted but refused accept that this was a security risk or to issue a patch. During our email correspondence the general theme could be wrapped up in the following quotes:
"We tell end users not to run the rlm server (which implements the web server) in privileged mode. There is no reason it needs to run with elevated privileges."
Good. That's good practice. Of course they're aware that users ignore your best practices and typically leave defaults in place, right?
"The license and options file editors in the web interface are no more dangerous than notepad or wordpad."
Um, not quite, unless you give access to Notepad or Wordpad on your system to anyone with access to the RLM port. We attempted to explain the difference between an anonymous remotely accessible file editor and notepad.exe, but the vendor's final response was:
"We do not consider this a vulnerability, any more than vi or notepad are vulnerabilities. Of course, NO ONE should run the servers as root/administrator; if they do, they deserve what they get. They can, also, disable the web interface, or, if they want to run it, they can enable logins for it. So there are plenty of opportunities for an admin to prevent any file writing."
While it's pretty obvious that this support person was not well educated on the potential risk here, the real issue isn't the support staff but an organization that has no approved process to accept third party vulnerability reports. While their response might sound hostile, there was no escalation path for this support person.
The biggest problem we run into during the disclosure process is getting the disclosure in front of the correct audience. Even though these vendors are basically getting a free audit that helps them secure their products for their customers, we are often met with hostility simply because they are unsure how to handle the report. If you don't have the capability to support this process in house there are third party options like Bugcrowd that can get you started and manage the process for you.
If you must use the web server component: