Comment on page
Domain/Subdomain takeover
If you discover some domain (domain.tld) that is being used by some service inside the scope but the company has lost the ownership of it, you can try to register it (if cheap enough) and let know the company. If this domain is receiving some sensitive information like a sessions cookie via GET parameter or in the Referral header, this is for sure a vulnerability.
A subdomain of the company is pointing to a third-party service with a name not registered. If you can create an account in this third party service and register the name being in use, you can perform the subdomain take over.
There are several tools with dictionaries to check for possible takeovers:
Recently, I wrote about subdomain takeover basics. Although the concept is now generally well-understood, I noticed that people usually struggle to grasp the risks that subdomain takeover brings to the table. In this post, I go in-depth and cover the most notable risks of subdomain takeover from my perspective.
Note: Some risks are mitigated implicitly by the cloud provider. For instance, when subdomain takeover is possible on Amazon CloudFront, there is no way you can set up TXT records to bypass SPF checks. The post, therefore, aims to provide risks on general subdomain takeover. Nevertheless, most of these apply to cloud providers as well.
To start off, let's look at DNS resolution where CNAME is involved:
DNS resolution
Note that step #7 requests sub.example.com rather than anotherdomain.com. That is because the web browser is not aware that anotherdomain.com even exist. Even though CNAME record is used, the URL bar in the browser still contains sub.example.com. This is the transparency for the browser. If you think about that, the browser places all the trust in the DNS resolver to provide accurate information about the domain. Simplified, subdomain takeover is a DNS spoofing for one particular domain across the Internet. Why? Because any browser performing the DNS resolution on affected domain receives A record set by an attacker. The browser then happily shows whatever is received from this server (thinking that is legitimate).
Such a domain makes a perfect scenario for phishing. Attackers are often using typosquatting or so-called Doppelganger domains to mimic the legitimate domain/website for phishing purposes. After an attacker takes over some legitimate domain name, it is almost impossible for a regular user to tell whether the content on the domain is provided by a legitimate party or an attacker. Let's take for instance a random bank. If one of the bank's subdomains is vulnerable to subdomain takeover, an attacker can create an HTML form which mimics the login form to the bank's internet banking system. Then, an attacker can run spear phishing or mass phishing campaign asking users to log in to and change their passwords. At this stage, the passwords are captured by an attacker who is in control of the domain in question. The URL provided in the phishing e-mail is a legitimate subdomain of a bank. Therefore users are not aware of something malicious going on. Spam filters and other security measurements are also less likely to trigger the e-mail as spam or malicious because it contains domain names with higher trust.
Indeed, the domain name itself place a significant role in a successful campaign. Having 5th level subdomain vulnerable to subdomain takeover is much less "legit" that having a 2nd level subdomain with some friendly subdomain name. I saw several instances of perfect subdomains for phishing, including:
- purchases.SOMETHING.com
- www.SOMETHING.com
- online.SOMETHING.com
- shop.SOMETHING.com
All of them vulnerable to subdomain takeover. All of them were big brands. Talking about perfect phishing?
Nevertheless, recent phishing campaigns host content on domains with long domain names that include name of the brand (see Apple example). Having valid SSL certificate (more on that below), keyword in domain name and website which mimics the website of targeted brand, people tend to fall into these attacks. Think about chances with a legitimate subdomain of this brand.
The attack above can be enhanced by generating a valid SSL certificate. Certificate authorities such as Let's Encrypt allow automatic verification of domain ownership by content verification:
Let's Encrypt Flow
That is, if there is a specific content placed on a specific URL path, Let's Encrypt will approve the issuance of a certificate for a given domain. Since an attacker has full control over the content of the domain which is vulnerable to subdomain takeover, this verification can be done in a matter of minutes. Therefore attackers are also able to generate SSL certificate for such domain which only lowers the suspicion of a phishing attack.
This goes hand-in-hand with browser transparency but has different consequences. Web browser implements many security policies to prevent malicious websites from causing harm. This includes things such as Same-origin policy. One of the primary security responsibilities of a browser is to secure saved cookies. Why? While HTTP is a stateless protocol, cookies are used to track sessions. For convenience, users often save cookies for an extended period to prevent logging in every single time. These cookies, therefore, act as a login token which is presented to the web server and the user is identified. Attacks such as Session hijacking naturally evolved from this concept.
The browser automatically presents stored to cookies with every request to the domain that issued them. There is an exception to that such that cookies might be shared across subdomains (read here, also notice section 8.7). It usually happens when the website uses cookie-based Single sign-on (SSO) system. Using SSO, a user can log in using one subdomain and share the same session token across a wide range of subdomains. The syntax for setting a regular cookie is the following:
HTTP/1.1 200 OK
Set-Cookie: name=value
If this cookie is issued by web server residing on example.com, only this server can access this cookie later on. However, the cookie can be issued for wildcard domain (for the reasons explained above) in the following manner:
HTTP/1.1 200 OK
Set-Cookie: name=value; domain=example.com
The cookie will be included in HTTP requests to example.com but also to any other subdomain such as subdomain.example.com. This behavior creates a possibility of high severity attacks using subdomain takeover. Suppose that some particular domain is using session cookies for wildcard domain. If there is one subdomain vulnerable to subdomain takeover, the only thing for gathering user’s session token is to trick him or her into visiting the vulnerable subdomain. The session cookie is automatically sent with the HTTP request.
The browser also implements additional security mechanisms for cookies:
- HttpOnly cookie — Cookies can by default be accessed by Javascript code running in the context of the website which created the cookies. Javascript can read, update, and delete the cookies. HttpOnly cookie flag (set by the web server) indicates that the particular cookie cannot be accessed by Javascript code. The only way to get it is through HTTP request and response headers.
- Secure cookie — When the cookie has the Secure flag set by the web server, it can be communicated back to the web server only if HTTPS is used.
If the domain is vulnerable to subdomain takeover, an attacker can gather cookies issued by that domain in the past just by tricking users into visiting that website. HttpOnly and Secure flags don't help since the cookie is not being accessed using Javascript and SSL certificate can be easily generated for the taken domain.
Cookie stealing using takeover was explained in bug bounty report by Arne Swinnen. The report explains the problem with one of the Ubiquiti Networks subdomains (ping.ubnt.com). This subdomain was vulnerable to subdomain takeover, pointing to unclaimed AWS CloudFront distribution. Since Ubiquiti Networks is using SSO with wildcard session cookies, all users visiting ping.ubnt.com could have their session cookies stolen. Even though this domain is pointing to AWS CloudFront, CloudFront distribution settings allow logging cookies with each request. Therefore the scenario with extracting session cookies is entirely possible even with subdomains pointing to AWS CloudFront. In 2017, Arne also demonstrated similar attack vector against Uber's SSO system.
The behavior explained above is not limited to cookies. Since Javascript scripts have full control over the websites, they are run on, having ability to replace such scripts on the legitimate website might lead to catastrophic consequences. Suppose that website is using Javascript code from the external provider using script tag and src attribute. When the domain of external provider expires, the browser fails silently, i.e., it doesn't trigger any alerts visible to regular users. If the external code is not doing any important stuff (e.g., it is used only for tracking) such external provider might stay on the website for an extended period. An attacker can take over this expired domain, match the URL path of provided Javascript code and thus gain control over every visitor that visits the original website.
There is, however, one way of protecting the integrity of Javascript files in a browser. Subresource Integrity was proposed as a mechanism to include cryptographic hash as an attribute integrity to script tag in HTML5. When the provided cryptographic hash does not match the download file, the browser refuses to execute it.
When CNAME subdomain takeover is possible, MX records can be set up by an attacker to an arbitrary web server as well. It allows receiving e-mails to a legitimate subdomain of some brand - particularly useful again in (spear) phishing attacks where interaction between an attacker and victim is necessary. Attackers usually spoof
Return-Path header to receive a reply to the e-mail. With correct MX records, this problem is bypassed.On the other side, sending e-mails is also possible. Although it is trivial to spoof
From header to include any e-mail addresses, SPF filters are usually checking Return-Path header and allowed mail-sending hosts for the domain. SPF stores configuration in DNS TXT records. With subdomain takeover, TXT records are in control of attacker too - SPF checks can be passed easily.As I noted in the beginning, these tactics usually don't work with majority of cloud providers since you don't have control over DNS zone directly.
The concept of subdomain takeover can be naturally extended to NS records: If the base domain of at least one NS record is available for registration, the source domain name is vulnerable to subdomain takeover.
One of the problems in subdomain takeover using NS record is that the source domain name usually has multiple NS records. Multiple NS records are used for redundancy and load balancing. The nameserver is chosen randomly before DNS resolution. Suppose that the domain sub.example.com has two NS records: ns.vulnerable.com and ns.nonvulnerable.com. If an attacker takes over the ns.vulnerable.com, the situation from perspective of the user who queries sub.example.com looks as follows:
- 1.Since there are two nameservers, one is randomly chosen. This means the probability of querying nameserver controlled by an attacker is 50%.
- 2.If user's DNS resolver chooses ns.nonvulnerable.com (legitimate nameserver), the correct result is returned and likely being cached somewhere between 6 and 24 hours.
- 3.If user's DNS resolver chooses ns.vulnerable.com (nameserver owned by an attacker), an attacker might provide a false result which will also be cached. Since an attacker is in control of nameserver, she can set TTL for this particular result to be for example one week.
The process above is repeated every time the cache entry expires. When an attacker chooses to use TTL with high value, the false result will stay in DNS cache for that period. During this time, all requests to sub.example.com will use false DNS result cached by an attacker. This idea is even amplified when public DNS resolvers (e.g., Google DNS) are used. In this case, public resolvers are likely to cache the false results which means that all users using the same DNS resolver will obtain false results until the cache is revoked.
In addition to control over the source domain name, control over all higher-level domains of source domain name is gained as well. That is because owning a canonical domain name of NS record means owning the full DNS zone of the source domain name.
In 2016, Matthew Bryant demonstrated a subdomain takeover using NS record on maris.int. The .INT top-level domain is a special TLD, and the only handful of domains are using it. Bryant showed that even though registration of such domain names is approved exclusively by IANA, nameservers can be set to arbitrary domains. Since one of maris.int nameservers was available for registration (cobalt.aliis.be), subdomain takeover was possible even on this restricted TLD.
Matthew also demonstrated even higher severity attack where he was able to gain control over nameserver of .IO top-level domain. Gaining control over .IO means controlling responses for all .IO domain names. In this case, one of .IO nameservers were ns-a1.io which was available for registration. By registering ns-a1.io Bryant was able to receive DNS queries and control their responses for all .IO domains.
The mitigation strategies for domain names already vulnerable to subdomain takeover are rather straightforward:
- Remove the affected DNS record — The simplest solution is to remove the affected record from the DNS zone. This step is usually used if the organization determines that the affected source domain name is no longer needed.
- Claim the domain name — This means registering the resource in particular cloud provider or a case of a regular Internet domain, repurchasing the expired domain.
To prevent subdomain takeover in the future, organizations should change the process of creating and destructing resources in their infrastructure. In case of resource creation, the DNS record creation has to be the last step of this process. This condition prevents DNS record to be pointing to a non-existing domain at any point in time. For resource destruction, the opposite holds: DNS record needs to be removed as the first step in this process. Tools such as aquatone include checks for subdomain takeover. The checks should be periodically performed by a security team of an organization to verify that there are no vulnerable domains. Processes for central collection of exposed domain names are often not efficient inside organizations (due to global teams, etc.) and external monitoring is usually the best way to go.
Mitigation strategy for cloud providers should be considered as well. Cloud services are not verifying the domain ownership. The reason behind this is primarily convenience. Cloud provider is not introducing any vulnerability by not verifying ownership of a source domain name. It is therefore up to the user to monitor its DNS records. Another reason is, that when cloud resource is removed, the user is usually no longer a customer of that service. The question cloud providers then ask themselves is: Why should we even care?
Providers such as GitLab realized that subdomain takeover is an issue and implemented a domain verification mechanism.
Until next time!