Chain of hacks leading to Database Compromise!

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 —

/etc/passwd file

Reading other sensitive files via LFI

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” —

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 —

SSRF

Tried reading the /etc/password using different URL schemas (file:/// , dict:// , ftp:// and gopher://) and was able to do the same using file:/// scheme —

SSRF leads to access /etc/passwd

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.

ElasticBeanstalk in use

This message was sufficient for me to decide to go ahead and search for AWS Instance MetaData and User Data via SSRF —

AWS Instance User Data

AWS Instance MetaData

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” —

AWS Metadata — Retrieving the Account ID and Region

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.

http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanstalk-ec2-role

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—

AWS Account access ID and access Key

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 —

Configuring AWS Command Line Interface

Copying s3 bucket content to the local machine —

Recursively copying all the S3 Bucket content

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!

Thanks for reading!

~Logicbomb ( https://twitter.com/logicbomb_1 )