1. DNS/hijacking/thehackerblog
Contents
<The Managed DNS Vulnerability> はもっと広く知られるべきだ。
類似のページ： https://news.ycombinator.com/from?site=thehackerblog.com
Floating Domains – Taking Over 20K DigitalOcean Domains via a Lax Domain Import System August 25, 2016 ../Floating Domains
Respect My Authority – Hijacking Broken Nameservers to Compromise Your Target https://thehackerblog.com/respect-my-authority-hijacking-broken-nameservers-to-compromise-your-target/
2. The Orphaned Internet –
Taking Over 120K Domains via a DNS Vulnerability in AWS, Google Cloud, Rackspace and Digital Ocean December 05, 2016
ここの最初のコメントは論点をはずしている。
https://news.ycombinator.com/item?id=13118111
3. The Managed DNS Vulnerability
The issue occurs when a domain name is used with one of these cloud services and the zone is later deleted without also changing the domain’s nameservers.
This means that the domain is still fully set up for use in the cloud service but has no account with a zone file to control it. In many cloud providers this means that anyone can create a DNS zone for that domain and take full control over the domain.
This allows an attacker to take full control over the domain to set up a website, issue SSL/TLS certificates, host email, etc. Worse yet, after combining the results from the various providers affected by this problem over 120,000 domains were vulnerable (likely many more).
4. Detecting Vulnerable Domains via DNS
If the domain is vulnerable then the nameservers will return either a SERVFAIL or REFUSED DNS error.
In order to find a list of domains vulnerable to this issue I used my copies of the zone files for the .com and .net TLDs which are available via Verisign (you have to apply to get access).
Google Cloud DNS (~2.5K Domains Affected, Patched)
Amazon Web Services – Route53 (~54K Domains Affected, Multiple Mitigations Performed)
I wrote a small Python proof-of-concept script which would create and delete Route53 zones until the proper nameservers were returned.
Raise awareness by updating existing Route53 documentation to explicitly mention that nameservers should be changed if a zone is deleted from Route53.
Rackspace (~44K Domains Affected, Won’t Fix)
5. Remediation Recommendation
Different cloud providers took different approaches to this issue. My recommendation for remediation of this issue is fairly straightforward and is the following:
1. User adds the domain to their account via the cloud management panel.
2. At this time the cloud provider returns a random list of nameservers for the domain owners to point their domain to.
For example the following is an example list:
a-nameserver-one.example.com
a-nameserver-two.example.com
a-nameserver-three.example.com
3. The cloud provider now continually queries the TLD’s nameservers for the list of nameservers that the domain has been set to.
Once the user has set their nameservers properly the cloud provider stores the list of nameservers and the domain in a database.
4. For any future zones created for this domain the cloud provider will only return nameservers
which do not match the stored list of nameservers.
This means that in order to use a newly created zone the domain owner will have to set their domain’s nameservers
to a new nameserver set, ensuring that only the domain owner can actually carry out this action.
5. The cloud provider will continually query the TLD nameservers to see if the domain’s nameservers have changed
to the new set and will store the results in a database as we did in step 3.
6. 評価
The above method does add a bit of friction to the process of re-creating a zone for a domain, but completely prevents this issue from occurring. Since the friction is only equivalent to the initial domain import process it doesn’t seem to be too unreasonable but it is possible that provider won’t want to inconvenience customers this way.