The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers). An example of a network attack is an attacker causing a denial of service by sending a specially crafted TCP packet across a wide area network (e.g., CVE-2004-0230).
Attack Complexity
Low
AC
The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Privileges Required
Low
PR
The attacker requires privileges that provide basic capabilities that are typically limited to settings and resources owned by a single low-privileged user. Alternatively, an attacker with Low privileges has the ability to access only non-sensitive resources.
User Interaction
None
UI
The vulnerable system can be exploited without interaction from any human user, other than the attacker. Examples include: a remote attacker is able to send packets to a target system a locally authenticated attacker executes code to elevate privileges
Scope
Unchanged
S
An exploited vulnerability can only affect resources managed by the same security authority. In the case of a vulnerability in a virtualized environment, an exploited vulnerability in one guest instance would not affect neighboring guest instances.
Confidentiality
Low
C
There is some impact on confidentiality, but the attacker either does not gain control of any data, or the information obtained does not have a significant impact on the system or its operations.
Integrity
Low
I
Modification of data is possible, but the attacker does not have control over what can be modified, or the extent of what the attacker can affect is limited. The data modified does not have a direct, serious impact on the system.
Availability
Low
A
There is reduced performance or interruptions in resource availability. However, the attacker does not have the ability to completely prevent access to the resources or services; the impact is limited.
Below is a copy: QRadar Community Edition 7.3.1.6 Path Traversal
------------------------------------------------------------------------
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
This information is provided for TESTING and LEGAL RESEARCH purposes only. All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum