New product update to scan for subdomain takeover vulnerabilities

AppCheck has released a new detection module available to all customers to scan for subdomain takeover vulnerabilities.

What is subdomain takeover?

The term “Subdomain takeover” refers to a class of vulnerability that allows an attacker to hijack an online resource which is integrated with your systems and applications.

In summary, a domain takeover vulnerability can arise in one of the following scenarios:

• DNS records pointing to cloud-based service providers can become orphaned if the service expires, is misconfigured or deleted. If left unchecked, an attacker could register the service with their own credentials and hijack your domain.

• Your own DNS Domains or those used by third-parties could expire, e.g. when an integrated service changes its name or goes out of business. The attacker could then register the expired domain to attack your applications.

• If a resource such as a script is imported using a URL with a misspelt domain, the attacker could register it to take control of your application.

Subdomain takeover attacks have affected some of the world’s largest online organisations including: Uber, Slack and the US Government. (see https://dzone.com/articles/what-are-subdomain-takeovers-how-to-test-and-avoid)

How Can AppCheck help?

AppCheck analyses all hostnames encountered while crawling your web application to determine if a Domain Takeover attack is possible. When a vulnerable domain is identified, a detailed report is provided along with supporting evidence. In cases where no vulnerabilities are found, an audit report is provided to list each tested domain within a table. Where applicable, a domain aging report is also generated to show domains soon to expire along with domains recently registered (a possible compromise indicator).

For an example of the output you can expect from this module, see sections 4.6 and 4.16 in this sample report:

AppCheck_Sample_Report

An Overview of Sub-Domain Takeover Attacks

There are several variants of the flaw which can allow this powerful attack to be overlooked.

Service provider domain takeover

Modern web application deployments, even those that are hosted in-house, will often integrate external components from cloud-based service providers to add functionality or content to the application. Common examples include Amazon AWS, Shopify, Heroku, WordPress, Azure, and GitHub to name a few.

Each of these providers offer a method of integrating their services using a hostname that is consistent with your organisation. For example, rather than hosting a Shopify online shop at https://appcheckshop.myshopify.com , Shopify permits the use of a DNS record to access the same resource at the more recognisable name such as https://shop.appcheck.com.

This is achieved through the creation of a Canonical Name (CNAME) DNS record. CNAME records are used to create an alias to another DNS record, in the case of cloud-service providers, that means an alias in your domain pointing to a hostname at the provider.

For example, to host a Shopify shop at http://shop.appcheck.com the following CNAME record could be created within the appcheck DNS Zone.

shop.appcheck.com       CNAME       shops.myshopify.com

At the provider side, the resource is configured to recognise requests for “shop.appcheck.com” and route to the correct online shop (the original hostname is submitted in the HTTP host header). This method of routing is often referred to as virtual hosting.

The ability to use your organisation’s internet domain not only ensures continuity, but also offers a layer of security since only the owner of the domain is able to create the required DNS record.

The vulnerability

A vulnerability can arise when the configuration held by the service provider is deleted, expires or becomes misconfigured. To continue with the example above, Shopify is able to serve content for the AppCheck shop since it has a configuration entry that lists “shop.appcheck.com” as an alias (virtual host).

However, should this configuration entry (shop) be deleted, the alias will be deleted with it, but the DNS record may remain unchanged. When this happens, accessing the http://shop.appcheck.com URL will return a Shopify holding page.

At this point a Domain Takeover vulnerability is introduced. To exploit the flaw the attacker would create her own account at Shopify and add a domain alias for shop.appcheck.com. Now any future attempts to access http://shop.appcheck.com shop are routed to the attacker’s shop. From there the attacker is able to capture user credentials, deploy malware and capture any information such as cookies which are scoped to the appcheck.com domain.

Many cloud-based service providers are vulnerable to variants of the attack described above including (but not limited to);

Microsoft Azure, Amazon AWS/S3, Bitbucket, Campaign Monitor, Cargo Collective, Fastly, Feedpress, Ghost, Github, Help Juice, Help Scout, Heroku, JetBrains, Shopify, Statuspage, Surge.sh, Tumblr, Unbounce, UserVoice, WordPress and Zendesk

Traditional Domain Takeover

Another variant of Domain takeover can arise when a domain referenced by your systems and applications is allowed to expire. Whilst this is unlikely to occur for your primary domain, it could occur for legacy components such as those referencing an old domain (e.g. following a merger of acquisition) or a third-party component that is no longer in business or has re-branded.

Should this occur, the attacker could exploit the flaw by registering the expired domain to host a malicious component which is then imported by your application.

Additional information

If you require additional information on this release please feel free to contact your account manager or get in touch with us at: info@localhost