Anti-Domain-Hijacking on the Cheap

August 25 2017

Your email inbox is your online passport - only more dangerous. For better or worse, it provides a pathway of control for your entire life, both online and increasingly, offline. So, you think to yourself, I will buy my own domain and use it for my primary email address. That way, I’m not tied to a specific email provider over time. Great!

New problem: you are now also responsible for securing control of the domain. Domain hijacking is a thing, and it happens all the time.

To make things worse, the common attack scenarios/targets are spread across different operational areas which means you must mount multiple layers of defence: registrar, nameserver operator, and email provider. You can consolidate providers, but hopefully, seeing the constant DDoS attacks against registrars and NS operators everyone, people are catching on that this is unwise.

Existing Protections

Registrar lock - only protects against registration change (oblivious to zone changes and nameserver changes), can be disabled easily, not supported by all TLDs.

Nameserver lockdown - Very thin support across TLDs, very expensive (e.g. $30/month for .au space), oblivious to zonefile changes.

Brand Protection (e.g. MarkMonitor) - $$$$$

Other 3rd Party Monitoring (e.g. ZoneWatcher or MXToolbox) - only monitoring the zonefile (oblivious to registration/nameserver changes), while not super expensive, still multiples the cost of domain registration over the registration period, disappointing polling intervals, even at high-tier plans.

Protection Stacking - relying on a combination of these is possible, but inelegant (multiple providers) and relatively expensive compared to domain registration fees.

I was a customer of ZoneWatcher for a few months but was not happy with the lack of nameserver registration tracking, they would just exfil the zonefile via Route53/Cloudflare APIs/AXFR etc and do diffs. In other words, it would detect an intrusion into my AWS/Cloudflare accounts, but not to my registrar account(s).

Serverless to the rescue

For the goal of not getting my inbox hijacked, assuming that my email provider secures my actual account to a reasonable level (which I accept for FastMail and Google Mail):

  • Must track: domains point to the intended nameservers
  • Must track: MX record points where I intend
  • Tracking interval must not be long (<1hr)
  • Relatively out-of-band notifying mechanism

For others scenarios, you can sprinkle A, CAA, SOA, whatever records here, it does not matter.

Seems like an obvious candidate for a script. A problem of the past is that reliable script execution means you also need a server or always-online device to run the script - ops and $$$ blowout. Finally a reason to use AWS’ Lambda … yay.

Function

tl;dr; The lambda function is here.

It will do naive resolution attempts against a list of domains, checking their NS and MX, and will report via Pushover.net (or anything you want, its up to implementation) when something has gone wrong. That said, Pushover has a great mechanism where you can set an emergency priority and it will force you to acknowledge the message.

It will generally run in under 300ms for 5 domains (~90th percentile) (which is important since we are being billed per 100ms) and well within the smallest memory allocation for Lambda (128M).

IntervalAvg. Runtime$USD/month (w/o free tier)
1 hour500ms$0.00
1 hour5000ms$0.01
15 minutes500ms$0.00
15 minutes5000ms$0.03
1 minute5000ms$0.47

Even with a highly paranoid run interval and a slow run time, this is absurdly cheap to operationalize.

Some improvements can be made, though unnecessary if you want to keep the complexity down:

  • Don’t do naive (syscall) lookups, query root and authoritative nameservers directly. Only reason this is not done is that Node doesn’t provide those APIs and the pure-Node DNS clients are unmaintained. However, this concern is probably overrated since we get a fresh environment every run.
  • Keep wanted state in a DB somewhere (DynamoDB or Firebase or something) so redeploys are not required.
  • Track ongoing state and history.
  • Generalize across serverless implementations, run in parallel across Google Cloud Functions or something to get multiple views of the zone across different networks.

More generally …

I think that domain protection is definitely underrated, at least, when we compare it to the hype surrounding passwords, email accounts, two-factor authentication etc. At least, underrated in the sense that there are probably market opportunities surrounding it. I think Cloudflare has realized this (as have auDA, given their price gouging .auLOCKDOWN), though their offering isn’t widely available yet.