A Deep Dive on the Recent Widespread DNS Hijacking

Ca By cb.list6 at gmail.com
Mon Feb 25 04:06:09 UTC 2019

I just checked


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.


On Sun, Feb 24, 2019 at 7:43 PM Montgomery, Douglas (Fed) <dougm at nist.gov>

> 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 at 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 at nist.gov]
>     >Sent: Sunday, 24 February, 2019 15:38
>     >To: nanog at nanog.org
>     >Cc: kmedcalf at 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-&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=%2B6dEhg63cXX3MiBx8tWgFY6zoGmqqSxC1aE3RfOLVqc%3D&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&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=WoLoqR%2BPBRd1dKChGSK%2BZpvP15wAZvezmPatgElG8hY%3D&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 at dessus.com>
>     >    To: "nanog at nanog.org" <nanog at nanog.org>
>     >    Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking
>     >           Attacks
>     >    Message-ID: <6e31d305aee69c4d85116e6a81d0c91d at 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-&data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264&sdata=A0j0UwTN566qmIwxHeX5FROC6JaMDuccp3ykJSCl8%2Fk%3D&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.
>     >
>     >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190224/d6a34d9c/attachment.html>

More information about the NANOG mailing list