Current Offer on Pentesting Exam: 90% Off on CBP

The Anatomy of AWS Misconfigurations: How to Stay Safe

The Anatomy of AWS Misconfigurations: How to Stay Safe

Hello readers! In this blog post, our Senior Consultant Raj has discussed some of the most common AWS misconfigurations, their exploitation, recommendations and practice labs for hands-on experience.

TL;DR

  • To store or compute data, most organisations utilise AWS services such as S3 buckets, Relational Databases (RDS), EC2 instances, and so on. The process of configuring AWS services is increasingly important while using them. Misconfigurations can arise for a variety of causes, including human mistakes, a lack of understanding, or insufficient security practises, which can allow unauthorised access to an organization’s vital assets or data.
  • A dedicated free practice lab related to common AWS misconfigurations can be accessed by navigating to Vulnmachines.

What is AWS?

Amazon Web Services (AWS) is a cloud computing platform offered by Amazon. It provides a wide range of cloud-based services like computing power, storage, and databases, as well as tools for machine learning, artificial intelligence, and Internet of Things (IoT) applications. AWS offers a pay-as-you-go model, which means that customers only pay for the services/resources they use, and they can easily scale up or down as per their requirements. AWS is one of the most popular choices for businesses of all sizes because of its reliability, scalability, and affordability. Its extensive developer and user community has also contributed to the development of a vast ecosystem of tools and services.

AWS offers a vast range of services and some of its most common services include:

  • Amazon Elastic Compute Cloud (EC2): Provides scalable computing capacity in the cloud and allows users to launch virtual machines and run applications on them.
  • Amazon Simple Storage Service (S3): Provides secure and durable object storage for storing and retrieving data in the cloud.
  • Amazon Relational Database Service (RDS): Provides a managed database service that makes it easy to set up, operate, and scale relational databases in the cloud.
  • Amazon Lambda: Allows users to run code without provisioning or managing servers. It scales automatically, responding to each request and charges only for the compute time consumed.
  • Amazon CloudFront: A Content Delivery Network (CDN) that securely delivers data, videos, applications, and APIs to customers globally.

AWS offers over 200 services, making it a comprehensive solution for all cloud computing needs. For more information on the services provided by AWS visit the following URL: AWS services.

Understanding Misconfigurations in S3 Buckets

What is the AWS S3 bucket?

S3 (Simple Storage Service) bucket is a public cloud storage resource available in Amazon Web Services (AWS). S3 buckets consider each resource as an independent object. S3 buckets are like files/folders, which store objects and their metadata.

How to access resources from the S3 bucket?

S3 buckets can be accessed using path-style and virtual-hosted–style URLs or through programmatically(AWS-CLI):

https://bucket-name.s3.region-code.amazonaws.com/resource-name

https://s3.region-code.amazonaws.com/bucket-name/resource-name

Example:

https://TestBucket.s3.ap-south-1.amazonaws.com/TestResource

https://s3.ap-south-1.amazonaws.com/TestBucket/TestResource

Access Control Lists

Access Control Lists (ACLs) allow you to manage access to S3 buckets and its objects. Each S3 bucket and its objects have ACL attached to it as a sub-resource. It defines which AWS accounts or groups are granted access and the type of access.

Amazon S3 has a set of predefined groups. AWS provide the following predefined groups:

Authenticated Users group

It is represented by http://acs.amazonaws.com/groups/global/AuthenticatedUsers. This group represents all AWS accounts. When you grant access to the Authenticated Users group, any AWS-authenticated user worldwide can access your resource.

All Users group

It is represented by http://acs.amazonaws.com/groups/global/AllUsers. Access permission to this group allows anyone worldwide to access the resources.

Log Delivery group

It is represented by http://acs.amazonaws.com/groups/s3/LogDelivery. This group allows WRITE permission on a bucket to write server access logs.

Reference: https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html

Public Buckets

