Exploiting Django Debug Mode for Unrestricted Access to the Internal Dashboard!
Django Debug Mode Enabled Leads to Unauthorized Access to Company’s Internal Dashboard
Hello Hackers!
I hope you all are doing well. Myself Rokkam Vamshi, a Security Researcher. In this Blog, I will share one of my findings about How I Leveraged Django Debug Mode Enabled to Gain unauthorized access to a Cloud Cost Scheduler Dashboard.
Let us say the target is the redacted.com for time being. The technique is pretty simple, yet rewarding and effective!
As this is my first blog, there might be some grammatical mistakes. This blog covers the following Topics:
- What Is Django?
- How can one determine whether a subdomain is running on the Django framework?
- What is Wrong with ‘Debug = True’ in the Django Framework?
- How can one determine whether the debug mode is enabled or not?
- How I Leveraged Debug Mode Enabled to Gain Unauthorized Access to Cloud Cost Scheduler Dashboard?
So, Let's get started.
1. What is Django?
Django is a free and open-source web framework, written in Python. It is used to build and maintain websites and web applications. Django is designed to be secure. It includes several features that help to protect web applications from attacks, such as cross-site scripting (XSS) protection, cross-site request forgery (CSRF) protection, and SQL injection protection.
2. How can one determine whether a subdomain is Built on the Django framework?
It is pretty simple and easy to find whether a Domain/Subdomain is Built with Django Framework. You can use the Extension called Wappalyzer. Using this Extension we can easily find whether that particular domain/subdomain is built on the Django Framework. You can use other extensions like BuiltWith.
3. What is Wrong with ‘Debug = True’ in the Django Framework?
As we have discussed earlier, Django Web Framework is used to Build and Maintain Websites. Setting ‘Debug = True’ in the Django framework is common during development for debugging purposes. However, deploying a Django application with ‘Debug = True’ in a production environment is risky. It exposes sensitive information and could potentially allow attackers to gather details about your application’s structure, such as database schema or internal code. This can be a security risk as attackers might exploit these vulnerabilities to compromise the system. Therefore, it’s crucial to set ‘Debug = False’ in production to enhance security.
4. How can one determine whether the debug mode is enabled or not?
Once you find a Subdomain built on the Django Web Framework, It is pretty simple to find out whether the debug mode is enabled or not by just appending any Random text to the Root of the Subdomain like ‘https://redacted.com/RANDOM_TEXT’. If the Debug Mode is set to True then you will see a Non-standard 404 Error Page. But if Debug Mode is False then you will see a Standard 404 Error Page. Observe the Images below.
5. How I Leveraged Debug Mode Enabled to Gain Unauthorized Access to the Cloud Cost Scheduler Dashboard?
In this Section, I will Speak about the entire process of how I got to that particular Vulnerable IP Address which belongs to redacted.com
My Recon Flow:
Whenever I decide to Hunt on a target, I Open up my Kali Linux and run my Custom Made script on the target [redacted.com] which automates my Recon process partially. The Typical Flow of the script is as follows:
It starts by Performing Subdomain Enumeration using different Tools like Subfinder, Assestinder, Amass, and Knockpy. Then it adds up all the results, deduplicates them, and gets the Live Subdomains using the httpx tool. This script continues to perform the remaining Recon Process. But it is out of the scope of this blog which I would cover in another Blog.
##This is part of the recon process
subfinder -d "$target" --silent -o "$HOME/$folder_name/subdomains_subfinder.txt"
assetfinder --subs-only "$target" | tee "$HOME/$folder_name/subdomains_assetfinder.txt"
amass enum -d "$target" -brute | tee "$HOME/$folder_name/subdomains_amass.txt"
crt.sh/crt.sh -d "$target" | sort | uniq | grep -Eo --color=auto "(^|[^a-zA-Z0-9_.-])([a-zA-Z0-9_-]+\.)?${target}" | tee "$HOME/$folder_name/subdomains_crt-sh.txt"
knockpy "$target" | tee "$HOME/bb/$folder_name/subdomains_knockpy.txt"
cat "$HOME/$folder_name/subdomains_subfinder.txt" "$HOME/$folder_name/subdomains_assetfinder.txt" "$HOME/$folder_name/subdomains_crt-sh.txt" | sort -u >> "$HOME/$folder_name/all_subdomains.txt"
cat "$HOME/$folder_name/all_subdomains.txt" | httpx -sc -cl -silent | tee "$HOME/$folder_name/httpx.txt"
echo "Subdomain Enumeration is complete" | notify -silent
##The Remaining process continuesWhile My Custom script is Running in the Background, I usually do Shodan Search.
The Shodan Dorks I used for finding the WebApps using Django are as follows:
http.component:django ssl:redacted.com
http.title:"DisallowedHost at /"I usually open each result from the above dorks in a new Tab and manually Hunt on them.
Likewise, I searched for the HTTP.component:django ssl:redacted.com and got two results. In Which one of them is Django’s Debug Mode Enabled [True].
Then I opened the second result in a new tab and found Cloud Cost Scheduler Login Page.
I found that the Debug Mode is Set to True by appending the Random text to the root URL as https://redacted.com/random_text. The Non-Standard 404 Page Not Found is Disclosing the Internal Endpoints as shown in the below image.
Now, All I did was simply Check every Endpoint by appending it to the root URL like:
https://redacted.com/task/disable
https://redacted.com/cloud
https://redacted.com/schedule
https://redacted.com/admin
https://redacted.com/adminlteBut Nothing gave any good results. I lost Hope but one endpoint was left unchecked. I thought why not give it a try? I tried to access the URL https://redacted.com/adminlte. To My surprise, I was Redirected to the Cloud Cost Scheduler Dashboard without any Authentication.
I was able to see all the information without logging in.
Then I made a Clear Proof-of-concept Video explaining everything and Reported it to the Security Team Through Hackerone. The Triager asked me to prove that the IP belongs to Redacted.com. Then I provided the required information and the Internal Team triaged the report! Hurray :)
After a few days, the security team resolved the vulnerability and awarded Swag.
This is one of my findings. I have reported similar vulnerabilities to other HackerOne Private Programs in which I got Sensitive Information.
I Hope You have learned something from this Blog. I want to thank my friend for helping me out in writing this Blog Yaswanth sai.
If you find value in this article, you can follow me for more content like this :)
LinkedIn | Twitter | Instagram
Thank You for Reading…
By Rokkam Vamshi
