Security Tip: Hijacking Domains, the Easy Way?

[Tip#54] Don't leave domains (or subdomains) pointing at servers or nameservers you don't control, or you might get a copy of the email I just received! 😧

Security Tip: Hijacking Domains, the Easy Way?

This morning I received a rather curious email from the “Netcraft Takedown Service”:

Full email from Netcraft regarding a hijacked domain, the link provided in the following text provides all the details available in the email.
Email from “Netcraft Takedown Service” regarding one of my domain names.

The email is pretty self-explanatory and provides a link to the Netcraft security report with more details. Basically, someone has somehow hosted a malicious web shell on one of my domains! Ironically, it also happens to be www.laravelsecurityindepth.com! 😲 🤣

💡
A Web Shell is essentially a hacking toolkit, which allows for complete control over the compromised server, as well as for launching attacks against other sites and servers. They are often part of a botnet or network of compromised sites.

How did they do it?

In many cases, this would be done by hacking the website, but although I own the domain, I wasn’t doing anything with it and it shouldn’t have been pointing at any of my servers. Accessing the root domain directly landed me on a “Welcome to nginx!” page, which made it clear it wasn’t my server (Forge servers have a different default page).

“Welcome to nginx!” default page.

This left two options for what was happening:

  1. Either I’d left DNS configured on my domain, pointing to an IP address I no longer controlled.

This is an incredibly common attack, usually against subdomains. Companies will often create temporary subdomains, point them to the IP address of a server they control on a cloud provider like AWS or DigitalOcean, and then when they are done, remove the server but forget the subdomain. It keeps pointing at the IP, which goes back into the available pool of IPs at that provider. Hackers will identify these open subdomains, and keep creating and deleting servers at the provider until they get the IP they are trying to get. Once they have control of the subdomain, bypassing things like CSRF and CSP is trivial.

  1. Or I’d configured Nameservers on my domain to point to a DNS provider but hadn’t configured DNS.

Another common attack is looking for domains where nameservers are pointing towards a DNS provider, like Cloudflare or DigitalOcean, but the domain owner hasn’t configured any DNS records. The attacker can claim ownership of the domain with the provider, create their own DNS records, and have full control.

I’d done #2! 🤦

The nameservers for laravelsecurityindepth.com were pointing towards ns1.digitalocean.com, but I didn’t have the domain in my account or DNS configured. This meant all the hacker had to do was login to DO, register my domain for DNS, and do whatever they want.

Total rookie move on my part, but also, so incredibly easily to overlook and forget about! It's also, incredibly easy to fix - all I needed to do was switch the nameservers over so it’s no longer pointing towards DO.

The moral of the story: Be careful with your domain names and DNS records. Ensure you set the nameservers on your domains intentionally, and you control the DNS for all of your domains. Also remember to remove old subdomains and DNS records that are no longer in use or needed.

If a hacker can hijack the DNS for a domain name you control, they can damage your reputation and the reputation of the domain itself - making it harder for you to use in the future. If they can hijack a subdomain, they can directly attack your apps.