Shifting to cloud is becoming more prevalent as a cloud based platform could provide operation efficiency, simplicity if the best security practices and proper configuration are enabled when utilizing the cloud vendors. However, sometimes a misconfiguration in utilizing AWS could lead to deadly data breaches.
Common misconfigurations in AWS cloud
In this article, we will break down the 5 most common misconfigurations or ignorance which could lead to a nasty data breach from a pentest perspective.
Misconfiguration 1: Dangling DNS Records lead to Subdomain takeover
If a DNS record entry is pointing to a resource, for example, S3 bucket, IP address, cloudfront instance that are not available and the DNS record is still present in your DNS zone, this is called a “dangling DNS”. A “dangling DNS” in your AWS configuration is likely to lead to subdomain takeover exploitation.
When an attacker finds a dangling DNS, they could create and claim the non-available or non-existent resource and host some malicious content after claiming the non-existent resource (S3 bucket or IP address, etc) . Now when the users are visiting the DNS domain in their browser, their traffic will be directed to the malicious content controlled by the attacker.
Take the following scenarios for a better illustration,
- An organization created a DNS record, files.example.org and CNAME to an AWS S3 bucket filessharing_example.s3.amazonaws.com to host some static javascript files
- The organization deleted the S3 bucket or the S3 bucket expired and the organization did not renew it. AWS will recycle this S3 bucket name and make it available for other users to claim it.
- When the attacker found the DNS record files.example.org is pointing to a nonexist S3 bucket. The attacker could claim the S3 bucket and host some malicious content in this S3 bucket
- Now the victims visit files.example.org in its browser, they will be visiting the malicious content controlled by the attackers.
S3 bucket takeover is the most common exploitation when performing penetration test because the exploitation is very straightforward and simple
Mitigations
The mitigation for dangling DNS is easy, to keep robust hygiene practices. When a resource in your AWS is deleted or removed, you need sunset or delete the corresponding DNS record too.
Misconfiguration 2: Internal servers deployed in public subnets
AWS provides a default VPC for a new account. Sometimes, a developer is deploying a server and database directly in the default public subnet of that VPC to speed up the deployment for testing or POC purposes.
Take the following scenarios as an example, a developer was trying to perform a POC to its potential clients. In order to ensure the clients have access to the service, the developers deployed an EC2 instance with the demo into a public network. As a consequence, this could lead to potential data breach if the EC2 instance is hosting an internal application or has the database installed in it.
Mitigation
Deploy internal servers under private subnets and set up the correct security groups to limit the right groups of applications to access it. If the server is a public facing application, ensure that only the necessary ports are running.
Misconfiguration 3: Over permissive S3 bucket
Misconfigured permission of S3 buckets has been identified as the root causes for many data breaches even though AWS set all its buckets and its objects private by default.
Most of these incidents happen when the Resource Based Policies (Bucket Policies) is not correctly configured. In a bucket policy, the owner of the bucket could specify which user has which kind of permissions (read, write,list) to this bucket. A developer or an owner could mistakenly grant permissions to the undesired users.
Take the following publicly disclosed incident for example, the organization is using the following Bucket policy to configure permissions for its S3 bucket
{
"Sid": "AllowPublicRead",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::media.twiliocdn.com/taskrouter/*"
}This bucket policy means anyone could read and write any files under the /taskrouter/ directory under this bucket.
Mitigation
Follow the security best practices listed by AWS when configuring your AWS S3 bucket, for example, try to apply least privilege access, enable data encryption, blocking public access to S3 bucket.
Misconfiguration 4: EC2 Metadata Service leaks Secret Token via SSRF
SSRF became a new category of OWASP Top 10 (2021) as it enables attackers to use vulnerable servers to request and receive data from protected internal sources and lead to serious attack. The impact of SSRF is being worsened by the offering of public clouds, like AWS. For example, the most notorious capital one data breach was caused by SSRF exploitation. As a penetration tester, to steal EC2 Metadata with AWS credentials is becoming a standard POC to demonstrate the exploit and damage of the SSRF vulnerabilities.
The following two factors could be blamed for the widespread SSRF attacks against AWS cloud.
1) there is a Metadata service running http://169.254.169.254 in most of EC2 instances,
2) the service will reveal the IAM credentials of the role attached to the EC2 instances.
Mitigations
Enforcing IMDSv2 to your EC2 instance could significantly reduce the risk of SSRF attack as the IMDSv2 requires a PUT request prioring to extracting the AWS credentials with a get request.
Misconfiguration 5: Private AMIs got shared with public
Accidentally public Amazon Machine Images (AMIs) is another common security issue observed during penetration testing. AWS allows its customers to customize the instance (for example, installing software, configure sensitive environment variables on the instance) and then save it as a custom AMIs.
Once a customized AMI is saved, it could be shared among different accounts or shared with the public. Sometimes, AMI could be shared with the public by mistakes and it leaks to sensitive data leakage if the AMI contains sensitive information.
Conclusion
There are far more misconfigurations that could put your cloud platform in jeopardy. These 5 misconfigurations are the most common misconfigurations in AWS cloud infrastructure from my perspectives when performing penetration testing.
Nevertheless to say, to securely configure a cloud based platform utilizing AWS is a very challenging task as AWS itself is complex and it takes time and effort to understand all the features and options. Sometimes, this is made worse when the recommended configuration or setting is not suitable for your organization or platform.
However, the aforementioned 5 common misconfigurations are not hard to discover when you are following the AWS Security best practices and performing a regular audit against your platform.