August 1st, 2024

Don't Let Your Domain Name Become a "Sitting Duck"

Over a million domain names are at risk of hijacking due to authentication vulnerabilities in web hosting services. Experts highlight the need for improved DNS management and cooperation among stakeholders to mitigate these risks.

Read original articleLink Icon
ConcernConfusionSkepticism
Don't Let Your Domain Name Become a "Sitting Duck"

New research indicates that over a million domain names, including those registered by major companies, are at risk of being hijacked due to authentication vulnerabilities in several large web hosting and domain registrar services. The Domain Name System (DNS) translates website names into numeric addresses, and issues arise when a domain's DNS records are "lame," meaning the authoritative name server lacks sufficient information to resolve queries. This can occur due to misconfigurations or missing records, allowing cybercriminals to claim control over domains without accessing the legitimate owner's account.

Historically, this vulnerability has been exploited, as seen in a 2019 incident involving GoDaddy, where attackers seized thousands of domains. Recent findings from Infoblox and Eclypsium reveal that these weaknesses persist, with an estimated one million "Sitting Duck" domains currently vulnerable. These domains can be used for phishing, scams, and other malicious activities, with at least 30,000 hijacked since 2019.

The researchers identified three key attributes that make these domains susceptible: delegation of authoritative DNS services to a different provider, lack of information about the domain's Internet address, and exploitable DNS providers. Some hosting companies are working on solutions to mitigate these risks, but experts emphasize the need for better cooperation among stakeholders to address the underlying vulnerabilities in DNS management.

Related

The prevalence, persistence, and perils of lame delegations (2021)

The prevalence, persistence, and perils of lame delegations (2021)

The Domain Name System (DNS) translates domain names to IP addresses. Lame delegations, causing delays and security risks, stem from unreachable nameservers and misconfigurations. Passive analysis detects issues, with 50% in .BIZ domain.

384k sites pull code from sketchy code library recently bought by Chinese firm

384k sites pull code from sketchy code library recently bought by Chinese firm

Over 384,000 websites linked to a code library in a supply-chain attack by a Chinese firm. Altered JavaScript code redirected users to inappropriate sites. Industry responses included suspensions and replacements.

Researchers: Weak Security Defaults Enabled Squarespace Domains Hijacks

Researchers: Weak Security Defaults Enabled Squarespace Domains Hijacks

Researchers found Squarespace's weak security defaults allowed hackers to hijack domains, targeting cryptocurrency businesses. Migration from Google Domains left accounts vulnerable, leading to phishing attacks. Squarespace improved security measures post-incident.

Cloudflare reports almost 7% of internet traffic is malicious

Cloudflare reports almost 7% of internet traffic is malicious

Cloudflare's report highlights a rise in malicious internet traffic, driven by global events. It emphasizes the need for timely patching against new vulnerabilities, notes a surge in DDoS attacks, stresses API security, and warns about harmful bot traffic. Organizations are urged to adopt robust security measures.

Phish-friendly domain registry ".top" put on notice

Phish-friendly domain registry ".top" put on notice

ICANN warned Jiangsu Bangning Science & Technology to improve phishing management for the ".top" domain by mid-August 2024, following its high usage in phishing attacks and inadequate responses.

AI: What people are saying
The comments discuss various aspects of domain hijacking and the vulnerabilities in DNS management.
  • Users express confusion about how domain hijacking can occur despite existing policies and security measures.
  • Concerns are raised about third-party DNS providers allowing unauthorized control over domains.
  • Some commenters highlight the importance of proper DNS zone management and sharding to prevent exploitation.
  • Links to resources and guides on securing domain names are shared, indicating a desire for better awareness and practices.
  • Questions arise about the implications of letting domains expire and the potential for misuse.
Link Icon 12 comments
By @Neil44 - 6 months
So you point your nameservers at a third party, let your account with that third party expire, then someone later on can create an account at third party and resume control of the DNS zone? I mean yeah, but you mustn't care much about the domain and any credibility it has will evaporate quickly.
By @metadat - 6 months
From TFA:

> There is a frequently updated list published on GitHub called “Can I take over DNS,” which has been documenting exploitability by DNS provider over the past several years.

https://github.com/indianajson/can-i-take-over-dns

Whoa, names like Digital Ocean, Google Cloud, Linode, Hurricane Electric - all classified as fully vulnerable.

