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.

Improve this question
10
  • 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, 2020 at 18:56
  • 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, 2020 at 0: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, 2020 at 0: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, 2020 at 18:11
  • 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: arstechnica.com/tech-policy/2014/11/… Note: it is a decision by a US Federal Judge...
    – Patrick Mevzek
    May 14, 2020 at 18:46

6 Answers 6

Reset to default
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 [email protected] (or [email protected], 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 [email protected], 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.

Improve this answer
13
  • 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, 2020 at 21:27
  • 3
    @HagenvonEitzen noticeable only if made at scale or if one is lucky.
    – fraxinus
    May 12, 2020 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, 2020 at 1:04
  • 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, 2020 at 7:35
  • 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, 2020 at 18:53
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.

Improve this answer
9
  • 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, 2020 at 10:49
  • Interesting. And good call.
    – Pedro
    May 13, 2020 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, 2020 at 18:02
  • 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, 2020 at 5: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, 2020 at 10:49
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.

Improve this answer
3
  • 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, 2020 at 13:18
  • 1
    (*second point is helpful here)
    – Jon Bentley
    May 14, 2020 at 7: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, 2020 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.

Improve this answer
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.

Improve this answer
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.

Improve this answer
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, 2020 at 5: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, 2020 at 7:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .