Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Bill Woodcock]

> On Feb 26, 2019, at 1:34 PM, James Renken via NANOG  wrote:
> 
> On Feb 25, 2019, at 5:20 AM, Bill Woodcock  wrote:
>> We know that neither Comodo nor Let's Encrypt were DNSSEC validating before 
>> issuing certs.
> 
> I’d like to clarify that Let’s Encrypt has always validated DNSSEC, dating to 
> before we issued our first publicly trusted certificate in September 2015.

Yes, my apologies…  Comodo may well have been used in the attack against us 
_because_ Let’s Encrypt was DNSSEC validating.  I’m sorry for tarring both 
Let’s Encrypt and Comodo with the same brush.

The fact remains, however, that both Let’s Encrypt and Comodo are facilitating 
these hijacks by issuing illegitimate certificates to attackers.  So, ipso 
facto, both organizations’ security practices are insufficient.

We had what I thought to be a productive call with Jacob Hoffman-Andrews, of 
Let’s Encrypt, late last week, and arrived at a couple of possibilities for 
improving the situation a bit, but I don’t imagine that PCH has the expertise 
to contribute substantively to CA business process improvements, as that’s well 
outside our field.

-Bill



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[James Renken via NANOG]

On Feb 25, 2019, at 1:16 PM, Hank Nussbacher  wrote:
> Yes if an attacker pwned the DNS then game over no matter what. I go 
> under the assumption that the attacker was not able to take over the DNS 
> system but rather other things along the way, in which case CAA should 
> be of some assistance.

I’m excited about a proposed CAA extension 
(https://tools.ietf.org/html/draft-ietf-acme-caa-06) that would allow domain 
owners to restrict issuance to a particular ACME account and a particular 
validation method. This could provide stronger protection against most attacks 
short of a registry or registrar hijack. It’s implemented in Let’s Encrypt's 
staging environment, and I hope it’s able to move forward.

-- 
James Renken (pronouns: he/him)
Internet Security Research Group
Let's Encrypt: A Free, Automated, and Open CA

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[James Renken via NANOG]

On Feb 25, 2019, at 5:20 AM, Bill Woodcock  wrote:
> We know that neither Comodo nor Let's Encrypt were DNSSEC validating before 
> issuing certs.

I’d like to clarify that Let’s Encrypt has always validated DNSSEC, dating to 
before we issued our first publicly trusted certificate in September 2015.

-- 
James Renken (pronouns: he/him)
Internet Security Research Group
Let's Encrypt: A Free, Automated, and Open CA

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Nico Cartron]

> On 26 Feb 2019, at 21:58, Bill Woodcock  wrote:
> 
> 
> 
>> On Feb 26, 2019, at 8:12 AM, John Levine  wrote:
>> 
>> In article 
>>  you 
>> write:
>>> Swapping the DNS cabal for the CA cabal is not an improvement. Right?  They
>>> are really the same arbitraging rent-seekers, just different layers.
>> 
>> The models are different.  If I want to compromise your DNS I need to
>> attack your specific registrar.  If I want a bogus cert, any of the
>> thousand CAs in my browser will do.
> 
> Exactly.  And if you’re an organization that has money and pays attention to 
> DNS and security, you can get yourself a TLD, and be your own registry, at 
> which point you only need to worry about the security of the root zone.

Interesting. 
Never thought of new TLD from this angle :)

-- 
Nico  

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Bill Woodcock]

> On Feb 24, 2019, at 9:20 PM, 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.

Sorry, a correction:

Apparently Let’s Encrypt _does_ do a DNSSEC validation check, and presumably 
that’s why a Comodo cert was used to attack us.  It was my prior understanding 
that Let’s Encrypt certs had been used against DNSSEC-signed zones, but 
apparently that was not the case.

My apologies for my confusion.  Nonetheless, even with the DNSSEC validation, 
there’s a problem here that needs to be solved, on both the parts of the CAs 
involved and the registry/registrar chain.

-Bill



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[bzs]

On February 26, 2019 at 20:45 jo...@iecc.com (John Levine) wrote:
 > In article <3fd86d54-7fe4-4e1d-8c8d-a4d79f030...@pch.net> you write:
 > >That’s the main reason for having a brand TLD at this point, from my point 
 > >of view.  It’s the reason I’d get one in a heartbeat, if I could afford the 
 > >fees.
 > 
 > Well, actually, you can't get one.  The 2013 round is still working
 > out some issues, e.g. two companies both named Merck who hate each
 > other want .MERCK and neither will budge.  There may be another round
 > but given the stupendous non-success of the current round, I wouldn't
 > hold my breath.