By @Brajeshwar - 6 months
UK.GOV has a good guide on "Keeping your domain name secure." https://www.gov.uk/guidance/keeping-your-domain-name-secure
By @amiga386 - 6 months
This is how I understand the exploit, can someone please confirm if I have the right idea?

1. I register a domain name -- example.com -- with a registrar like NameCheap. They tell Network Solutions (the .com registry) to add records on my behalf like below, which means the rest of the internet asks NameCheap's nameservers when they want to look up my domain.

    example.com. 172800 IN NS ns1.namecheaphosting.com
    example.com. 172800 IN NS ns2.namecheaphosting.com
2. For no reason, I ask NameCheap to change those NS records to another company's nameservers, such as Hurricane Electric, which I am NOT a customer of

    example.com. 172800 IN NS ns1.he.net
    example.com. 172800 IN NS ns2.he.net
3. Hurricane Electric (HE) are "exploitable"; one of their customers claims to be tranferring a domain to HE, example.com (my domain!), HE doesn't verify the actual ownership and they let it happen.

4. Now this HE customer has control over my domain... because I told my registrar to change the NS records to HE's nameservers. Why would I ever do that?

My understanding is this should never happen, I have no reason why I'd want to make such a change. ICANN have a policy on domain transfer between registrars: https://www.icann.org/resources/pages/transfer-policy-2016-0... -- and transferring a domain should only be done with the gaining registrar (HE in my example) putting an explicit request to the losing registar (NameCheap in my example), and the losing registrar getting to decide yes or no to the transfer.

So... how are there a million or more domains at risk this way? Is it old practises that haven't been corrected? How would this work?

By @everfrustrated - 6 months
Part of this problem is authoritative dns server operators not sharding their zones.

The only provider I know who does this correctly is AWS Route 53. Your zone gets assigned 4 unique authoritative servers from a set of namespaced shards. eg ns-2048.awsdns-64.com

Someone else can create a zone for the same domain but will map to different shard so no real world effect.

Always surprising to me that hardly any providers do it.

By @quicksilver03 - 6 months
I've just launched a DNS hosting provider ( https://www.ptrdns.net ) and this is one of the problems I'm worried about. With the PowerDNS backend I'm using, once a zone is added PowerDNS will respond to queries for its record regardless of the nameserver the queries are sent to. One can, for example, query the IP address of the nameserver to get a response.

The Route 53 technique of assigning random server names looks a bit like the technique of creating virtual hosts in a nginx server, but it looks like this is a custom AWS implementation and not something that comes out of the box in any DNS server software I know.

By @Joeboy - 6 months
Somewhat related question: I have a (obscure) domain that I'm planning to let expire soon. Is there anything I could / should do to stop it being used for questionable purposes?
By @loopdoend - 6 months
Isn’t this the same as the spammy bear attack?
By @octopoc - 6 months
What happens if you set your name servers to e.g. Digital Ocean then go to Digital Ocean and try to add your domain name there but you find that an attacker has already created that domain name under their account? They were watching the name server records on your domain.
By @256_ - 6 months
From TFA:

> DNSMadeEasy founder and senior vice president Steve Job

That name surprised me. I thought it couldn't possibly be real. I looked it up and apparently that's actually his name; presumably no relation to the plural one who ran Apple. Most articles seem to write his first name with an N to make it more believable.

By @StuntPope - 6 months
The Gell-Mann Amnesia is strong in this story and thead.

As I posted on Krebs' article:

This is neither news nor new. There have been prior panics around this “water is wet” type issue going back at least a decade.

(Search up “Floating Domains – Taking Over 20K DigitalOcean Domains via a Lax Domain Import System” – and others).

I also wrote about this on CircleID from the DNS operator’s perspective (“Nameserver Operators Need the Ability to “Disavow” Domains”) – after this same issue was used to DDoS attack another DNS provider by delegating a domain to their DNS servers without having setup an account there, and then doing a DNS reflection attack on that domain. That was over ten years ago.

The fact that people can delegate their own domains to somebody else’s nameservers without ever properly setting up a zone on those nameservers, or ever keeping track of where THEIR OWN DOMAINS point is 100% the responsibility of the domain owner – and to varying degrees a function of their REGISTRAR – who is the only entity that has any control over it.

It’s a weird flex for corporate registrars who purport to be “high touch” and exclusive, to simply shrug their shoulders and turn a blind eye to their own clients’ obviously broken and vulnerable nameserver delegations.

For our part this is specifically one of things we actively monitor and alert our clients about.