[mreithub]

Wow, I don't think I would've even considered such an attack...

DNSSEC, HSTS and Certificate Pinning would've made it more difficult to abuse this, but I guess it would've been pretty easy to get valid SSL certificates for all your favourite .io domains.

Let's try to play malicious party here:

Phase A: First set up a simple DNS forwarder playing by the rules and answering requests as we should (as to not get any unwanted attention). Gather usage statistics.

Phase B: Crawl the list of most-used domains to see if there are any valuable targets without HTTPS (port 443 is closed). Alternatively/additionally see if there are API subdomains used by software other than browsers (of which a few won't have annoying features like Cert Pinning - golang's DNS resolver for example afaik doesn't do DNSSEC). Pick some medium to high level targets where the attack might go undetected for at least some time.

Phase C: MitM time! Get certificates for the target domain(s) of your choice and get to work. Start with only a few percent of the requests to not draw too much attention (and to avoid the majority of their traffic coming from a single IP (range) all of a sudden) Obfuscate the attack by acting like a third party app or something simply doing requests for their users.

Congratulations on finding the vulnerability (and thanks for looking for that kinda stuff in the first place).

[LinuxBender]

If you control the root DNS servers for .io, you can simply not answer the DNSSEC queries. Many resolvers will fail open.

HSTS requires the site is HTTPS with a valid cert. If you own all .io, you can use LetsEncrypt to get that for free. They now even support Wildcard Certs! :-) That said, you would have to choose your targets carefully and/or load balance your requests to LetsEncrypt. There is a rate limit. There are browser plugins that can tell you if a cert just changed, assuming you have been to that site prior.

Then there is Public Key Pinning. This would be great, but I suspect the number of big companies implementing this are low. I don't have numbers, but you can test your favorite sites in Qualys[1] or using testssl.sh[2] that only depends on openssl and bash.

You could proxy all requests to the real root servers for .io and only become authoritative for the ones you wish to target.

Given the small number of zones, I think a modest server could keep up, or you could balance the load on a bunch of VM's. It may take a while for anyone to notice. I am curious actually, how many fellow geeks have nagios/sensu alerts that would tell them if the root server IP's changed.

All of this said, there are BGP attacks you can do that accomplish the same thing for any TLD and the IP's wouldn't even have to change. Only more advanced monitoring tools that keep an eye on route path might notice, but probably would not alert anyone.

[1] https://www.ssllabs.com/ssltest/index.html [2] https://github.com/drwetter/testssl.sh

[ConfucianNardin]

LetsEncrypt don't support wildcards yet. They will, starting January next year.

[LinuxBender]

Ah, I was not aware it would be January. Then for now the targets would have to be specific DNS records.

[jancsika]

So how does certificate transparency fit into all this?

https://www.certificate-transparency.org/what-is-ct

Let's assume an attacker who selectively hijacks .io traffic in such a magical* way that the owners of the relevant domain names do not notice the attack is happening. Assuming that, what exactly would the CT monitors notice? I assume there would be new LetsEncrypt certificates entered into the append-only log, but then what?

Edit: added word magical for clarity

[LinuxBender]

That could certainly be useful in the follow-up investigation and forensics. Hopefully our attacker did not spin up those VM's using a burner card or stolen CC and proxies.

There isn't anything magical about selectively targeting domains. One simply creates multiple recursors and sets the upstream forwarder to the proper IP's of the original root servers. Then one adds zones for the domains or individual records they wish to modify. Unbound DNS is great for taking over individual records. I use it for this very purpose to block advertisements and trackers. In this case however, we are just acting as a root server, so there isn't much to take over. We just point the victims to ourselves for the domains we wish to hijack. We could then have a second level of recursors to perform the above selective attacks.

[michaelmior]

I think the problem with PKP is that there's such a big risk of temporarily unfixable breakage if things aren't done right.

[pingiun]

Could you get a wildcard certificate for *.io this way?

[LinuxBender]

I don't know if LetsEncrypt would issue that, even if you control it. That would be a good exercise to validate if there is an "easy mode" for state sponsored fun.

I've read that browsers are said to block such wildcards, but I don't know to what they are referring. I create wildcard TLD self signed certs all the time. I've never had one signed by a proper CA, so I can't tell you if the browsers have any logic to ignore them.

[djrogers]

Your missing a ton of potential here by assuming that all DNS is good for is Web traffic. For one thing, taking over or intercepting email (remember, you now control the DNS, so you also control SPF and DKIM records) becomes trivial. you could even leverage that control of email to get SSL certificates for domains you really want to do https for (letsencrypt will even generate a wildcard cert using only dns based verification).

You could also be much more surgical, and target specific people/organizations using that .tld, ignoring dns requests for everyone that you don’t want to alert to your control. Hijack their email, and you control access to things like account recovery for domain users, and have a great method for phishing account credentials for the domains customers.

Honestly, the list of what you could do here is almost only limited by your imagination

[btown]

Or, in Phase C, an attacker could proxy traffic through a botnet to avoid the single-ip-range issue; they could even find botnet participants geographically close to each user, so they might not even trigger any red flags from a close look at IP logs. Setting aside DNS hijacking altogether, the idea that phishing sites could do something like this, perfectly proxy i.e. a bank's content and remain largely undetectable, makes me very concerned that we're only just seeing the beginning of sophisticated phishing attacks.

[mandatory]

Author here, thanks - glad you liked the post! :)

[claytonjy]

Thanks for this; as very-much-not-a-security guy, the alarm sounded by the original post was surprisingly clear, but fleshing out a plausible attack scenario like this really helps drive the point home while also teaching me a bit.