Menu
In our previous Dangling DNS records post, we examined the risks of leaving ‘dangling’ CNAME records pointing to DNS zones which are not under the domain-owner’s sole control. The consequences include increased risk of successful phishing attacks as well as reputational damage. The examples given in that post focused on Azure ‘App Services’ as those services are vulnerable to the kinds of subdomain takeover attacks previously described.
Lest we be accused of picking on Azure, let us now focus on some AWS services which are also prone to such attacks.
Elastic Beanstalk is an AWS (platform-as-a-)service (PaaS) which allows you quickly deploy an application running on a variety of platforms such as Java, ASP.NET or Python without having to bother yourself with setting up VPCs, EC2 instances or load balancers. The service does all that for you (under the covers) with a few button clicks, allowing you to focus on the development of the application itself.
When creating a Beanstalk application, you can supply a custom domain under which your application will be available under the URL:
https://.ap-southeast-2.elasticbeanstalk.com
In the above URL, “ap-southeast-2” refers to the AWS region which you have configured to host the application.
If you choose a custom domain which is already taken you will receive an error:
Of course, it’s impossible to tell which domains have records which have a CNAME pointing to an ‘available’ Elastic Beanstalk subdomain. There is no equivalent of the PTR record for CNAMEs. The best you can do it try to enumerate them all and find the ones you are interested in.
Fortunately, with a bit of scripting, you can do that yourself! Rapid7’s Project Sonar provides a wealth of data from their efforts to ‘scan’ the Internet. This includes a 20GB (uncompressed) file of approximately 193 million CNAME records which they have obtained from the hostnames seen in various sources such as Certificate Transparency logs as well as any SubjectAltNames appearing in endpoint certificates encountered during their scans.
From this 193 million CNAME records, there are approximately 90K which point to a subdomain of elasticbeanstalk.com and about 9K of which are ‘dangling’ (i.e. available for takeover). If we just restrict ourselves to those subdomains of ap-southeast-2.elasticbeanstalk.com (i.e. the ones associated with the AWS Sydney region) there are 421 domains available for takeover.
WorkMail (and WorkDocs) are AWS services offering End User applications to organisations in the form of managed email and online file storage.
Similar to the Elastic Beanstalk case, attempting to register an access point which has already been taken generates an error:
And similar to the Elastic Beanstalk case, there are organisations who have created CNAME records pointing to a subdomain of .awsapps.com which can be taken over by an attacker. Using the Project Sonar data we were able to find 13 such domains which were vulnerable to ‘takeover’ of their WordDocs/WorkMail services.
AWS Cognito is an service which allows you to set up an (OAuth2-based) identity provider which you then use to provide authenticated access to service providers under your control.
Again, the Cognito service allows you to create a custom subdomain which you can use to direct your users to login:
Similar to the Workmail case above, if an organisation has CNAME records already pointing to the Cognito service you’ve just set up, you can take advantage of this as an attacker. In this particular case, Cognito URLs are inherently related to authentication, and hence would be ideal for use in phishing campaigns to steal user credentials.
Having said all that, a search of the Project Sonar data did not turn up any dangling CNAME records for Cognito services – which is good!
While we have noted that several AWS services are potentially vulnerable to takeover, via CNAME we also emphasise that the vast majority are not, including favourites such as
This is because the subdomain names created when you create an instance of one of those services include enough randomness such as:
myelb-2d1234ce2e3a2g8b.elb.ap-southeast-2.amazonaws.com
This makes creating a load balancer with just the right name practically infeasible.
Having said that, the widely-used Elastic Beanstalk service is vulnerable to subdomain takeovers. So the conclusions of the previous post remain: clean up those ‘dangling’ DNS records before some one cleans you up! The next article in our series will focus on ‘elastic’ IP addresses as supported by the various cloud providers.
Until then, have fun, and don’t forget to drop us a message if you’re lonely or bored! 🙂