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)
Version Affected: 12.2BL2 and earlier
"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.
PoC: RCE with Arbitrary File Write
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:
- User AppData Startup folder:
- (if rlm.exe is privileged) IIS webroot:
- (if rlm.exe is privileged) All Users Startup folder:
Example RCE via user startup folder
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
Writing the malware to disk
The malware contents are passed via
lfdata and the target path is specified by
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.
rlm.exe is running with elevated privileges, it may be better to write the shell to
%PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup\ instead.
PoC: Reflected XSS in RLM
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
XSS payload reflected in response
The payload is passed via the
lf parameter either through
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:
- Do not run RLM with high-privilege
- Limit network access to the RLM web server
- Enable strong authentication for RLM web server
- 05/18/2018 - Vulnerability disclosed to vendor
- 05/18/2018 - Vendor refuses to patch, insisting these are not vulnerabilities
- 05/21/2018 - Vendor is encouraged to reconsider and patch
- 06/04/2018 - Vendor chooses to discontinue communication
- 07/18/2018 - Public disclosure