Subdomain Takeover in a (charmy) Box
This is not the first time we write about subdomain takeover and probably it won’t be the last. Every time we find a subdomain takeover we ask ourselves “How big is this (assets management) problem?”. This time we decided to answer our own question but we got caught in the rabbit hole where we met Section.io and BoxyCharm by IPSY.
What is Subdomain takeover?
As a rule of thumbs, a subdomain takeover occurs when an attacker controls the content served by a domain or subdomain he does not own. An attacker can achieve this by exploiting dangling DNS records, for instance, a DNS record pointing to an auctionable domain the attacker can buy.
Most of the black magic around subdomain takeover happens at the DNS level. One type of record in the DNS protocol is the CNAME record. The CNAME record is a map between an alias domain e.g. domain-a.com and a canonical domain e.g. domain-z.com, usually owned by two different entities. In this scenario, when entering domain-a.com in a web browser it will in fact show the content returned by the server domain-z.com points to. If domain-z.com is for sale, then anyone can buy and configure it to point to its own server, hence controlling the content shown by domain-a.com.
Sometimes the “delegation chain” is a bit more complex long. Not so rare domain-a.com points to domain-b.com, which in turns points to domain-c.com and so on, until at some point one domain points to domain-z.com.
Impact
A subdomain takeover often leads to malicious content being served by a trustworthy domain. The malicious content can be a very convincing web page/site aimed to steal credentials such as auth cookies, login credentials, or credit card information but it can also be a “simple” JavaScrip script loaded by major websites.
The rabbit hole
To find the answer to our initial question “How big is the Subdomain Takeover problem?”, we took Fortune 500 companies’ digital assets as a sample. We were expecting to see many domains/subdomains pointing to popular cloud providers services but at some point Section.io stood out.
Section.io “is a supercloud on which you can deploy apps, containers, or K8s workloads in the best locations for you, your users and your budget” (source).
The applications will be hosted on Section.io Edge Network on a server whose IP address is dictated by the server’s geolocation chosen by the user when first creating a project. If the user selects the location “London”, the range of IPs that compose the servers hosting the user’s application will differ from the user selecting the location “Los Angeles”.
Deployed applications can optionally be accessed through users-owned custom domains/subdomains. The configuration is done on the Section.io dashboard: the user provides the domain/subdomain name and it is asked to create a CNAME record pointing to an address computed from the given domain/subdomain suffixed with “.c.section.io”. For char49.com it would be char49.com.c.section.io. To complete the process the user has to click the verify button. This verification ensures it is possible to reach Section.io Edge Network through the provided domain/subdomain.
Some cloud provider services with a similar approach are prone to subdomain takeover. Amazon S3 Cloud Object Storage is a well-known one. Maybe Section.io services were also prone to subdomain takeover. Of course we had to dig deeper.
In our quest to find the answer we stumble upon the ftp.boxycharm.com subdomain connected to Section.io Edge Network via a CNAME record pointing to boxycharm.com.c.section.io. It caught our attention because it did not obey the pattern we’ve described earlier: ftp.boxycharm.com was supposed to point to ftp.boxycharm.com.c.section.io. The boxycharm.com domain was properly configured, thus the ftp.boxycharm.com subdomain was ultimately pointing to the IP address configured inside the Edge Network for boxycharm.com. Lucky us, at least at the time, IPSY had a well-established vulnerability disclosure policy.
We’ve tried to access http://ftp.boxycharm.com using a web browser getting in turn a 409 Conflict error message. This error and the DNS “anti-pattern” brought another question to our minds: could we bypass the custom domain verification and control ftp.boxycharm.com from within Section.io?
We created a new Section.io project to deploy a basic web application adding ftp.boxycharm.com as a custom domain to access it. Since ftp.boxycharm.com was already pointing to Section.io edge network the validation succeeded, otherwise we wouldn’t be able to add the required DNS records since we don’t own the domain. Nevertheless, our web application content was not accessible at http://ftp.boxycharm.com. We had to step back to find out what was missing.
We confirmed our application was running properly and accessible as ftp.boxycharm.com connecting to one of the IP addresses assigned to our project and sending manual HTTP requests with the Host request header set to ftp.boxycharm.com. Then, we checked again the ftp.boxycharm.com DNS chain. At this point we noticed none of the IP addresses that ftp.boxycharm.com was ultimately pointing to matched those assigned to our Section.io project. That had to be it!
Now the question was what location was boxycharm at? The ftp.boxycharm.com DNS CNAME chain included a hint: the “lon” in the last CNAME of the chain. Could this mean the location was London?
We changed our project location to “London” and after DNS propagation, the content was served by the vulnerable subdomain. We had full control over the content served by ftp.boxycharm.com.
Attack Scenario
A bad actor could have used the vulnerable subdomain to host a phishing campaign that would allow him to steal private user information such as credentials or credit card information.
For example, bad actors could have created a clone of the official BoxyCharm online store (boxycharm.com) with a login form whose data would be sent to their server. They could have gone even further offering a shopping cart with online payments. All payment attempts would either fail or succeed, but for sure credit card details would end-up on the attacker's controlled server.
Subdomain takeover can also be used to abuse web browser’s Same Origin Policy, allowing authenticated requests (including cookies) to other websites or APIs in the same origin.
Conclusion
Although the BodyCharm subdomain was not pointing to a dangling CNAME record, the way Section.io works allowed us to take control over the content being served.
If you are using Section.io, be careful when creating CNAME chains: remember to assign all the domains in the chain to your Section.io project, otherwise you may fall victim to subdomain takeover.
Timeline
• 2023-05-24 - Security Advisory was sent to IPSY
• 2023-06-06 - IPSY acknowledged the vulnerability offering a $200 bounty
• 2023-07-03 - We’ve challenged IPSY to donate additional $200 to a charity
• Never heard back from IPSYResearch by Francisco Santos, intern at Char49 at the time