/env and bypass 403
Last updated
Last updated
When it comes to a big target like Microsoft, Google or Apple, we must keep in mind the size of the scope of the company. As these are extremely large companies, we must know how to start an approach, what to look for and how to work with a huge amount of data.
I started my approach at Apple by first targeting the main domain apple.com as my target. These large companies generally have their acquisitions in scope and accept vulnerabilities in their acquisitions. But I chose to test Apple’s main domain first.
I set the apple.com as my target because it would probably be the domain with the most subdomains I could find, so I could automate subdomain takeover vulnerabilities and my attack surface would be much bigger to test.
Like every bug hunter, I started my subdomain enumeration. Not to waste my time, I’ve already created an automation using tools like Amass, Subfinder, Assetfinder, Sublist3r, Dnscan and more to do the process of finding subdomains. And remembering again, as this is a big company, you need to know how to work with a lot of data, and from my experience, I knew that it would take a long time and there would be a lot of subdomains to look at, so I used a prioritization strategy of host.
Before validating if the subdomains were active, I filtered the subdomains by keywords that I thought could have interesting data and more critical vulnerabilities in the application. So the filter looks like this:
So, I left the automation running and did a more careful manual analysis of the hosts in the file called “priority.txt”.
The first thing I did was validate which subdomains were active with httpx and save the output in a file called “active_priority.txt”.
And after I did the discovery of files and directories through brute force using the dirsearch tool with my own list.
During the analysis, I found a host whose /env endpoint was exposed to the public.
At that point my heart skipped a beat because I knew I had found an information disclosure bug that leaked information about the host environment.
The application was exposing a lot of information about the Springboot environment, but unfortunately I didn’t find any extremely sensitive information like API keys or passwords.
What I was able to get was information about usernames, software versions, knowledge of the server’s internal structure, knowledge of other external and internal servers, and paths in the application.
Environment Variables: These might include API keys, passwords, database connection strings, and other sensitive details that might be set up as environment variables.
Application Configurations: Information about how the application is configured. This might include details about other services it communicates with, specific application settings, and perhaps sensitive information that shouldn’t be there.
System Details: Information about the operating system, Java version, system user, and other specifics. This information can be used in a social engineering attack or to pinpoint potential vulnerabilities based on specific software versions.
Connectivity Information: Connection strings, service URLs, and other details that give insight into the application’s infrastructure setup.
Command-Line Arguments: These can reveal operation modes, configured options, or perhaps sensitive details passed at startup.
Configuration Details: By understanding the hierarchy and origin of configurations, an attacker might pinpoint misunderstandings or mistakes in how configurations were set.
Continuing…
I ran some other tests if I could manage to escalate the vulnerability, but to no avail. (Other things that can be tested: here ).
So I decided to report this to Apple and luckily they accepted my report and on the same day applied the vulnerability fix.
And as expected, they fixed it by restricting the page, and when you accessed the page, it returned a status code 403 Forbidden.
Well, now that access is blocked, that means the vulnerability is completely fixed, right? NO!
When I saw 403 Forbidden in the response I was reminded of some articles and reports on Medium and HackerOne about a technique known as the “403 Bypass”. It was the most obvious test I could try and that’s exactly what I did.
I read a very interesting article about an IDOR Vulnerability in Apple and the researcher was able to bypass the vulnerability fix and I was inspired to try and ignore correction, after all all technologies and especially humans are prone to making mistakes.
(Article: https://ahmdhalabi.medium.com/pii-disclosure-of-apple-users-10k-d1e3d29bae36)
I believe that one of the things that every hacker must have is curiosity and learning not to trust 100% in the security of something.
I continued my “403 bypass” tests with an automated tool available on github: https://github.com/Dheerajmadhukar/4-ZERO-3 and ran the script like this:
That way, the script will run all the payloads it has. And after a few seconds I finally saw a different response…
Yes, I really didn’t believe it at the time, because it was the first thing that came to my mind, I decided to test it and it really worked.
I ran the command that the script brought me and BOOMMMMMMM!!!
I got all the sensitive information again!
I reported to the Apple Team how I was able to bypass the vulnerability fix and they fixed it after a day. And unfortunately I couldn’t bypass the second security fix hahaha! :)
