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.
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:
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.
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
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:
Developer’s Approach/Recommendation:
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.
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.
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/
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:
http://169.254.169.254 URL and observe whether instance metadata is accessible or not.http://169.254.169.254/latest/meta-data/iam/ URL and observe the response.http://169.254.169.254/latest/meta-data/iam/<IAM-role-name> to get IAM credentials.Developer’s Approach/Recommendation:
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.
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.
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
Pentester’s Approach:
Developer’s Approach/Recommendation:
* in action.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.