Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Ca By <cb.list6 () gmail com>]

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) <dougm () nist gov>
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" <kmedcalf () dessus com> 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:dougm () nist gov]
>     >Sent: Sunday, 24 February, 2019 15:38
>     >To: nanog () nanog org
>     >Cc: kmedcalf () 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-acme-acme-&amp;data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&amp;sdata=%2B6dEhg63cXX3MiBx8tWgFY6zoGmqqSxC1aE3RfOLVqc%3D&amp;reserved=0
>     >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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fnews%2Fannouncement-2019-02-22-en&amp;data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&amp;sdata=WoLoqR%2BPBRd1dKChGSK%2BZpvP15wAZvezmPatgElG8hY%3D&amp;reserved=0
>     >
>     >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" <kmedcalf () dessus com>
>     >    To: "nanog () nanog org" <nanog () nanog org>
>     >    Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking
>     >           Attacks
>     >    Message-ID: <6e31d305aee69c4d85116e6a81d0c91d () 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkrebsonsecurity.com%2F2019%2F02%2Fa-deep-dive-on-the-recent-&amp;data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&amp;sdata=A0j0UwTN566qmIwxHeX5FROC6JaMDuccp3ykJSCl8%2Fk%3D&amp;reserved=0
>     >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.
>     >
>     >