Leaking AWS Metadata

I’m testing an application which is a professional’s networking platform just like Linkedin,

Fire up my burp suite and start looking for bugs. Found a blind SSRF vulnerability in photo upload functionality, but what’s next cause it’s just make a request from the target machine and nothing else, no response message! Couldn’t find any way to escalate it or extract the AWS metadata(though the main goal) Cause with blind SSRF I already knew the service is running with AWS Elastic beanstalk with some ec2 instances as server pings with the ec2 instance IP.

This is the request which is responsible to update profile picture with elastic-beanstalk bucket url. (This &imgurl= parameter is vulnerable to blind SSRF but of no use😔)

But wait … how do I forget to look HTTP history

Upon checking HTTP History in burp I found an exposed AWS Cognito API call for the GetCredentialsForIdentity,Which in response gives AccessKeyID, SecretKey, and Security Token.

Amazon Cognito is a user identity and data synchronization service that makes it easy for developers to manage user data for their apps across multiple mobiles or connected devices they can create identities for users of their app use public log-in providers like Google Facebook and Amazon. Just save the user data using the Amazon Cognito API and sync it and that’s it the user’s data is securely synced and stored in the AWS cloud. If the website uses other AWS services (like Amazon S3, Amazon Dynamo DB, etc.) Amazon Cognito provides you with delivering temporary credentials with limited privileges that users can use to access database resources.

GetCredentialsForIdentity API request

Returns credentials for the provided identity ID

OK Let me rewind things for you to look at the application flow of profile pic upload feature

The Exposed AWS Cognito API call for GetCredentialsForIdentity which helps application to put data into bucket with assigning temporary credentials. Woohoo! I hit my goal.

Abusing the Metadata:

We got the credentials, Now we can do pretty much bad things but first Let’s configure this credentials with AWS CLI

Now just hit some CLI commands to extract data we need.

To list all buckets objects you have to give the bucket name otherwise it will show Access Denied . I already know the bucket name with the profile pic image location.

As you see we got read / write access to the bucket, Its enough to show the impact. But what attacker can do is worse, can download all the data locally, deletes the entire bucket and again create a bucket with the same name from his account.

And even over all this, An attacker can escalate it to RCE by uploading PHP webshell to s3 bucket and execute system level commands there. Read it here: https://www.notsosecure.com/exploiting-ssrf-in-aws-elastic-beanstalk/

Conclusion:

Look into every HTTP request and response(Just fire up your burp proxy in the background and play with all features of the application), especially where data is reading or writing over the server. Sometimes flaws are just there, you just have to look through the request and response.

Although due to new security integration with IMDSv2, Extracting data with SSRF is not possible but still many applications didn’t update it yet for this so there is still chances to make a hit.

References: https://docs.aws.amazon.com/cognitoidentity/latest/APIReference/API_GetCredentialsForIdentity.html

Thanks for the proofread vartul goyal.

I ❤ Memes & Security. Open to any discussion at twitter.com/nullb0t