Leaking AWS Metadata
— The Unusual Way
A short tale of finding credentials of AWS instance from an unusual way and exploiting it to gain read/write access to bucket objects.
Tl;dr: Found the AWS Cognito API call for the GetCredentialsForIdentity through the profile picture upload feature of the application which leaks the AWS credentials in the response.
AWS Instance metadata is data about your instance that you can use to configure or manage the running instance. In AWS, the Instance Metadata Service (IMDS) makes information about a compute instance, its network, and storage available to software running on the instance. IMDS also makes temporary credentials. Configuring this metadata credentials in AWS CLI, one can access the services associated with the account.
The Usual Way
The traditional way to extract AWS credentials is via exploiting SSRF. SSRF attacks give the privilege to make requests from the target machine. And if the application is running on any cloud services the attacker can attempt to access the metadata services.
In the case of AWS cloud services its route on Automatic Private IP address over http://169.254.169.254/
Since the metadata service of AWS doesn’t require any particular headers, fetching the URL http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLENAME will return the AccessKeyID, SecretKey, and Security Token.
Test Case:
filename.ext?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/rolename
Tip💡: Use CanaryTokens or Pythonanywhere server to test for SSRF BugsThe scenario I came across:
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.
- Check AWS get-caller-identity
- Listing out bucket objects
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.
- Moving files to the bucket
- Deleting any file from the bucket
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