Yeah well ICANN might've done something about string collisions and
trademarks, a 200+ year old problem the rest of the world has worked
out some rules on like the 40+ product categories WIPO uses (tho those
two Merck companies are an unusual problem due to historical reasons.)

But n, they made it worse, or not any better, and instead turned
TLDs into something resembling "Pro Wrestling" with all the chair
throwing and phony chokeholds that implies.

(remarks certainly not aimed at John, just venting.)

 > Also, with only one exception, all of the brand TLDs are in fact run
 > by a handful of of familiar back end services.  (The exception is a
 > phone company in the Philippines that rolled their own, pretty
 > marginally.)  PCH presumably has the infrastructure to run one, but
 > you're really just as well off becoming a registrar and managing your
 > 2LDs in well run TLDs.  You can do that now, it's a lot cheaper.
 > 
 > 
 > 

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[John Levine]

In article <3fd86d54-7fe4-4e1d-8c8d-a4d79f030...@pch.net> you write:
>That’s the main reason for having a brand TLD at this point, from my point of 
>view.  It’s the reason I’d get one in a heartbeat, if I could afford the fees.

Well, actually, you can't get one.  The 2013 round is still working
out some issues, e.g. two companies both named Merck who hate each
other want .MERCK and neither will budge.  There may be another round
but given the stupendous non-success of the current round, I wouldn't
hold my breath.

Also, with only one exception, all of the brand TLDs are in fact run
by a handful of of familiar back end services.  (The exception is a
phone company in the Philippines that rolled their own, pretty
marginally.)  PCH presumably has the infrastructure to run one, but
you're really just as well off becoming a registrar and managing your
2LDs in well run TLDs.  You can do that now, it's a lot cheaper.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Bill Woodcock]

> On Feb 26, 2019, at 1:25 PM, Nico Cartron  wrote:
> 
> 
> 
>> On 26 Feb 2019, at 21:58, Bill Woodcock  wrote:
>> 
>> 
>> 
>>> On Feb 26, 2019, at 8:12 AM, John Levine  wrote:
>>> 
>>> In article 
>>>  you 
>>> write:
 Swapping the DNS cabal for the CA cabal is not an improvement. Right?  They
 are really the same arbitraging rent-seekers, just different layers.
>>> 
>>> The models are different.  If I want to compromise your DNS I need to
>>> attack your specific registrar.  If I want a bogus cert, any of the
>>> thousand CAs in my browser will do.
>> 
>> Exactly.  And if you’re an organization that has money and pays attention to 
>> DNS and security, you can get yourself a TLD, and be your own registry, at 
>> which point you only need to worry about the security of the root zone.
> 
> Interesting.
> Never thought of new TLD from this angle :)

That’s the main reason for having a brand TLD at this point, from my point of 
view.  It’s the reason I’d get one in a heartbeat, if I could afford the fees.

-Bill



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Bill Woodcock]

> On Feb 26, 2019, at 8:12 AM, John Levine  wrote:
> 
> In article 
>  you 
> write:
>> Swapping the DNS cabal for the CA cabal is not an improvement. Right?  They
>> are really the same arbitraging rent-seekers, just different layers.
> 
> The models are different.  If I want to compromise your DNS I need to
> attack your specific registrar.  If I want a bogus cert, any of the
> thousand CAs in my browser will do.

Exactly.  And if you’re an organization that has money and pays attention to 
DNS and security, you can get yourself a TLD, and be your own registry, at 
which point you only need to worry about the security of the root zone.

-Bill



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Mark Andrews]

> On 27 Feb 2019, at 6:46 am, Bill Woodcock  wrote:
> 
> 
> 
>> On Feb 26, 2019, at 9:15 AM, Jacques Latour  wrote:
>> DNSSEC should of never been part of the domain registration process, it was 
>> because we didn’t have the CDS/CDNSKEY channel to automated the DS 
>> maintenance and bootstrap. But if you keep DNSSEC maintenance outside the 
>> registrar control then it can be effective tool (amongst other) in 
>> identifying hijacks.  Taking away he ability of the bad actors to disable 
>> DNSSEC via registrar control panel.
>> This is what happens when you have all your eggs in one basket and you loose 
>> the keys to your kingdom.
> 
> Agreed.  There’s absolutely no reason for registrars to be involved with DS 
> records of zones they’re not signing.  And, for the same reason, there’s no 
> reason for them to be involved with NS records, either, after an initial 
> bootstrap.
> 
>-Bill

