GHSA-c8m8-3jcr-6rj5: Hardcoded JWT Signing Secret in FUXA

FUXA is an open-source web-based Human-Machine Interface (HMI) and SCADA software used for process visualization and industrial automation. It relies on JSON Web Tokens (JWT) to manage user sessions and authentication state. Ideally, the cryptographic secret used to sign these tokens should be unique to each installation and kept confidential.

However, versions of FUXA prior to 1.3.0 implemented a fallback mechanism that utilized a static, hardcoded string—frangoteam751—whenever the administrator did not manually define a secretCode in the configuration. This vulnerability, identified as GHSA-c8m8-3jcr-6rj5, is a classic example of CWE-798: Use of Hardcoded Credentials.

Because the fallback secret is embedded in the open-source codebase and was even documented in the project's Wiki, it is effectively public knowledge. This flaw fundamentally breaks the trust model of the application's authentication. Any actor aware of this default configuration can generate valid session tokens without needing to compromise a database or crack passwords, leading to direct privilege escalation.

The vulnerability stems from an insecure default configuration in the server's initialization logic. When the FUXA server starts, it attempts to load security settings, including the secret key used for HMAC-SHA256 signing of JWTs. The application logic checked for the presence of a user-defined secret but provided a static string as a fallback to ensure the application would run 'out of the box' without complex setup.

The root cause lies specifically in the fallback value being a constant string rather than a randomly generated value. In secure design patterns, if a critical security parameter is missing, the application should either fail to start (forcing the user to configure it) or generate a cryptographically strong random value at runtime and persist it securely.

By defaulting to frangoteam751, the application created a predictable attack surface. Since many deployments of software rely on default configurations—especially in OT/IoT environments where ease of deployment is prioritized—a significant number of installations likely remain vulnerable to this trivial authentication bypass.

The vulnerability existed in the configuration loading module of the FUXA server. Below is a representation of the vulnerable logic found in versions prior to 1.3.0.

Vulnerable Implementation:

The code utilized a simple logical OR (||) to assign the secret. If config.secretCode was undefined or null, the hardcoded string was used immediately.

// In secure implementations, this should never be a static string
const secret = config.secretCode || 'frangoteam751';
 
// This secret is then used to sign tokens
const token = jwt.sign(payload, secret, options);

Patched Implementation (v1.3.0):

In the patched version, the hardcoded fallback was removed. The remediation strategy involves ensuring that a unique secret is available. While the exact patch details rely on context, the standard fix for this pattern involves generating a random string if one is not provided.

// Conceptual fix in v1.3.0
const crypto = require('crypto');
 
let secret = config.secretCode;
if (!secret) {
    // Generate a secure random secret if none exists
    secret = crypto.randomBytes(64).toString('hex');
    // Ideally, this new secret is then saved to the config file
    saveConfig({ secretCode: secret });
}

This change ensures that even if an administrator neglects to configure a secret, the application generates a unique key that an external attacker cannot guess.

Exploiting this vulnerability requires no specialized tools beyond a standard JWT library and knowledge of the target's user structure (which is often standard, e.g., 'admin'). The attack vector is strictly network-based and relies on the target instance running with the default configuration.

Prerequisites:

1. Network access to the FUXA web interface.
2. The target FUXA instance must be using the default secretCode configuration.

Attack Steps:

1. Token Generation: The attacker uses a script to generate a JWT. They set the algorithm to HS256 (HMAC with SHA-256) and sign the payload with the known secret frangoteam751.

const jwt = require('jsonwebtoken');
 
// Construct a payload granting administrative privileges
const payload = {
  user: 'admin',
  role: 'administrator',
  // Standard claims like expiry may be required depending on validation logic
  exp: Math.floor(Date.now() / 1000) + (60 * 60)
};
 
// Sign with the hardcoded secret
const forgedToken = jwt.sign(payload, 'frangoteam751');
console.log(forgedToken);

2. Injection: The attacker navigates to the FUXA interface and injects this forged token into the browser's storage (LocalStorage or Cookies) or includes it in the Authorization header of API requests.

3. Access: Upon refreshing the page or sending a request, the server validates the signature against the hardcoded secret. Since they match, the server accepts the session as valid, granting the attacker full administrative access.

The impact of this vulnerability is severe, particularly given the operational context of FUXA as a SCADA/HMI solution. Successful exploitation allows for complete system compromise.

Confidentiality: Attackers can view sensitive process data, visualization layouts, and potentially proprietary industrial configurations. The CVSS metric for Confidentiality is High.

Integrity: Attackers can modify process parameters, change visualization logic, or alter alarm thresholds. In an industrial context, this could lead to physical equipment damage, spoilage of goods, or safety hazards. The CVSS metric for Integrity is High.

Privilege Escalation: The vulnerability allows a low-privileged user (or an unauthenticated user if the endpoint allows anonymous token submission) to elevate privileges to Administrator. While the CVSS vector notes PR:L (Low Privileges Required), the nature of JWT forgery often acts as a full authentication bypass if the attacker can guess a valid username.

Availability: While the direct impact is not Denial of Service, an attacker with administrative access could easily shut down the server or disrupt operations, indirectly affecting availability.