Executive Summary

Heimdall is a cloud native Identity Aware Proxy and Access Control Decision service. Prior to version 0.17.14, Heimdall handled URL-encoded slashes (%2F) in a case-sensitive way, recognizing only the uppercase %2F but not the lowercase %2f. Since percent-encoding is defined to be case-insensitive, this inconsistency caused Heimdall to interpret request paths differently than upstream components when the default setting allow_encoded_slashes was off.

This mismatch in path interpretation could lead to an authorization bypass, where access controls enforced by Heimdall might be circumvented because certain encoded slashes were not recognized properly. For example, a request path containing %2f might bypass Heimdall's rules but still be interpreted as a slash by upstream services, potentially granting unauthorized access.

The vulnerability was fixed in version 0.17.14 by changing Heimdall to handle URL-encoded slashes in a case-insensitive manner, ensuring consistent path processing and preventing this bypass.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can lead to unauthorized access by bypassing Heimdall's access control rules due to inconsistent handling of URL-encoded slashes. If Heimdall is configured with permissive or insecure default rules, an attacker could exploit this to gain access to restricted resources.

The impact includes potential unauthorized data access, modification, or privilege escalation depending on the specific configuration and environment where Heimdall is deployed.

Mitigations include updating Heimdall to version 0.17.14 or later, configuring deny-by-default rules, rejecting encoded slashes at the proxy layer, or using JWTs with rule IDs for verification.

Useful 0 Not Useful 0

Detection Guidance

Detection of this vulnerability involves identifying requests that use lowercase URL-encoded slashes (%2f) which Heimdall prior to version 0.17.14 does not properly recognize when allow_encoded_slashes is set to off. Such requests may bypass authorization rules due to inconsistent path interpretation.

You can monitor your network or system logs for requests containing %2f in URLs, especially targeting sensitive paths like /admin%2fsecret.

Example commands to detect such requests in logs might include:

• Using grep on access logs to find lowercase encoded slashes: grep -i '%2f' /path/to/heimdall/access.log
• Using curl to test if the server treats %2f and %2F differently: curl -v 'https://yourheimdallserver/admin%2fsecret' and curl -v 'https://yourheimdallserver/admin%2Fsecret' to compare responses.

Additionally, checking the Heimdall version and configuration (allow_encoded_slashes setting) can help identify if the system is vulnerable.

Useful 0 Not Useful 0

Mitigation Strategies

The primary immediate mitigation step is to upgrade Heimdall to version 0.17.14 or later, where this vulnerability has been patched.

If upgrading immediately is not possible, consider the following workarounds:

• Avoid using insecure flags or configurations that disable secure defaults, such as explicitly disabling deny-by-default rules.
• Configure Heimdall with a deny-by-default rule to prevent unauthorized access by default.
• Reject encoded slashes at the proxy layer before requests reach Heimdall.
• Include rule IDs in JWTs for verification to ensure authorization rules are properly enforced.

Review your Heimdall configuration to ensure that allow_encoded_slashes is set appropriately and that authorization rules are not overly permissive.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability in Heimdall allows for an authorization bypass due to improper handling of URL-encoded slashes, which can lead to unauthorized access, data modification, or privilege escalation depending on the configuration.

Such unauthorized access or data breaches could potentially impact compliance with common standards and regulations like GDPR or HIPAA, which require strict access controls and protection of sensitive data.

If exploited, this vulnerability could compromise confidentiality and integrity of protected data, thereby increasing the risk of non-compliance with these regulations.

However, the risk is mitigated if secure default configurations are used, such as deny-by-default rules or rejecting encoded slashes at the proxy layer.

Useful 0 Not Useful 0