Using https://datatracker.ietf.org/doc/draft-andrews-dnsop-update-parent-zones/ 
with TSIG or SIG(0)
would have prevented this with TFA for updating the credentials required to 
authenticate the updates.
The method works with either TSIG or SIG(0) and you can have specific keys to 
update DS records or
NS records and glue records.  You can’t MITM TSIG or SIG(0).  TSIG and SIG(0) 
have time limited replay
windows.  This is just bolting together tried and proven technology with 
database lookups to determine
which registrar authenticates the update.

Nameservers already forward UPDATE messages to the primary server for 
processing using TSIG and
SIG(0) between the UPDATE client and the primary server.  The key name is in 
the clear so it is
easy to use that to select how to redirect the update.  This also works with 
existing DNS servers
when EPP is not thrown into the mix.  It also doesn’t require DNSSEC to be 
deployed.

Tools to do this have been shipped with nameservers since UPDATE, TSIG and 
SIG(0) were invented.

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

[Bill Woodcock]

> On Feb 26, 2019, at 5:35 AM, Ca By  wrote:
> DNS guy says the solution for insecure DNS…

I am not a DNS guy.  I’m a routing guy who became a routing-economics guy as my 
hair got pointier.  Stephane and Allison and Bert and Olafur are DNS people, to 
pick a few examples.  And I believe that, yes, DNS people believe that the 
solution to insecurity in the DNS is to replace insecure portions of the DNS 
with more secure improvements to the DNS.

-Bill



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Bill Woodcock]

> On Feb 26, 2019, at 9:15 AM, Jacques Latour  wrote:
> DNSSEC should of never been part of the domain registration process, it was 
> because we didn’t have the CDS/CDNSKEY channel to automated the DS 
> maintenance and bootstrap. But if you keep DNSSEC maintenance outside the 
> registrar control then it can be effective tool (amongst other) in 
> identifying hijacks.  Taking away he ability of the bad actors to disable 
> DNSSEC via registrar control panel.
> This is what happens when you have all your eggs in one basket and you loose 
> the keys to your kingdom.

Agreed.  There’s absolutely no reason for registrars to be involved with DS 
records of zones they’re not signing.  And, for the same reason, there’s no 
reason for them to be involved with NS records, either, after an initial 
bootstrap.

-Bill



signature.asc
Description: Message signed with OpenPGP

RE: A Deep Dive on the Recent Widespread DNS Hijacking

[Jacques Latour]

DNSSEC should of never been part of the domain registration process, it was 
because we didn’t have the CDS/CDNSKEY channel to automated the DS maintenance 
and bootstrap. But if you keep DNSSEC maintenance outside the registrar control 
then it can be effective tool (amongst other) in identifying hijacks.  Taking 
away he ability of the bad actors to disable DNSSEC via registrar control panel.

This is what happens when you have all your eggs in one basket and you loose 
the keys to your kingdom.


From: NANOG  On Behalf Of Bill Woodcock
Sent: February 26, 2019 4:57 AM
To: Hank Nussbacher 
Cc: nanog@nanog.org
Subject: Re: A Deep Dive on the Recent Widespread DNS Hijacking



> On Feb 24, 2019, at 10:03 PM, Hank Nussbacher 
> mailto:h...@efes.iucc.ac.il>> wrote:
> Did you have a CAA record defined and if not, why not?

It’s something we’d been planning to do but, ironically, we’d been in the 
process of switching to Let’s Encrypt, and they were one of the two CAs whose 
process vulnerabilities the attackers were exploiting.  So, in this particular 
case, it wouldn’t have helped.

I guess the combination of CAA with a very expensive, or very manual, CA, might 
be an improvement.  But it’s still a band-aid on a bankrupt system.

We need to get switched over to DANE as quickly as possible, and stop wasting 
effort trying to keep the CA system alive with ever-hackier band-aids.

-Bill

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Carl Byington via NANOG]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, 2019-02-25 at 17:04 +1100, Mark Andrews wrote:
> 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 want a registrar that can use TOTP 2fa for updates, but that
interferes with automated KSK key rollovers. Are there any registrars
that use rfc5011 to allow automated KSK key rollovers, combined with
TOTP 2fa for web based updates like the initial transition to a secure
zone, NS record changes, etc.?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlx1aWgACgkQL6j7milTFsF9mACfVIXUZNLTOEyzbjneuZDeIBEg
2GUAnjoWsNZXtu0PgTuTvPwK0Je9DpCG
=nZy7
-END PGP SIGNATURE-

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[John Levine]

In article 
 you 
write:
>Swapping the DNS cabal for the CA cabal is not an improvement. Right?  They
>are really the same arbitraging rent-seekers, just different layers.

The models are different.  If I want to compromise your DNS I need to
attack your specific registrar.  If I want a bogus cert, any of the 
thousand CAs in my browser will do.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Tony Finch]

