Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Mark Andrews <marka () isc org>]

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 <cb.list6 () gmail com> 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) <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.
>     >
>     >

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka () isc org