code

How We Were Able to Fetch Internal Server Resources

Written by Snir Aviv on

How We Were Able to Fetch Internal Server Resources

Written by Snir Aviv on


Introduction

During a penetration test, we discovered a critical vulnerability that allowed access to private Git repositories, exposing highly sensitive files. The web application permits authentication for doctors and patients and consists of sensitive medical information.

How we Found the Critical Finding

Step 1: Initial Access to the Web Application

We accessed the web application and evaluated the logic by reviewing the client-side code and performing basic functionalities. Next, we observed that the application repeatedly used a directory named docs. However, at first glance, it did not return any interesting information besides an HTTP 200 OK response code.

Exploring the Web Application and Accessing Directories

Step 2: Fuzzing

Next, we focused on the docs directory and performed fuzzing using a publicly available wordlist. While doing so, we gradually encountered several Git directories that were publicly accessible. For instance, we found a Git configuration file that revealed global variables and also included the full URL of an interesting repository.

Git Configuration Data Contains Accessible Repositories

Step 3: Putting All Together and Exploit

This repository could be easily cloned, which seemed to contain server-side code after a quick investigation inside. In addition, we have found resources consist of sensitive data about users and admins of the application, including IDs, email addresses, phone numbers as well as credentials in clear text:

Cloning the Web Application’s Server-Side Code 
Git Repository Contains Sensitive Information About Users and Administrators

Mitigation

Clear Gate advised blocking access to the exposed sensitive files from the Internet. After implementing the solution, Clear Gate confirmed it was applied correctly and that the risk no longer applies.

References

Protect Data Everywhere – OWASP