------------------------------------------------------------------------ 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