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 —
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 —
Tried reading the /etc/password using different URL schemas (file:/// , dict:// , ftp:// and gopher://) and was able to do the same using file:/// scheme —
Earlier, when I was grabbing sensitive files via LFI attack, I happened to read /etc/motd file which suggested that the application was deployed over AWS ElasticBeanstalk.
This message was sufficient for me to decide to go ahead and search for AWS Instance MetaData and User Data via SSRF —
I was also able to retrieve the AWS account ID and Region from the below API “http://169.254.169.254/latest/dynamic/instance-identity/document” —
When I was reading about AWS Elastic Beanstalk, I came across an API call which could fetch AWS Access Key, Secret Access Key, and Token.
I quickly made the call via SSRF and I was able to grab their AWS Access key, ID, token and earlier I got their account id too, and that was the moment when the vulnerability became more critical—
Now it’s time to authenticate into the AWS account. Just to make sure the credentials are not expired, I configured aws-cli and tried to list and download the S3 bucket data onto my local machine and I was able to do so —
Copying s3 bucket content to the local machine —
While reviewing each and every single S3 bucket, I found some critical files inside some buckets, there were files like database.js, config.js, app.js, payment.config files which quickly grabbed my attention and as I was expecting, they found to contain information like Payment hash key and salt (which could be used to tamper with the order’s payment), several database credentials, some internal tools username, and password and much more. There was also one MongoDB instance running whose credentials were also found to be lying in plain text in of the config files and when I tried connecting to it, I found their customer's data stored inside it —
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!