Message-ID: <e5d799cd-2bae-dbff-001d-b38a83479f26@securify.nl>
Date: Mon, 20 Apr 2020 12:27:36 +0200
From: "Securify B.V. via Fulldisclosure" <fulldisclosure@...lists.org>
To: fulldisclosure@...lists.org
Subject: [FD] Cross-Site Request Forgery & weak access control in QRadar
 ConfigServices webservice

------------------------------------------------------------------------
Cross-Site Request Forgery & weak access control in QRadar
ConfigServices webservice
------------------------------------------------------------------------
Yorick Koster, September 2019

------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------
The QRadar web application is deployed with Apache Axis to expose a
number of SOAP services. No measures have been implemented in Axis
and/or QRadar to prevent Cross-Site Request Forgery attacks against
these webservices. Due to this it is possible for an attacker to call
any exposed service via Cross-Site Request Forgery. A successful attack
requires that the attacker tricks/forces a logged in victim to visit the
attacker's specially crafted URL.

Besides the lack of Cross-Site Request Forgery protection, most methods
also lack proper access control checks. A handful of these methods
perform some form of access control, but most methods can be called by
any authenticated user. This could for example be used by a logged in
attacker to gain access to sensitive information (eg, login
credentials).

------------------------------------------------------------------------
Tested versions
------------------------------------------------------------------------
This issue was successfully verified on QRadar Community Edition [2]
version 7.3.1.6 (7.3.1 Build 20180723171558).

------------------------------------------------------------------------
Fix
------------------------------------------------------------------------
IBM reports that Apache Axis is no longer used and therefore this issues
has been resolved in upstream builds. In addtion, it is stated that
thist issue is resolved in QRadar Community Edition version 7.3.3 [3].

------------------------------------------------------------------------
Introduction
------------------------------------------------------------------------
QRadar [4] is IBM's enterprise SIEM [5] solution. A free version of
QRadar is available that is known as QRadar Community Edition [2]. This
version is limited to 50 events per second and 5,000 network flows a
minute, supports apps, but is based on a smaller footprint for
non-enterprise use.

The QRadar web application is deployed with Apache Axis [6] to expose a
number of SOAP services. By default, Axis allows users to call the SOAP
services via a GET request. The GET request is internally converted to a
SOAP envelope, before it is processed by Axis. No measures have been
implemented in Axis and/or QRadar to prevent Cross-Site Request Forgery
attacks against the webservices exposed by Axis. Due to this it is
possible for an attacker to call any exposed service via Cross-Site
Request Forgery. A successful attack requires that the attacker
tricks/forces a logged in victim to visit the attacker's specially
crafted URL.

Besides the lack of Cross-Site Request Forgery protection, most methods
also lack proper access control checks. A handful of these methods
perform some form of access control, but most methods can be called by
any authenticated user. This could for example be used by a logged in
attacker to gain access to sensitive information.

By calling the getNvaProperty() method, it is possible to retrieve any
'NVA' configuration setting. Sensitive settings, like passwords, are
stored encrypted, however there is also a getDecrypted() method that
allows these values to be decrypted. Some passwords are reused for
different services, which also allows users to elevate their own
privileges. For example, the property jpa.connection.password is used
for connecting to PostgreSQL, but is also used as the password for the
ConfigServices account.

------------------------------------------------------------------------
Details
------------------------------------------------------------------------
Apache Axis provides a SOAP implementation, services can be configured
in various ways. In case of QRadar the services are configured in the
server-config.wsdd file, located under WEB-INF. Three service classes
are currently configured:

- AdminService
- Version
- configservices

The first two are distributed with Axis, the latter one is custom for
QRadar. The AdminService allows for deploying and undeploying of
webservers, however it is configured to only be accessible from
localhost.

The implementation of the configservices webservice can be found in the
class com.q1labs.configservices.core.ConfigurationServices. Any public
method in this class can be called through Axis. The webservice is
mapped to the path /console/services/configservices. There are two ways
to call these methods:

- POST request containing a SOAP envelope. The first tag in the SOAP
body should have the same name as the method that needs to be invoked.
Method parameters are provided as child elements within this tag.
- GET request; the URL parameters are converted into a SOAP message by
Axis. The method is provided via the method URL parameter, its arguments
are provided as URL parameter with the same name  as the method
argument.

No measures have been implemented in Axis and/or QRadar to prevent
Cross-Site Request Forgery attacks against the webservices exposed by
Axis. Due to this it is possible for an attacker to call any exposed
service via Cross-Site Request Forgery. Methods that can be called
include:

- saveScannerConfigFile(data)
- addManagedHost(ipAddress, password, isTunneled, isCompressed, ipPublicAddress, natId, consoleIpToUse, runPrecheck, remappingip)
- startComponent/stopComponent/restartComponent(host, type, componentName)
- startComponents/stopComponents/restartComponents(host)
- startSystem/stopSystem/restartSystem()
- injectDeploymentModel/saveDeploymentModelToStaging(deploymentModel)
- deployStagingConfiguration(fullDeploy)
- restoreFromBackupDeployment()
- saveFile(fileName, data)

An attacker can create a URL that when visited by a logged in target
executes one or more of the exposed methods, for example:

https://<ip>/console/services/configservices?method=stopSystem

Besides the lack of Cross-Site Request Forgery protection, most methods
also lack proper access control checks. A handful of these methods
perform some form of access control, but most methods can be called by
any authenticated users. For example the saveFile() and retrieveFile()
methods check if the logged on user has permission to write or access
the requested file.

com.q1labs.configservices.core.ConfigurationServices:
public byte[] retrieveFile(String fileName, boolean staging) throws
ConfigServicesFault {
	try {
		if (!fileName.contains("/") && !fileName.contains("\\")) {
		String qradarUsername = this.requestSession.getQradarUsername();
		boolean canAccess = RequestSession.hasPermission(qradarUsername);
		if (!canAccess) {
			throw new UnauthorizedException("Provided username from security token does not have permission to use this method");
[...]

A logged on attacker can call all methods without proper access control.
One notable attack is to call the getNvaProperty() method. By calling
this method it is possible to retrieve any 'NVA' configuration setting -
including sensitive information like (encrypted) credentials.
Credentials are stored encrypted on disk, in some case they are stored
decrypted in memory. If the are already decrypted, getNvaProperty() will
return the plaintext value. If they are encrypted they can easily be
decrypted by calling the getDecrypted() method of the webservice.

Some passwords are reused for different services, which allows users to
elevate their own privileges. For example, the property
jpa.connection.password is used for connecting to PostgreSQL, but is
also used as the password for the ConfigServices account. A low
privileged user can request the password for the PostgreSQL user. Since
PostgreSQL is normally not exposed over the network it would still not
be possible to log in. However due to the password reuse it is possible
to use the same password to login as the ConfigService user.

https://<ip>/console/services/configservices?method=getNvaProperty&key=jpa.connection.password

------------------------------------------------------------------------
References
------------------------------------------------------------------------
[1] https://www.securify.nl/advisory/SFY20200403/cross-site-request-forgery-_-weak-access-control-in-qradar-configservices-webservice.html
[2] https://developer.ibm.com/qradar/ce/
[3] https://www.ibm.com/account/reg/us-en/signup?formid=urx-32552
[4] https://www.ibm.com/security/security-intelligence/qradar
[5] https://en.wikipedia.org/wiki/Security_information_and_event_management
[6] http://axis.apache.org/


_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists