CVE-2025-70973

Executive Summary

CVE-2025-70973 identifies a critical Session Fixation vulnerability in ScadaBR version 1.12.4. The application fails to regenerate the JSESSIONID cookie after a user authenticates, allowing an attacker to pre-set a known session identifier and then trick a victim into authenticating with that session. Once the victim logs in, the attacker can hijack the authenticated session, gaining unauthorized access to the ScadaBR web interface and potentially manipulating industrial control system (ICS) settings.

This vulnerability is particularly dangerous in ICS/SCADA environments where session hijacking can lead to unauthorized control of critical infrastructure. The CVSS score is 0.0 in the NVD data, but based on the description and impact, a more accurate score is 8.1 (High) with the vector provided above.

Supply Chain & Package Security

ScadaBR is a Java-based web application typically deployed as a WAR file on Apache Tomcat. The vulnerability is in the application's session management logic, not in any third-party package. However, the lack of a patch or official advisory from the vendor increases supply chain risk, as operators must rely on custom mitigations or workarounds.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – The attacker can exploit this remotely.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): None (N) – No authentication needed to initiate the attack.
• User Interaction (UI): Required (R) – The victim must log in after the attacker sets the session.
• Scope (S): Unchanged (U) – The vulnerable component is the only one affected.
• Confidentiality (C): High (H) – Full access to the victim's session data.
• Integrity (I): High (H) – The attacker can modify settings or issue commands.
• Availability (A): None (N) – The attack does not directly affect availability.

Threat Level: High (8.1) – Exploitation is straightforward and can lead to full compromise of the ScadaBR instance.

Deep Dive & Mechanics

The vulnerability stems from ScadaBR's session management implementation. When an unauthenticated user visits the application, a JSESSIONID cookie is assigned. This session ID remains unchanged after the user authenticates. The attack flow is:

