CVE-2023-43804: A Deep Dive into the urllib3 Cookie Leakage Vulnerability

Introduction:

In the realm of web automation and data acquisition, libraries like urllib3 in Python serve as critical tools. However, lurking beneath the surface can be vulnerabilities like CVE-2023-43804, posing significant security risks. This blog delves into the technical intricacies of this vulnerability, its impact with a proof of concept, and mitigation strategies.

Technical Breakdown:

CVE-2023-43804 resides in urllib3 versions prior to 2.0.6. The culprit lies in the library's lack of inherent support for the Cookie HTTP header. While users have the ability to specify cookies within request headers, urllib3 itself doesn't provide:

  • Automatic Cookie Management: The library doesn't automatically manage or store cookies across requests, unlike libraries like requests. This necessitates manual handling by the user.

  • Integration with Browser Cookies: There's no built-in mechanism to interact with or utilize browser-stored cookies, further limiting cookie management capabilities.

This seemingly normal omission can become a security concern under specific circumstances due to how some servers handle redirects and cookies.

Exploitation Mechanics:

  1. Crafting the Malicious Header: An attacker or an unsuspecting user can inject a crafted Cookie header into a request sent through urllib3. This header can contain sensitive information like:

    • Authentication Tokens: These tokens grant access to user accounts and resources, making them prime targets for attackers.

    • User IDs: Unique identifiers can be used to track user activity or link them to specific actions.

    • Other Sensitive Data: Preferences, tracking information, or any data stored in cookies can potentially be leaked.

  2. Server-Side Misconfiguration: The vulnerability stems from vulnerabilities in the target server's handling of redirects and cookies:

    • 30x Redirects (e.g., 302 Found): If the server blindly copies cookies from the initial request to subsequent responses during redirects, the user's information can be inadvertently exposed in the redirected response.

    • Improper Cookie Handling: Flawed server-side logic that allows copying of cookies from the request to the response, regardless of redirects, can also lead to leakage.

Technical Nuances:

The vulnerability exploits a specific behavior in HTTP protocol specifications. When a client (e.g., our script using urllib3) sends a request to a server, it can include a Cookie header containing key-value pairs of cookie information. However, during redirects (indicated by 3xx status codes), the server might improperly include these cookies in the subsequent response, even if not explicitly intended by the client. This behavior is not inherently wrong, as some legitimate use cases exist for preserving certain cookies across redirects. However, vulnerable servers either lack proper configuration or implement faulty logic, resulting in unintentional leakage of sensitive information.

Impact and Consequences:

A successful exploit can have severe repercussions:

  • Session Hijacking: If the attacker acquires an authentication token through leaked cookies, they can potentially take over the user's session, granting unauthorized access to accounts and resources.

  • Information Disclosure: Leaked cookies might reveal personal information like user IDs, preferences, or behavioral data, potentially leading to privacy violations.

  • Account Takeover: In extreme scenarios, leaked data combined with other vulnerabilities might facilitate account takeover attempts by attackers.

Proof of Concept:

To reproduce this vulnerability in a local environment to experience it in real-time. We will first install a vulnerable version of urllib3. We can do it by running the following command on our terminal:

python3 -m pip install urllib3==2.0.5

Now let's create simple flask app which redirects the users to google.com. We can use this script to set up a flask server:

from flask import Flask, redirect
app = Flask(__name__)

@app.route('/')
def index():
    # Redirect to 'https://google.com' with a 301 status code
    return redirect("https://google.com", code=301)

if __name__ == '__main__':
    app.run(host="0.0.0.0", debug=True)

We can save this flask code in a file called app.py and simply run the server on our localhost by:
python3 app.py

Once we have the server up and running which redirects the users to another website, we can execute following exploit script to verify if the request made to this server using a vulnerable version urllib3 library actually sends the request headers to the redirected website:

import urllib3
url = 'http://127.0.0.1:5000/'
headers = {'Cookie': 'TEST_COOKIE=WhiteHackLabs'}

http = urllib3.PoolManager()
response = http.request('GET', url, headers=headers)

print(
    f"""
    CVE-2023-43804
    You must have URLLib3 version < 2.0.6
    Info:
    Current version: {urllib3.__version__}
    Current Cookie: {headers['Cookie']}
    URL: {url}
    
    Status Code: {response.status}
    Redirected URL: {response.headers.get('Location')}
    """,
    f"\nCookies: {response.getheader('Set-Cookie')}" if 'Set-Cookie' in response.headers else
"No leaked cookies"
)

We can expect a following response from this script if we successfully exploit the CVE-2023-43804 flaw:

Here we can see that the server response is actually forwarding the request header to the website where it is redirecting the incoming request to.

CVE-2023-43804 Patch:

In the patch commit, they are now removing cookie from the headers when it is redirecting to a different host as there could potentially be sensitive information stored in it. Previously, it used to just remove the Authorization header.

Mitigation Strategies:

  • Upgrade urllib3: Updating to urllib3 version 2.0.6 or later is critical. These versions implement proper handling of the Cookie header, preventing unintended leakage.

  • Manual Cookie Management (if upgrading isn't feasible):

    • Avoid setting sensitive information in request headers.

    • Implement custom logic to isolate and manage request and response cookies explicitly.

    • Consider alternative libraries like requests that offer built-in cookie management features.

  • Server-Side Safeguards: Server administrators should:

    • Review redirect handling logic to ensure appropriate cookie behavior.

    • Implement robust cookie management practices on the server to prevent unintended leakage.

Conclusion:

CVE-2023-43804 serves as a reminder of the importance of understanding library functionalities and potential vulnerabilities. By adhering to secure programming practices, staying updated with library versions, and advocating for secure server-side implementations, we can collectively mitigate risks associated with vulnerabilities like CVE-2023-43804 and safeguard sensitive information in web interactions.

Disclaimer:

The information presented in this blog post is for educational purposes only. It is intended to raise awareness about the CVE-2023-43804 vulnerability and help mitigate the risks. It is not intended to be used for malicious purposes.

It's crucial to understand that messing around with vulnerabilities in live systems without permission is not just against the law, but it also comes with serious risks. This blog post does not support or encourage any activities that could help with such unauthorized actions.

CVE-2024-22416: CSRF Vulnerability in pyLoad (pyload-ng)
CVE-2024-22416: CSRF Vulnerability in pyLoad (pyload-ng)
2024-05-19
James McGill
CVE-2023-1177: Path Traversal Vulnerability in MLflow
CVE-2023-1177: Path Traversal Vulnerability in MLflow
2024-05-19
James McGill
CVE-2024-1561: Unauthorized Local File Read Vulnerability in Gradio Applications
CVE-2024-1561: Unauthorized Local File Read Vulnerability in Gradio Applications
2024-05-12
James McGill
CVE-2024-27956: SQL Injection Vulnerability in ValvePress Automatic (WP-Automatic)
CVE-2024-27956: SQL Injection Vulnerability in ValvePress Automatic (WP-Automatic)
2024-05-05
James McGill
CVE-2023-23752: Improper Access Control in Joomla! Versions 4.0.0 through 4.2.7
CVE-2023-23752: Improper Access Control in Joomla! Versions 4.0.0 through 4.2.7
2024-05-05
James McGill
CVE-2024-4040: A Critical CrushFTP Server-Side Template Injection Vulnerability
CVE-2024-4040: A Critical CrushFTP Server-Side Template Injection Vulnerability
2024-05-02
James McGill