- 12.08.2021 The video of the talk presented during Usenix Security has been published!
- 12.08.2021 We have been interviewed by The Daily Swig!
- 02.07.2021 Our research has been covered by The Register and other newspapers. Check out the media coverage section.
- 12.04.2021 Shopify Fix
Shopify fixed the www redirection issue. As of April 2021, the www subdomain of a shop cannot be claimed by another shop. The inverse is still intentionally allowed: if the www subdomain is registered first, any other shop can claim the non www-prefixed version.
Introduction
A related-domain attacker is a web attacker who controls a malicious website hosted on a sibling domain of the target web application. For instance, when reasoning about the security of www.example.com, one might assume that a related-domain attacker controls test.example.com. The privileged position of a related-domain attacker endows it, for instance, with the ability to compromise cookie confidentiality and integrity, because cookies can be shared among domains with a common ancestor.
A key observation is that a related-domain attacker shares the same site of the target web application (example.com in this case). The notion of site has become more and more prominent for web security over the years, going well beyond cookie issues. For example, the Site Isolation mechanism of Chromium ensures that pages from different sites are always handled by different processes: this mitigates the leakage of cross-origin data via memory disclosure and renderer exploits, including attacks based on Spectre. Moreover, major browsers recently changed their behavior so that cookies are only attached to same-site requests by default, which further differentiates related-domain attackers from web attackers.
Organizations owning a large number of subdomains might suffer from incorrect configurations, which allow an attacker to make subdomains resolve to malicious hosts. This problem, called subdomain takeover, is a serious and widespread security risk that received attention also from the general media. In this work, we quantify subdomain takeover issues at scale, and we measure their impact on web application security.
In particular, we enumerate more than 26 million subdomains of the top 50,000 websites and discover practically exploitable vulnerabilities in 887 sites, for a total of 1520 subdomains, including major websites like cnn.com, nih.gov, harvard.edu, and cisco.com. We also study the security implications of third-party service providers and dynamic DNS services, employing known and novel subdomain hijacking techniques. We then show how these vulnerable subdomains can be exploited to compromise same-site web applications by focusing on attacks against cookies, bypasses of web security mechanisms, and abuses of JavaScript APIs, concluding that related-domain attackers have a considerable gain over traditional web attackers.
The Related-Domain Attacker
More precisely, two domains are related if they share a suffix that is not included in the Public Suffix List (PSL). The suffixes listed in the PSL are called effective TLDs (eTLDs) and define the boundary between names that can be registered by individuals and names that are private. Domains sharing the same eTLD+1 are said to belong to the same site.
A related-domain attacker operates a malicious website that is hosted on a related domain of the target website. The attack vector exploited to acquire a related-domain position is not a detail, but has an impact on the capabilities granted to the attacker. While full control of the host grants the attacker the ability to configure the web server to host arbitrary content, other attack scenarios only grant more limited power. For example, exploiting a reflected XSS on a subdomain of a company poses several restrictions on the actions that can be undertaken by the attacker. To precisely characterize the power of the related-domain attacker, we introduce a fine-grained definition based on the acquired capabilities and the associated web security threats.
| Capability |
Description |
headers |
access and modify HTTP headers |
js |
arbitrary JavaScript code execution |
html |
alter the markup of the website with the exclusion of JavaScript |
content |
alter the textual content of the website with the exclusion of embed tags,frames and JavaScript code |
file |
host arbitrary files |
https |
operate a website under HTTPS with a valid certificate |
Note
js subsumes both html and content, since it is possible to edit the DOM by using JavaScript.
Similarly, html subsumes content.
Evaluation
We performed a large-scale vulnerability assessment of the top 50,000 sites of the Tranco list to measure the pervasiveness of the threats, first by identifying subdomains of websites that are vulnerable to a takeover, and second by evaluating the security implications on web applications hosted on related domains of the vulnerable websites. Our methodology is based on the pipeline summarized below.
The likelihood of a site to be vulnerable to a subdomain takeover is directly related to the breadth of its attack surface, i.e., the number of subdomains discovered during the enumeration phase. Furthermore, sites in top positions are more likely to have a vulnerable subdomain than those with a lower rank. The sites have been further partitioned into categories: academic institutions generally have complex and heterogeneous public-facing IT infrastructures that translate into a high number of subdomains. By restricting the analysis to the .edu sites, the percentage of domains with at least one vulnerable subdomain is 7.32%, which is substantially higher than any other observed TLD.
Our web security analysis aims at quantifying the number of domains hosting web applications that can be exploited by taking over the vulnerable domains discovered by RDScan. In particular, for every site with at least one vulnerable subdomain, we selected from the CommonCrawl dataset the list of the 200 most popular related domains. For each related domain, our crawler visited the homepage and up to 5 other pages to analyze security implications of 5 different web mechanisms.
| Mechanism |
Threats |
Summary |
| Cookies |
Domain cookies are leaked to subdomains (confidentiality). Cookies can be shadowed from subdomains (integrity). |
81% of the sites have confidentiality issues, possibly leading to session hijacking attacks. 99% of the sites have integrity issues that might introduce session fixation attakcs, CSRF, etc. |
| CSP |
Policies might have milder restrictions on related domains and allow for content inclusion or framing. |
Most policies are broken and provide no protection against web attackers. A RDA can void the protection mechanism on 139 additional domains compared to a standard web attacker. |
| CORS |
Server-side policies which might allow for bypasses of the Same Origin Policy (confidentiality) from compromised subdomains. |
The related-domain attacker can read cross-origin data on +11% overall websites compared to the standard web attacker. In the case of cross-origin requests with credentials, the percentage raises to +54%. |
| postMessage |
Due to lax or missing origin checking, the postMessage API might use untrusted messages into dangerous sinks (e.g., code execution). |
No instances that are exclusively exploitable from related domains. Origin validation is either correct or missing, so a web attacker has the same power of a related-domain attacker. |
| Domain relaxation |
The legacy API document.domain allows to disable the Same Origin Policy when the target and a related-domain set its value to a common ancestor. |
59% of the domains using the document.domain mechanism are exclusively exploitable by a related-domain attacker. Critical vulnerability which allows to bypass all web security boundaries. |
Third-Party Services
Third-party services are widely used to extend the functionalities of a website. Organizations can integrate external platforms by making them accessible under one of their subdomains. For instance, blog.example.com could be a blog hosted by WordPress and shop.example.com could be an e-shop run by Shopify. Mapping a subdomain to a service is typically a 2-step procedure that requires to 1) create a DNS record for the subdomain, so that it points to the service provider (e.g., WordPress), and 2) claim the ownership of the subdomain in the administration panel of the service. If the service provider does not verify the domain ownership explicitly, an attacker can takeover any unclaimed subdomain with a valid DNS record in place, which is usually referred to as dangling DNS record.
We manually evaluated 26 service providers against the following security pitfalls: wildcard, the domain ownership verification allows attackers to claim subdomains of an already mapped domain, e.g., due to the presence of a wildcard DNS entry; redirect, if the www subdomain of a mapped domain automatically redirects to the parent domain, e.g., www.shop.example.com redirects to shop.example.com, whether the former can be claimed by a different account; PSL, if the service allows users to create a website under a specific subdomain, whether the parent domain of the assigned website is included in the PSL.
| Service |
Wildcard |
Redirect (www) |
PSL |
Capabilities |
| agilecrm |
|
|
|
js https |
| anima |
|
|
|
js https |
| campaignmonitor |
|
|
|
content |
| cargo |
|
|
|
js |
| feedpress |
|
|
|
html |
| gemfury |
|
|
|
file https |
| github |
|
|
|
js file https |
| helpscout |
|
|
|
js file https |
| jetbrains |
|
|
|
content |
| launchrock |
|
|
|
js https |
| ngrok |
|
|
|
js file headers https |
| persona |
|
|
|
js https |
| pingdom |
|
|
|
js |
| readme.io |
|
|
|
js https |
| shopify |
|
|
|
js https |
| smartjobboard |
|
|
|
js https |
| statuspage |
|
|
|
js https |
| strikingly |
|
|
|
js https |
| surgesh |
|
|
|
js https |
| tumblr |
|
|
|
js file https |
| uberflip |
|
|
|
js https |
| uptimerobot |
|
|
|
content |
| uservoice |
|
|
|
js https |
| webflow |
|
|
|
js https |
| wordpress |
|
|
|
js https |
| worksites |
|
|
|
js https |
Notation
- service is not affected
- service is vulnerable
- the conditions of redirect and PSL do not apply
- could not evaluate, e.g., due to payment required, no public registration form, etc.
Helpscout allows to host only arbitrary active content files (JavaScript, CSS); Gemfury allows to host only arbitrary passive content files (images, media, …); Launchrock implicitly associates every subdomain to the mapped domain, not only the www subdomain.
The adoption of the PSL across 5 different dynamic DNS providers is shown in the following table, along with the number of domains that a user can choose from.
| Service |
# Domains |
PSL |
| afraid (FreeDNS) |
52443 |
0/52443 |
| duckdns |
1 |
1/1 |
| dyndns |
293 |
287/293 |
| noip |
91 |
85/91 |
| securepoint |
10 |
10/10 |
You can reach us via mail or twitter:
FAQ
Unfortunately, this is not a straightforward task: except for aliases (CNAME) to expired domains, which can be easily detected by the occurrence of an error in the DNS name resolution process, the other vulnerabilities are much harder to spot. In the case of discontinued services, for instance, the DNS records resolve correctly but the domain name on the service platform is not bound to a valid account and can therefore be claimed by any registered user.
We suggest reviewing all the DNS records of type CNAME pointing to external domains, and all A/AAAA records pointing to IP addresses that are not directly controlled by your organization, e.g., those of services and cloud providers. If any of the pointed resources are not used anymore, you should remove the corresponding DNS entries to avoid takeover vulnerabilities.
While this may be a rather simple task for smaller organizations, maintaining an updated list of active subdomains can be a very complex task in large organizations comprising hundreds of different web applications, where requirements may change rapidly and resources are managed by several people. This indeed explains the pervasiveness of takeover vulnerabilities in the wild.
The attacker manages to host arbitrary contents on a domain that may be perceived as trustworthy by the users and/or by the developers of web applications hosted on related domains of the vulnerable one.
Users’ trust can be abused in different ways, e.g., to conduct phishing campaigns or to distribute malware from an apparently legitimate website. Moreover, developers may write security policies that enable a related-domain attacker to perform attacks that were otherwise impossible to conduct from a cross-site position. For instance, a CSP policy could allow for the inclusion of JavaScript from related domains but not from arbitrary websites as a way to mitigate XSS vulnerabilities.
Finally, some security mechanisms implemented by web browsers adopt the notion of site (rather than origin) as security boundary (e.g., Same-Site cookie attribute, Site Isolation), hence they can be trivially bypassed by an attacker sitting on a related domain of the target.
As a web developer, you can write security policies according to the least privilege principle, that is, restrict the attack surface as much as possible. For instance, if your application hosted at www.example.com requires scripts from cdn.example.com and static.example.com, the corresponding CSP directive script-src should specify exactly these two domains instead of relying on wildcards, such as *.example.com. Even better, the CSP should be based on nonces or hashes since allowlist-based CSPs can be often bypassed.
However, there are no mitigations that can protect from abuses of the, nowadays obsolete, document.domain API: in such a case, you need to refactor the web application and use the safer postMessage API, which may require some non-negligible effort.
Finally, you should consider the usage of the __Host- cookie prefix if the cookies set by your web application do not need to be shared with other related domains.
Yes. Besides disclosing the security vulnerabilities found on service providers, we also reported all the subdomain takeover vulnerabilities discovered during our study when we could identify a security point of contact from bug bounty programs, the security.txt file, the abusix database, and whois information. Our disclosure campaign yielded better results compared to previous studies on large-scale vulnerability disclosures. The remediation ratio across the informed parties 6 months after the disclosure corresponds to 31% of the vulnerable subdomains (22% of the vulnerable sites). Notice that in several cases, sites fixed only a subset of their vulnerable domains, remaining thus vulnerable to related-domain attacks. The subset of sites for which we could not identify a security point of contact has been handled by our national CERT. Please refer to the Appendix A of our research paper for further details.
