12

Context and system configuration:

  • AWS EC2 instance with a public IP address
  • AWS Route53-managed DNS with a somesubdomain.somedomain.io pointing to the above IP address
  • Above AWS EC2 instance was not running all the time, it was stopped most of the time with only occasional periods of running
  • Every time the EC2 instance was started, DNS entries were updated to point at its new IP address - EC2 instances are not retaining their public IP addresses when they are not running, they are getting new public IP address on startup
  • DNS entries were left as-is when the instance was stopped
  • The reason behind this bit unusual setup is cost saving, while being able to use static domain names for connecting to the instance when running

Attack:

  • One day I noticed there was a website under the somesubdomain.somedomain.io mentioned above, despite my EC2 instance being down
  • This website had my domain name in its banner/logo, so this couldn't have been a coincidence

Analysis:

  • I did not carry out as much analysis as I could at that time. In fact I just wanted to solve the problem. Now I just delete DNS entries when shutting down the instance.
  • I realised there is a problem with a DNS entry under my domain pointing at the past public IP address of my EC2 instance. When the instance was last shut down, the IP address got back to available pool and could be re-assigned to a completely different instance

Questions:

  • Does this attack have a common name?
  • What would be the primary benefits for the attacker?
2
  • 5
    "This website had my domain name in its banner/logo, so this couldn't have been a coincidence" - Sure it can be a coincidence; they might have a generic site that operates under multiple domains, and they just show the domain the visitor uses in the banner. It's pretty trivial to make a website do that. So their site works well as both foo.com and bar.com. Then you come along and point automatictester.com to their server, and sure, that works too. The webserver doesn't care. So unless the site copied your concept or styling, I wouldn't assume malice.
    – marcelm
    Commented Jul 12, 2020 at 19:03
  • As Conor's answer states, this is known as a subdomain takeover. The attack/vulnerability was pioneered by Frans Rosén and popularized by Detectify in a 2014 blog post.
    – jub0bs
    Commented Feb 12, 2021 at 7:21

1 Answer 1

18

This is a subdomain takeover.

They typically happen in one of 2 ways:

  1. You have an A record pointing to an IP address that no longer exists and an attacker can gain control of the IP address in question
  2. You have a CNAME record pointing to a domain that no longer exists, and the attacker can register the domain.

The reasons can vary depending on the circumstances. To pick two:

  1. Impersonation is much easier if you can control an "official" domain. This can lead to phising, social engineering attacks, and more.
  2. If the main domain has cookies which are valid for sub domains, then the attacker will be able to steal all cookies from the main site if a victim visits their subdomain.

And yes, there are ways to scan for such misconfigurations and attackers can and will find them.

Solution:

The simplest and most effective way to stop subdomain takeovers is to always cleanup you DNS records - don't leave an A or CNAME record pointing to non-existent resources/domains.

In your case though you have another option. You can reserve an elastic IP address to your account and attach/detach it from your EC2 instance as needed. By reserving the IP you will make sure it does not return to AWS' pool for someone else to use. This solution has a slight advantage that you don't have to update DNS or worry about DNS propagation, but it has a slight disadvantage in that you will pay a nominal hourly fee while the IP address is not in use.

1
  • A subdomain takeover may also be used to bypass defenses like an Origin check (against CSRF or in the context of CORS). Also, another thing you can do to prevent them is to choose vendors wisely; think twice before becoming patrons of the ones that don't protect you against subdomain takeovers, as they represent a liability for your organization. Shameless plug: I've just published a post on the topic, in which I go into more details.
    – jub0bs
    Commented Feb 12, 2021 at 7:18

You must log in to answer this question.