Hi Guys,
This is yet another a security vulnerability writeup about one of my recent findings of a chain of security vulnerabilities that linked up to compromise one of the databases of India’s most profitable E-commerce company. Let’s see the complete story —

(This was done with the explicit permission of the concerned company)

This was supposed to be a targetted attack where I was specifically focussing on finding an LFI vulnerability (local file inclusion) so I was more keen on searching and exploring functionalities and endpoints which were related to some interaction with files and then I came across a usual functionality where application provides you with the options of “Android Google play” and “iPhone App store” to download their app.

and when I clicked on it, it redirected me to the following page with the following URL-

and then immediately redirected to the previously referred page and when I opened it in incognito window to see what’s the response when there is no referred page, it got redirected to “404 Page not found” so it was clear that it was looking for some condition and parameters and then following the simple if/else logic. To see if there were any parameters which got missing, I stumbled to look upon the HTML code of the page-

The logic as expected was very clear and the interesting thing which I noticed (as you can see in the red box), there was a php file “download_handler.php” which was missing in the URL which requires a parameter “path” as finaldownloadlink and “name” for the name of the URL and that’s the reason why nothing got downloaded. Let’s follow the above code, so the final URL came out to be —

downloadcallback/download_handler.php?path=

where I simply tried directory traversal attack (../../../../etc/passwd) and to all my luck, files had the maximum permission given (a common mistake :/) and I was able to read /etc/passwd content and various other juicy files —

I was able to read various Linux system files, configuration, access logs which got me user access token coming in get params and much more sensitive information. The culprit of this complete loophole was the “download_handler.php” —

The php file was simply taking the file as an input and reading it back to the client. Could easily see it vulnerable to SSRF as well —

Though it was not containing all the user details but it was as many as more than 10K. I reported the vulnerability soon after this and they were very quick to patch it and also rotated all of their affected credentials and keys. So having started from LFI, I reached to SSRF from where I came to know that the application was deployed over Elastic Beanstalk and from there I was able to grab one of the AWS accounts credentials which helped me to reach one of their Databases credentials which were lying in one S3 bucket over which I had complete read/write access and connecting to the database, I found thousands of customer’s details lying along with various other sensitive credentials/keys and information.

That’s it about this interesting finding!