valdis.kletni...@vt.edu  wrote:
>
> Unless you get it down to the SMS "wait for a msg, type in the 6 digit number"
> level, it's going to be a tough start...

Isn't this what Duo's business is based on? Usable TOTP?

See also Google Authenticator, Authy, 1Password, etc. usw.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Southeast Iceland: Southwesterly gale 8 to storm 10, veering westerly 5 to 7
later. High or very high, becoming rough or very rough later. Squally showers.
Moderate or poor.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Ca By]

On Tue, Feb 26, 2019 at 6:25 AM David Conrad  wrote:

> On Feb 26, 2019, at 2:35 PM, Ca By  wrote:
>
> On Tue, Feb 26, 2019 at 1:58 AM Bill Woodcock  wrote:
>
>> > On Feb 24, 2019, at 10:03 PM, Hank Nussbacher 
>> wrote:
>> > Did you have a CAA record defined and if not, why not?
>>
>> It’s something we’d been planning to do but, ironically, we’d been in the
>> process of switching to Let’s Encrypt, and they were one of the two CAs
>> whose process vulnerabilities the attackers were exploiting.  So, in this
>> particular case, it wouldn’t have helped.
>>
>> I guess the combination of CAA with a very expensive, or very manual, CA,
>> might be an improvement.  But it’s still a band-aid on a bankrupt system.
>>
>> We need to get switched over to DANE as quickly as possible, and stop
>> wasting effort trying to keep the CA system alive with ever-hackier
>> band-aids.
>>
>> -Bill
>
>
> DNS guy says the solution for insecure DNS is... wait for it more DNS
> ...
>
>
> Well, no. "DNS guy” (Bill’s a bit more than that, of course) says the
> solution for a fundamentally broken trust model is a different system to
> derive trust.
>
> Or do you think Let’s Encrypt/Comodo increase trust?
>

The trust issue has not yet been solved on the internet.

Swapping the DNS cabal for the CA cabal is not an improvement. Right?  They
are really the same arbitraging rent-seekers, just different layers.

Using DANE to verify multiple layers is interesting, but the web folks
aren’t playing so it won’t go anywhere. Right?  Google, Wechat, FB, msft,
and Apple aren’t coming along.

Since you mentioned Let’s Encrypt, they have reduced plaint text, which is
great. But trust is a harder issue.

For example, Symantec has lost trust. But only after repeated bad actions.



> Regards,
> -drc
>
>

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[David Conrad]

On Feb 26, 2019, at 2:35 PM, Ca By  wrote:
> On Tue, Feb 26, 2019 at 1:58 AM Bill Woodcock  > wrote:
> > On Feb 24, 2019, at 10:03 PM, Hank Nussbacher  > > wrote:
> > Did you have a CAA record defined and if not, why not?
> 
> It’s something we’d been planning to do but, ironically, we’d been in the 
> process of switching to Let’s Encrypt, and they were one of the two CAs whose 
> process vulnerabilities the attackers were exploiting.  So, in this 
> particular case, it wouldn’t have helped.
> 
> I guess the combination of CAA with a very expensive, or very manual, CA, 
> might be an improvement.  But it’s still a band-aid on a bankrupt system.
> 
> We need to get switched over to DANE as quickly as possible, and stop wasting 
> effort trying to keep the CA system alive with ever-hackier band-aids.
> 
> -Bill
> 
> DNS guy says the solution for insecure DNS is... wait for it more DNS ...

Well, no. "DNS guy” (Bill’s a bit more than that, of course) says the solution 
for a fundamentally broken trust model is a different system to derive trust.

Or do you think Let’s Encrypt/Comodo increase trust?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Ca By]

On Tue, Feb 26, 2019 at 1:58 AM Bill Woodcock  wrote:

>
>
> > On Feb 24, 2019, at 10:03 PM, Hank Nussbacher 
> wrote:
> > Did you have a CAA record defined and if not, why not?
>
> It’s something we’d been planning to do but, ironically, we’d been in the
> process of switching to Let’s Encrypt, and they were one of the two CAs
> whose process vulnerabilities the attackers were exploiting.  So, in this
> particular case, it wouldn’t have helped.
>
> I guess the combination of CAA with a very expensive, or very manual, CA,
> might be an improvement.  But it’s still a band-aid on a bankrupt system.
>
> We need to get switched over to DANE as quickly as possible, and stop
> wasting effort trying to keep the CA system alive with ever-hackier
> band-aids.
>
> -Bill



DNS guy says the solution for insecure DNS is... wait for it more DNS
...



>
>

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Bjørn Mork]

Bill Woodcock  writes:

