IDRM has an API endpoint at /albatross/saml/idpSelection that associates an ID provided by the attacker with a valid user on the system. The method that handles this endpoint is shown below:
This method accepts an arbitrary sessionId and username parameters from the HTTP request, and if username exists on the application’s user database, it then associates that sessionId to the username.
IDRM exposes an API at /albatross/restAPI/v2/nmap/run/scan that allows an authenticated user to perform nmap scans. The call stack and relevant code is pasted below:
Having access to nmap allows running arbitrary commands if we upload a script file and then pass that as an argument to nmap with “–script=<FILE>”. However, to achieve code execution in this way it 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>”.
IDRM exposes an API at /albatross/eurekaservice/fetchLogFiles that allows an authenticated user to download log files from the system. However, the logFileNameList parameter contains a basic directory traversal flaw that allows an attacker to download any file off the system.
The administrative user in the IDRM virtual appliance is “a3user”. This user is allowed to login via SSH and run sudo commands, and it is set up with a default password of “idrm”.
When combined with vulnerabilities #1 and #2, this allows an unauthenticated attacker to achieve remote code execution as root on the IDRM virtual appliance, leading to complete system compromise.
While IDRM forces the administrative user of the web interface (“admin”) to change its password upon first login, it does not require the same of “a3user”.
IBM Data Risk Manager 2.0.2 and 2.0.3
Vendor has not fixed the issue yet.