Vulnerability or Not? Pen Tester Quarrels With Software Maker
19.7.18 securityweek  Vulnerebility

Security Industry Battles Over Testing Methods

Researcher Publishes PoC; Vendor Says it's Not a Vulnerability

A SpiderLabs security researcher has published details of what he considers to be a vulnerability in the RLM web application provided by Reprise Software. Reprise CEO Matt Christiano has told SecurityWeek, it is not a vulnerability.

RLM is the Reprise License Manager, described by Reprise as "a flexible and easy-to-use license manager with the power to serve enterprise users." The researcher is Adrian Pruteanu, security consultant with SpiderLabs at Trustwave.

During a penetration engagement, Pruteanu writes, "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."

Christiano responded, "The issue described in the [SpiderLabs] article is certainly not a vulnerability, it is misuse of the product."

Pruteanu claims RLM allows users (and attackers) to read and write data to any file on disk provided RLM has access to it. By default, RLM's web server running on port 5054, does not require authentication. This allows an attacker to write malware to the user startup folder without administrator access and even if RLM.exe is running under a low-privilege user. If RLM.exe is privileged, the malware can be written to the All Users Startup folder.

Christiano retorts, "RLM does not require elevated permissions to perform any operation, and is designed to be run in a segregated, non-privileged account. To install the program as root/administrator is simply negligent. This is clearly documented."

Christiano goes on to state that port 5054 was assigned to RLM by IANA in 2008. Furthermore, he adds, "License server machines are rarely internet-facing, and when they are, port 5054 is not required for operation, and should not be enabled thru the company's firewall."

The researcher provides a full proof of concept (PoC) for his 'vulnerability'. He also located a cross-site scripting (reflected) vulnerability 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 GET request.

What worries the researcher even more than the vulnerabilities themselves (vulnerabilities can be fixed through responsible disclosure) has been the vendor's support staff response to the disclosure. Pruteanu reports, "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'."

Pruteanu's response is that users typically ignore best practices and leave pre-existing defaults untouched.

Reprise support continued, "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."

Christiano expanded on his support staff comments. He clearly sees the issue as user or installer security misconfiguration (#6 in OWASP's current Top Ten Web Application Risks) rather than a vulnerability. "SpiderLabs refused to identify the 'customer' with this 'problem', denying us the opportunity to review our ISV's installation procedures and correct them," he said.

Of course, SpiderLabs is almost certainly enjoined by customer NDAs not to mention it by name. "One could argue," continued Christiano, "that SpiderLabs cares less about solving the problem than they do about creating sensational headlines to generate more business. I am not arguing that, but one could."

The timeline for the researcher's attempted responsible disclosure is short and limited. Over the course of just 13 days in May 18, the researcher claims that he disclosed the vulnerabilities; the vendor, he says, refused to accept they are vulnerabilities and refused to patch; the researcher encouraged the vendor to reconsider; and the vendor chose to discontinue communication. There was no route to escalate the issue beyond the support person; and Pruteanu feels he had no alternative but to go to public disclosure.

But Christiano refutes this. "We did correspond with SpiderLabs thru June 18 (not May)," he told SecurityWeek, "and described the situation to them; we received no further reply from them until they provided you with this misleading information."

"The biggest problem we run into during the disclosure process," comments Pruteanu "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."

Christiano replies, "It is not at all clear how [SpiderLabs] did their testing, or how the software was installed. Clearly, it was installed incorrectly. Finally, Reprise has never refused to address any security vulnerability in any of our products."

It comes down to whether 'allowing' misconfiguration is in itself a vulnerability. Pruteanu believes it is. Christiano believes it is not, and that software installers have a responsibility to configure applications in the way intended and advised.

Chicago-based data security and compliance solutions firm Trustwave was acquired by Singapore Telecommunications (Singtel) for $810 million in cash in April 2015.