> We need to get switched over to DANE as quickly as possible, and stop
> wasting effort trying to keep the CA system alive with ever-hackier
> band-aids.

Sure. Just won't happen as long as there is money left in the CA
business.


Bjørn

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Michael Hallgren]

Le 2019-02-26 11:04, Sander Steffann a écrit :
Op 26 feb. 2019, om 10:56 heeft Bill Woodcock  het 
volgende geschreven:


We need to get switched over to DANE as quickly as possible, and stop 
wasting effort trying to keep the CA system alive with ever-hackier 
band-aids.


+1
Sander

+1
mh

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Sander Steffann]

> Op 26 feb. 2019, om 10:56 heeft Bill Woodcock  het volgende 
> geschreven:
> 
> We need to get switched over to DANE as quickly as possible, and stop wasting 
> effort trying to keep the CA system alive with ever-hackier band-aids.

+1
Sander



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Bill Woodcock]

> On Feb 24, 2019, at 10:03 PM, Hank Nussbacher  wrote:
> Did you have a CAA record defined and if not, why not?

It’s something we’d been planning to do but, ironically, we’d been in the 
process of switching to Let’s Encrypt, and they were one of the two CAs whose 
process vulnerabilities the attackers were exploiting.  So, in this particular 
case, it wouldn’t have helped.

I guess the combination of CAA with a very expensive, or very manual, CA, might 
be an improvement.  But it’s still a band-aid on a bankrupt system.

We need to get switched over to DANE as quickly as possible, and stop wasting 
effort trying to keep the CA system alive with ever-hackier band-aids.

-Bill



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Saku Ytti]

On Tue, Feb 26, 2019 at 4:05 AM  wrote:

> So what registries/registrars are supporting 2FA that's better than SMS?
> Or since 98% of domain names are Bait type, is nobody bothering
> to support something for the 2% that could use it?

Gandi does TOTP and CIDR filtering, that is, you can give them list of
CIDRs from which login is permissible at all.

-- 
  ++ytti

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Hunter Fuller]

On Mon, Feb 25, 2019 at 8:02 PM  wrote:
> So what registries/registrars are supporting 2FA that's better than SMS?
> Or since 98% of domain names are Bait type, is nobody bothering
> to support something for the 2% that could use it?

If Joe's Bait and Tackle buys from Namecheap, they can utilize TOTP
for their second factor.

https://www.namecheap.com/support/knowledgebase/article.aspx/10073/45/how-can-i-use-the-totp-method-for-twofactor-authentication

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Eric Kuhnke]

Markmonitor runs a registrar popular with fortune 500s that implements
additional security steps, and talking to a clued in live human in the loop
to modify anything in your domain record.

On Mon, Feb 25, 2019, 6:03 PM  wrote:

> On Mon, 25 Feb 2019 18:23:44 -0700, Paul Ebersman said:
>
> > Agreed. But this also gets down to the risk vs hassle tradeoff. Joe's
> > Bait & Tackle Shop probably isn't getting attacked by nation states who
> > can hack SS7, so SMS text might be good enough. And certainly better
> > than just an 8 char plain text password.
>
> So what registries/registrars are supporting 2FA that's better than SMS?
> Or since 98% of domain names are Bait type, is nobody bothering
> to support something for the 2% that could use it?
>
> Or is there a business opportunity lurking here? :)
>

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[valdis . kletnieks]

On Mon, 25 Feb 2019 18:23:44 -0700, Paul Ebersman said:

> Agreed. But this also gets down to the risk vs hassle tradeoff. Joe's
> Bait & Tackle Shop probably isn't getting attacked by nation states who
> can hack SS7, so SMS text might be good enough. And certainly better
> than just an 8 char plain text password.

So what registries/registrars are supporting 2FA that's better than SMS?
Or since 98% of domain names are Bait type, is nobody bothering
to support something for the 2% that could use it?

Or is there a business opportunity lurking here? :)

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Paul Ebersman]

ebersman> Yup. This is a good example of what I'm advocating. Just
ebersman> saying "use 2FA" or "use DNSSEC" or "have a CAA" isn't
ebersman> sufficient detail to make informed decisions of
ebersman> risk/effort/reward tradeoffs. Simplistic suggestions without
ebersman> details or context isn't doing anyone any favors.

ebersman> That said, even SMS 2FA is better than no 2FA. Barely. Just
ebersman> like forcing lousy passwords is better than no password but
ebersman> still not a best practice.

