CVE-2014-1830

What it actually does

The vulnerability lies in the Python requests library's handling of HTTP redirects. When a request is made through an authenticated proxy, the `Proxy-Authorization` header, containing credentials, is incorrectly forwarded to the destination server if a redirect occurs. This exposes the proxy credentials to the server at the redirected location.

Why it matters to the business

If an application uses an authenticated proxy for outbound web requests, this flaw can leak those proxy credentials to external, potentially malicious, servers. An attacker who obtains these credentials could misuse the proxy to bypass network security controls, access internal resources, exfiltrate data, or incur financial costs, all while appearing to originate from the compromised organization's network.

How an attack unfolds

An attacker would host a web service and entice a vulnerable application to make a request to it. This could be achieved by manipulating user-controllable input, such as a webhook URL. Upon receiving the request, the attacker's server responds with an HTTP redirect (e.g., status code 301 or 302) to another attacker-controlled endpoint. The vulnerable requests library follows this redirect but fails to strip the `Proxy-Authorization` header. The new request, sent to the attacker's final destination, includes the proxy credentials, which the attacker can then harvest from their server logs.

How to fix it

Upgrade the Python requests library to version 2.3.0 or later. This can be accomplished by updating the project's dependency file (e.g., `requirements.txt`, `Pipfile`, `pyproject.toml`) to specify `requests>=2.3.0` and then running the appropriate package manager command (e.g., `pip install --upgrade -r requirements.txt`).

How to confirm the fix worked

To confirm the vulnerability is remediated, check the installed version of the Python requests library in all relevant application environments. Use a command like `pip show requests` or `pip list | grep requests` to ensure the version is 2.3.0 or higher. Additionally, you can create a test case that makes a request through an authenticated proxy to a server that issues a redirect, and verify that the `Proxy-Authorization` header is not present in the request sent to the final redirected destination.

Typical attack path

1. An attacker identifies an application using a vulnerable version of the Python requests library and an authenticated proxy.
2. The attacker tricks the application into making a request to a malicious URL under their control.
3. The malicious server responds with an HTTP redirect.
4. The vulnerable client follows the redirect, erroneously sending the `Proxy-Authorization` header to the attacker's final destination server.
5. The attacker captures the proxy credentials from the incoming request headers on their server.

How to detect it

Detecting past exploitation is difficult as the evidence resides on the attacker's server. To detect active exploitation, monitor web server access logs for any incoming requests that contain a `Proxy-Authorization` header. This header should only ever be sent to a proxy server, so its presence in a request to a standard web server is a strong indicator of this vulnerability being exploited. Correlate these findings with outbound traffic logs from internal systems to identify the source of the vulnerable client.

• "Proxy-Authorization:" in web server access logs (not proxy logs)

What your security team should do

• Immediately identify all applications and systems using the Python requests library and prioritize upgrading any instances older than version 2.3.0.
• Use software composition analysis (SCA) tools to scan for vulnerable versions of this library in your codebase and container images.
• If an immediate upgrade is not possible, consider rotating proxy credentials frequently to limit the window of exposure for any leaked credentials.