Today, many websites use S3 buckets to store data and host static websites. Whenever you use an S3 bucket for website storage or as a static site hosting option, you have to make some resources or all the resources public so that the website can be accessed by anyone. This is an easy process, but if done incorrectly, it can potentially put all of your data at risk of a breach. If the S3 bucket is public then it will allow users to list and access all the available resources stored in that bucket.

Use aws s3api get-bucket-acl --bucket <Bucket_Name> to retrieve bucket ACL:

Here the All Users group is assigned READ permissions so anyone can access all the resources stored in this bucket.

Pentester’s Approach:

  • Retrieve and observe bucket ACL
  • Look for sensitive information about web applications or AWS account
  • Try to upload new files or remove existing ones based on the bucket ACL

Developer’s Approach/Recommendation:

  • Use Access Analyzer for S3 to review bucket ACLs/policies.
  • Do not store any sensitive information in publicly accessible S3 buckets.

Practice Lab: Public Bucket

We have created a lab around S3 bucket misconfiguration which can be accessed here – Lab on Public Bucket

Once on the lab URL, observe that the web application is hosted on an S3 bucket:

Use aws s3api get-bucket-acl --bucket vnm-sec-bucket command to retrieve bucket ACL.

As you can see in the above-mentioned ACL, the bucket is publicly accessible.

Bucket vnm-sec-bucket is public, so it will allow the listing of its objects. Now, modify the URL as shown in the below figure, to list all the objects available in the bucket:

You can observe in the above figure that the bucket has a flag.txt file. You can access the flag.txt file by appending the filename in the URL.

Practice Lab: Misconfigured Bucket

We have created a lab around misconfigured bucket misconfiguration which can be accessed here – Lab on Misconfigured Bucket

Once on the lab URL, observe that the web application is hosted on an S3 bucket:

Now let’s try to list all objects by modifying the URL, as shown in the figure below:

Here, bucket vnm-sec-aws is not public so it will not allow users to list all objects.

Use aws s3api get-bucket-acl --bucket vnm-sec-aws command to retrieve bucket ACL.

As you can see in above mentioned ACL, the bucket is accessible by any AWS authenticated user.

Here, you can use AWS CLI to list all the objects of the vnm-sec-aws bucket. Use https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html to set up AWS CLI and use aws configure to add any valid credentials, as shown in the below figure:

Use aws s3 ls s3://vnm-sec-aws/ --recursive command to list all objects, as shown in the below figure:

Use aws s3 cp s3://vnm-sec-aws/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/flag.txt . command to copy flag.txt on your computer:

Now you just need to decode the text to retrieve the flag.

Understanding Misconfigurations in EC2 Instance

What is an AWS EC2 instance?

An Amazon EC2 instance is a virtual server in Amazon’s Elastic Compute Cloud (EC2) for running applications on the Amazon Web Services (AWS) infrastructure.

Instance metadata is data about your instance that you can use to configure or manage the running instance. Most EC2 Instances have access to the metadata service at 169.254.169.254. This contains useful information about the instance such as its IP address, the name of the security group, etc. On EC2 instances that have an IAM role attached, the metadata service will also contain IAM credentials to authenticate as this role.

Use the following URLs to view all categories of instance metadata from within a running instance:

IPv4: http://169.254.169.254/latest/meta-data/

IPv6: http://[fd00:ec2::254]/latest/meta-data/

Stealing IAM Credentials from EC2 Metadata via SSRF

Server Side Request Forgery (SSRF) is a server-side attack that allows an attacker to send a request on behalf of the victim server. Successful exploitation of SSRF can lead to the compromise of internal machines/devices in the same network.

When any web application is hosted on an AWS EC2 instance, an attacker can exploit SSRF vulnerability and access Instance Metadata Service (IMDS) to get IAM credentials.

Pentester’s Approach:

  • After the successful identification of SSRF vulnerability on web applications hosted on the EC2 instance, access http://169.254.169.254 URL and observe whether instance metadata is accessible or not.
  • Once you can access instance metadata, try to access http://169.254.169.254/latest/meta-data/iam/ URL and observe the response.
    • 404 Not Found: no IAM role associated with the EC2 instance
    • 200 OK with empty body: IAM role has been revoked
    • 200 OK with body: IAM role associated with EC2 instance
  • After getting the IAM role associated with the EC2 instance, try to access http://169.254.169.254/latest/meta-data/iam/<IAM-role-name> to get IAM credentials.

