Fishing the AWS IP Pool for Dangling Domains

Amazon and other cloud providers have made it child’s play to spin up ephemeral server instances for quick deployment of various services. If you want a web server to host your new .io domain name, you can have it set up in no time at all. Starting a website has never been easier — just spin up an EC2 instance, install your stack, point your domain/subdomain to the instance, and kill it when you’re tired of it.

Hold on, though — did you clear that DNS entry?

If the answer is “No” or “I don’t know,” then keep reading.

Into the Elastic IP Ether

What happened to that IP tied to that EC2 instance that you just killed? Well, when you terminate an instance, that IP address isn’t put to waste. Instead, it’s reused by other AWS customers. There is a massive pool of IP addresses that are constantly being recycled and trusted by various organizations and people.

So, let’s allocate ourselves an IP! If you have an AWS account, navigate to your management console and select Services > EC2. Under this option, you’ll find a section titled “Elastic IPs” under the “Network & Security” header. You should see something like this:

Once we’ve allocated an IP, we’ll receive a message similar to the following:

 

Neat, an IP of our very own! Instead of taking any old IP though, we should make sure this IP doesn’t have a history with a quick Bing search.

Yes, a Bing search. Unlike Google, Bing has the “ip:” search operator that allows you to search for sites via an IP address. Normally we’d use it to see what sites share the same server, but in this case, let’s see if any domains point to that IP we just allocated.

The results?

Uh oh, it looks like a few people forgot to remove their DNS entries. Since 54.243.128.77 was recycled back into the pool and picked up by us, we now fully control all of these domains.

For example, when you perform a DNS lookup for one of these domains:

mandatory@Matthews-MBP-2 ~/P/node> dig A engagementninja.com @8.8.8.8

; <<>> DiG 9.8.3-P1 <<>> A engagementninja.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35451
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;engagementninja.com. IN A

;; ANSWER SECTION:
engagementninja.com. 599 IN A 54.243.128.77

;; Query time: 164 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Jun 27 22:59:08 2015
;; MSG SIZE rcvd: 53

You can clearly see that the domain points to our newly allocated IP address. Of course, this isn’t an isolated incident …

Gone AWS Fishin’

What happens when you continually allocate AWS IPs looking for dangling DNS entries?

The answer is … anything.

The domains are more or less random — you can pick up domains belonging to Fortune 1000 corporations and domains belonging to tech bloggers. It’s a mixed bag, but it’s also incredibly interesting because you never know what you’ll find. You’ll pick up a subdomain for a Japanese VPN company (cyberdeftech.softether.net) …

… and then grab an Ebola awareness subdomain immediately thereafter (uat.ebolaexplained.co.uk) … 

Even large companies, such as EA's Origin site, fell victim to this attack. We allocated an IP address that the subdomain qa.oms.origin.com points to (107.22.178.127). While we released this IP address back into the pool, this illustrates how even large organizations can forget to clear their DNS entries.

It's not just corporations, either; we also allocated domains belonging to educational intuitions and government sites as well. This same mistake is being made across the board.

Once you've allocated an IP that has a cool domain pointing to it, how much would it cost to hold on to this newly obtained address?

The answer is $0.005 dollars per hour, which is 1/2th of a cent. Annually, this comes to about $43.80. A malicious user could squat your IP/domain/subdomain for almost the same cost of an .io domain registration.

View the Elastic IP Stream Live

As a proof of concept, I’ve created a page that streams the output of a tool I wrote for continually allocating elastic IP addresses. Upon allocating an IP address, the tool runs the IP against multiple DNS databases to find any domains/subdomains that are directing to it. Subsequently, these database results are verified with a DNS check before the domain is outputted to the stream.

If you would like to view this happening in real time, see the below image for the page:

What Does This Mean?

Having a subdomain nets you a lot of implicit trust. For example, you could use your newly obtained subdomain to carry out powerful phishing attacks against the organization that owns the base domain. This is possible because you can send and receive email from the subdomain as well as host content on it. After all, why wouldn't employees trust a subdomain that appears to belong to their company?

Having a subdomain is also useful for exploiting a company. If a website incorrectly scopes their cookies to all subdomains, you can hijack user sessions. This was the case with Origin, which scopes all of its cookies so that the subdomains of Origin.com can also read them. This means that we could send the link to the subdomain we took over (qa.oms.origin.com) to any logged-in Origin users and take full control over their account.

Do they have a crossdomain.xml policy? It probably allows all subdomains. You can then use Flash to hijack their account and steal sensitive account information. For example, if a financial institution made any of these mistakes, you could steal customer financial information or send money from a customer's account.

The greater issue exposed by this attack is the challenge of trusting ephemeral resources. Organizations need to stay vigilant of who and what they are trusting, as things like cloud instances are subject to change. When that change happens, the trust placed in that asset could be reacquired by an attacker.

Conclusion

Mitigation is simple; when you tear down an EC2 instance, ensure your DNS is updated along with it. Companies with a considerable AWS presence need to be especially mindful as the chance of a mismanaged DNS entry becomes more probable. You may notice a trend of companies that make this mistake often, as you’ll pick up multiple subdomains from them. It’s quite possible that, as time goes on, the IP space for AWS will become more cluttered with DNS entries pointing to it. In fact, AWS fishing might become even easier in the future.