CVE-2024-45336

What it actually does

The vulnerability causes an HTTP client to incorrectly re-attach sensitive headers, such as 'Authorization', to a request following a specific redirect sequence. If a request to a trusted domain is redirected to an external domain, and that external domain issues a subsequent redirect to itself, the client will erroneously include the sensitive headers from the original request. This results in the leakage of credentials or session tokens to the external domain.

Why it matters to the business

This flaw can lead to the exposure of user credentials and session tokens to malicious third parties. An attacker who successfully exploits this could impersonate users, gain unauthorized access to sensitive data, and perform actions on behalf of the compromised user. This poses a significant risk to data confidentiality, user privacy, and can result in account takeovers.

How an attack unfolds

An attacker would first set up a malicious web server. They would then trick a user of a vulnerable application into making a request that gets redirected to this server. For example, the user clicks a link that directs them to a legitimate service, which then issues a redirect to the attacker's server. The attacker's server then issues a second redirect to another page on the same malicious server. Due to the flaw, the user's client would incorrectly attach the original 'Authorization' header (intended for the legitimate service) to the request for the second page on the attacker's server. The attacker can then log this header and steal the user's session token or credentials.

How to fix it

To remediate this vulnerability, update the affected component to a version where the HTTP client correctly handles headers during redirect chains. For the specified Red Hat OpenShift products, update the 'coreos-installer' package and its dependencies to version '0:0.8.0-4.rhaos4.7.el8' or later. For other software, identify the underlying HTTP client library and apply the vendor-supplied patch that corrects this behavior.

How to confirm the fix worked

To validate the fix, create a test that simulates the attack. Set up a local web server that first redirects a request from a trusted origin (e.g., localhost:8000) to a different origin (e.g., localhost:9000), and then has the second origin redirect to itself. Send a request with a test 'Authorization' header using the client being tested. A patched client will not send the 'Authorization' header to the final destination (localhost:9000), while a vulnerable one will. Check the server logs at the final destination to confirm whether the header was received.

Typical attack path

1. An attacker establishes a web server they control that is configured to issue redirects.
2. The attacker induces a user to initiate a request from a vulnerable client to a legitimate service, where the request includes a sensitive header (e.g., 'Authorization').
3. The legitimate service responds with a redirect to the attacker's web server.
4. The attacker's server receives the initial redirected request and responds with a second redirect to a different URL on the same attacker-controlled domain.
5. The vulnerable client follows the second redirect and incorrectly attaches the sensitive header from the original request.
6. The attacker's server receives the request, captures the sensitive header, and gains access to the user's credentials or session token.

How to detect it

Detecting historical exploitation requires analyzing detailed client, network, or web server logs. Look for a sequence of events where a client request containing a sensitive header (like 'Authorization' or 'Cookie') is followed by a redirect to an external domain, which is then immediately followed by another request to that same external domain. Correlating the presence of the original sensitive header in the final request to the external domain is the key indicator of exploitation. This is most feasible with full packet capture (PCAP) analysis or advanced application-level logging.

What your security team should do

• Prioritize patching all client applications that use the vulnerable HTTP library, starting with those that handle sensitive data or are used by privileged accounts.
• Review and enforce network egress filtering to restrict client applications from connecting to untrusted or non-whitelisted external domains, which can limit the impact of a successful exploit.
• If immediate patching is not feasible, consider deploying a network proxy that can inspect and strip sensitive headers like 'Authorization' from requests that are being redirected across different domains.