[RandomTrees]

The core of the problem, a lot of paragraphs down:

> we have strong evidence that supports our hypothesis that the adversary gained access to our [DNS provider's] credentials through the compromise of a third party provider

> A factor which possibly helped the attacker was that the password had not been changed since 2013

> We chose our DNS provider 18 years ago when 2FA was neither a consideration nor a possibility

[c12]

Slightly off topic but 2FA was both possible and a consideration 18 years ago, just not for the majority of people.

[gpvos]

Did any DNS providers implement it at that time?

[chinathrow]

Correct. Banks in Europe hat various 2FA methods in place, even in the early days of online banking around year 2000.

[kybernetikos]

I was using a simple form of 2FA with my retail bank in Switzerland back in the early 2000s.

[gist]

> but 2FA was both possible and a consideration 18 years ago

You could setup your own dns servers obviously 18 years ago and in fact when starting out in the mid 90's that is exactly what we and many others did. (Criket Liu nutshell books from O'Reilly)

http://shop.oreilly.com/product/9781565920101.do

http://www.oreilly.com/pub/au/284

[pfg]

To clarify, the problem here wasn't with their DNS servers, but rather the registrar being compromised. You could run your own DNS servers and still get compromised like this unless you also happen to run your own registrar.

[astura]

Yeah, that stuck out to me too, I know SecurID has been around since at least the early 2000s.

[pc86]

18 years ago was 1999.

[ams6110]

First time I used a 2FA device was an RSA "Safeword Card" which looked like a small handheld calculator and would display a multi-digit code that changed every minute or so. This was in 1998 and it had been put into use before that.

[mc32]

I think Sun Micro had deployed those to all their engs, perh others too. I think it had a PIN which when entered displayed the code which was valid for a min.

[ams6110]

Yeah, you're right. The rotating number device (with no PIN entry) came later.

[plussed_reader]

You never possessed a bank or credit card prior to 1998?

Isn't the account on the card + your pin 2FA?

[astura]

I'm well aware.

I meant SecurID were fairly well established by the early 2000s for VPN access, from what I remember, so I assume they came around at least a few years earlier, which would be the late 90s, they also weren't the only option on the market.

[bearcherian]

So 18 years of outdated security practices...

[w8rbt]

Most all of the registrars and DNS mgt services support TOTP now for 2FA. If yours does not, move to one that does.

[arthurfm]

It's a shame so few registrars support hardware tokens [1] since those would be better still.

[1] https://twofactorauth.org/#domains

[discordianfish]

To me the biggest question is whether or not TLS was in place. That should prevent the attacker from intercepting the actual data without the victim noticing.

[tomwas54]

No, it doesn't. As mentioned in the article, the attacker successfully requested a TLS certificate for the hostname, which was possible because he could pass a CA's domain validation.

I'm not entirely sure, but I think HPKP could have prevented this for returning customers, because Fox-IT would have been able to pin the key of their own certificate. Then the new certificate used by the attacker would have been rejected by the customer's browser.

[ams6110]

Yes, it more highlights that the simple presence of a valid certificate does NOT guarantee that you are connecting to the service that you think you are.

EV certs would be harder to compromise, but likely not too difficult for a sophisticated attacker. And who really notices if a site that had an EV cert suddenly doesn't? I might for my bank, but likely would not for a software product website.

[da_chicken]

> he could pass a CA's domain validation

What! That's impossible! /s

[jorams]

The post says the following:

> Maximum 10-minute time window during which the attacker temporarily rerouted and intercepted Fox-IT email for the specific purpose of proving that they owned our domain in the process of fraudulently registering an SSL certificate for our ClientPortal.

[tialaramex]

Specifically Comodo reports that they sent their normal validation email to [e-mail] (which unknown to Comodo or Fox-IT at the time was being directed to the attackers). I've never used Comodo's implementation of 3.2.2.4.4 but typically there's an email with a code in it, telling you to go to a web page and paste the code in if you want to authorise the issuance of the requested certificate, or something along those lines.

The security of this validation method (3.2.2.4.4) depends upon

1. You control DNS for your domain including the MX records used to deliver email (this is where Fox-It came undone here)

2. You control the MX servers, or if you have a third party providing backup MX, you trust them not to abuse that

3. The Certificate Authority does a good job of getting accurate DNS records and connecting to the right IP address

4. All email addresses in your WHOIS records plus a handful of famous ones like hostmaster@ postmaster@ are delivered to people you trust in your organisation.