1. Attacker obtains a valid session ID by visiting the ScadaBR login page (e.g., http://target/ScadaBR/login.htm). The server responds with a Set-Cookie: JSESSIONID=ABC123; Path=/ScadaBR; HttpOnly header.
2. Attacker crafts a malicious link that includes the session ID (e.g., http://target/ScadaBR/login.htm;jsessionid=ABC123) or uses a cross-site scripting (XSS) vector to set the cookie in the victim's browser.
3. Victim clicks the link and logs in to ScadaBR. The server does not regenerate the session ID, so the session ABC123 becomes authenticated.
4. Attacker uses the known session ID to access the application (e.g., by setting the cookie in their own browser), gaining full access to the victim's authenticated session.

The root cause is the absence of a call to HttpSession.invalidate() or request.changeSessionId() after authentication. In Java Servlet API, the recommended practice is to regenerate the session ID upon login to prevent fixation.

Vulnerable vs. Patched Code

Vulnerable Code (ScadaBR 1.12.4):

// In login servlet or filter
HttpSession session = request.getSession();
// No session regeneration after successful authentication
session.setAttribute("user", authenticatedUser);

Patched Code (Hypothetical fix):

// After successful authentication
HttpSession oldSession = request.getSession(false);
if (oldSession != null) {
    oldSession.invalidate();
}
HttpSession newSession = request.getSession(true);
newSession.setAttribute("user", authenticatedUser);
// Or use Servlet 3.1+ API:
// request.changeSessionId();

The patch must ensure that a new session is created and the old one is invalidated upon login. Since no official patch exists, operators must implement this manually or use a reverse proxy to enforce session regeneration.

Exploitation & Lab Setup

Red Team

Lab Setup:

1. Deploy ScadaBR 1.12.4 on Apache Tomcat 9.
2. Create a test user account (e.g., admin:password).
3. Use a tool like Burp Suite or a simple Python script.

Exploitation Steps:

1. Obtain a session ID:

   curl -v http://target:8080/ScadaBR/login.htm 2>&1 | grep Set-Cookie
   

   Output: Set-Cookie: JSESSIONID=ABC123; Path=/ScadaBR; HttpOnly

2. Craft a phishing link:

   http://target:8080/ScadaBR/login.htm;jsessionid=ABC123
   

   Or use an XSS payload to set the cookie:

   <script>document.cookie="JSESSIONID=ABC123; path=/ScadaBR";</script>
   

3. Victim logs in (simulate by logging in with the known session ID in another browser).

4. Hijack the session:

   curl -v --cookie "JSESSIONID=ABC123" http://target:8080/ScadaBR/
   

   The response will contain the authenticated dashboard.

Blue Team

Detection:

• Monitor for multiple login attempts from the same IP with different session IDs.
• Alert on session IDs that appear in both unauthenticated and authenticated requests without a change.
• Use a WAF to block requests containing ;jsessionid= in the URL (a common session fixation vector).

Prevention:

• Configure Tomcat to regenerate session IDs on authentication (requires code change).
• Use a reverse proxy (e.g., Nginx) to strip jsessionid from URLs and enforce cookie-based sessions.
• Implement multi-factor authentication (MFA) to reduce the impact of session hijacking.

Indicators of Compromise (IOCs)

• Network:

  • HTTP requests with ;jsessionid= in the URL path.
  • Repeated Set-Cookie headers with the same JSESSIONID value from different IPs.
  • Unauthenticated requests to protected resources (e.g., /ScadaBR/ without login) using a known session ID.

• Host:

  • Tomcat access logs showing the same JSESSIONID in both unauthenticated and authenticated requests.
  • Multiple login events from the same session ID in a short time.

• Sample IOC Log Entry:

  192.168.1.100 - - [10/May/2025:12:34:56 +0000] "GET /ScadaBR/login.htm;jsessionid=ABC123 HTTP/1.1" 200 1234
  192.168.1.100 - - [10/May/2025:12:35:00 +0000] "GET /ScadaBR/ HTTP/1.1" 200 5678 "JSESSIONID=ABC123"
  

Detection Engineering

YARA Rule

rule ScadaBR_SessionFixation {
    meta:
        description = "Detects ScadaBR session fixation attempts via URL or cookie"
        author = "Valters IT"
        date = "2025-05-10"
        cve = "CVE-2025-70973"
    strings:
        $url_pattern = /;jsessionid=[a-zA-Z0-9]+/ nocase
        $cookie_pattern = /JSESSIONID=[a-zA-Z0-9]+/ nocase
    condition:
        any of them
}

Sigma Rule

title: ScadaBR Session Fixation Attempt
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects HTTP requests with jsessionid in URL or repeated session IDs
author: Valters IT
date: 2025/05/10
logsource:
    category: webserver
    product: tomcat
detection:
    selection_url:
        cs-uri-query|contains: ';jsessionid='
    selection_cookie:
        cs-cookie|contains: 'JSESSIONID='
    condition: selection_url or selection_cookie
falsepositives:
    - Legitimate use of URL rewriting (rare in modern apps)
level: high

Suricata Rule

alert http any any -> any any (msg:"ScadaBR Session Fixation Attempt"; flow:to_server; content:";jsessionid="; http_uri; classtype:attempted-user; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate (Workaround):

   • Disable URL-based session tracking in Tomcat by setting disableURLRewriting="true" in context.xml.
   • Use a reverse proxy (e.g., Nginx) to strip jsessionid from URLs:

     location /ScadaBR {
         proxy_pass http://tomcat:8080;
         proxy_set_header Cookie $http_cookie;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         # Strip jsessionid from URL
         rewrite ^(.*);jsessionid=[^&]*(.*)$ $1$2 permanent;
     }
     

   • Implement a custom Tomcat valve to regenerate session IDs on authentication (requires Java code).

2. Long-term:

   • Apply a patch from the vendor (once available) or upgrade to a fixed version.
   • Implement multi-factor authentication (MFA) to reduce the impact of session hijacking.
   • Conduct a security audit of the application's session management.

3. Detection:

   • Deploy the YARA, Sigma, and Suricata rules provided above.
   • Monitor for anomalous session behavior in Tomcat access logs.

Valters IT
Securing Digital Frontiers