[Digital Business Africa] – Digital Business Africa vous propose le témoignage de Fredrik N. Almroth, hacker éthique et promoteur de  Detectify, qui, en 2020, a acquis le nom de domaine utilisé dans les délégations NS pour le ccTLD de la République démocratique du Congo (.cd). Il avait alors temporairement pris le contrôle de 50% de tout le trafic DNS pour les sites web utilisant le .cd et aurait pu l’exploiter à des fins malveillants et pour d’autres abus. Son témoignage tel que publié sur son site web : 

Note: This issue has been resolved and the .cd ccTLD no longer sends NS delegations to the compromised domain.

TL;DR: Imagine what could happen if the country-code top-level domain (ccTLD) of a sovereign state fell into the wrong hands. Here’s how I (@Almroot) bought the domain name used in the NS delegations for the ccTLD of the Democratic Republic of Congo (.cd) and temporarily took over 50% of all DNS traffic for the TLD that could have been exploited for MITM or other abuse.

Background

‘Twas the week before Christmas 2020 and I decided to run an analysis of all NS records used by all the TLDs globally. However one thing caught my attention. The domain name “scpt-network.com” had the EPP status code “redemptionPeriod”, which meant that someone had failed to renew their domain (pay their invoice?) in time.

This is quite problematic as the name servers managing .cd are the following:

[email protected]:~$ dig NS +trace cd | grep "cd." cd.			172800	IN	NS	ns-root-5.scpt-network.com. cd.			172800	IN	NS	igubu.saix.net. cd.			172800	IN	NS	sangoma.saix.net. cd.			172800	IN	NS	ns-root-2.scpt-network.com. cd.			172800	IN	NS	sabela.saix.net. cd.			172800	IN	NS	ns-root-1.scpt-network.com. 

So I figured I might as well make a bash script to ping me of any EPP status change of the domain.

To my surprise, about a week or so later, I got a ping that the domain had reached status “pendingDelete”.

I realized the severity of this. The domain name would soon be available for purchase by anyone on the Internet, meaning that the person who gets hold of that domain name would also get the NS capabilities of .cd.

I modified the script, and started probing the registrar on a minute basis for any further status changes.

On the evening of December 30, I got a ping. I opened my laptop and purchased the domain name to keep it from falling into the wrong hands.

As the three remaining delegations pointing to SAIX (the South African Internet eXchange) were still working, the TLD remained operable throughout this time (albeit with a slight performance impact on any domain lookups).

Since I owned scpt-network.com, I could configure any subdomain under the zone at will. If I created a new subdomain (like ns-root-1) with an A-pointer to IP 1.3.3.7, then 1.3.3.7 would get legitimate incoming DNS queries meant for .cd. Any DNS response to those queries would be accepted by the caller.

To not reply would cause the caller to reach a timeout, and the status code SERVFAIL would be assumed. This is good as a SERVFAIL will force the caller to try reaching any other name server (NS record) for the zone (.cd). That is, the caller would eventually hit one of the legitimate SAIX records and be routed appropriately to the correct destination.

Potential impact

Hijacking the country-code top-level domain of a sovereign state has serious negative implications, especially if the domain were to fall into the hands of cybercriminals or a foreign adversary. The Democratic Republic of Congo (DRC) is not a small country. There are roughly 90 million people, not to mention many international companies and organizations operating with a .cd website.

DNS hijacking involving the TLD of an entire country is rare but not unheard of. For example, the ccTLD of the former Soviet Union (.su) has been hijacked by cybercriminals in the past, and the Lenovo and Google websites for Vietnam (.vn) also fell prey to DNS hijacking in 2015. Redirecting DNS traffic from legitimate .cd websites to a phishing site is one clear potential for abuse, but there’s more.

If I had operated with malicious intent, I could have also:

• Passively intercepted DNS traffic
  – which could be used for surveillance or data exfiltration
• Made new domain names “out of thin air”
  – imagine the capabilities if leveraged for Fast Fluxing  
• Launched remote code execution (RCE) attacks on local networks
  – and target companies that use WPAD to query public DNS servers
• Replied to legitimate DNS queries with bogus DNS responses
  – and completely took over targeted apex domains for companies or institutions with a .cd website or even launched a DDoS attack.

For example, I could have crafted an exploit that completely hijacked a specific apex domain under .cd. Let’s imagine that I always reply with NS ns-root-1.scpt-network.com (instead of these four: [ns1,ns2,n3,ns4].google.com) for any NS requests to google.cd. Now the caller will see this, and then carry out any subsequent DNS requests to ns-root-1.scpt-network.com which I control.

This also got me thinking, what if I replied to all NS queries with a reference back to myself. Then for any A question replied with 1.3.3.7, all domain lookups for any apex or subdomain would eventually hit my manipulated A pointer. All subsequent network traffic would then be redirected to 1.3.3.7 and lead in a DDoS attack.

In fact, this would also affect the availability of the entire TLD. 50% of the DNS traffic would become faulty, and the impact of (both) DoS attacks could be amplified by setting a high TTL in the DNS replies.

Taking this a step further, say I were to explicitly target TXT records served for google.cd. Then I would be able to abuse the Let’s Encrypts DNS-01 challenge to issue a valid certificate for google.cd and effectively undermine SSL/TLS communications.

As I could control the NS delegations of any .cd apex domain, and get valid certificates, I would have been able to perform a MITM attack even when SSL/TLS is enforced by the target.

While Google has various counter measures and mitigations for this kind of abuse, it’s safe to say this is not the case for all apex domain names under .cd. Further information on how CA’s verify the ownership of domain names can be found in BR 1.7.3.

Last but not least, with privileged access on an upstream host with DNS control, I could even infiltrate the local networks of companies (redacted in screenshot below) that send DNS lookups for WPAD by monitoring their queries, spoofing a reply, and redirecting the local network caller to download and execute malicious JS-based proxy configuration over the Internet. The WPAD protocol has had its share of issues, including RCE vulnerabilities as discussed by Google’s Project Zero.

Mitigation

On January 7th, I reac