Tag Archives: Subdomain takeover

Five Common AWS Misconfigurations from Pentest Perspective

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,

  1. 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
  2. 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.
  3. 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
  4. 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.

Trending Application Vulnerabilities not listed under OWASP TOP 10

OWASP TOP 10 is the list of the 10 most common application vulnerabilities. It also shows their risks, impacts, and countermeasures. Auditors often view an organization’s failure to address the OWASP Top 10 as an indication that it may be falling short with regards to compliance standards or best security practise.

In general, OWASP TOP 10 outlines the most recurring application security weakness in the application security domain. However, it seems that some trending application security weakness are not listed under current TOP 10 categories after managing two bug bounty programs in the past two years and working as bug hunter in my free time. SSRF ,Cache Poisoning and subdomain takeover are some of these trending vulnerabilities not included in the latest OWASP TOP 10. I believe these vulnerability should get some attentions from security engineers as they could lead to severe security incident.

Sever Side Request Forgery (SSRF)

Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain (behind the WAF or internal domain) of the attacker’s choosing.

How SSRF vulnerability could be introduced in your application?

Most likely, SSRF could be introduce when a public facing application allows an end use to add a URL as a parameter. For example, an application allows a user to pull the content, metadata from another web page by inputting the URL of a web page. Or an application allows its users to define a web hook (URL) and the application will send a request to the web hook URL.

What is the impact of SSRF vulnerability?

The severity of impact of successfully exploiting a SSRF could vary a lot depending on how the application is configured or implemented. Sometimes, the SSRF could only be used to scan open ports or IPs of the internal hosts to fingerprint the intranet of an organization. However, sometimes, SSRF could lead to the leakage of sensitive tokens or credentials of your application if your application is powered by AWS, Google Cloud or Azure. The root cause of the recent Capital One data breach was AWS credentials leakage through an SSRF exploitation.

How could you prevent SSRF vulnerability?

Multiple countermeasures could be employed to combat against SSRF by considering the use case of the applications. For example, URL whitelisting or Network segregation are two popular methods to use. URL blacklisting should not be your first preference when remediating the SSRF vulnerability. In a private bug bounty program I joined, the application is using blacklist, like, localhost, 127.0.0.1 to prevent a request to the localhost. However, I was able to bypass it by using http://[::] and http://0.0.0.0/ to bypass the blacklisting. In most of the case, I think network segregation could be a good option if that is affordable for your application.

Web Cache Poisoning

Web cache poisoning is an advanced attacking technology where an attacker exploits the behavior of a web server by modifying web cache with some malicious data and harmful HTTP response containing these malicious cached data is served to other legitimate users.

Why your application could be victim of the web cache poisoning attack?

Some modern application are heavily using CDN web cache method to serve as many client requests as possible without having to retrieve the original content each time. Having a cache layer will significantly reduce the server load of the application. for CDN or web server, it is relying on using cache keys to look up whether a request is cached or not. If the application directly reflects the value of a certain unkeyed header in the response, it could be a good indicator that this application is vulnerable to cache poisoning. Because the header is unkeyed, its value is not part of the cache key and plays no part in deciding about cache hits. If the attacker sends a request where only this header is maliciously modified, the response to this request will be cached. Users subsequently requesting content that matches the same cache key will receive the malicious data injected by the attacker.

What is the impact of Cache Poisoning vulnerability?

The impact of web cache poisoning attack depends on what data could be cached with a crafted request from an attacker and the amount of the traffic on the affected page. Portswigger has a good explanation on the potential impact. If the home page of an organization is vulnerable to web cache poisoning attack, that will be a huge problem to the company as legitimate user will be not able to access the page normally.

How could you remediate web cache poisoning vulnerability?

There is no silver bullet to remove web cache poisoning issue as most applications using web cache has the requirement to use it to ensure a great user experience. One good method would be restrict the cache content to be something purely static.

Subdomain takeover

Subdomain takeover is another trending security issues prevailing in applications. According to portswigger, security researchers have discovered more than 400,000 subdomains with misconfigured CNAME records, leaving many at risk of malicious takeover as a result. The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service.

How could subdomain takeover happen?

The subdomain takeover issue is always introduced by a human error or mistake. For example, you set up and add a DNS entry blog.example.com and CNAME to a 3rd Party domain, company1.bloghost.com. However, you forget to claim the ownership of the CNAME domain company1.bloghost.com, then an adversary claimed the CNAME domain company1.bloghost.com and hosting some malicious content. Another case would be, you are using AWS to power your application and you create a DNS entry blog.example.com and resolve it to an IP address AWS owned IP address 52.47.73.72 . However, you forget to reserve the IP. Then an attacker claim the ownership of that IP and host some malicious content. As a consequence, all the legitimate user visiting blog.example.com will get the malicious code executed in their browsers.

What is the impact of subdomain takeover?

The impact of subdomain takeover could be very severe. Attackers can then serve malicious content to visitors to the exploited subdomain, and potentially intercept internal emails, mount clickjacking attacks , hijack users’ sessions by abusing OAuth whitelisting, and abuse cross-origin resource sharing (CORS) to harvest sensitive information from authenticated users.

How could you prevent subdomain takeover?

Preventing subdomain takeovers is a matter of order of operations in lifecycle management for virtual hosts and DNS. Depending on the size of the organization, this may require communication and coordination across multiple departments, which can only increase the likelihood for a vulnerable misconfiguration.

Conclusion

With more and more applications are shifting to micro services and serverless platforms. SSRF, Web Cache Poisoning and Subdomain taken over will draw more attention and probably get more spotlights in the cyber security domains. That could explain why SSRF is highly proposed to be added in upcoming OWASP TOP 10 2021.