A Deep Dive on the Recent Widespread DNS Hijacking
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>
> 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
> 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
> 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
> 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
> >Or maybe ACME ..
> >"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
> >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
> >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
> > >about the recent domain name hijackings (not using the DNS, just
> > >old hijackings at registrar or hoster).
> > >
> > 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...
More information about the NANOG