Service Digital Ocean
Status Vulnerable
Nameserver
ns1.digitalocean.com
ns2.digitalocean.com
ns3.digitalocean.com
Explanation
To perform a takeover create a new account on Digital Ocean and follow the DNS quick start guide. In short, once inside the Dashboard click on the big green Create button and select Domains/DNS. Enter the vulnerable domain in the form field labeled Enter domain. If the page allows you to create the zone the takeover was successful.
Digital Ocean’s vulnerability to DNS takeovers was discussed in detail by Matthew Bryant in 2016 and they are still vulnerable today.
DigitalOcean Takeover:
To start, one notable way to tell if a domain has been added to a DigitalOcean account is to perform a regular DNS query and see how the DigitalOcean nameserver’s respond. As an example, we’ll use alert.cm, which has their nameservers set to DigitalOcean but are not listed under any DigitalOcean account:
mandatory@Matthews-MacBook-Pro-4 ~> dig NS alert.cm @ns1.digitalocean.com. ; <<>> DiG 9.8.3-P1 <<>> NS alert.cm @ns1.digitalocean.com. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 53736 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;alert.cm. IN NS ;; Query time: 51 msec ;; SERVER: 173.245.58.51#53(173.245.58.51) ;; WHEN: Tue Aug 23 23:09:00 2016 ;; MSG SIZE rcvd: 26
As can be seen in the above dig output, the DigitalOcean nameservers returned a DNS REFUSED (RCode 5) error which indicates that the nameservers refused to respond to the NS record query we performed. This gives us an easy and lightweight way to differentiate between domains that are currently listed under a DigitalOcean account and domains that aren’t.
This solves one part of the problem, but checking every domain on the Internet this way is still very intensive. Additionally, how can we get a list of every domain name on the Internet? The answer is to get a copy of the zone files for various top level domains (TLDs). To start we’ll acquire the zone files for the .com and .net TLDs because they are easily acquirable from Verisign for research purposes. The zone files contain every .com and .net domain in existence and their corresponding nameservers. By grepping through these zone files we can figure out exactly how many .com & .net domain names use DigitalOcean for DNS hosting. At the time of this writing, the count for both TLDs are the following:
- .com: 170,829
- .net: 17,101
Combined, this is a total of 187,930 domain names that have DigitalOcean as their DNS provider. We can now query all of these domains to check for DNS REFUSED errors to see if they are not listed under a DigitalOcean account (and are thus able to be taken over). After a short Python script and a few hours of DNS querying we are able to enumerate all of the vulnerable domains (at least in the two TLDs previously mentioned). The final count comes out to be 21,598 domains that returned a DNS REFUSED error upon querying them. After adding these domains to my DigitalOcean account via their API, the real number turned out to be closer to ~19,500 domains (as it appears the DNS method was not 100% accurate). For all of the domains added to my account a single DNS A record for the base domain was added to a EC2 instance. This was done in hopes of understanding why so many domains ended up in this state, and the results were quite surprising.
The Sinkholed Traffic
While I expected that most of the domains were purely spam/junk domains that had not yet been configured (perhaps all belonging to a single domain reseller for example) – this was not the case. The sinkhole server was just a standard nginx web server returning a blank webpage and logging web requests. After having the server up for just a few days the access logs have grown to 1.8GB in size with a constant stream of requests pouring in. Most of these are unsurprisingly from search engines eager to crawl the web as quickly as possible (~80% of the traffic was from spiders) however the rest are legitimate users navigating to the now redirected websites.