GHSA-3fqm-frhg-7c85 CVE-2023-41041
Graylog user session is still usable after logout
- Severity
- 2.6 / 10
- Low · CVSS 3.1
- Exploit chance (EPSS)
- 0.48%
- Chance of exploitation in the next 30 days. Higher than 41.55% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-613 Insufficient Session Expiration
- Fix
5.0.9- Upgrade org.graylog2:graylog2-server to this version or later
Description
Summary
In a multi-node Graylog cluster, after a user has explicitly logged out, a user session may still be used for API requests until it has reached its original expiry time.
Details
Each node maintains an in-memory cache of user sessions. Upon a cache-miss, the session is loaded from the database. After that, the node operates solely on the cached session. Modifications to sessions will update the cached version as well as the session persisted in the database. However, each node maintains their isolated version of the session.
When the user logs out, the session is removed from the node-local cache and deleted from the database. The other nodes will however still use the cached session.
These nodes will only fail to accept the session id if they intent to update the session in the database. They will then notice that the session is gone. This is true for most API requests originating from user interaction with the Graylog UI because these will lead to an update of the session's "last access" timestamp.
If the session update is however prevented by setting the X-Graylog-No-Session-Extension:true header in the request, the node will consider the (cached) session valid until the session is expired according to its timeout setting.
PoC
In a 2-node setup, with both nodes behind a load balancer:
- Log in
- Extract the session ID from the cookie
- Log out and close the browser
- Perform the following API request repeatedly with curl (with
<session-id>replaced with the session id from step 2 and<lb-host>replaced with the hostname of your load balancer):curl -I -H X-Graylog-No-Session-Extension:true https://<session-id>:session@<lb-host>/api/system/cluster/nodes - Notice that the request is sometimes rejected, but sometimes succeeds
Impact
No session identifiers are leaked.
After a user has logged out, the UI shows the login screen again, which gives the user the impression that their session is not valid anymore. However, if the session becomes compromised later, it can still be used to perform API requests against the Graylog cluster. The time frame for this is limited to the configured session lifetime, starting from the time when the user logged out.
Affected versions
Maven
| Package | Vulnerable | Fixed in |
|---|---|---|
| org.graylog2:graylog2-server | >= 1.0, < 5.0.9 |
5.0.9 |
| org.graylog2:graylog2-server | >= 5.1.0, < 5.1.3 |
5.1.3 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
org.graylog2:graylog2-server Maven → 5.0.9
- maven
<dependency><groupId>org.graylog2</groupId><artifactId>graylog2-server</artifactId><version>5.0.9</version></dependency>- gradle
implementation("org.graylog2:graylog2-server:5.0.9")
Severity breakdown
CVSS 3.1 2.6
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N
- Attack vector
- Network
- Attack complexity
- High
- Privileges required
- Low
- User interaction
- Required
- Scope
- Unchanged
- Confidentiality
- Low
- Integrity
- None
- Availability
- None
Weakness
CWE-613: Insufficient Session Expiration
According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."
How to prevent it
- Implementation: Set sessions/credentials expiration date.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-m9c2-85gv-8xr5 Graylog: Manager-to-Owner privilege escalation on saved searches and dashboards | Medium | Also affects org.graylog2:graylog2-server |
| GHSA-j769-9gv9-65gr Graylog token revocation endpoint allows authenticated users to delete other users’ access tokens | Medium | Also affects org.graylog2:graylog2-server |
| GHSA-gqr6-r77p-c2pj Fortigate syslog message parser can be exploited to modify or delete fields from the original message | High | Also affects org.graylog2:graylog2-server |
| GHSA-q79r-r9xg-r863 Graylog Server: System Catalog titles endpoint can be used to retrieve values of protected database fields | Medium | Also affects org.graylog2:graylog2-server |
| GHSA-3m86-c9x3-vwm9 Graylog vulnerable to privilege escalation through API tokens | High | Also affects org.graylog2:graylog2-server |
| GHSA-76vf-mpmx-777j Graylog Allows Session Takeover via Insufficient HTML Sanitization | Medium | Also affects org.graylog2:graylog2-server |
| GHSA-q9q2-3ppx-mwqf Graylog Allows Stored Cross-Site Scripting via Files Plugin and API Browser | High | Also affects org.graylog2:graylog2-server |
| GHSA-q7g5-jq6p-6wvx Graylog's Authenticated HTTP inputs ingest message even if Authorization header is missing or has wrong value | Medium | Also affects org.graylog2:graylog2-server |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor