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:
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 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:
So what kind of cloud services are vulnerable, how does the issue arise and what can you do to prevent it?
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’ ?
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:
However, we have now just created the perfect conditions for a hostile subdomain takeover!
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!
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.
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.