Hello people, Here I am sharing another four-digit write-up which is one of my very old findings. If you haven’t read my previous writeup about how I was able to bypass a strong rate limit mechanism on all the endpoints then here is the link to it:

Lots of people were confused with the title when I initially posted about this bug. So here is the complete writeup and methodology that I used. At the time I discovered this bug I had just started my bug bounty journey after reading many E-books and write-ups.

I decided to choose a target randomly to and I got to know that only mentioned domains and subdomains were in scope. All the other subdomains were considered as Out of Scope. They also mentioned in their policy that *.target.com is out of scope but target.com was in scope. This is because the company was actually providing some kind of services to their clients which allows them to make their customize subdomains like client1.target.com,client2.target.com. Due to this, they restricted testing on any of the subdomains. So what to do when this type of target crosses our brain? The first thought that came into my mind was that maybe I should try to find any critical vulnerability on their subdomains as not so many researchers have checked due to their policy.

The first thing I did was to find subdomains but not with our normal method. Instead, I used subdomain enumeration wordlist which contained words like app,development,dev,service,app-dev etc.

Very limited subdomains were extracted using this method and out of them, one subdomain was like services.target.com. On visiting this subdomain it showed a DNS error but still, I don’t know how this got detected in subdomain enumeration phase. Next thing I tried to use google dork i.e. site:*.services.target.com where I found some results from domains like public.services.target.com etc.

You must have observed that the subdomain contains word “services” which may indicate that there are some more services running on this subdomain. Next thing I extracted subdomains for the domain “services.target.com”. Interestingly I found a subdomain “sserver.services.target.com”.

This page contains a normal login page and upon observing UI, I guessed that it was used to manage source codes and other things by directly giving access to the github account.

So maybe this login portal was meant for employees and only employees are given credentials to access further. Now I was just wondering what to do next, Search for JS files, use github dorks for credentials leak, etc. but nothing interesting came as this domain was not mentioned anywhere.

I observed the URL which was “/sign-in?returnTo=%2F”. And tried to change the “sign-in” to other URLs like “register”, ”get-started” and simply “sign-up” showed me a signup page asking for email, username, and password.

Still, I was in doubt that after clicking on register, it may show error that sign-up is not possible just like JIRA. But guess what? It allowed me to signup using my email and I was successful in signing into account.

Now next task was to see what access we have and what sensitive information we can see. And I was not able to believe my eyes, They were using this server portal to manage all of their github codes. Even the private repositories. Any new users were given direct access to all the codes shared on this portal.

Now when I tried to access the same repo from the portal, then it was easily accessible and I was able to see all the credentials as well as any secret files.

All of their private repositories were accessible and all of their secret API keys, and admin account credentials were visible. It was a complete organizational takeover. As they were providing services to many clients, all of their client data was also accessible through these exposed credentials.

I immediately created a report and the team triaged and fixed this report within 40mins making the portal inaccessible from public view. Also, they rotated any credentials exposed. They rewarded me with their highest payout for critical i.e. 2000$

TIP: Even if something is not in scope, give it a try. Don’t try aggressive testing but still look for any critical vulnerabilities.

Look even for subdomains of subdomain if you feel any suspicious subdomains running.

Look for any endpoints that may contain words like “services”, “internal” etc., and look for any open services available.

That’s it guys, I hope you liked it, and do share if you found it helpful.