CVE-2023-45289

What it actually does

A flaw in Go's standard library http.Client causes it to improperly handle sensitive headers (such as 'Authorization' and 'Cookie') during cross-domain HTTP redirects. When a vulnerable client follows a redirect, it may fail to strip these headers from the new request, sending them to the destination server. This results in the leakage of sensitive credentials like API keys or session tokens to the redirect target.

Why it matters to the business

Exploitation of this vulnerability can lead to the theft of user or service credentials, enabling attackers to gain unauthorized access to accounts and systems. This could result in data breaches, account takeovers, financial fraud, and reputational damage. The risk is highest for applications that make HTTP requests to user-supplied or untrusted URLs.

How an attack unfolds

An attacker first needs to position themselves to control a web server that a vulnerable Go-based application will interact with. This could be achieved by tricking a user or the application into making a request to a malicious URL. The attacker's server then responds with an HTTP 3xx redirect message, pointing the client to a different domain, also controlled by the attacker. A vulnerable Go http.Client, upon receiving the redirect, will follow it but fail to clear the sensitive headers from the original request. Consequently, the client sends a new request to the attacker's second domain, but this request now includes the original 'Authorization' or 'Cookie' headers, delivering the credentials directly to the attacker.

How to fix it

This vulnerability is fixed in the Go standard library. To remediate, upgrade the Go toolchain to version 1.21.8 or 1.20.13 (or newer). After upgrading the build environment, all Go applications must be recompiled and redeployed to ensure they incorporate the patched http.Client implementation.

How to confirm the fix worked

To confirm remediation, verify that all Go applications are built with a non-vulnerable version of the Go toolchain (1.21.8+ or 1.20.13+). This can be checked by running `go version <path_to_binary>` on compiled application artifacts. To test for exposure, create a test case where a Go client connects to a controlled endpoint that issues a cross-domain redirect, and use network monitoring tools to confirm that 'Authorization' and 'Cookie' headers are not forwarded in the redirected request.

Typical attack path

1. An attacker identifies a Go application that makes HTTP requests to external or user-controllable URLs.
2. The attacker induces the application to make a request to a server they control.
3. The attacker's server responds with an HTTP redirect (e.g., 301, 302, 307) to a different, attacker-controlled domain.
4. The vulnerable Go client follows the redirect without stripping sensitive headers like 'Authorization' or 'Cookie'.
5. The client sends the request, including the sensitive headers, to the attacker's second domain.
6. The attacker captures the headers, stealing the session token or API key.
7. The attacker uses the stolen credentials to impersonate the user or service and gain unauthorized access.

How to detect it

Detecting historical exploitation requires detailed network or application logs. Analysts should search for patterns where an outbound request from a Go application receives an HTTP 3xx redirect response, and the subsequent request to the new domain unexpectedly contains sensitive internal headers like 'Authorization' or 'Cookie'. Correlating application logs with outbound web proxy or firewall logs can help identify requests to untrusted domains that may have been the target of a credential-stealing redirect.

What your security team should do

• Identify all applications built with Go that make outbound HTTP requests and catalog the Go version used in their build pipelines.
• Prioritize upgrading all Go build environments to use Go version 1.21.8+ or 1.20.13+.
• Trigger recompilation and redeployment for all identified Go applications to ensure the fix is active in production.
• As a defense-in-depth measure, review application logic to restrict or validate URLs used in HTTP requests, minimizing interaction with untrusted endpoints.