Dangling DNS (part 1) - Abandon and dispair!

Recently, there has been some interesting news describing how attackers have been able to take over various subdomains by taking advantage of dangling DNS records.

To recap, this is a security mis-configuration issue:

  1. A victim organisation sets up (perhaps in a testing scenario) a service on a public cloud provider such as Azure.
  2. The organisation then creates a CNAME pointing an entry in the organisation’s DNS records to the cloud-provider endpoint.
  3. Some time later the organisation then deletes the cloud provider service (it was only temporary after all), but forgets to delete the CNAME.
  4. An attacker comes along, finds the abandoned DNS record, and creates a service in the same cloud provider with the same endpoint DNS name.

Voila! The attacker now owns and controls an endpoint (web site, service, whatever) that is pointed to by the victim’s legitimate DNS records.

So what? Why should I care?

So, what is the harm in that you might say? Well, just ask Epic Games!

Back in March 2020, some of the Epic Games subdomains were hijacked to serve poisoned PDF files. From the user’s perspective, they were downloading documents from a legitimate Epic Games web site but malicious code in the documents (along with other vulnerabilities in the Epic Games infrastructure) may have lead to compromised user accounts for an affiliated mobile app.

The use of a hijacked subdomain for phishing purposes provides a number of clear advantages for attackers:

  • Rather than setting up a completely new (but  related) domain name (e.g. <target_org>-verification.com instead of <target_org>.com) to attempt to trick users, you can take advantage of target users having innate trust in their own domain. Those security-awareness training courses never told you to be suspicious of your own domain right?
  • It’s likely that the target organisation’s mail and web content filters are going to be lenient on content containing URLs using their own domain – indeed they may have explicit policies to whitelist such URLs, lest IT security starts interfering with their business processes!
  • Common ‘low-risk’ application vulnerabilities in the target organisations web applications such as weak Content-Security-Policy headers or use of common domain cookies suddenly become a whole lot more serious when an attacker controls an application which uses your domain.

So what kind of cloud services are vulnerable, how does the issue arise and what can you do to prevent it?

I want to try this!

To take a well-known example (Azure App Services), suppose we want to create a test Azure web application in the Azure portal. The first thing to do is choose a name:

Bummer – ‘test6’ is already taken by someone. What about ‘test61’ ?

Perfect! Now what?

We now proceed to develop our web application and deploy it to Azure under this name. But I don’t want my users to have to hit “https://test61.azurewebsites.net”; instead, I’d prefer them to visit “https://test.dotsec.com”; it’s all about aesthetics you know 🙂

In order to serve your Azure app under a custom domain (such as dotsec.com) you need to prove you own the domain. The typical way to do this is to create a TXT record in your DNS zone with the value provided to you by the Azure portal. The Azure portal will the look up this record using a public DNS server and if it exists, it is considered validated. A similar DNS validation procedure will allow us to generate a certificate from a Certification Authority such as DigiCert.

Once we have all this set up, the final step is to create a CNAME record in our DNS zone which points test.dotsec.com to test61.azurewebsites.net:

Now our app is all set up under https://test.dotsec.com and our users are happy.
 
After  a while, we decide that we no longer need that web app (it was a test application after all) and we delete it in our Azure Portal (to save money), and continue on with our next important IT project.
 

However, we have now just created the perfect conditions for a hostile subdomain takeover!

Enter the dragon!

Attackers targeting your organisation will be constantly trying to enumerate all the hostnames in your DNS zone: they won’t attempt a zone transfer (since it’s almost certain that operation is not possible with your DNS provider – it’s not 1995 after all), rather they will use a bunch of open source sites and freely available tools to find valid DNS records in your zone.

At the end of the day these tools will notice that since you deleted your Azure web app, the DNS CNAME record for test.dotsec.com still points to test61.azurewebsites.net, but the latter hostname no longer resolves. Bingo!   All the attacker now needs to do is to create their own Azure app with the name ‘test61’, and then create a phishing site at test61.azurewebsites.net which will be hit when your users visit test.dotsec.com again! Of course, the attacker must also add the ‘custom domain’ test.dotsec.com to his Azure app service, and to do that he needs to prove domain ownership right ? Well, no – according to our tests, once that particular App Service name has been validated by the original (target) organisation, the attacker does not need to perform any further validation. Thanks Azure!

Someone think of the certificates!

The attacker would prefer those potential victims to visit https://test.dotsec.com, not http://test.dotsec.com – their security awareness training has taught them to look for the padlock right? The attacker cannot use DNS verification to prove domain ownership of dotsec.com because they don’t control the DNS records.

Fortunately, most Certificate Authorities alternatively allow you to prove ownership of a site by placing a text file with well-known content on that site. Since you already control that site, you can put the required content on the site and get your certificate that way.

How do you prevent all this happening in the first place ? You just need to make sure you clean up those ‘dangling’ DNS records that you think are no longer pointing to a real resource. This will prevent attackers from cyber-squatting on your real-estate and putting themselves in prime position to attack your users. Microsoft’s own advice on this matter makes it pretty clear.

The end.... ?

Now,  as we come to the end of our post, you may be thinking that Azure (with it’s simple naming scheme for App Services) is alone in facilitating subdomain takeovers. Unfortunately, there are many cloud services which may potentially be vulnerable. Stay tuned for part 2 of this series of blog posts where we take a look at some vulnerable AWS services which can be targeted by similar methods.