valdis> Feel free to suggest a workable 2FA.  Personally, I use a
valdis> Yubikey where I can.  Oath seems to be a reasonable approach for
valdis> technically minded people, but I'm not sure that it scales well
valdis> to the people who own the long tail domains in the 40 million
valdis> .coms.  I can get oathtool to behave the way I want, but I'm not
valdis> sure the owner of joes-bait-tackle-and-gunshop.com will be able
valdis> to deal with it.

Agreed. But this also gets down to the risk vs hassle tradeoff. Joe's
Bait & Tackle Shop probably isn't getting attacked by nation states who
can hack SS7, so SMS text might be good enough. And certainly better
than just an 8 char plain text password.

Risk/attack surface is part of that context I mention. Folks in
sensitive jobs will need better protection and hopefully be more capable
of using less "user friendly" tech. Folks protecting less and with less
geek background should still have some protection but it doesn't need to
be nearly as fancy.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Ross Tajvar]

Speaking of registrars vs registries - I've noticed some companies have
become their own registrar to improve their domain security (Cloudflare,
Google, etc.). Is that a feasible path for smaller organizations? How much
risk does that mitigate? It seems like it gives the organization control
over more of the domain registration, which allows them to manage things
better than a typical registrar might. But credentials can be compromised
in either case.

Does anyone have any experience with that setup?

On Mon, Feb 25, 2019, 1:49 PM Owen DeLong  wrote:

>
>
> > On Feb 25, 2019, at 09:25 , Paul Ebersman 
> wrote:
> >
> > ebersman> If someone owns your registry account, you're screwed. And
> > ebersman> right now, it tends to be the most neglected part of the
> > ebersman> entire zone ownership world. Let's use this opportunity to
> > ebersman> help folks lock down their accounts, not muddying the waters
> > ebersman> with dubious claims.
> >
> > Reread this and felt I should clarify that I realize that John and Doug
> > are not the ones saying DNSSEC is useless. I just hate to see the knee
> > jerk "oh, see, DNSSEC didn't save the day so it's obviously
> > useless". Let's give the world a better explanation.
>
> @Paul — I think you meant “registrar account” rather than “registry
> account”
> since most domain holders don’t have registry accounts. Registry accounts
> are
> primarily held by registrars. If someone owns a registrar’s registry
> account, then
> all of their customers (and potentially many many others) are screwed.
>
> Owen
>
>

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[valdis . kletnieks]

On Mon, 25 Feb 2019 12:14:59 -0700, Paul Ebersman said:
> ekuhnke> One thing to consider with authentication for domain registrar
> ekuhnke> accounts:
>
> ekuhnke> DO NOT USE 2FA VIA SMS.
>
> Yup. This is a good example of what I'm advocating. Just saying "use
> 2FA" or "use DNSSEC" or "have a CAA" isn't sufficient detail to make
> informed decisions of risk/effort/reward tradeoffs. Simplistic
> suggestions without details or context isn't doing anyone any favors.
>
> That said, even SMS 2FA is better than no 2FA. Barely. Just like forcing
> lousy passwords is better than no password but still not a best
> practice.

Feel free to suggest a workable 2FA.  Personally, I use a Yubikey where I can.
Oath seems to be a reasonable approach for technically minded people, but I'm
not sure that it scales well to the people who own the long tail domains in the
40 million .coms.   I can get oathtool to behave the way I want, but I'm not
sure the owner of joes-bait-tackle-and-gunshop.com will be able to deal with
it.

Unless you get it down to the SMS "wait for a msg, type in the 6 digit number"
level, it's going to be a tough start...

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Paul Ebersman]

ekuhnke> One thing to consider with authentication for domain registrar
ekuhnke> accounts:

ekuhnke> DO NOT USE 2FA VIA SMS.

Yup. This is a good example of what I'm advocating. Just saying "use
2FA" or "use DNSSEC" or "have a CAA" isn't sufficient detail to make
informed decisions of risk/effort/reward tradeoffs. Simplistic
suggestions without details or context isn't doing anyone any favors.

That said, even SMS 2FA is better than no 2FA. Barely. Just like forcing
lousy passwords is better than no password but still not a best
practice.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Paul Ebersman]

ebersman> If someone owns your registry account, you're screwed. And
ebersman> right now, it tends to be the most neglected part of the
ebersman> entire zone ownership world. Let's use this opportunity to
ebersman> help folks lock down their accounts, not muddying the waters
ebersman> with dubious claims.

owen> Paul, I think you meant "registrar account" rather than "registry
owen> account" since most domain holders don't have registry accounts.

Yes. I please ICANN jargon dyslexia brought on by excess blood in my
caffeine stream. ;)

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Eric Kuhnke]

One thing to consider with authentication for domain registrar accounts:

DO NOT USE 2FA VIA SMS.

