https://feed.craftedsignal.io/products/heimdall/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioTue, 02 Jan 2024 12:00:00 +0000https://feed.craftedsignal.io/briefs/2024-01-02-heimdall-case-sensitivity/Tue, 02 Jan 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-02-heimdall-case-sensitivity/Heimdall performs case-sensitive host matching, which can lead to policy bypass because HTTP hostnames are case-insensitive, potentially leading to unauthorized access, data modification, or privilege escalation if the request host is part of the rule.Heimdall, a Go-based access management system, is susceptible to a case-sensitivity vulnerability in its host matching mechanism. HTTP hostnames are case-insensitive, but Heimdall performs host matching in a case-sensitive manner. Discovered and reported in April 2026, this discrepancy can result in Heimdall failing to match a rule for a request host that differs only in letter casing. Version 0.16.0 and later enforce secure defaults and refuse to start with an “allow all” configuration unless explicitly disabled using flags like --insecure-skip-secure-default-rule-enforcement or --insecure. The vulnerability affects Heimdall versions prior to 0.17.14 and can be exploited if rule matching relies on the request host, potentially leading to unintended access control bypass.

Attack Chain

1. The attacker identifies a Heimdall instance with host-based access control rules.
2. The attacker identifies a specific rule where the host is used for access control (e.g., admin.example.com).
3. The attacker crafts an HTTP request with a Host header that differs only in casing (e.g., Admin.Example.Com).
4. Heimdall fails to match the intended rule due to the case-sensitive comparison.
5. If no default rule is configured, Heimdall returns a “404 Not Found” error.
6. If a permissive default rule is configured (e.g., allowing anonymous access, which is discouraged since v0.16.0), Heimdall executes this default rule.
7. The attacker gains unauthorized access to resources or functionality that should be protected by the intended rule.
8. The attacker exploits the gained access to modify data, invoke functionality, or escalate privileges depending on the exposed functionality.

Impact

Bypassing access control policies enforced by Heimdall can lead to unauthorized access to sensitive data, modification of critical information, or invocation of restricted functionality. Depending on the exposed functionality, this could also lead to privilege escalation. The severity of the impact depends heavily on the misconfiguration of Heimdall’s rules, particularly the presence of overly permissive default rules. Successful exploitation can compromise the confidentiality, integrity, and availability of the protected application or service.

Recommendation

• Normalize request hosts to lowercase in layers in front of Heimdall to mitigate the case sensitivity issue.
• Avoid configuring permissive default rules. Remove or disable the --insecure or --insecure-skip-secure-default-rule-enforcement flags.
• When using the regex type for host matching, define expressions in a case-insensitive manner (e.g., (?i)^admin\.example\.com$).
• Upgrade to Heimdall version 0.17.14 or later to patch the vulnerability directly.

]]>highadvisorydefense-evasionpolicy-bypassaccess-controlhttps://feed.craftedsignal.io/briefs/2024-01-02-heimdall-auth-bypass/Tue, 02 Jan 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-02-heimdall-auth-bypass/Heimdall is vulnerable to an authorization bypass due to a path normalization mismatch between Heimdall and downstream components, potentially leading to unauthorized access and privilege escalation.Heimdall, a cloud-native security proxy, is susceptible to an authorization bypass vulnerability. This issue arises from a discrepancy in how Heimdall handles request paths compared to downstream components. Specifically, Heimdall performs rule matching on the raw, non-normalized request path, while downstream components might normalize dot-segments (e.g., /user/../admin) according to RFC 3986. This can lead to Heimdall authorizing a request based on the raw path, whereas the downstream service processes a different, normalized path, potentially bypassing intended access controls. The vulnerability affects Heimdall versions prior to 0.17.14. Exploitation is possible when using wildcards in rule matching without further constraints. This could allow attackers to access restricted resources or functionalities.

Attack Chain

1. Attacker crafts a malicious HTTP request with a path containing dot-segments (e.g., /public/../user/resource).
2. The request is sent to the Heimdall proxy.
3. Heimdall performs rule matching on the raw, non-normalized path (/public/../user/resource).
4. Heimdall incorrectly matches the request to a less restrictive rule, such as a rule for /public/**, due to the initial /public segment.
5. Heimdall authorizes the request based on the matched rule, potentially allowing anonymous access.
6. The request is forwarded to the downstream service.
7. The downstream service normalizes the request path to /user/resource.
8. The downstream service processes the request as /user/resource, bypassing the intended access controls for that resource, possibly leading to data access or privilege escalation.

Impact

Successful exploitation of this vulnerability allows attackers to bypass access control policies enforced by Heimdall. This can lead to unauthorized access to sensitive data, modification of restricted data, invocation of privileged functionality without proper authentication or authorization, and in certain configurations, escalation of privileges. The number of potential victims depends on the deployment and configuration of Heimdall within affected environments.

Recommendation

• Apply the available patch to upgrade Heimdall to version 0.17.14 or later to remediate the vulnerability.
• Implement HTTP path normalization or rejection of HTTP paths containing relative path expressions in layers in front of Heimdall, as suggested in the advisory.
• Deploy the Sigma rule provided below to detect suspicious HTTP requests containing dot-segments (..) in the request path.
• Configure your proxies (e.g., Envoy) to normalize paths, as described in the advisory.

]]>highadvisoryauthorization-bypasspath-normalizationcloud