Re: A Deep Dive on the Recent Widespread DNS Hijacking
> On 25 Feb 2019, at 4:34 pm, Bill Woodcock wrote: > > > >> On Feb 24, 2019, at 5:51 PM, Keith Medcalf wrote: >> >> That they also "forgot" to disable DNSSEC on PCH is not particularly >> relevant. It only goes to prove my point that DNSSEC is irrelevant and only >> gives a false sense of security (for this particular attack vector). > > For those watching from the sidelines, This guy is perfectly encapsulating > one of the arguments that seem to pop up in the wake of attacks: “What > actually happened is irrelevant, because I can imagine other things that > could hypothetically have happened, but didn’t, which would have reinforced > my view of the world.” > > I can’t say that I understand the psychology behind people thinking this way, > but as we’re choosing to be transparent about our experience for the benefit > of others, I thought I’d highlight this particular quirk, as Mr. Medcalf is > far from alone (not about DNSSEC specifically, but apparently attacks bring > people with all manner of chips on their shoulders out of the woodwork). > It’s a particularly self-defeating logical fallacy, so being aware of it is > the first step to recognizing it and avoiding it. > >-Bill I would also note that a organisation can deploy RFC 5011 for their own zones and have their own equipment use DNSKEYs managed using RFC 5011 for their own zones. This isolates the organisation’s equipment from the parent zone’s management practices. I would also note that you can configure validating resolvers to expect secure responses for parts of the namespace and to reject insecure responses even when they validate as insecure. An organisation can also deploy DLV for their own zones using their own registry. While the current code DLV validating code is only invoked when the response validates as insecure, there is nothing preventing a policy which says that DLV trumps or must also validate for entries in a registry. At this stage is would be a minor code change to add such policy knobs. DLV is a just a in-band way of distributing trust anchors. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: A Deep Dive on the Recent Widespread DNS Hijacking
On 25/02/2019 07:20, Bill Woodcock wrote: On Feb 24, 2019, at 7:41 PM, Montgomery, Douglas (Fed) wrote: In the 3rd attack noted below, do we know if the CA that issued the DV CERTS does DNSSEC validation on its DNS challenge queries? We know that neither Comodo nor Let's Encrypt were DNSSEC validating before issuing certs. The Let’s Encrypt guys at least seemed interested in learning from their mistake. Can’t say as much of Comodo. -Bill Bill, Did you have a CAA record defined and if not, why not? -Hank
Re: A Deep Dive on the Recent Widespread DNS Hijacking
> On Feb 24, 2019, at 5:51 PM, Keith Medcalf wrote: > > That they also "forgot" to disable DNSSEC on PCH is not particularly > relevant. It only goes to prove my point that DNSSEC is irrelevant and only > gives a false sense of security (for this particular attack vector). For those watching from the sidelines, This guy is perfectly encapsulating one of the arguments that seem to pop up in the wake of attacks: “What actually happened is irrelevant, because I can imagine other things that could hypothetically have happened, but didn’t, which would have reinforced my view of the world.” I can’t say that I understand the psychology behind people thinking this way, but as we’re choosing to be transparent about our experience for the benefit of others, I thought I’d highlight this particular quirk, as Mr. Medcalf is far from alone (not about DNSSEC specifically, but apparently attacks bring people with all manner of chips on their shoulders out of the woodwork). It’s a particularly self-defeating logical fallacy, so being aware of it is the first step to recognizing it and avoiding it. -Bill signature.asc Description: Message signed with OpenPGP
Re: A Deep Dive on the Recent Widespread DNS Hijacking
> On Feb 24, 2019, at 7:41 PM, Montgomery, Douglas (Fed) wrote: > In the 3rd attack noted below, do we know if the CA that issued the DV CERTS > does DNSSEC validation on its DNS challenge queries? We know that neither Comodo nor Let's Encrypt were DNSSEC validating before issuing certs. The Let’s Encrypt guys at least seemed interested in learning from their mistake. Can’t say as much of Comodo. -Bill signature.asc Description: Message signed with OpenPGP
Re: A Deep Dive on the Recent Widespread DNS Hijacking
Google has been validating on 8.8.8.8 for years now though they only properly enabled EDNS for Google.com on Jan 10, 2019. Prior to that you needed to include a EDNS ECS option to get a EDNS response. They also DNSSEC sign some of their zones. https://developers.google.com/speed/public-dns/faq > On 25 Feb 2019, at 3:06 pm, Ca By wrote: > > I just checked > > Bing.com > Google.com > Amazon.com > Facebook.com > Netflix.com > Twitter.com > Chase.com > Coinbase.com > > None of them have dnssec signed domains. > > They are smart. They make money on the web. And they have, likely > consciously, made a cost / benefit risk driven evaluation of dnssec that it > is not worth using. More specifically, their inaction implies dnssec is more > risk than benefit, which i agree with. > > Those FANG companies have the resources to lead the way, but if they are > balkiing it’s a tall order to ask the rest of us (we have to buy our own > lunch crowd) to jump in the pool. > > But, icann is rationally raising the “never waste a good outage” to advance > your tired agenda. > > CB > > > > On Sun, Feb 24, 2019 at 7:43 PM Montgomery, Douglas (Fed) > wrote: > Keith, > > You are right, if you can compromise a registrar that permits DNSSEC to be > disabled (without notification/confirmation to POCs etc), then you only have > a limited period (max of DS TTL) of protection for those resolvers that have > already cached the DS. > > If that makes DNSSEC irrelevant in this specific scenario is in the eye of > the beholder I guess. I agree in that specific scenario it is not > preventative. > > In the 3rd attack noted below, do we know if the CA that issued the DV CERTS > does DNSSEC validation on its DNS challenge queries? > > Hopefully folks who deploy DNSSEC signed zones test validation on their > domains on a regular basis, and I would hope that a CA issuing DV CERTS would > do DNSSEC validation on signed zones in their DNS challenges. > > Given that this is only one vector for attacks of a similar style, it seems > like locking down the underlying infrastructure is still a good idea. > > The paper below mentioned in a NANOG talk last week gives food for thought. > > Bamboozling Certificate Authorities with BGP > https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee > > dougm > -- > DougM at NIST > > > On 2/24/19, 8:52 PM, "Keith Medcalf" wrote: > > > Obviously none of y'all read the report. Here is the relevant quote: > > > DNSSEC protects applications from using forged or manipulated DNS data, > by requiring that all DNS queries for a given domain or set of domains be > digitally signed. In DNSSEC, if a name server determines that the address > record for a given domain has not been modified in transit, it resolves the > domain and lets the user visit the site. If, however, that record has been > modified in some way or doesn’t match the domain requested, the name server > blocks the user from reaching the fraudulent address. > > While DNSSEC can be an effective tool for mitigating attacks such as > those launched by DNSpionage, only about 20 percent of the world’s major > networks and Web sites have enabled it, according to measurements gathered by > APNIC, the regional Internet address registry for the Asia-Pacific region. > > Jogbäck said Netnod’s infrastructure suffered three separate attacks from > the DNSpionage attackers. The first two occurred in a two-week window between > Dec. 14, 2018 and Jan. 2, 2019, and targeted company servers that were not > protected by DNSSEC. > > However, he said the third attack between Dec. 29 and Jan. 2 targeted > Netnod infrastructure that was protected by DNSSEC and serving its own > internal email network. Yet, because the attackers already had access to its > registrar’s systems, they were able to briefly disable that safeguard — or at > least long enough to obtain SSL certificates for two of Netnod’s email > servers. > > Jogbäck told KrebsOnSecurity that once the attackers had those > certificates, they re-enabled DNSSEC for the company’s targeted servers while > apparently preparing to launch the second stage of the attack — diverting > traffic flowing through its mail servers to machines the attackers > controlled. But Jogbäck said that for whatever reason, the attackers > neglected to use their unauthorized access to its registrar to disable DNSSEC > before later attempting to siphon Internet traffic. > > “Luckily for us, they forgot to remove that when they launched their > man-in-the-middle attack,” he said. “If they had been more skilled they would > have removed DNSSEC on the domain, which they could have done.” > """ > > If you manage to get access to the change the dns delegation at the > parent you can also turn DNSSEC off. Clearly the scripties managed to do > this once but "forgot" to do it the second time around ...
Re: A Deep Dive on the Recent Widespread DNS Hijacking
On Mon, Feb 25, 2019, 1:30 PM John Levine wrote: > > You are right, if you can compromise a registrar that permits DNSSEC to > be disabled (without notification/confirmation to POCs > > etc), then you only have a limited period (max of DS TTL) of protection > for those resolvers that have already cached the DS. > > As far as I can tell, that's roughly all of them. If you have the > credentials to log in and change the NS, you can change or remove the > DS, too. > And, that wouldn't change in the nearest future, because the concept of "hostile pinning" as it was present with HTTPS Public Key Pinning could also be ported to DNSSEC this way. "Hostile signing"... doesn't that sound scary. -- Töma >
Re: A Deep Dive on the Recent Widespread DNS Hijacking
In article you write: >You are right, if you can compromise a registrar that permits DNSSEC to be >disabled (without notification/confirmation to POCs >etc), then you only have a limited period (max of DS TTL) of protection for >those resolvers that have already cached the DS. As far as I can tell, that's roughly all of them. If you have the credentials to log in and change the NS, you can change or remove the DS, too. As someone else noted, the only reason DNSSEC made any difference was that the script kiddies sometimes forgot to turn it off or install their own DS. If you are actually interested in preventing this stuff, 2FA will be orders of magnitude more effective than messing with DNSSEC. There are certainly threats that DNSSEC addresses, but getting your registrar account pwned isn't one of them. R's, John
Re: A Deep Dive on the Recent Widespread DNS Hijacking
I just checked Bing.com Google.com Amazon.com Facebook.com Netflix.com Twitter.com Chase.com Coinbase.com None of them have dnssec signed domains. They are smart. They make money on the web. And they have, likely consciously, made a cost / benefit risk driven evaluation of dnssec that it is not worth using. More specifically, their inaction implies dnssec is more risk than benefit, which i agree with. Those FANG companies have the resources to lead the way, but if they are balkiing it’s a tall order to ask the rest of us (we have to buy our own lunch crowd) to jump in the pool. But, icann is rationally raising the “never waste a good outage” to advance your tired agenda. CB On Sun, Feb 24, 2019 at 7:43 PM Montgomery, Douglas (Fed) wrote: > Keith, > > You are right, if you can compromise a registrar that permits DNSSEC to be > disabled (without notification/confirmation to POCs etc), then you only > have a limited period (max of DS TTL) of protection for those resolvers > that have already cached the DS. > > If that makes DNSSEC irrelevant in this specific scenario is in the eye of > the beholder I guess. I agree in that specific scenario it is not > preventative. > > In the 3rd attack noted below, do we know if the CA that issued the DV > CERTS does DNSSEC validation on its DNS challenge queries? > > Hopefully folks who deploy DNSSEC signed zones test validation on their > domains on a regular basis, and I would hope that a CA issuing DV CERTS > would do DNSSEC validation on signed zones in their DNS challenges. > > Given that this is only one vector for attacks of a similar style, it > seems like locking down the underlying infrastructure is still a good idea. > > The paper below mentioned in a NANOG talk last week gives food for thought. > > Bamboozling Certificate Authorities with BGP > https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee > > dougm > -- > DougM at NIST > > > On 2/24/19, 8:52 PM, "Keith Medcalf" wrote: > > > Obviously none of y'all read the report. Here is the relevant quote: > > > DNSSEC protects applications from using forged or manipulated DNS > data, by requiring that all DNS queries for a given domain or set of > domains be digitally signed. In DNSSEC, if a name server determines that > the address record for a given domain has not been modified in transit, it > resolves the domain and lets the user visit the site. If, however, that > record has been modified in some way or doesn’t match the domain requested, > the name server blocks the user from reaching the fraudulent address. > > While DNSSEC can be an effective tool for mitigating attacks such as > those launched by DNSpionage, only about 20 percent of the world’s major > networks and Web sites have enabled it, according to measurements gathered > by APNIC, the regional Internet address registry for the Asia-Pacific > region. > > Jogbäck said Netnod’s infrastructure suffered three separate attacks > from the DNSpionage attackers. The first two occurred in a two-week window > between Dec. 14, 2018 and Jan. 2, 2019, and targeted company servers that > were not protected by DNSSEC. > > However, he said the third attack between Dec. 29 and Jan. 2 targeted > Netnod infrastructure that was protected by DNSSEC and serving its own > internal email network. Yet, because the attackers already had access to > its registrar’s systems, they were able to briefly disable that safeguard — > or at least long enough to obtain SSL certificates for two of Netnod’s > email servers. > > Jogbäck told KrebsOnSecurity that once the attackers had those > certificates, they re-enabled DNSSEC for the company’s targeted servers > while apparently preparing to launch the second stage of the attack — > diverting traffic flowing through its mail servers to machines the > attackers controlled. But Jogbäck said that for whatever reason, the > attackers neglected to use their unauthorized access to its registrar to > disable DNSSEC before later attempting to siphon Internet traffic. > > “Luckily for us, they forgot to remove that when they launched their > man-in-the-middle attack,” he said. “If they had been more skilled they > would have removed DNSSEC on the domain, which they could have done.” > """ > > If you manage to get access to the change the dns delegation at the > parent you can also turn DNSSEC off. Clearly the scripties managed to do > this once but "forgot" to do it the second time around ... That they also > "forgot" to disable DNSSEC on PCH is not particularly relevant. It only > goes to prove my point that DNSSEC is irrelevant and only gives a false > sense of security (for this particular attack vector). I suppose you could > have really long timeouts on your DS records, but that would merely > "complicate" matters for the scripties and would not be protective ... > > > --- > The fact that there's a Highway to Hell but only a Stairway to Heaven >
Re: A Deep Dive on the Recent Widespread DNS Hijacking
Keith, You are right, if you can compromise a registrar that permits DNSSEC to be disabled (without notification/confirmation to POCs etc), then you only have a limited period (max of DS TTL) of protection for those resolvers that have already cached the DS. If that makes DNSSEC irrelevant in this specific scenario is in the eye of the beholder I guess. I agree in that specific scenario it is not preventative. In the 3rd attack noted below, do we know if the CA that issued the DV CERTS does DNSSEC validation on its DNS challenge queries? Hopefully folks who deploy DNSSEC signed zones test validation on their domains on a regular basis, and I would hope that a CA issuing DV CERTS would do DNSSEC validation on signed zones in their DNS challenges. Given that this is only one vector for attacks of a similar style, it seems like locking down the underlying infrastructure is still a good idea. The paper below mentioned in a NANOG talk last week gives food for thought. Bamboozling Certificate Authorities with BGP https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee dougm -- DougM at NIST On 2/24/19, 8:52 PM, "Keith Medcalf" wrote: Obviously none of y'all read the report. Here is the relevant quote: DNSSEC protects applications from using forged or manipulated DNS data, by requiring that all DNS queries for a given domain or set of domains be digitally signed. In DNSSEC, if a name server determines that the address record for a given domain has not been modified in transit, it resolves the domain and lets the user visit the site. If, however, that record has been modified in some way or doesn’t match the domain requested, the name server blocks the user from reaching the fraudulent address. While DNSSEC can be an effective tool for mitigating attacks such as those launched by DNSpionage, only about 20 percent of the world’s major networks and Web sites have enabled it, according to measurements gathered by APNIC, the regional Internet address registry for the Asia-Pacific region. Jogbäck said Netnod’s infrastructure suffered three separate attacks from the DNSpionage attackers. The first two occurred in a two-week window between Dec. 14, 2018 and Jan. 2, 2019, and targeted company servers that were not protected by DNSSEC. However, he said the third attack between Dec. 29 and Jan. 2 targeted Netnod infrastructure that was protected by DNSSEC and serving its own internal email network. Yet, because the attackers already had access to its registrar’s systems, they were able to briefly disable that safeguard — or at least long enough to obtain SSL certificates for two of Netnod’s email servers. Jogbäck told KrebsOnSecurity that once the attackers had those certificates, they re-enabled DNSSEC for the company’s targeted servers while apparently preparing to launch the second stage of the attack — diverting traffic flowing through its mail servers to machines the attackers controlled. But Jogbäck said that for whatever reason, the attackers neglected to use their unauthorized access to its registrar to disable DNSSEC before later attempting to siphon Internet traffic. “Luckily for us, they forgot to remove that when they launched their man-in-the-middle attack,” he said. “If they had been more skilled they would have removed DNSSEC on the domain, which they could have done.” """ If you manage to get access to the change the dns delegation at the parent you can also turn DNSSEC off. Clearly the scripties managed to do this once but "forgot" to do it the second time around ... That they also "forgot" to disable DNSSEC on PCH is not particularly relevant. It only goes to prove my point that DNSSEC is irrelevant and only gives a false sense of security (for this particular attack vector). I suppose you could have really long timeouts on your DS records, but that would merely "complicate" matters for the scripties and would not be protective ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-Original Message- >From: Montgomery, Douglas (Fed) [mailto:do...@nist.gov] >Sent: Sunday, 24 February, 2019 15:38 >To: nanog@nanog.org >Cc: kmedc...@dessus.com >Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > >You might have missed reading the very article you cite. > >"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. > >Aside from that, DNSSEC saved us from being really, thoroughly >owned.” > > > >Or maybe ACME ..
RE: A Deep Dive on the Recent Widespread DNS Hijacking
Obviously none of y'all read the report. Here is the relevant quote: DNSSEC protects applications from using forged or manipulated DNS data, by requiring that all DNS queries for a given domain or set of domains be digitally signed. In DNSSEC, if a name server determines that the address record for a given domain has not been modified in transit, it resolves the domain and lets the user visit the site. If, however, that record has been modified in some way or doesn’t match the domain requested, the name server blocks the user from reaching the fraudulent address. While DNSSEC can be an effective tool for mitigating attacks such as those launched by DNSpionage, only about 20 percent of the world’s major networks and Web sites have enabled it, according to measurements gathered by APNIC, the regional Internet address registry for the Asia-Pacific region. Jogbäck said Netnod’s infrastructure suffered three separate attacks from the DNSpionage attackers. The first two occurred in a two-week window between Dec. 14, 2018 and Jan. 2, 2019, and targeted company servers that were not protected by DNSSEC. However, he said the third attack between Dec. 29 and Jan. 2 targeted Netnod infrastructure that was protected by DNSSEC and serving its own internal email network. Yet, because the attackers already had access to its registrar’s systems, they were able to briefly disable that safeguard — or at least long enough to obtain SSL certificates for two of Netnod’s email servers. Jogbäck told KrebsOnSecurity that once the attackers had those certificates, they re-enabled DNSSEC for the company’s targeted servers while apparently preparing to launch the second stage of the attack — diverting traffic flowing through its mail servers to machines the attackers controlled. But Jogbäck said that for whatever reason, the attackers neglected to use their unauthorized access to its registrar to disable DNSSEC before later attempting to siphon Internet traffic. “Luckily for us, they forgot to remove that when they launched their man-in-the-middle attack,” he said. “If they had been more skilled they would have removed DNSSEC on the domain, which they could have done.” """ If you manage to get access to the change the dns delegation at the parent you can also turn DNSSEC off. Clearly the scripties managed to do this once but "forgot" to do it the second time around ... That they also "forgot" to disable DNSSEC on PCH is not particularly relevant. It only goes to prove my point that DNSSEC is irrelevant and only gives a false sense of security (for this particular attack vector). I suppose you could have really long timeouts on your DS records, but that would merely "complicate" matters for the scripties and would not be protective ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-Original Message- >From: Montgomery, Douglas (Fed) [mailto:do...@nist.gov] >Sent: Sunday, 24 February, 2019 15:38 >To: nanog@nanog.org >Cc: kmedc...@dessus.com >Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > >You might have missed reading the very article you cite. > >"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. > >Aside from that, DNSSEC saved us from being really, thoroughly >owned.” > > > >Or maybe ACME .. https://tools.ietf.org/html/draft-ietf-acme-acme- >12#section-11.2 > >"It is therefore RECOMMENDED that ACME-based CAs make all DNS queries >via DNSSEC-validating stub or recursive resolvers. This provides >additional protection to domains which choose to make use of DNSSEC.” > >I am not sure how many of the domains listed as being hijacked are >DNSSEC signed, but it seems if they were, and had a reasonable long >TTL on a DS record at their parent, many if not most of these could >have been prevented/detected. > >ICANN seems to think that is the case: ICANN Calls for Full DNSSEC >Deployment >https://www.icann.org/news/announcement-2019-02-22-en > >Of course, DNSSEC is often blamed for not protecting those who did >not deploy/use it. Not sure what can be said about that line of >reasoning. > >Dougm >-- >Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST > > > > >Date: Sat, 23 Feb 2019 12:13:41 -0700 >From: "Keith Medcalf" >To: "nanog@nanog.org" >Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > Attacks >Message-ID: <6e31d305aee69c4d85116e6a81d0c...@mail.dessus.com> >Content-Type: text/plain; charset="us-ascii" > >On Saturday, 23 February, 2019 10:03, Stephane Bortzmeyer wrote: > >>Very good article, very detailed, with a lot of technical >precisions, >>about the recent domain name hijackings (not using the DNS, just >good >>old hijackings at registrar or hoster). > >
RE: A Deep Dive on the Recent Widespread DNS Hijacking
You might have missed reading the very article you cite. "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. Aside from that, DNSSEC saved us from being really, thoroughly owned.” Or maybe ACME .. https://tools.ietf.org/html/draft-ietf-acme-acme-12#section-11.2 "It is therefore RECOMMENDED that ACME-based CAs make all DNS queries via DNSSEC-validating stub or recursive resolvers. This provides additional protection to domains which choose to make use of DNSSEC.” I am not sure how many of the domains listed as being hijacked are DNSSEC signed, but it seems if they were, and had a reasonable long TTL on a DS record at their parent, many if not most of these could have been prevented/detected. ICANN seems to think that is the case: ICANN Calls for Full DNSSEC Deployment https://www.icann.org/news/announcement-2019-02-22-en Of course, DNSSEC is often blamed for not protecting those who did not deploy/use it. Not sure what can be said about that line of reasoning. Dougm -- Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST Date: Sat, 23 Feb 2019 12:13:41 -0700 From: "Keith Medcalf" To: "nanog@nanog.org" Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking Attacks Message-ID: <6e31d305aee69c4d85116e6a81d0c...@mail.dessus.com> Content-Type: text/plain; charset="us-ascii" On Saturday, 23 February, 2019 10:03, Stephane Bortzmeyer wrote: >Very good article, very detailed, with a lot of technical precisions, >about the recent domain name hijackings (not using the DNS, just good >old hijackings at registrar or hoster). >https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/ So in other words this was just an old school script kiddie taking advantage of DNS registrars, the only difference being this was a whole whack of script kiddies acting in concert directed by a not-quite-so-stupid script kiddie, with some "modernz" thrown in for good measure. (Sounds like an NSA operation to me -- and the targets perfectly match those that the NSA would choose -- plus some good old misdirection just for the jollies of it) The second takeaway being that DNSSEC is useless in preventing such an occurrence because the script kiddies can merely turn it off at the same time as they redirect DNS. However, having DNSSEC can protect you from incompetent script-kiddies. It can also give you a false sense of security. Did I miss anything? --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
