The world of bug bounty is somewhat complex since you have to know numerous tools as well as techniques to identify vulnerabilities. Many times, the urge to find vulnerabilities causes us to overlook domains that we believe have nothing. In this article I will tell you about my case with a domain.
BUG BOUNTY PROCESS
I was facing a new program in a bug bounty platform. As similar to each new program, i did all process from the beginning:
- Searching subdomains: assetfinder, findomain, subfinder, amass, oneforall…
- Generating permutations over discovered subdomains: dnsgen
- Verifying live subdomains: httpx
- Verifying takeovers: subjack
- Etc ….
After completed this process, i began with a manual recon with alive subdomains, one by one:
- Clicking in all links
- Signing up
- Searching in archive.org
- Reviewing response headers (web cache poison)
- Reviewing postmessages
One of this alive subdomains (which i will refer from now as redacted.com) was showing a simple message:
As there were no content, i tried to discover some juicy directories and files by fuzzing redacted.com with ffuf:
ffuf -w /wordlists/raft-medium-directories.txt -c -fc 404 -u https://redacted.com/FUZZ/
Once finished, only platform directory was identified:
When accessed, another simple message was shown, in this case, Hello Platform:
Bad luck 🙁 . The last thing i did was to review response headers. No information was detailed at all except JSESSIONID cookie:
You would ask yourself why?. Because i remembered that a good friend of mine (@0xd0m7 best hacker in 3rd day of h1-2010 hackerone event) told me:
“I always try /..;/ in JAVA applications because of path normalization discovered by Orange Tsai.”
So, let’s give it a try to see if it works. Then i appended /..;/ to the URL address https://redacted.com/platform/..;/ and my reaction was… WHAT??!!:
I got access to the deployed Tomcat in server 🙂 . This happens when you are using reverse proxy with JAVA as your back-end service, which truncates all the trailing parts by semicolon.
In URL https://redacted.com/platform/..;/ the /..;/ it is threated like a directory (in fact, it represents the parent directory) with the /platform whitelist.
When clicked on Host Manager to access the Tomcat application manager but a 404 Not found was shown:
Wait, wait, what was happening?. Damn, URL address didn’t have the /..;/ . I requested again the URL address with /..;/ and got access to login form:
Nice !!! . Next step was to try default username/password for Tomcat. Something was telling me that it was my day. I loaded default credentials and some requests later…. admin/password granted me access to Tomcat:
I couldn’t believe it !!!. From here, we had to try to get RCE by uploading a WAR file with a reverse shell through Deploy war section. I used msfvenom to generate a reverse shell pointing my VPS IP address and port where netcat would be listening:
Through WAR deploy section, the war file was uploaded:
Finally, we set a listener in our VPS server with netcat and requested the application deployed with https://redacted.com/platform/..;/bugbounty. The connection was received, where i tried a whoami command to verify:
With this RCE i received a 4 digits bounty !!!.
Thanks for reading.
“Don’t give up, great things take time”.