UPDATED
Four serious security vulnerabilities in the IBM Data Risk Manager (IDRM) have been identified that can lead to unauthenticated remote code execution (RCE) as root in vulnerable versions, according to analysis – and a proof-of-concept exploit is available.
IBM weighed in on the problem this week, after a researcher went public with the bugs, one of which may end up being a zero-day issue — Big Blue is still investigating.
IDRM is a software platform that aggregates threat data from disparate security systems, in order to perform enterprise security risk analysis. According to security researcher Pedro Ribeiro from Agile Information Security, older versions (v. 2.0.1 to 2.0.3) of the IDRM Linux virtual appliance contains bugs pertaining to authentication bypass; command injection; insecure default password; and arbitrary file download. The first three can be chained together to achieve RCE in vulnerable versions.
“IDRM is an enterprise security product that handles very sensitive information,” Ribeiro wrote in a Tuesday analysis. “The hacking of an IDRM appliance might lead to a full-scale company compromise, as it stores credentials to access other security tools, not to mention it contains information about critical vulnerabilities that affect the company.”
Three Chained Bugs for RCE
The first three bugs that Ribeiro found can be combined to allow a remote attacker to gain full system compromise, according to the research.
The first is as-yet unaddressed by IBM: An authentication-bypass issue that exists in the appliance’s API endpoint, /albatross/user/login. This endpoint is authenticated by a method that takes the username and sessionID credentials of the person trying to log in, and checks if username exists in the database and if the sessionId is associated with that username. If it all checks out, the application returns a newly generated random password for that username. However, Ribeiro demonstrated that a remote attacker can send a specially crafted request that subverts this process and allows an attacker to retrieve a valid Bearer administrative token. That can then be used to access various APIs.
“It’s also possible to login as a normal web user on the /albatross/login endpoint, which will yield an authenticated cookie instead of a token, allowing access to the web administration console,” explained the researcher. “In any case…authentication is now completely bypassed and we have full administrative access to IDRM.”
The command-injection bug, which has a patch, meanwhile exists because the IDRM exposes an API at /albatross/restAPI/v2/nmap/run/scan that allows an authenticated user to perform nmap scans.
“Having access to nmap allows running arbitrary commands, if we can upload a script file and then pass that as an argument to nmap with –script=<FILE>,” the researcher explained. “However, to achieve code execution in this way, we still need to upload a file. Luckily, there is a method that processes patch files and accepts arbitrary file data, saving it to /home/a3user/agile3/patches/<FILE>.”
That method is supposed to accept a patch file, process it and apply it. However, Ribeiro explained that “there are several bugs in version 2.0.2 that cause the method to abort early and fail to process the file. Still, the file is uploaded and kept on disk even after the method aborts.”
In order to exploit this bug, an attacker would need to have an authenticated session as an administrator, which can be achieved with the first vulnerability.
The third bug, which IBM says can be solved by reconfiguring the appliance, comes from the use of hard-coded credentials: The administrative user in the IDRM virtual appliance is “a3user” by default.
“This user is allowed to login via SSH and run sudo commands, and it is set up with a default password of ‘idrm,'” said Ribeiro.
And, when combined with the first two bugs, this allows an unauthenticated attacker to achieve RCE as root on the IDRM virtual appliance, leading to complete system compromise, the researcher said.
A Metasploit proof-of-concept exploit module implementing the full RCE chain has been released and a video demonstration can be found here.
Arbitrary File Download
The fourth bug, also fixed in later versions, is a path traversal bug that comes from an improper limitation of a pathname to a restricted directory.
“IDRM exposes an API at /albatross/eurekaservice/fetchLogFiles that allows an authenticated user to download log files from the system,” explained Ribeiro. “However, the logFileNameList parameter contains a basic directory traversal flaw that allows an attacker to download any file off the system.”
He added that exploitation is “very simple.”
This flaw too can be chained. When combined with the first authentication-bypass bug, an unauthenticated attacker can download any file readable by “a3user” off the system, Ribeiro said. A second Metasploit module implementing this was released and a video demo can be found here.
Patch Information and Mitigation
Versions 2.0.1 to 2.0.3 have been confirmed as vulnerable to the first three flaws, according to Ribeiro; as for the fourth issue, version 2.0.1 is not vulnerable, but v. 2.0.2 and 2.0.3 are. According to IBM’s advisory, issued on April 22 after Ribeiro disclosed his findings, the command-injection vulnerability and the arbitrary-file download bug were both fixed in version 2.0.4. IBM also said that the default-password issue is a configuration choice and up to administrators to change (guidance available here).
As for the first vulnerability, the authentication bypass, IBM said in the advisory that it is “investigating this report and will provide further information on fix action as appropriate.”
The current version of the IDRM is v. 2.0.6.
Initially, Ribeiro made an attempt to coordinate disclosure with IBM via CERT/CC, but IBM did not accept the vulnerability report for review:
“We have assessed this report and closed as being out of scope for our vulnerability disclosure program since this product is only for ‘enhanced’ support paid for by our customers,” according to Big Blue’s response to CERT/CC. “This is outlined in our policy https://hackerone.com/ibm. To be eligible to participate in this program, you must not be under contract to perform security testing for IBM Corporation, or an IBM subsidiary, or IBM client within six months prior to submitting a report.”
However, after Ribeiro made his findings public, Big Blue said the rejection was a mistake.
“A process error resulted in an improper response to the researcher who reported this situation to IBM,” a spokesperson told Threatpost on Tuesday. “We have been working on mitigation steps and they will be discussed in a security advisory to be issued.”
This article was updated at 4 p.m. ET on Tuesday, April 21 with a statement from IBM, and at 10 a.m. ET on Wednesday, April 22 with fresh advisory information from IBM.
Worried about your cloud security in the work-from-home era? On April 23 at 2 p.m. ET, join DivvyCloud and Threatpost for a FREE webinar, A Practical Guide to Securing the Cloud in the Face of Crisis. Get exclusive research insights and critical, advanced takeaways on how to avoid cloud disruption and chaos in the face of COVID-19 – and during all times of crisis. Please register here for this sponsored webinar.
