SSD Advisory – QRadar Remote Command Execution

Vulnerability Summary
Multiple vulnerabilities in QRadar allow a remote unauthenticated attackers to cause the product to execute arbitrary commands. Each vulnerability on its own is not as strong as their chaining – which allows a user to change from unauthenticated to authenticated access, to running commands, and finally running these commands with root privileges.

Sponsorships Available

Vendor Response
The vendor has issued a patch which can be found by visiting this page: http://www.ibm.com/support/docview.wss?uid=swg22015797

CVE
CVE-2018-1418
(NOTE while only a single CVE was issued three vulnerabilities were patched by the vendor)

Credit
An independent security researcher, Pedro Ribeiro, has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program.

Vulnerability Details
QRadar has a built-in application to perform forensic analysis on certain files. This is disabled in the free Community Edition, but the code is still there, and part of it still works. This application has two components, one servlet running in Java, and the main web application running PHP. This exploit chain abuses both components of the forensics application to bypass authentication and write a file to disk, and then it abuses a cron job to escalate privileges to root.

QRadar has an Apache reverse proxy sitting in front of all its web applications, which routes requests according to the URL. Requests sent to /console/* get routed to the main “console” application, which not only runs the web interface but also performs the main functions of QRadar. Then there are several helper applications, such as the forensics application described above, which can be reached at /forensics and /ForensicAnalysisServlet, the SOLR server, reachable at /solr and others.

Technical details
Vulnerability: Authentication Bypass (in ForensicAnalysisServlet)
Attack Vector: Remote
Constraints: None
Affected products / versions:
– IBM QRadar SIEM: 7.3.0 and 7.3.1 confirmed; possibly all versions released since mid-2014 are affected

QRadar authentication is done via a SEC cookie, which is a session UUID. This is managed centrally by a session manager which runs in the main QRadar console application. The SEC cookies can be obtained in three ways:
– Upon login in the main console application
– Using a previously created authorisation token (also created in the console)
– From the /etc/qradar/conf/host.token file, which contains a UUID generated at install time, used by internal services to perform administrative actions.

The ForensicAnalysisServlet stores the SEC cookie in a HashMap, and then checks if the cookie is valid with the console application before committing any action… except for one specific codepath.

The function doGetOrPost() processes all requests to ForensicsAnalysisServlet. This function does a number of actions, such as fetching a results file, checking the status of an analysis request, etc. In order to authenticate, the requester has to have its SEC and QRadarCSRF tokens registered with the servlet. This is done by application with the setSecurityTokens action, with which a requester specifies both tokens and registers them with the servlet. In order to perform authentication for the setSecurityTokens action, the servlet checks if the host.token SEC cookie was sent with the request.

However, if the forensicsManagedHostIps parameter is sent with the setSecurityTokens action, doGetOrPost() will pass on the request to doPassThrough() before authenticating it:

doPassThrough() also validates if the request contains a valid SEC cookie… at some point. The problem is that if we send the setSecurityTokens action, in the beginning of the function the SEC and QRadarCSRF values are added to the servlet HashMap of valid tokens… before being validated:

Following the code snippets above, it is clear that an unauthenticated user can insert arbitrary SEC and QRadarCSRF values into the servlet cookie HashMaps.

To show this in action, let’s try to do a request to the servlet, and we get a 403 error:

Request:

Response:

Now we send our request to add the SEC and QRadarCSRF values to the valid token lists. By sending the following request, the values “owned” and “superowned” are added to the valid SEC and QRadarCSRF tokens:

To which the server will respond:

And now our cookies have been added to the SECCookiesMap and QradarCSRFCookiesMap, so we can invoke all actions (even the ones that required authenticated cookies) in ForensicsAnalysisServlet.

So let’s try to repeat the initial request, for which we got a 403:

Response:

Success! We’ve bypassed authentication.

Vulnerability: Command Injection (in PHP web application)
Attack Vector: Remote
Constraints: Authentication needed (can be bypassed with vulnerability #1)
Affected products / versions:
– IBM QRadar SIEM: 7.3.0 and 7.3.1 confirmed; possibly all versions released since mid-2014 are affected

The second vulnerability in this exploit chain is in the PHP part of the forensics web application. Using vulnerability #1 to add our SEC and QRadarCSRF cookies to the ForensicAnalysisServlet HashMaps means that we can invoke any function in the Java part of the application, but the PHP part uses a separate authentication scheme which doesn’t have a similar flaw. However, it accepts any requests coming from localhost without needing authentication. Authentication is done in the PHP part by including the DejaVu/qradar_helper.php file, which invokes the LoginCurrentUser function:

Note that not having authentication for local requests is not necessarily a vulnerability, although it is a bad practice as it can lead to situations like we are going to describe.

So how can we make requests seem like they come from localhost? Something as simple as changing the Host HTTP header will not work. Luckily, we can leverage ForensicAnalysisServlet doPassThrough() again. After the snippet shown in vulnerability #1, the function goes on to forward the request to the host address(es) entered in the forensicsManagedHostIps parameter:

It is clear from the code that if we send 127.0.0.1 in the forensicsManagedHostIps parameter, we can make ForensicAnalysisServlet forward our request to the PHP web application and bypass authentication. So now how to exploit this? In the PHP we application, we have file.php, which has a “get” functionality that allows an authenticated user to fetch certain files off the filesystem. file.php forwards the request to DejaVu/FileActions.php, which does some checks to ensure that the file is in a restricted set of directories:

The codepath that we are interested to hit is the pcapArray if, shown below. If we send a PHP array with several pcap parameters, the web application will ZIP these files before sending:

Which clearly leads to a command injection right here, using the pcap filenames:

Bingo! It allows us to execute code as the httpd web server user, which is the unprivileged “nobody” user. For example, to download and execute a shell from 172.28.128.1, we can send the following GET request, provided we have used vulnerability #1 to create valid SEC and QRadarCSRF cookies:

This will take a few seconds to process, but eventually our shell gets downloaded, and we get the following response:

The pcap[1][pcap] parameter is shown unencoded to facilitate reading, but the actual exploit should have this parameter fully URL encoded. As you can see, we can use the forensicsManagedHostIps not only to pick the host address but also to inject the URL path that will be used.

Care needs to be taken when choosing a directory to download the file to. The “nobody” user cannot write to /tmp, but a good choice is /store/configservices/*, which is used for various tasks, and is writeable by “nobody”. The /store/configservices/staging/updates/ was chosen (and created) because it plays a central role in our upcoming root privilege escalation exploit.

Vulnerability: Privilege Escalation (“nobody” user to root)
Attack Vector: Local
Constraints: “nobody” user shell needed (can be obtained with vulnerability #2)
Affected products / versions:
– IBM QRadar SIEM: 7.3.0 and 7.3.1 confirmed; possibly all versions released since mid-2014 are affected

The final step to totally owning QRadar is to escalate privileges from our limited “nobody” user to root.
For this we can leverage the following cron job, which runs as root every minute:

The code is convoluted, so it won’t be shown here for brevity. However, this Perl script invokes checkRpm(), which then calls checkRpmStatus(). The latter will fetch the autoupdate_patch database table and check if there are any entries left to process. If the file entry name ends with .rpm, it will invoke processRpm(), which installs it, otherwise it will invoke installMinor(), which will run “sh +x” on the file entry. These file entries are expected to be in the “update_download_dir” directory, which can be fetched with psql -U qradar -c “select value from autoupdate_conf where key = ‘update_download_dir’”, but it is /store/configservices/staging/updates/ by default. As explained in vulnerability #2, /store/configservices/* is writeable by “nobody”, so we can dump any files we want there, create directories, etc.

Luckily, the “nobody” user can access the database – after all, the Java and PHP server processes need to access it, and they run as “nobody”. Because the /tmp directory cannot be accessed by the “nobody” user, we cannot rely on password-less local socket connection to the database; so we have to use TCP/IP, which means we need the database password. The password is in /opt/qradar/conf/config_user.xml (readable by “nobody”) and it is stored encrypted, but can be decrypted using the code of a built-in shell script.

So once we have the database password, all we need to do is to add an entry to that table to a script we control (for example /store/configservices/staging/updates/owned.sh), and within one minute it will be run as root:

The exploit script that does this privilege escalation and returns a root reverse shell to 172.28.128.1:4445 is shown as Appendix A. This file can be written using a combination of vulnerabilities #1 and #2 to complete the full exploit chain, allowing an unauthenticated user to achieve root code execution remotely.

Appendix A

Exploit