32

Let’s say:

  1. We buy a domain from http://cheap-unsecure-domains.example.
  2. Then in our control panel at cp.cheap-unsecure-domains.example we configure it to use the Cloudflare service.
  3. We set some MX record at Cloudflare and point them to Google, for example.
  • In theory it should be possible for cheap-unsecure-domains to hijack our MX records answering them by itself instead of referring to Cloudflare. Is this correct?
  • If yes, is there any type of protection against this kind of attacks? Except using something like GPG.

I'm considering possible attacks on the receiving side.

Peter Mortensen
  • 877
  • 5
  • 10
Ravexina
  • 423
  • 4
  • 7
  • 14
    What you describe is exactly what governments/courts use to force a domain takedown - basically legally hijacking your entire domain. This has actually happened several times to botnets, pedophile websites, torrent sites etc. The main reason why services don't do this without a court order is that this would quickly make them unpopular and they'll lose business or get sued themselves. Apart from that there's basically no other protection - it's all based on trust – slebetman May 12 '20 at 18:56
  • @slebetman this is an excellent point. This is why authoritarian governments loath decentralized networks, such as TOR (the onion network), which eliminate the need for registrars, CA's, and DNS - by using addresses that are derived from public keys. The only downside is that the addresses may be somewhat user-unfriendly (e.g. https://www.nytimes3xbfgragh.onion/). – mti2935 May 13 '20 at 15:48
  • 5
    `cheap-unsecure-domains` is hierarchically above you regarding domain administration, so technically, they don't need to _hijack_ something they already control. – Pedro Lobito May 14 '20 at 00:14
  • 2
    You can transfer your domain to Cloudflare so you have fewer companies that you have to trust, it'll probably be cheaper too – lights0123 May 14 '20 at 00:19
  • 3
    @lights0123 - `fewer companies that you have to trust` **that bears repeating**. If you buy a `.us` domain from a UK-based registrar company, and host your web+email in France, at that point _any of those 3 governments_ could hijack your email (with the only caveat being that France's government couldn't _permanently/indefinitely_ commandeer it). – JamesTheAwesomeDude May 14 '20 at 18:11
  • @lights0123 CloudFlare is not currently a registrar in all TLDs, far from it, nor really open to clients outside of their ecosystem for now. – Patrick Mevzek May 14 '20 at 18:13
  • @PatrickMevzek that's true, but the asker says that they already use Cloudflare so they're already part of their ecosystem. – lights0123 May 14 '20 at 18:15
  • A real-life example: my `xyz` domain is vulnerable to _permanent_ seizure by the British government due to this TLD being operated by [CentralNic](http://archive.is/D2Itu); it is **also** vulnerable to _permanent_ siezure by the U.S. Government due to my merely having _registered_ it by [Namecheap](http://archive.is/epn38). If I were actually doing anything of note / political activism / violating social norms / etc., I'd be hosting it in a neutral country such as `se`, with a more-committed registrar (ideally one in the same country). – JamesTheAwesomeDude May 14 '20 at 18:30
  • 1
    @JamesTheAwesomeDude Even without the dependency through Namecheap, it would still be vulnerable to US laws, because the registry is under contract with ICANN, which is an US entity. That makes all gTLDs, in some way, dependent on US laws. It is less clear for ccTLDs but note the historical lawsuit for some to reclaim ccTLDs as part of retribution: https://arstechnica.com/tech-policy/2014/11/judge-sides-with-icann-plaintiffs-cant-take-all-of-irans-domain-names/ Note: it is a decision by a US Federal Judge... – Patrick Mevzek May 14 '20 at 18:46
  • What you described kind of happened already in a big scale even for big players, see: https://arstechnica.com/information-technology/2019/02/inside-the-dnspionage-hacks-that-hijack-domains-at-an-unprecedented-scale/ You should specially look at the end with the list of 7 possible mitigations. DNSSEC is one of them for part of the problem but just one out of 7 and just for part of the problems. See also how even companies deep in the field and hence knowledgeable were using 3 monitoring systems and none of them helped... – Patrick Mevzek May 14 '20 at 18:52

6 Answers6

49

Yes, your registrar can hijack not only your MX records, but your entire DNS.

Not only that - but they can then proceed to intercept mail sent to your domain, get a valid CA-signed SSL certificate for your domain, and host a site for your domain using the trusted SSL certificate. And DNSSEC won't prevent any of this.

One of the primary functions of your registrar is to register the nameservers for your domain. For example, if you do a whois lookup for stackexchange.com, you'll see that the registrar for stackexchange.com is eNom, LLC., and that the nameservers for stackexchange.com are hosted by Google Cloud and Amazon AWS. So, the DNS for stackexchange.com is handled by Google Cloud and Amazon AWS.

In the example that you gave in your question, cheap-unsecure-domains is the registrar for yourdomain.example. With cheap-unsecure-domains, you specified Cloudflare's nameservers as nameservers for yourdomain.example. So, DNS for yourdomain.example is handled by Cloudflare's nameservers. Then, in Cloudflare's control panel, you setup your DNS records for yourdomain.example, including your A records, MX records, etc.

So if cheap-unsecure-domains wanted to intercept your mail - they wouldn't need to hack into your account at Cloudflare to change your DNS records. They would simply change the nameservers for yourdomain.example to their own, then create MX records for yourdomain.example in their nameservers to point to their own mail servers. Then, they would start receiving mail sent to your domain.

Interestingly, they could start receiving mail for yourdomain.example securely using SMTP STARTTLS, without even getting an SSL certificate for yourdomain.example. They could just use their own certificate. See https://blog.filippo.io/the-sad-state-of-smtp-encryption/.

Now, things get more insidious. They can start receiving mail for hostmaster@yourdomain.example (or admin@yourdomain.example, or any of the other designated approved email addresses used for SSL domain validation). Then, they can request a SSL certificate for yourdomain.example from a trusted CA, and when the CA sends the verification link to hostmaster@yourdomain.example, they'll receive it, and the CA will issue the certificate. Now, they can setup an A record for www.yourdomain.example, and run a site with a valid certificate for www.yourdomain.example.

At this point, you might be wondering - can't this type of attack be prevented using DNSSEC? The answer is no. DNSSEC records are stored in the DNS for the domain. When the registrar changes the nameservers for yourdomain.example to their own, the DNSSEC records that you created for yourdomain.example are gone, along with all of the other DNS records that you created. See https://moxie.org/blog/ssl-and-the-future-of-authenticity/ for more info.

Patrick Mevzek
  • 1,748
  • 2
  • 10
  • 23
mti2935
  • 19,868
  • 2
  • 45
  • 64
  • 3
    and there is nothing to stop them ... except that this is noticeable and they will loose reputation as registrar for whaterver TLD we are talking about, and may therefore have their registrar privileges revoked by TLD-owner - if they bother – Hagen von Eitzen May 12 '20 at 21:27
  • 3
    @HagenvonEitzen noticeable only if made at scale or if one is lucky. – fraxinus May 12 '20 at 21:29
  • 1
    @fraxinus Or one is a competent and possibly slightly paranoid admin who is monitoring everything. If this happened to one of my domains, my phone would be blowing up within five minutes. – Michael Hampton May 14 '20 at 01:04
  • Yep. Competent AND lucky. At that level of sophistication of the possible attack, it costs nothing to spoof proper DNS replies for the monitoring host. – fraxinus May 14 '20 at 06:40
  • @fraxinus as long as they know what might be a monitoring host. If the monitoring runs on a server that has a record in the domain they do. But it can run from an unnamed node in some random cloud and then the rogue registrar does not know whether to spoof it or not. Or it can actually request a recursive query on a caching nameserver, whether CF's (1.1.1.1), Google's (8.8.8.8) or the internet provider's. Then the rogue registrar will only know the region, but not specific source of the query. – Jan Hudec May 14 '20 at 07:28
  • 2
    Of course by doing this the registrar is violating the contract and committing serious felony. And since they are not a hard to track cracker, but an identified company, the police and courts should be able to take it from there. Which means avoid registrars incorporated in countries where you don't trust the judicial system or are not sure you could get good legal support. – Jan Hudec May 14 '20 at 07:35
  • As a former SRE for stack Exchange I'm concerned at the NS records you're seeing... You should be seeing Google Cloud and Route 53 as nameservers... – Mark Henderson May 14 '20 at 09:35
  • @MarkHenderson Thanks. I fat-fingered the domain when I did the whois. I've edited my answer to correct it. – mti2935 May 14 '20 at 11:10
  • Would it be worth clarifying that, while a **registrar can permanently hijack** a domain, a `name server provider` (as-phrased in the Question) **cannot**? e.g., if I register my domain with Gandi in Singapore, but I point my NS records at Afraid.org's FreeDNS for quicker updating, this does **not** open me up to _permanent_ siezure by FreeDNS-and-or-USG, just _temporary_ hijacking (assuming I do everything else right.) – JamesTheAwesomeDude May 14 '20 at 18:34
  • " DNSSEC records are stored in the DNS for the domain." Only partially true. DS records are in the parent, not the child. Of course if you control the registrar you can make it send any DS records to the registry, or remove them. – Patrick Mevzek May 14 '20 at 18:50
  • There is no need to control email to issue certificates if you already control the DNS: for DV-certificates validations, http-01 or dns-01 methods are enough and easy to do if you control the DNS – Patrick Mevzek May 14 '20 at 18:50
  • 1
    @JanHudec at least in gTLD world, registrars are accredited by ICANN. Doing something as described here, if ICANN becomes involved would probably mean loosing their accreditations quite fast, and hence not being able anymore to manage domain names. Of course the harm would already have been done and that would prevent only further damages (but the same bandits could then create another entity and restart doing the same thing etc.) – Patrick Mevzek May 14 '20 at 18:53
  • "When the registrar changes the nameservers for yourdomain.example to their own, the DNSSEC records that you created for yourdomain.example are gone" Not exactly true. A registrar can change nameservers as well as DS records at the registry. These can be separate operations, or only one doing both. But just changing the nameservers does not automatically change the DS records, it needs a specific action from the registrar. As for the linked article about "trust agility", this is a problem long "solved", see PGP Web of trust. Which comes with its own drawbacks/limits. – Patrick Mevzek May 14 '20 at 20:01
9

In theory it should be possible for cheap-unsecure-domains to hijack our MX records answering them by itself instead of referring to Cloudflare. Is this correct?

Yes it would be possible for them to do this. Although they can't without you noticing. So you can monitor this.

If yes is there any type of protection against this kind of attacks? Except using something like GPG.

Use a reputable domain registrar, not necessarily a cheap one. Monitor your DNS.

Pedro
  • 3,911
  • 11
  • 25
  • 2
    It's worth noting that registrars are free to implement IP-region-based dns resolution, so they could appear correct to you, while still intercepting emails coming from providers located in another country. Someone will be able to observe it, yes, but a clever hijacker could avoid some obvious surveillance from the person who bought the domain. – daboross May 13 '20 at 10:49
  • Interesting. And good call. – Pedro May 13 '20 at 13:27
  • 2
    @daboross if the NS records in the TLD for the zone delegation point to cloudflair the Registrar cannot mess with their own anycast servers, they would need to change this registration which is hosted by an other NIC or root nameserver, and can therefore be detected. – eckes May 13 '20 at 18:02
  • Oh, true! They wouldn't own the tld. – daboross May 13 '20 at 20:28
  • @eckes but would they? the tld NS records (cheap-unsecure-domains.example) would be held and served by root name servers, though the mentioned subdomain would be referred to by name servers controlled by the domain owner, not the root name servers? I'm sure a few overcomplicated dig commands would be able to clear this. – Pedro May 14 '20 at 08:00
  • 1
    @ Pedro @daboross you seem to both forget that registrar and DNS provider are two different jobs with two different purposes. Both functions can be done by the same entity, but the fact that you register a domain through registrar X, does not necessarily mean that X is your DNS provider. The registrar can technically change any NS and DS records at the parent (registry). The DNS provider can technically change any record in the hosted zone. In both cases, "silent" change of true values is possible. – Patrick Mevzek May 15 '20 at 05:24
  • 1
    @Patrick Mevzek I think @ Pedro's point was that in this case (where the DNS provider is reputable, but the registrar is not) any NS changes need to happen in the TLD authority - and that TLD authority is publicly observable at all times, and not geographically based. So you can always tell if something's changed by checking the TLD's records? – daboross May 18 '20 at 10:49
  • "and that TLD authority is publicly observable at all times, and not geographically based." I do not know what that means. ccTLD, by definition, are geographically based. – Patrick Mevzek May 18 '20 at 14:32
  • I mean that when you request a domain from a TLD server, you get the same set of records regardless of where in the world you request it from. Some name servers implement returning different local IPs depending on who's requesting the data. To my knowledge, no TLD servers do that when returning NS records. – daboross May 19 '20 at 15:00
2

"In theory it should be possible for cheap-unsecure-domains to hijack our MX records. Is this correct?"

This is correct for a domain registrar company that is not reputable and it's security to be considered lackluster! Good companies offer security services and suites for their customers, but this often comes at a cost, hence there are users who frequent other alternatives like these 'cheap-unsecure-domains companies'.

The most common practices to thwart such attacks (hijacking/social engineering/identity theft) would be,

  • The standard good ol' cyber hygiene (strong passwords, two-factor authentication (2FA) on your 'domain control panel' and your domain owner email account)
  • Avoid unreputable domain hosts providers (a good percentage of hijacking comes from exploiting a vulnerability in the domain name registrar's system)
  • Keep your domain details and contact information up-to-date, and set notifications if changes are made (more of a recovery practice).

You've mentioned using Cloudflare as your control panel. They do offer a suite of security services at your disposal. Their DNSSEC might be suited for you.

Peter Mortensen
  • 877
  • 5
  • 10
mallocation
  • 1,668
  • 5
  • 20
  • 5
    In what way does the first and third points help thwart such an attack? Remember we are talking about the registrar hijacking the domain, not a third party. It seems to me that only the first point is helpful here. – Jon Bentley May 13 '20 at 13:18
  • 1
    (*second point is helpful here) – Jon Bentley May 14 '20 at 07:49
  • "This is correct for a domain registrar company that is not reputable and it's security to be considered lackluster!" Absolutely everyone can fail pray to social engineering, no companies is shielded from that. And there has been numerous examples in the past, at various registrars, where someone claiming to be owner of the domain managed, through a call to customer service, to have some changes being done, starting with an email change which then prompts a password reset and then full control. Only registrar or registry lock can defeat that. – Patrick Mevzek May 14 '20 at 20:04
2

They would have to change the upstream nameservers for the domain back to their own DNS-servers, where they could host a copy of your DNS-records with only the MX-record changed. As long as the upstream NS records remain pointed to Cloudflare they can't override only the MX record.

So, you could monitor that your domain's NS records at the upstream registry are still pointing to cloudflare and alert if they're changed.

Martijn Heemels
  • 263
  • 1
  • 7
2

There is one mitigation of this problem: registry lock for your domains.

If you subscribe to this service, changes pushed by the registrar to the registry will NOT be applied until the registry double check, separately, that those changes were indeed called for (by contacting relevant people). This makes any change cumbersome (and is a problem for DNSSEC when you have to rotate your keys at the parent through the DS records) but protects you against a malicious or attacked registrar.

Now some caveats:

  • the name is not even "registry lock" everywhere
  • does not exist with all registries (TLDs)
  • is completely non standard, so each registry will provide a slightly different service; you have to clearly see what is protected (locked). A change in contacts, or a change in the domain of email addresses used by contacts or domain used to name the nameserver can also impact your domain.
  • may be costly
  • has to be initially bought through your current registrar typically (maybe some registries allow to order it directly from them but it would probably be less common), and probably not many of them provide this service.

Some examples in some registries:

It is not known a lot (for various reasons) but is clearly part of the solution for those problems. It is listed among the 7 points of mitigation at https://arstechnica.com/information-technology/2019/02/inside-the-dnspionage-hacks-that-hijack-domains-at-an-unprecedented-scale/, which page shows a recent attack (targeting no less than a DNS provider of root nameservers, through various attacks at the registrar, DNS, and email levels) very similar to the threat you describe.

With a proper registry lock, once your DS records are set, any change anywhere about your name resolution would trigger an error (and thwart an attack)... as long as people are using validating recursive nameservers of course.

Patrick Mevzek
  • 1,748
  • 2
  • 10
  • 23
0

DNS can be altered but most likely you would notice something was amiss. For example if someone caused mail.example.com to resolve to a different IP not controlled by me, without ever compromising the original mail.example.com, then I would be prompted to accept a new key when I authenticated over ssh. Unless they fully compromised the original server and stole the SSH private key. But in that case they don't need to attack my DNS. They already have root. Or at least they already have my ssh user who can sudo.

If you want to make sure your email is not read, you probably need to use public key encryption (such as PGP and GPG) and get your correspondents to encrypt all email sent to you. Then, even if "they", whoever they are, get mail intended for you, "they" will not be able to read it unless they have also stolen your private key somehow.

mkeith
  • 101
  • 2
  • "I would not be able to authenticate with the new mail.example.com" Why? The server could reply that any login+password is ok, hence retrieving your credentials. – Patrick Mevzek May 15 '20 at 05:21
  • I guess that is true for email submission. I would have to already be suspicious but then test it by deliberately submitting the wrong password. That doesn't fit the scenario. But there would be a problem with SSH. They wouldn't have the right key. My client would prompt me to accept a new key and I would know something was wrong. – mkeith May 15 '20 at 07:02