CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Unpatched Remote Code Execution in Reprise License Manager

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.

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: %APPDATA%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\
  • (if rlm.exe is privileged) IIS webroot: %SYSTEMDRIVE%:\inetpub\wwwroot\shell.aspx
  • (if rlm.exe is privileged) All Users Startup folder: %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup\

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:

Rlm-diag

The following Empire reverse shell will be written to C:\Users\Bob\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\ConfigureProfile.bat:

Rlm-empire-rev

Writing the malware to disk

The malware contents are passed via lfdata and the target path is specified by lf:

Rlm-poc-1-http

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.

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 GETrequest.

XSS payload reflected in response

The payload is passed via the lf parameter either through POST or GET:

Rlm-poc-2-http

Vendor Response

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.

Recommendations

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

Timeline

  • 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

Latest SpiderLabs Blogs

Fake Dialog Boxes to Make Malware More Convincing

Let’s explore how SpiderLabs created and incorporated user prompts, specifically Windows dialog boxes into its malware loader to make it more convincing to phishing targets during a Red Team...

Read More

The Secret Cipher: Modern Data Loss Prevention Solutions

This is Part 7 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here. Far too many organizations place Data Loss Prevention (DLP) and Data...

Read More

CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway

UPDATE: Palo Alto Networks confirmed on Tuesday (4/16) that disabling device telemetry is no longer considered an effective mitigation. On Wednesday (4/17), the company released new threat signatures...

Read More