How do I transition from BlackBox pentesting to WhiteBox pentesting?
Introduction
Penetration testing (pentesting) comes in two main flavors: BlackBox and WhiteBox.
BlackBox Pentesting involves testing a system with no prior knowledge of its internals, simulating an external attacker’s perspective. It focuses on what an outsider can discover.
WhiteBox Pentesting involves testing a system with full access to its internal details, such as source code and architecture. This approach allows for a deeper and more thorough analysis.
Transitioning from BlackBox to WhiteBox pentesting can be valuable as it provides a more complete view of a system’s security, allowing you to identify and fix vulnerabilities more effectively. This shift can enhance your testing skills and improve security outcomes.
Yesterday, I was given a BlackBox pentest task, and one of the subdomains is https://admin.example.com. Even though I requested the admin username and password from the company, they said that since it’s a BlackBox test, I am not allowed to obtain any credentials. After that, I said, “Okay, let me cook.” and I started directory fuzzing. Booom! I found https://admin.example.com/.git. I laughed a lot and thought, “You really messed up.”
Exposing the .git Directory: A Case Study
During a recent BlackBox pentest, I discovered that the .git directory was exposed on a subdomain (https://admin.example.com). This directory, usually hidden and secure, contains critical version control information for Git repositories.
Accessing the .git Directory
By pulling the .git directory from the server, I obtained the entire repository’s metadata and history. The .git directory includes:
- Objects: The actual file content and changes.
- Refs: Branches and tags pointing to specific commits.
- Config: Repository configuration settings.
- Index: The staging area for commits.
Restoring the Repository
Once I had the .git directory, I used the command:
git restore .
BOOOOOMMM! I GOT THE SOURCE CODE!!!
Then I started analyzing the source code to identify additional risks and vulnerabilities. During this process, I discovered a file named actions.php and visited it.
Because I had the source code, I was able to identify additional parameters to test. I analyzed the code and determined which parameters to use for further exploration.
Then I aimed to trigger a reflected XSS vulnerability. I tested it by using the following URL: view-source:https://admin.example.com/actions.php?id=1&mynetref=test.
YESSS. I triggeredd XSS!!!
Conclusion
In this pentesting exercise, I demonstrated how a seemingly simple exposure of the .git directory can lead to significant security risks. By accessing and analyzing the .git directory, I was able to retrieve the entire source code of the application. This not only highlighted the importance of securing such directories but also allowed me to identify and exploit additional vulnerabilities, including reflected XSS.
This case underscores the necessity of implementing robust security practices, such as preventing unauthorized access to version control directories and conducting thorough code reviews. It also illustrates the value of having both BlackBox and WhiteBox testing approaches in identifying and mitigating security risks.
By understanding and addressing these vulnerabilities, we can better protect our systems and ensure a more secure digital environment. Continuous vigilance and proactive measures are essential in maintaining the integrity and safety of our applications.
THANKS FOR READING!
