CVE-2014-0472

What it actually does

The vulnerability exists in the `django.core.urlresolvers.reverse` function. When an application view uses this function to generate a URL and passes user-supplied data as the view name, an attacker can craft the input to be a "dotted Python path" (e.g., `malicious.module.view`). Django's URL resolver will attempt to import this path, leading to the execution of arbitrary Python code if the attacker can place a malicious module within the application's `PYTHONPATH`. This results in remote code execution (RCE) with the privileges of the Django application process.

Why it matters to the business

Successful exploitation leads to remote code execution on the web server, allowing an attacker to take full control of the application. This can result in the theft of sensitive data, service disruption, and using the compromised server to launch further attacks against the internal network. The consequences include significant financial losses, reputational damage, and potential legal and regulatory penalties.

How an attack unfolds

An attacker first identifies a vulnerable Django application where user-controlled input is passed to the `django.core.urlresolvers.reverse` function. The attacker then needs to place a malicious Python module (e.g., `evil.py`) somewhere on the server's filesystem that is included in the application's `PYTHONPATH`. This could be achieved through a separate vulnerability or a misconfigured file upload feature. Finally, the attacker sends a crafted request to the application, providing the dotted path to their module (e.g., 'evil') as the input that gets passed to the `reverse` function. The Django URL resolver will then import and execute the attacker's module, giving them control over the server.

How to fix it

The primary remediation is to upgrade Django to a non-vulnerable version. Upgrade to Django 1.4.11 or later, 1.5.6 or later, 1.6.3 or later, or 1.7 beta 2 or later. If immediate upgrade is not possible, developers must ensure that any user-provided data passed to the `django.core.urlresolvers.reverse` function is strictly validated against an allow-list of known, safe view names. Do not allow any special characters, particularly dots (`.`), in the input that is passed to this function.

How to confirm the fix worked

To validate the fix, verify that the Django framework has been upgraded to a patched version (e.g., 1.5.6+, 1.6.3+, etc.). Perform a security code review, searching for all calls to `django.core.urlresolvers.reverse`. For each call, confirm that any arguments originating from user input are strictly validated against an allow-list of expected values and do not contain path-like structures. A penetration test can confirm the fix by attempting to pass dotted Python paths to views that use the `reverse` function and observing the server's response.

Typical attack path

1. An attacker identifies a public-facing Django application running a vulnerable version.
2. The attacker probes the application to find a view that constructs a URL using the `reverse()` function with user-controllable input.
3. The attacker leverages a separate mechanism, such as an unrestricted file upload, to place a malicious Python module onto the server in a predictable, importable location.
4. The attacker sends a specially crafted request containing the dotted path to their malicious module as the parameter for the `reverse()` function.
5. The Django application processes the request, causing the URL resolver to import and execute the attacker's code, leading to remote code execution.

How to detect it

To detect potential exploitation, security teams should review web server access logs and application logs for requests containing suspicious strings in their parameters. Look for values that resemble Python's dotted-path notation (e.g., `user_input=module.submodule.function`). On the host, monitor the Django application's process for unusual child processes, such as `/bin/sh`, `bash`, `nc`, or `python` executing unexpected commands. Check for file writes of `.py` or `.pyc` files in unusual locations, especially in directories that might be part of the application's `PYTHONPATH`, which could indicate the staging of a malicious module.

• /[?&][^=]+=.*\w+\.\w+/ in HTTP request URI
• Anomalous child processes of the WSGI server process (e.g., gunicorn, uwsgi), such as `sh`, `bash`, `nc`, `curl`, `wget`.
• HTTP request logs containing dotted paths referencing common Python modules used for code execution, such as `os.system`, `subprocess.run`, `pty.spawn`.

What your security team should do

• Immediately upgrade all Django instances to a patched version (1.4.11+, 1.5.6+, 1.6.3+, or 1.7 beta 2+).
• If patching is not immediately feasible, instruct development teams to audit their code for uses of `django.core.urlresolvers.reverse` and implement strict allow-list validation on any user-controlled input passed to it.
• Run static analysis security testing (SAST) tools across Django codebases to automatically detect vulnerable calls to the `reverse` function.
• Review web server access logs for requests containing suspicious dotted-path strings in parameters, which may indicate exploitation attempts.