This is a known attack vector that's been used by SS7 hijacking techniques
for several well documented thefts of cryptocurrency, from people who were
known to be holding large amounts of (bitcoin, ethereum, whatever) on
exchanges which supported 2FA authentication.

In some cases there was no SS7 hijacking going on, but rather social
engineering of (t-mobile, sprint, verizon, at) customer service
representatives to get a new SIM card issued for the attack target's phone.

tl;dr: ss7 considered harmful





On Mon, Feb 25, 2019 at 10:48 AM Owen DeLong  wrote:

>
>
> > On Feb 25, 2019, at 09:25 , Paul Ebersman 
> wrote:
> >
> > ebersman> If someone owns your registry account, you're screwed. And
> > ebersman> right now, it tends to be the most neglected part of the
> > ebersman> entire zone ownership world. Let's use this opportunity to
> > ebersman> help folks lock down their accounts, not muddying the waters
> > ebersman> with dubious claims.
> >
> > Reread this and felt I should clarify that I realize that John and Doug
> > are not the ones saying DNSSEC is useless. I just hate to see the knee
> > jerk "oh, see, DNSSEC didn't save the day so it's obviously
> > useless". Let's give the world a better explanation.
>
> @Paul — I think you meant “registrar account” rather than “registry
> account”
> since most domain holders don’t have registry accounts. Registry accounts
> are
> primarily held by registrars. If someone owns a registrar’s registry
> account, then
> all of their customers (and potentially many many others) are screwed.
>
> Owen
>
>

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Owen DeLong]

> On Feb 25, 2019, at 09:25 , Paul Ebersman  wrote:
> 
> ebersman> If someone owns your registry account, you're screwed. And
> ebersman> right now, it tends to be the most neglected part of the
> ebersman> entire zone ownership world. Let's use this opportunity to
> ebersman> help folks lock down their accounts, not muddying the waters
> ebersman> with dubious claims.
> 
> Reread this and felt I should clarify that I realize that John and Doug
> are not the ones saying DNSSEC is useless. I just hate to see the knee
> jerk "oh, see, DNSSEC didn't save the day so it's obviously
> useless". Let's give the world a better explanation.

@Paul — I think you meant “registrar account” rather than “registry account”
since most domain holders don’t have registry accounts. Registry accounts are
primarily held by registrars. If someone owns a registrar’s registry account, 
then
all of their customers (and potentially many many others) are screwed.

Owen

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Sander Steffann]

Hi Paul,

> Reread this and felt I should clarify that I realize that John and Doug
> are not the ones saying DNSSEC is useless. I just hate to see the knee
> jerk "oh, see, DNSSEC didn't save the day so it's obviously
> useless". Let's give the world a better explanation.

Security is only as strong as its weakest link. No single link can be expected 
to protect the whole chain on its own.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Paul Ebersman]

ebersman> If someone owns your registry account, you're screwed. And
ebersman> right now, it tends to be the most neglected part of the
ebersman> entire zone ownership world. Let's use this opportunity to
ebersman> help folks lock down their accounts, not muddying the waters
ebersman> with dubious claims.

Reread this and felt I should clarify that I realize that John and Doug
are not the ones saying DNSSEC is useless. I just hate to see the knee
jerk "oh, see, DNSSEC didn't save the day so it's obviously
useless". Let's give the world a better explanation.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Paul Ebersman]

dougm> You are right, if you can compromise a registrar that permits
dougm> DNSSEC to be disabled (without notification/confirmation to POCs
dougm> etc), then you only have a limited period (max of DS TTL) of
dougm> protection for those resolvers that have already cached the DS.

johnl> As far as I can tell, that's roughly all of them.  If you have
johnl> the credentials to log in and change the NS, you can change or
johnl> remove the DS, too.

Yes, though with the 1 day TTL most registries put on DS records, you at
least have the chance to notice your DS has changed or been deleted and
attempt to recover your registry account.

That is somewhat a "locking the barn door" approach, and 2FA and other
account security is the best solution. However, we are in a world now
where every layer of security we can add is probably a good idea and
having a day to notice could be handy.

DNSSEC isn't useless but it solves one specific problem, end to end
data integrity. It also requires operational cleanliness and attention
to detail. We shouldn't make claims about what it can't do; we're much
better off getting everyone to understand what it does and doesn't
do. And underline what other security best practices they should be
following.

If someone owns your registry account, you're screwed. And right now, it
tends to be the most neglected part of the entire zone ownership
world. Let's use this opportunity to help folks lock down their
accounts, not muddying the waters with dubious claims.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Hank Nussbacher]

On 25/02/2019 11:37, Ask Bjørn Hansen wrote:



