Sign in Subscribe
Newsletter

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! 😧

Stephen Rees-Carter

— 3 min read
Security Tip: Hijacking Domains, the Easy Way?

Greetings my friends! It looks like last weeks security tip on Bypassing CSRF Protection with File Uploads was a big hit, so go check it if you missed it. I had a specific topic planned for this week, but then I received a rather curious email about a security issue on one of my domains, and I simply had to share it with you and pass on the warning.

⚠️ Laravel Security Audits and Penetration Tests → November is almost full, reach out now if you want an audit before 2024! Don’t forget I also offer low-price security reviews, if your budget won’t stretch to a full audit. 🕵️

Subscribe

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 shell1 on one of my domains! Ironically, it also happens to be www.laravelsecurityindepth.com! 😲 🤣

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 server2.

“Welcome to nginx!” default page.

This left two options for what was happening:

  1. Either I’d left DNS3 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.

  2. Or I’d configured Nameservers4 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 about5!

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.

Looking to learn more?
⏩ Security Tip #35: Leaking Data After Changes
▶️ In Depth #12: "Password Generator" Security Audit

  1. 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. ↩

  2. The Forge default pages look different, so it wasn’t pointing to one of my Forge servers. ↩

  3. DNS → Domain Name System, the system which maps domain names to raw IP addresses, allowing devices and apps to find the websites they are attempting to load. You need to manually define DNS records for each domain and subdomain, and where you want them to point. ↩

  4. Nameservers → Records set on the domain name itself, which point towards where the DNS records for that domain is hosted, allowing the DNS to be used to identify the server IP addresses. ↩

  5. Also, incredibly easy to fix. I’ve switched the nameservers over so it’s no longer pointing towards DO. ↩

Read more