This is nonsense, and possibly crossing the border from ignorant nonsense to malicious nonsense.
DNSSEC ensures that received DNS records are signed by an entity authorized to publish changes to the domain. It does not ensure, in any way, that this entity is publishing the right changes. It protects you against man-in-the-middle attacks, but not "hijacking" as usually envisioned. The linked article https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recen... identifies multiple cases of registrars saying that someone broke into their web interface (either by determining valid account credentials, or finding a flaw in the web interface). DNSSEC is not designed to protect against these attacks. As that article points out, some of the victims did in fact have DNSSEC set up.
As 'tptacek pointed out a few days ago, many .gov and .mil domains have DNSSEC and were nonetheless victims of DNS hijacking attacks. https://news.ycombinator.com/item?id=19180817 The US government is correctly not insisting on additional rollout of DNSSEC.
I myself have been a victim of DNS hijacking: in January 2013, someone hijacked mit.edu and (among other things) redirected the MX records to non-MIT servers. https://thetech.com/2013/01/23/hack-v132-n63 I lost email to my mit.edu address as a result, and if the attacker were interested in targeting me (or targeting MIT account holders in general) they could have triggered password resets by email, etc. They got in because they apparently knew the password for MIT's account at EDUCAUSE, domain registrar or guessed it on the first try. DNSSEC would not have prevented this. The attacker would have simply instructed EDUCAUSE to sign the records, or instructed EDUCAUSE to update the public key to one under the attacker's control.
And, for bonus points, had they done so, they likely would have been able to lock out MIT of regaining control of the domain for longer than it actually took.
As long as domain validation is the standard for getting certs, the security of the DNS system will be part of the security of DNS.
At the moment, DNSSEC is the only off-the-shelf authenticated DNS system. We need that authentication between the DNS servers and the Certificate Authorities.
DNSSEC between the DNS server and hosts doesn't matter much. There are other ways to MitM, and insecure fallback is inevitable.
In the end, the DNS system is what we use for identity management, so it should be authenticated. As the recent attacks have shown, the actual administration of the DNS servers (Registrars) also needs to be secured. That is not DNSSEC's role.
But in our current system, if a registrar is compromised, the system is compromised anyway. I'd love to hear an idea that obviates the need to trust Registrars. Without such an option, I don't think 'this doesn't defend against DNS account hijacking' counts, because nothing defends against DNS account hijacking.
Once someone has that account, you are fucked. HPKP is essentially the only thing that could save you, and that has (rightly) been deprecated.
Agreed. Requiring accredited registrars support/enforce 2FA (and preferably hardware OTPs) would be a much more effective response to this, in my opinion.
Maybe it won't do much for you, but for people like me whose governments actively try everything from DNS Cache poisoning to HTTP/HTML injection to censor the internet—DNSSEC would be amazing.
The whole system needs to be on DNSSEC to prevent hijacking. Just because you have a DNSSEC server doesn’t mean anything if the guy down the way can still be made to redirect traffic to a malicious site.
> And, for bonus points, had they done so, they likely would have been able to lock out MIT of regaining control of the domain for longer than it actually took.
You may have missed the part of the linked Krebs on Security article where they talked about cases where deployment of DNSSEC _did_ help:
> Woodcock said PCH’s reliance on DNSSEC almost completely blocked that attack, but that it managed to snare email credentials for two employees who were traveling at the time. Those employees’ mobile devices were downloading company email via hotel wireless networks that — as a prerequisite for using the wireless service — forced their devices to use the hotel’s DNS servers, not PCH’s DNNSEC-enabled systems.
> “The two people who did get popped, both were traveling and were on their iPhones, and they had to traverse through captive portals during the hijack period,” Woodcock said. “They had to switch off our name servers to use the captive portal, and during that time the mail clients on their phones checked for new email. Aside from that, DNSSEC saved us from being really, thoroughly owned.”
Obviously DNSSEC won't save you if your account with your domain registrar gets compromised, but there are other situations where it _is_ effective.
FWIW the article states this only applies for specific MITM cases, but yeah, this is kinda bullshit.
If you want to push back against this, find somebody near Kobe, Japan in the next few weeks who can go to this open session [1] and explain the problems, and provide some alternative solutions.
I agree with rocqua that the Registrar needs to have a more active role in securing DNS. I think we need new standards of control between domain owners, registrars, DNS TLDs, and certificate authorities.
I, as a domain owner, should be able to provide signed changes to the Registrar, and to entities further down the chain, so that just because someone gets access to my account on a service provider, they can not change anything without my private key. Delegation and revocation of other keys can also be handled for large organizations (we do that today with DNS).
Absolutely. It would make more sense for them to require all registrars to offer proper 2FA (i.e. SMS don’t count). This is something they have the authority to do and that would have a meaningful impact on security.
We as an industry have to stop using passwords. We have to stop using DNS. In this day and age who needs human-readable URLs? People only remember a tiny subset of most URLs anyway. Why not just make everything end-to-end encrypted and stop the stupid feudalism?
Nominet, the UK's domain registry, has a solution called "Domain Lock".
Whilst predominantly offered to registrars it is also available directly to registrants for the equivalent of $120 per year.
Assume a user has a domain name registered with their preferred registrar, e.g. Gandi, GoDaddy etc., then to change the DNS settings the user has to login to his Nominet portal (using mandatory 2SV) and unlock the DNS for up to 20 minutes (it can be manually re-locked earlier). The user then has to log into his registrar (preferably with 2SV set-up) and configure the relevant changes.
The additional steps involved are sufficient to prevent almost all unauthorized DNS changes except DNS poisoning.
Nominet say that their separate "DNSSEC signing service was withdrawn from service in January 2016 due to low uptake".
The tweet you linked to is making false claims about dnssec. It doesn't "blow up the sizes of dns requests" If you aren't explicitly looking up dnssec signatures, a signed zone's responses will be the same length as an unsigned zone's responses.
Also, dnssec for their real website, icann.org, is properly configured.
As much as I want DNSSEC to be a thing, it just doesn’t seem like it ever will. Checkout this name-and-shame site and you’ll see how hopeless it looks https://dnssec-name-and-shame.com
Why do you want it to be a thing? Have you ever been exposed to an attack that would have been prevented by DNSSEC?
I feel like most people who want DNSSEC just have very theoretical warm feelings about the idea of it. When they actually implement it it does nothing but consume time and energy while adding liability.
First of all, shame on that website for breaking my back button.
Second, that website has to be a parody of DNSSEC. It's showing that none of the major tech companies use it, meanwhile the "good examples" of DNSSEC compliance are all vendors substantially involved in standardizing or selling DNS services.
Handshake (handshake.org) provides an SPV Proof that the DNS records held in it's zone are authentic. This means if an attacker wanted to spoof records, they would have to:
1) Eclipse attack the client, meaning that the client is on a partitioned network with an alternative chain tip. This grows more expensive as the records were written further in the past
or
2) Steal the top level domain owners private key and update the database
While AWS supports DNSSEC for domain registration they don't support it for DNS. While it does appear that most of these attacks would not have been prevented by DNSSEC isn't it about time AWS supported DNSSEC ?
As I understand the attacks being against the login admin accounts for managing the domain itself, no DNSSEC would not have prevented changing the records in the zone. In addition, if the DNS provider hosting that domain automatically resigned the zone for the hacked account, then the hosting company would even have resigned the zone, thus making valid DNSSEC entries anyway.
What would be better is to require 2FA for all zone hosting companies.
Pretty sure you're right. The US-CERT advisory for this campaign implies the attackers were logging into the targets accounts at registrars or DNS providers directly.
Not really. In theory the zone signing could be done as a separate process from zone updates, but I don't think any DNS provider implements this - they hold the keys, not you. The other attacks used compromised domain registrar accounts, where the attacker could just disable DNSSEC or switch the nameservers to whatever.
Perhaps so, given that for most DNS provider, the ability to modify DNS records automatically gives you the ability to sign those record. This shows the importance of having a dedicated system for signing information, completely separate (and potentially offline) from the deployment system.
> This particular type of attack, which targets the DNS, only works when DNSSEC is not in use.
That doesn’t match any description I’ve seen of these attacks where the attacker had the same access to the management infrastructure as legitimate users. Is there some other incident being discussed or is this just fundamentally incorrect?
Call it DNSSEC or whatever, DNS needs more crypto. At present security of DNS rely on manual intervention, 2FA, "multi-perspective DNS lookups" and other rituals. That does not scale to 250M domains. Expect more hijacks until then.
DNSSEC use another chain of “ca”, not the root ca like those in browser. It is another complexity. Not sure it help in general and as said here not even dns hijicking. What is its point is still not sure.
Worse, those "additional CAs" are de facto and in many cases de jure controlled by world governments, many of whom (including my own) have demonstrated repeatedly their willingness to tamper with the DNS to achieve policy goals.
So erh a bunch of accounts get hacked, likely due to password reuse, weak passwords or phishing. But hey, it's about DNS and security, so let's push the dead horse DNSSEC, which would've done nothing to prevent this, because... whatever.
Even if your account is compromised,do they store the DNSSEC private keys for your domain? That maybe the issue here,requiring domain owners to generate the signature on their local computers seems to be a solution. What am I missing here?
If you mean this question in the cynical sense, then basically anyone who will be selling DNSSEC services to large enterprises benefits. And those services will probably be expensive.
sure, they would just hijack the outgoing TCP port 80 connection when you try to open a non HSTS domain. (and of course it could try to a port 443 with a fake cert thing too.)
also, there can be standardized portal lookup/discovery methods (this RFC has already expired, but it's likely that the effort will continue: https://tools.ietf.org/html/draft-pfister-capport-pvd-00 this seems to work with IPv6 only, as it builds on ICMPv6 Router Advertisement, but "provisioning domains" could simply be a DHCP data type too)
[+] [-] geofft|7 years ago|reply
DNSSEC ensures that received DNS records are signed by an entity authorized to publish changes to the domain. It does not ensure, in any way, that this entity is publishing the right changes. It protects you against man-in-the-middle attacks, but not "hijacking" as usually envisioned. The linked article https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recen... identifies multiple cases of registrars saying that someone broke into their web interface (either by determining valid account credentials, or finding a flaw in the web interface). DNSSEC is not designed to protect against these attacks. As that article points out, some of the victims did in fact have DNSSEC set up.
As 'tptacek pointed out a few days ago, many .gov and .mil domains have DNSSEC and were nonetheless victims of DNS hijacking attacks. https://news.ycombinator.com/item?id=19180817 The US government is correctly not insisting on additional rollout of DNSSEC.
I myself have been a victim of DNS hijacking: in January 2013, someone hijacked mit.edu and (among other things) redirected the MX records to non-MIT servers. https://thetech.com/2013/01/23/hack-v132-n63 I lost email to my mit.edu address as a result, and if the attacker were interested in targeting me (or targeting MIT account holders in general) they could have triggered password resets by email, etc. They got in because they apparently knew the password for MIT's account at EDUCAUSE, domain registrar or guessed it on the first try. DNSSEC would not have prevented this. The attacker would have simply instructed EDUCAUSE to sign the records, or instructed EDUCAUSE to update the public key to one under the attacker's control.
And, for bonus points, had they done so, they likely would have been able to lock out MIT of regaining control of the domain for longer than it actually took.
[+] [-] rocqua|7 years ago|reply
At the moment, DNSSEC is the only off-the-shelf authenticated DNS system. We need that authentication between the DNS servers and the Certificate Authorities. DNSSEC between the DNS server and hosts doesn't matter much. There are other ways to MitM, and insecure fallback is inevitable.
In the end, the DNS system is what we use for identity management, so it should be authenticated. As the recent attacks have shown, the actual administration of the DNS servers (Registrars) also needs to be secured. That is not DNSSEC's role.
But in our current system, if a registrar is compromised, the system is compromised anyway. I'd love to hear an idea that obviates the need to trust Registrars. Without such an option, I don't think 'this doesn't defend against DNS account hijacking' counts, because nothing defends against DNS account hijacking.
Once someone has that account, you are fucked. HPKP is essentially the only thing that could save you, and that has (rightly) been deprecated.
[+] [-] jakejarvis|7 years ago|reply
[+] [-] amingilani|7 years ago|reply
[+] [-] behindmyscreen|7 years ago|reply
[+] [-] agwa|7 years ago|reply
How would DNSSEC have made it take longer?
[+] [-] Ajedi32|7 years ago|reply
> Woodcock said PCH’s reliance on DNSSEC almost completely blocked that attack, but that it managed to snare email credentials for two employees who were traveling at the time. Those employees’ mobile devices were downloading company email via hotel wireless networks that — as a prerequisite for using the wireless service — forced their devices to use the hotel’s DNS servers, not PCH’s DNNSEC-enabled systems.
> “The two people who did get popped, both were traveling and were on their iPhones, and they had to traverse through captive portals during the hijack period,” Woodcock said. “They had to switch off our name servers to use the captive portal, and during that time the mail clients on their phones checked for new email. Aside from that, DNSSEC saved us from being really, thoroughly owned.”
Obviously DNSSEC won't save you if your account with your domain registrar gets compromised, but there are other situations where it _is_ effective.
[+] [-] peterwwillis|7 years ago|reply
If you want to push back against this, find somebody near Kobe, Japan in the next few weeks who can go to this open session [1] and explain the problems, and provide some alternative solutions.
I agree with rocqua that the Registrar needs to have a more active role in securing DNS. I think we need new standards of control between domain owners, registrars, DNS TLDs, and certificate authorities.
I, as a domain owner, should be able to provide signed changes to the Registrar, and to entities further down the chain, so that just because someone gets access to my account on a service provider, they can not change anything without my private key. Delegation and revocation of other keys can also be handled for large organizations (we do that today with DNS).
[1] https://meetings.icann.org/en/kobe64
[+] [-] fmajid|7 years ago|reply
[+] [-] deytempo|7 years ago|reply
[+] [-] wav-part|7 years ago|reply
[+] [-] EGreg|7 years ago|reply
[+] [-] jaas|7 years ago|reply
Let's kill it off and focus on efforts that solve real problems. It's worse than pointless, the added complexity is a huge liability.
[+] [-] hodo|7 years ago|reply
Whilst predominantly offered to registrars it is also available directly to registrants for the equivalent of $120 per year.
Assume a user has a domain name registered with their preferred registrar, e.g. Gandi, GoDaddy etc., then to change the DNS settings the user has to login to his Nominet portal (using mandatory 2SV) and unlock the DNS for up to 20 minutes (it can be manually re-locked earlier). The user then has to log into his registrar (preferably with 2SV set-up) and configure the relevant changes.
The additional steps involved are sufficient to prevent almost all unauthorized DNS changes except DNS poisoning.
Nominet say that their separate "DNSSEC signing service was withdrawn from service in January 2016 due to low uptake".
[+] [-] tptacek|7 years ago|reply
https://twitter.com/__agwa/status/1099782458046705669
[+] [-] Abekkus|7 years ago|reply
Also, dnssec for their real website, icann.org, is properly configured.
[+] [-] move-on-by|7 years ago|reply
[+] [-] jaas|7 years ago|reply
I feel like most people who want DNSSEC just have very theoretical warm feelings about the idea of it. When they actually implement it it does nothing but consume time and energy while adding liability.
[+] [-] throwawaymath|7 years ago|reply
Second, that website has to be a parody of DNSSEC. It's showing that none of the major tech companies use it, meanwhile the "good examples" of DNSSEC compliance are all vendors substantially involved in standardizing or selling DNS services.
[+] [-] tynes|7 years ago|reply
1) Eclipse attack the client, meaning that the client is on a partitioned network with an alternative chain tip. This grows more expensive as the records were written further in the past
or
2) Steal the top level domain owners private key and update the database
[+] [-] markwakeford|7 years ago|reply
[+] [-] throwawaymath|7 years ago|reply
[+] [-] ryanlol|7 years ago|reply
(Also kinda curious as to why pointing this out seems to be somewhat controversial? :)
[+] [-] bluejekyll|7 years ago|reply
What would be better is to require 2FA for all zone hosting companies.
[+] [-] DKnoll|7 years ago|reply
https://www.us-cert.gov/ncas/current-activity/2019/01/10/DNS...
[+] [-] r1ch|7 years ago|reply
[+] [-] entire-name|7 years ago|reply
[+] [-] avip|7 years ago|reply
[+] [-] firekvz|7 years ago|reply
> On 15 February 2019, in response to reports of attacks against key parts of the DNS infrastructure..
Is related to said attack ?
heres the link for the dns attack by venezuelan gov
https://news.ycombinator.com/item?id=19240685
it's worth a read
[+] [-] acdha|7 years ago|reply
> This particular type of attack, which targets the DNS, only works when DNSSEC is not in use.
That doesn’t match any description I’ve seen of these attacks where the attacker had the same access to the management infrastructure as legitimate users. Is there some other incident being discussed or is this just fundamentally incorrect?
[+] [-] gist|7 years ago|reply
Also most FAANG companies do not have dns sec implemented at all (or correction).
There are various ways to check this but the easiest is to simply pull a whois.
[+] [-] tptacek|7 years ago|reply
[+] [-] wav-part|7 years ago|reply
[+] [-] ngcc_hk|7 years ago|reply
[+] [-] tptacek|7 years ago|reply
[+] [-] godzillabrennus|7 years ago|reply
There was a somewhat high profile theft a few years back where the owner published how they recovered their domain:
https://www.forbes.com/sites/theyec/2015/02/28/how-to-recove...
[+] [-] hannob|7 years ago|reply
[+] [-] badrabbit|7 years ago|reply
[+] [-] basicplus2|7 years ago|reply
[+] [-] throwawaymath|7 years ago|reply
[+] [-] StreamBright|7 years ago|reply
https://vimeo.com/18279777
[+] [-] wav-part|7 years ago|reply
This is a fight for cert revenue: CAs vs ICANN.
[+] [-] ietf-dane|7 years ago|reply
[+] [-] philip1209|7 years ago|reply
[+] [-] pas|7 years ago|reply
also, there can be standardized portal lookup/discovery methods (this RFC has already expired, but it's likely that the effort will continue: https://tools.ietf.org/html/draft-pfister-capport-pvd-00 this seems to work with IPv6 only, as it builds on ICMPv6 Router Advertisement, but "provisioning domains" could simply be a DHCP data type too)
[+] [-] acd|7 years ago|reply