------------------------------------------------------------------------
QRadar session manager path traversal vulnerability
------------------------------------------------------------------------
Yorick Koster, September 2019

------------------------------------------------------------------------
Abstract
------------------------------------------------------------------------
A path traversal exists in the session validation functionality of
QRadar. In particular, the vulnerability is present in the part that
handles session tokens (UUIDs). QRadar fails to validate if the
user-supplied token is in the correct format. Using path traversal it is
possible for authenticated users to impersonate other users, and also to
executed arbitrary code (via Java deserialization). The code will be
executed with the privileges of the Tomcat system user.

------------------------------------------------------------------------
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 as part of the Session Authenticator rewrite session
information is no longer stored on disk. Consequently, this issue is
mitigated in QRadar 7.3.2 Patch 3 and newer. 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 supports several authentication methods,
including JAAS, basic authentication, OAuth, and token-based
authentication. The token-based authentication uses UUIDs, which either
represents a so-called host token or a file within the /store/sessions/
folder. Whenever QRadar encounters a session token, which is not a host
token, the sessions folder is searched for a file with the same name. If
the file exists, it will be opened and its contents will be
deserialized. The returned object is used to validate the user's
session. In some cases validation is performed on the provided token to
check if it is a properly formatted UUID. Several instances were found
where this validation is not done, allowing for path traversal attacks.

By exploiting this issue it would be possible for an attacker to open a
session file outside the sessions folder. A possible attack scenario
would be if a low privileged user uploads a file to the QRadar server
containing a serialized session object for a different user (eg, Admin)
and thus escalated privileges to that user.

No mitigations have been implemented to prevent deserialization of other
Java objects. Consequently, it is also possible to upload a file
containing other serialized objects. An authenticated attacker can
exploit this vulnerability by uploading a specially crafted (serialized)
object, which amongst other things can result in a denial of service,
change of system settings, or execution of arbitrary code.

------------------------------------------------------------------------
Details
------------------------------------------------------------------------
Deserialization of the session file happens in the class
com.q1labs.core.shared.sessionmanager.SessionManager. The session file
is retrieved by calling the getFileFromToken() method of the class
com.q1labs.core.shared.sessionmanager.UserSession.

com.q1labs.core.shared.sessionmanager.UserSession:
public static File getFileFromToken(String sessionToken) {
	return new File(NVAReader.getProperty("SESSION_DIR", "/store/sessions/") + sessionToken);
}

As can be seen in the code fragment above, the provided sessionToken
argument is directly concatenated with the SESSION_DIR configuration
property (normally /store/sessions/). If the file exits, its contents is
deserialized by the SessionManager class.

com.q1labs.core.shared.sessionmanager.SessionManager:
private UserSession deserializeSession(String sessionToken) {
	UserSession retSession = null;
	
	try {
		File sessionFile = UserSession.getFileFromToken(sessionToken);
		if (sessionFile.exists()) {
			if (this.log.isDebugEnabled()) {
				this.log.debug("Session file exists, deserializing...");
			}
	
			try {
				ObjectInputStream is = new ObjectInputStream(new FileInputStream(sessionFile));
				Throwable var5 = null;
	
				try {
					retSession = (UserSession)is.readObject();

The call to deserializeSession() is done from the getSession() method of
the same SessionManager class. None of these methods perform any
validation on the session token. The lack of validation allows for
directory traversal attacks if the calling methods also fail to validate
the session token format. Several instances have been found where this
is the case, thus allowing for directory traversal to happen. Some
examples of vulnerable instances include:

- com.q1labs.core.ui.servlet.RemoteJavaScript.doGet() via the sessionId
JSON property.
- com.q1labs.uiframeworks.auth.SessionAuthenticator.doAuthenticate() via
the SEC HTTP request header.
- com.q1labs.uiframeworks.util.RequestUtils.getSessionContext() via the
SEC HTTP request header.

com.q1labs.core.ui.servlet.RemoteJavaScript:
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws RemoteMethodException, IOException, ServletException {
[...]
				try {
					if (jsonRequest.has("sessionId")) {
[...]
						SessionManager sessionManager = SessionManager.getInstance();
						UserSession existingSession = sessionManager.getSession(sessionId);

com.q1labs.uiframeworks.auth.SessionAuthenticator:
protected boolean doAuthenticate(Request request, HttpServletResponse
response) throws IOException {
[...]
			String path;
			UserSession existingSession;
[...]
			path = (String)request.getSession().getAttribute("SEC");
			if (path == null) {
				path = request.getHeader("SEC");
			}
	
[...]
			if (session.isValid() && path != null) {
				existingSession = SessionManager.getInstance().getSession(path);

com.q1labs.uiframeworks.util.RequestUtils.java:
public static ISessionContext getSessionContext(HttpServletRequest
request, boolean newSession) throws UIFrameworksException {
[...]
		try {
			String sessiontoken = (String)request.getSession().getAttribute("SEC");
			if (sessiontoken == null) {
				sessiontoken = request.getHeader("SEC");
			}
	
[...]
	
				userSession = sm.getSession(sessiontoken);

By exploiting this path traversal vulnerability it is possible to load
any session file that is present on the system. Normally, there should
be no session file outside of the /store/sessions folder. However
authenticated users have the possibility to upload files to known
locations. By uploading a session file and abusing the path traversal
vulnerability it ios possible to impersonate any QRadar user. Even more
important, this mechanism allows for the deserialization of Java
objects. It was successfully verified that execution of arbitrary code
is possible by deserializing arbitrary Java objects.

------------------------------------------------------------------------
References
------------------------------------------------------------------------
[1] https://www.securify.nl/advisory/SFY20200409/qradar-session-manager-path-traversal-vulnerability.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