Developer’s Approach/Recommendation:

  • Enable Instance Metadata Service v2 (IMDSv2)
  • Limit the access IMDS to required users
  • Implement proper input validation on web application

Practice Lab: Vulnerable Instance

We have created a lab around misconfigured bucket which can be accessed here – Lab on Vulnerable EC2 Instance

Once on the lab URL, observe that the web application is hosted on an EC2 instance:

Now, observe the web application functionality and try to identify a vulnerability which you can exploit to retrieve the flag. We found a Server Side Request Forgery (SSRF) vulnerability in the web application. Further, We confirmed the SSRF vulnerability by adding a Burp collaborator link:

As this web application is hosted on an EC2 instance, you can try to access the http://169.254.169.254/ URL to check if you can read EC2 metadata, as shown in the figure below:

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

Now, try to access user-data from EC2 metadata using http://169.254.169.254/latest/user-data URL:

As you can observe, the user moved the f149.txt file to the root directory, so you just have to read the f149.txt file to retrieve the flag.

Vulnerabilities in Lambda Functions

What is Lambda in AWS?

AWS Lambda is an event-driven, serverless computing platform provided by AWS. It is a computing service that runs code in response to events and automatically manages the computing resources required by that code. Once the execution is over, the computing resources that run the code destroy themselves. You can create as many functions as you need to handle different tasks.

Insecure Lambda Functions

Cloud applications or functions running on serverless services are often vulnerable to similar vulnerabilities identified on traditional web applications. Most of the injection vulnerabilities can be identified on the serverless functions such as

  • Operating System (OS) Command Injections
  • Code Injections
  • SQL/NoSQL Injections
  • XML External Entity (XXE)
  • Server Side Request Forgery (SSRF)
  • Deserialization Attacks etc.

Pentester’s Approach:

  • Look for comments and API endpoints in all visible URLs
  • Manually test all the URLs and their parameters to identify the vulnerabilities
  • Exploit any vulnerability and try to access environment variables or sensitive information about AWS accounts.

Developer’s Approach/Recommendation:

  • Do not store sensitive information in the environment. Retrieve it from Secret Manager or DynamoDB
  • Use environment variables for configuration details and encrypt with KMS
  • Add minimum specific actions in role policies. Do not use * in action.
  • Limit outbound traffic to prevent data exfiltration
  • Application security testing and source code analysis
  • Monitor lambda logs regularly

Practice Lab: Serverless Application

We have created a lab around misconfigured bucket which can be accessed here – Lab on Serverless Application

Once on the lab URL, observe that a lambda function is used to run code on specific events:

In this challenge, you have to identify and exploit the vulnerability in the lambda function to retrieve the flag. Here, we started testing the endpoint by performing recon to identify URL parameters. We used the Param Miner Burp extension and found the URL parameter command:

Then, we tried to identify different web application vulnerabilities on command parameter. After some time, we found a command injection vulnerability which listed the files in the current directory, as shown in the figure below:

Here, we found different files out of which main.py caught our attention, so we tried to read main.py and we found the flag.

As cloud infrastructure usage continues to expand, it is crucial to recognize that any misconfiguration in the setup can lead to severe consequences and negatively impact businesses. Therefore, it is imperative to prioritise the secure configuration of cloud infrastructure.

References and Further Reading:

  • https://hackingthe.cloud/aws/exploitation/ec2-metadata-ssrf/
  • https://github.com/null-open-security-community/Research-Papers/blob/main/Common_Cloud_Security_Issues_AWS_Edition_Ver_1.0.pdf
  • https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/
  • https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html

Leave a Reply

Your email address will not be published. Required fields are marked *

Arrange a Callback

    Contact us
    Close