On 22-Oct-2019 I spoke at Boston Azure about network security and focused on some of the edges of using Azure DNS, and included some DNS subdomain hijacking awareness.
The command
dig CNAME bostonazuredemo.azuresecurely.com +short
will check public DNS records for a CNAME, returning whatever it is mapped to, if anything.
In the above screenshot:
- nothing returned from dig – this is before any DNS entry was created for the demo subdomain
- a cascade of CNAMES are returned from dig – this is after a DNS entry was created for the demo subdomain – and it pointed at an Azure Web App — the cascade here includes my subdomain => an azurewebsites.net subdomain (bostonazuredemo.azurewebsites.net) => a second azurewebsites.net subdomain (waws-prod-dm1-139.sip….) => a cloudapp.net domain => and finally an IP address
- a single CNAME is returned from dig – this is after the Azure Web App was deleted (), but the DNS subdomain entry (bostonazuredemo.azuresecurely.com) was left intact – creating a dangling subdomain at risk of being hijacked — anyone who registered bostonazuredemo.azurewebsites.net (and it was open for anyone) would automatically have bostonazuredemo.azuresecurely.com already wired up to it.
- a cascade of CNAMES are returned from dig – but different than the first – this is after bostonazuredemo.azurewebsites.net was registered again, by a hacker, and bostonazuredemo.azuresecurely.com was hijacked
Some other notes from the session:
- Here’s the heat map from Brian Krebs from the Mirai botnet attack.
- Let’s Encrypt config instructions –
- About DNS: https://www.linode.com/docs/networking/dns/dns-records-an-introduction/
- Managing multiple DNS sources: https://github.com/StackExchange/dnscontrol
- Sample code (nothing interesting): https://github.com/codingoutloud/claimdump/blob/master/ClaimDump/Views/Home/Index.cshtml
Subdomain takeover examples:
Coding Out Loud 