Subdomain Takeover - Azure Cloud Service (Classic)

Subdomain Takeover: Azure Cloud Service 

Background Information

What is a subdomain takeover?

The ability to take ownership of a subdomain (IE: xxxx.website.com) due to improper cleanup of CNAME/ALIAS DNS records when removing an external resource. 

You own a company and a domain (suintel.com, for example). You want to leverage hosting a subdomain on an external resource, such as Discourse, Azure, AWS, GitHub, Ghost, etc. To keep the domain name of your company, you create an alias DNS record pointing from azureservice.suintel.com to the DNS of the provider's record. You later decide you don't want to host this resource on this external provider (maybe used it for testing, or no longer use the service) so you decommission the external resource. In doing so, you also release the DNS record of the resource from the provider. 

Many of these external organizations allow users to pick the naming convention of the resource they are provisioning (IE: <your_input>.cloudapp.net), which allows for the use case of a subdomain takeover. If the external provider requires validation of a domain or implements a randomly generated record for your site, then it is not vulnerable to a takeover action (See here for a list of vulnerable external services: https://github.com/EdOverflow/can-i-take-over-xyz). After deleting this resource on the external provider, you need to also remove the ALIAS/CNAME record you created for your domain pointing to this external resource. If this isn't removed, then someone who finds this DNS record pointing to an unused resource can go to that external provider and align the provider's DNS record with the CNAME record your site points to resulting in a subdomain takeover. 

Risks and impact

An attacker owns a subdomain of your root domain. They are able to obtain valid SSL certificates for this domain, which increases the trust of victims using this site in a phishing campaign. This also allows for bypassing other security settings on other components of the said site (CSP, etc) for chaining attacks. Another concern is session cookies scoped to *.suintel.com as an attacker can directly obtain the user's session who navigated to the domain. This generally falls in the CVSS category as 'High', but can also result in a 'Critical' finding as well depending on the impact of the takeover.

Patrick Hudak did an amazing write-up just over the impacts of a subdomain takeover: https://0xpatrik.com/subdomain-takeover/

Subdomain Takeover: Azure Cloud Service (Classic)

Unlike many subdomain takeovers, Azure does not have a generic webpage where you generally search the HTML for common strings (IE: generic 404 errors). Instead, when Azure resources are not provisioned you will see in a 'dig' response only the CNAME in question with no A record. I have found every use case minus CDN endpoints (xxx.azureedge.net) to always result in a takeover scenario if this is true. 

Example response from 'dig azureservice.suintel.com':

;; ANSWER SECTION:

azureservice.suintel.com.     900     IN      CNAME   b8d65842-583f-496c-b943-aaa957dfd3ce.cloudapp.net.

For Azure Cloud Services (Classic) you will see the domain ending in 'cloudapp.net'. If a takeover is possible, you will not see any other entries in the answer section. Our goal after seeing this is to log in to our Azure portal and create a Cloud Service (classic) with a DNS name of  b8d65842-583f-496c-b943-aaa957dfd3ce with the auto-appended cloudapp.net. Once this is deployed you will essentially own the azureservice.suintel.com domain.

As you can see in the image when going to deploy a cloud service, the DNS name being used in the dig is not being used within this service. The next step for showing the proof of concept is where it gets a little more complicated.

At this point, to deploy an actual proof of concept vs. just owning the domain, you will want to generate a generic web application, such as ASP.NET, for display on this page using Visual Studio. Once you create this in Visual Studio, you will need to export the .cspkg and .cscfg files to an Azure Cloud Storage account where you can properly finish step 2 here. 

Once the deployment is finished, you can now do a dig and see an A record at the bottom of the answer section pointing to your cloud service instance. You will also see your webpage listed when visiting the domain you took over from the target organization (IE: azureservice.suintel.com). 

Generic HTML example for a basic proof of concept:

<html><body><p>jbreed poc</p></body></html>