Attack on AWS S3 via SSRF

Photo by Onur Binay on Unsplash

This article is based on a true incident that happened with Capital One, where almost 106 million customer accounts were breached. Paige Thompson was accused of the following incident.

We are going to understand how the attack happened and where the vulnerability resides so that you can find and report similar in your next voyage to safely secure the firms. To make it crystal clear and interesting I am going to use an analogy here, where I created a fictional story with characters included from the famous show Mr. Robot.

Before starting let’s clear some facts that we should keep in mind during the story, according to the report by KrebsOnSecurity, Paige Thompson exploited SSRF (Server Side Request Forgery) vulnerability to access AWS cloud endpoints.

So SSRF vulnerabilities are most commonly encountered when either :

  1. There is an attribute where some kind of file generation methodology is being used such as PDF generation.
  2. File upload for instance uploading scanned documents, images, files, etc.

LET THE STORY BEGIN

Elliot needed to take down ECORP, with their new financial laws and supremacy at the market, it’s high time for someone to step up and act and that’s what Elliot does.

Elliot plans his attack on ECORP, first, he visits the website:https://www.Ecorp.com. Elliot already has registered a Bank account at Ecorp (Because who hasn’t they are the Central authority of monetary control now), so he tries to login into that.

URL: https://www.Ecorp.com/login

Username: Elliot

Password: qwerty

Photo by Eduardo Soares on Unsplash

After successfully logging in, Elliot begins his move which is commonly called analyzing the attack surface.

Attack surface mapping is the process of analyzing the applications core functionality, business logic, and control flow to identify potential ways through which an attacker can communicate or interact with the application.

During the mapping, he finds out an interesting key feature and service called “Account Service”. This attribute contains multiple different types of other settings that a user can use to modify their bank account. Among all the services there is one that caught the eye of Elliot, this particular functionality allows any user to modify their Ecard( which is a credit/debit card) by adding a personalized image to the background of the card.

To order a customize Ecard, there is an Ecard Design Studio applet that allows a user to upload the user-supplied image. After uploading Elliot notice that in the preview section the widget URL is used to map parameter/value pair.

https://www.Ecorp.com/myaccount/personalize/cardimage/preview?url=https://s3.eu-central-3.amazonaws.com/file-upload/fsociety.jpg

An s3 bucket URL is being passed as an input parameter to the preview applet.

Looking at the URL, Elliot wonders what if we replace the S3 bucket value with some other link, would it still work?

And Bang !! the URL modifies the webpage according to Elliot's needs, which means that it is susceptible to SSRF attacks. It’s important to understand here that the Ecorp application server made the HTTP request to fetch the URL provided by Elliot.

The ability to manipulate web applications into sending an unauthorized request to a third-party site or resource is known as Server-side request forgery.

FINAL ATTACK

Being a security expert Elliot knows that SSRF has limited risk, but to escalate he needs to get creative and he is best in that. So what he does is use this vulnerability to request non-public URL’s which may expose some sensitive data.

One such service commonly exploited by attackers in the third-party cloud service is the REST-based web service known as cloud metadata endpoints. If configured, metadata endpoints allow lot modification for cloud servers such as system configuration, networking details, authentication access keys, etc.

To check the possible metadata, Elliot submits the modified request :

https://www.ecorp.com/myaccount/personalize/cardimage/preview?url=http://1.1.1.1/latest/metadata

And he retrieves all the categories of instance metadata points associated with it. Among the retrieved data, he focused on the IAM roles (IAM roles are an IAM identity that you can create in your account that has specific permissions), for this he issued the following request to get the security credentials endpoint.

http://1.1.1.1/latest/metadata/IAM/security-credentials/

Elliot completed his attack by stealing the IAM role credentials, once he gets the instance name used for IAM, which is the ISRM-WAF-ROLE he modified the above query as ‘security-credentials/ISRM-WAF-ROLES’ which return the AccessKeyID and SecretAccessKey token for the EC2 instance of ECORP infrastructure.

Using the stolen credentials Elliot now can begin making programmatic calls to the AWS API with the privilege of the ISRM-WAF-ROLE.

So that’s how an ordinary-looking SSRF can be pivoted to reveal confidential data and cause a probable data breach.

An Enthusiast learner who seeks to learn the tech in a whole new different perspective.