Executive Summary

This vulnerability in CRMEB up to version 5.6.1 involves the JWT HMAC Secret Handler component using a hard-coded cryptographic key with the default value "default". This predictable secret allows attackers to forge valid JWT tokens, bypass authentication, escalate privileges, and gain unauthorized access to protected resources. The vulnerability can be exploited remotely without authentication, although the exploit is considered difficult. The vendor did not respond to the disclosure, and no known mitigations currently exist. [1, 2]

Useful 0 Not Useful 0

Impact Analysis

Exploitation of this vulnerability allows an attacker to impersonate any user, including administrators, by forging JWT tokens signed with the known default secret. This leads to full authentication bypass, privilege escalation, unauthorized access to protected APIs, and potential exposure or exfiltration of sensitive business data. The impact affects confidentiality, integrity, and availability of the system's data and services. [1, 2]

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by inspecting JWT tokens used by the CRMEB application to see if they are signed with the default hard-coded secret "default." One approach is to capture JWT tokens from network traffic or application logs and attempt to verify or forge tokens using the secret "default." For example, you can extract JWT tokens from HTTP Authorization headers and decode them to check the issuer claim (e.g., "v5.crmeb.net"). Then, using tools like jwt.io or jwt-cli, attempt to verify or forge tokens with the secret "default." Commands might include: 1) Using curl or a proxy to capture tokens from requests, 2) Using jwt-cli or similar tools to decode and verify tokens, e.g., `jwt decode <token>`, `jwt verify <token> -s default`, or 3) Attempting to forge a token with elevated claims signed with "default" and testing access to protected endpoints. This confirms if the system is vulnerable to token forgery due to the hard-coded secret. [2]

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation steps include removing the hard-coded weak JWT secret and replacing it with a strong, randomly generated secret during installation or configuration. Administrators should be required to set and rotate the JWT secret regularly. Additionally, invalidate all tokens signed with the default secret "default" to prevent unauthorized access. If possible, replace the affected CRMEB version with a patched or alternative product that does not use the default secret. Since no official vendor response or patch is available, these steps are critical to reduce risk. [2, 1]

Useful 0 Not Useful 0