Three vulnerabilities, one access granted - Simple Techniques #3

Hello everybody, hope you're doing well. Welcome again to my third post from the series "Simple Techniques" where I share some situations I encounter when I'm doing my pentests or something that I think it's interesting to share. Today, I am going to talk about how one vulnerability led to me escalating to another vulnerability that allowed me to escalate to another vulnerability and gain access to the customer's internal network. It's an interesting story because it's the first time we could get access to the customer's infrastructure and communicate to the Active Directory.

The not-so-different beginning, but with something interesting

As always, I started my reconnaissance by enumerating all the subdomains linked to this organization. It's a good scope with various applications, but as I mentioned earlier, numerous pentests have already been conducted on the environment. Even so, there is no reason to give up on finding the pot of gold.

I use various techniques to enumerate as many subdomains as possible, such as using Subfinder with all defined API keys, performing subdomain brute force with a wordlist and ffuf, and using search engines like Security Trails, Shodan, Google, Dorki, etc. After that, I save all active subdomains in a text file and use Naabu to enumerate the open ports, which gives me a quick result.

Nothing much different from the traditional approach, I was able to find some vulnerabilities of informational, low, and medium severity, but nothing that would have the impact of high or critical severity vulnerabilities. So, I decided to thoroughly analyze each endpoint and access all the sites I could. I also found some different application paths on Google, which helped me receive a notification in my browser that caught my attention

This is amazing! We found an exposed Git through the DotGit extension created by "davtur19". This extension is very useful because you can configure it to automatically search for /.git directories, .env files, .svn directories, and other directories that may contain sensitive information on every site you access. Clearly, the relevance of this Git would only be high if it contained the source code of some interesting application, which did not seem to be the case here, but I was mistaken. For extracting the /.git directory, my favorite tool is GitHack, developed by "lijiejie".

The image above is just a simple representation; the content was much larger and included various PHP files, JS files, images, and more. However, the ones that caught my attention the most, including the database files, did not contain important information since the database connection was handled by an .env file, which was probably not extracted because it was in the .gitignore. I thought to myself that at least I would have another medium-level vulnerability to report, but I couldn't give up, and that's when I found another vulnerability through this one.

The second vulnerability, a breakthrough.

A very important piece of information I obtained through this exposed Git was the existence of a file called "dump.php," which exposed internal environment information. This included the internal path, internal IP address, and other details that were crucial for us to achieve the maximum impact possible.

Analyzing a specific PHP file that seemed to have little use, I found a very interesting piece of code that allowed me to escalate the severity of this vulnerability. This code appeared to be responsible for reading and downloading some files, which was done through a GET request with a "q" parameter. Further down in the code, I noticed the use of the readfile function, which, according to PHP documentation, reads a file and writes its output to the buffer. This is very promising; the code might be vulnerable to a Local File Inclusion vulnerability. However, it would likely be of limited use since we already have the source code of the entire application and it would be difficult to access and read any relevant files outside the web application's environment.

However, this function has a very interesting peculiarity. If we go back to the PHP documentation, there's a hint left by the development team that allowed me to escalate to another vulnerability.

As described in the image above, the readfile function accepts URLs as valid input if the fopen function is enabled in the environment. This is very interesting because it allows us to explore other vulnerabilities through this, such as a Server-Side Request Forgery (SSRF)! But... I'm not sure if the fopen function is enabled; maybe it won't work here, or will it? =]

At that moment, I began to sweat nervously. I was on a call with two colleagues who were assisting me with this pentest, and we were all anxious for it to work. I went back to my browser, accessed the PHP file, and entered internal IP address that I found through the dump.php as the value for the "q" parameter. Fortunately, we succeeded! The application returned the same web application I was accessing externally!

The third vulnerability, the incredible end.

Now that we can interact with the internal applications, my first idea was to enumerate the internal applications I could communicate with. I sent the same request to the Intruder in my Burp Suite, set the attack parameter and type to a list of numbers from 0 to 254, thus performing an internal enumeration. After a while, I received some interesting responses.

I noticed that at the IP address 192.168.20.168, a PHP application appeared to be internal and developed by the development team itself. It seemed to be an internal application responsible for performing various functions in other environments, such as updates, removals, and so on.

Automatically, all the pentest articles and Bug Bounty posts I had read throughout my life started coming to mind. For some reason, the parameters "p" and "c" caught my attention enough for me to believe that both were vulnerable to Command Injection, with no real evidence, just an intuition that they might be vulnerable. I was right!

My colleagues and I were stunned; we couldn't believe it had actually worked—that just an intuition and a random attempt could be successful. I remember hearing some cheers and experiencing unimaginable happiness. After a while, we calmed down and, using a coded Python reverse shell, managed to establish a reverse shell.

From the access to the Linux machine, we performed network interface forwarding and used crackmapexec to enumerate all active SMB-enabled computers we could communicate with. Once again, we demonstrated the impact to the client, and that’s it—we successfully penetrated the client's internal network.

The end

Thank you to everyone who read up to this point. It was a very cool story to share, as the whole process was quite time-consuming. In this article, it seems to have gone quickly, but during the call with my colleagues, we didn’t even notice the time passing, and before we knew it, it was night. It’s really fun when your experience and learning can actually help you so precisely in your work, and reading some articles and posts gave me an idea I might not have had otherwise. See you next time, everyone, take care.

References

• https://github.com/projectdiscovery/naabu
• https://portswigger.net/burp
• https://github.com/davtur19/DotGit
• https://github.com/lijiejie/GitHack