On Feb 24, 2019, at 22:03, Hank Nussbacher  wrote:

Did you have a CAA record defined and if not, why not?

If the attacker got a CA to issue the cert because they changed the DNS server 
to be their own, a CAA record wouldn’t have helped (or at least been even 
easier to thwart than DNSSEC).


Yes if an attacker pwned the DNS then game over no matter what. I go 
under the assumption that the attacker was not able to take over the DNS 
system but rather other things along the way, in which case CAA should 
be of some assistance.


-Hank




Ask

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Tony Finch]

Mark Andrews  wrote:
>
> 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.

Yes (as Mark knows) I would like to be able to use DLV in this enterprisey
way. It should also help validators to continue working for local domains
when external connectivity is funted.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
East Sole, Lundy, Fastnet, Irish Sea: Southeasterly 4 or 5. Rough or very
rough, but slight or moderate in Irish Sea. Mainly fair. Good, occasionally
poor.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Ask Bjørn Hansen]

> On Feb 24, 2019, at 22:03, Hank Nussbacher  wrote:
> 
> Did you have a CAA record defined and if not, why not?

If the attacker got a CA to issue the cert because they changed the DNS server 
to be their own, a CAA record wouldn’t have helped (or at least been even 
easier to thwart than DNSSEC).


Ask

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Måns Nilsson]

Subject: Re: A Deep Dive on the Recent Widespread DNS Hijacking Date: Mon, Feb 
25, 2019 at 05:04:39PM +1100 Quoting Mark Andrews (ma...@isc.org):
 
> 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.
 
One thing that immediately struck me upon reading the Krebs post was
that people got owned by having to downgrade the end-to-end model of
the Internet into Proxy-land. A hotel wifi. Probably only challenged by
"Free Wifi" in other spaces in its ability to demolish the Internet as
thought out and envisioned.
 
We can conclude in two different directions here; 

* We need to work on making the Internet more transparent to applications,
  and thus increasing security.

* We're all doomed anyway. DNSSEC is useless. 

Pick whichever you like. Our children will judge us. 
-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE   SA0XLR+46 705 989668
My EARS are GONE!!


signature.asc
Description: PGP signature

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Mark Andrews]

> 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

[Hank Nussbacher]

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

[Bill Woodcock]

> 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

[Bill Woodcock]

> 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

[Mark Andrews]

ack,” 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://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%7C636866563276432264sdata=%2B6dEhg63cXX3MiBx8tWgFY6zoGmqqSxC1aE3RfOLVqc%3Dreserved=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-endata=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264sdata=WoLoqR%2BPBRd1dKChGSK%2BZpvP15wAZvezmPatgElG8hY%3Dreserved=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" 
> >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://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%7C636866563276432264sdata=A0j0UwTN566qmIwxHeX5FROC6JaMDuccp3ykJSCl8%2Fk%3Dreserved=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 

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Töma Gavrichenkov]

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

[John Levine]

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

[Ca By]

t; 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://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%7C636866563276432264sdata=%2B6dEhg63cXX3MiBx8tWgFY6zoGmqqSxC1aE3RfOLVqc%3Dreserved=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-endata=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264sdata=WoLoqR%2BPBRd1dKChGSK%2BZpvP15wAZvezmPatgElG8hY%3Dreserved=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" 
> >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://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%7C636866563276432264sdata=A0j0UwTN566qmIwxHeX5FROC6JaMDuccp3ykJSCl8%2Fk%3Dreserved=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.
> >
> >
>
>
>
>
>
>
>

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Montgomery, Douglas (Fed)]

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 AC

RE: A Deep Dive on the Recent Widespread DNS Hijacking

[Keith Medcalf]

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"

RE: A Deep Dive on the Recent Widespread DNS Hijacking

[Montgomery, Douglas (Fed) via NANOG]

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.

 

Re: A Deep Dive on the Recent Widespread DNS Hijacking Attacks

[Bill Woodcock]

> On Feb 23, 2019, at 11:13 AM, Keith Medcalf  wrote:
> 
> 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.

It’s Iranian military.  If you want to call them script kiddies, that’s up to 
you, but people familiar with the campaign characterize it as an APT, and have 
been for the several years that it’s been going on.

> the targets perfectly match those that the NSA would choose

Amusing bedfellows, if they weren’t so annoying.

> The second takeaway being that DNSSEC is useless

You seem to have gotten that one backwards, by over-straining yourself in an 
effort to seem clever.

> Did I miss anything?

Apparently, yes.

-Bill



signature.asc
Description: Message signed with OpenPGP

RE: A Deep Dive on the Recent Widespread DNS Hijacking Attacks

[Keith Medcalf]

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.