From Django debug mode to full SSRF-DRIVEN organization takeover

Today, I’ll walk you through how I escalated Django Debug Mode DEBUG=True in a staging environment into a full SSRF exploit ultimately leading to an organization-wide takeover.

What is a debug mode in Django?

Debug mode in Django is a setting (DEBUG=True) that helps in the application development phase by providing detailed error pages when something goes wrong, but It's a security risk in a production environment and should be turned off.

Methodology

For privacy reasons, I’ll refer to the target as redacted.com

I began by enumerating the target's subdomains, which revealed a mix of both production and staging assets.

The subdomain api-staging.redacted.com caught my attention, so I used ffuf with the common.txt wordlist to fuzz for directories and files.

The results were:

https://api-staging.redacted.com/dashboard => 200 OK

The webpage returned a login portal, and using the Wappalyzer extension, I discovered that the web app was built with a Python/Django stack.

The first thing that comes to mind is verifying whether debug mode is enabled for this asset.

I intercepted the request and deliberately updated the host to an invalid one, api-fff.redacted.com, to test if the webpage returns the error page associated with debug mode.

As expected, the page returned the DisallowedHost error.

The returned page contained a large amount of data, including environment variables (secrets hidden), internal IPs, and other assets.

After carefully reviewing the page, three environment variables caught my eye: PROXY, PROXY2, and PROXY3, with the following values:
PROXY=https://X.X.X.X/proxy
PROXY2=https://X.X.X.X/proxy2
PROXY3=https://X.X.X.X/proxy3

After thoroughly investigating these assets, I was able to understand how they function.

hese proxies accept a URL and method parameters. The URL is not validated, allowing the proxy to make requests to any provided value, including internal URLs like localhost and 127.0.0.1.