by In this case we are going to work with a subdomain takeover in Zendesk as it’s a very common vulnerability in Bug Bounties and it could seem less dangerous compared to services likes S3, Heroku, etc.
First of all, as you might know it’s possible to inject JS code in the theme of the Zendesk Help Center. This will automatically trigger for example XSS on the main URL which is very interesting but also introduces other possible attack vectors.
The main objective of our research is to be able to send and receive mails from the vulnerable subdomain (e.g. [email protected]) with as much security validations (DKIM, DMARC, SPF) as possible to try to bypass the SPAM filters.
We will use GSuite, the Google service for business email which fits very well with our requirements, as it’s used in most of the organizations. Also their process of validation of the domain is compatible with our attack.
In GSuite we have three different ways to validate a domain:
- TXT record in the DNS.
- Upload an .html file in the / path.
- Include a meta-tag in the head of the main page.
In our case we will include meta-tag generated by GSuite in the head of the main page which in the case of Zendesk it’s possible to add it in the Help Center (Customize Design –> Templates –> document_head.hbs).
After enabling the Help Center, GSuite will be able to authenticate your subdomain and therefore you’ll be able to log in and start playing.
We have to consider that the severity of the attack will vary regarding to the configuration of the DNS of the organization.
Sending emails:
By default if it doesn’t have any DKIM signature, Google adds it automatically and the DKIM will PASS with domain (example.gappssmtp.com).
The DKIM won’t be PASS with the real subdomain as it will be necessary to include the key in the DNS records.
SPF by default will be SOFTFAIL.
If the DNS using a wildcard for the TXT SPF record with including _spf.google.com (GSuit) will be PASS.
If the DNS is using a wildcard with a CNAME to the main domain (redirect all the subdomains to the main page) and the main domain has the TXT SPF record with including _spf.google.com (GSuit) the SPF will be PASS.
DMARC by default won’t be found and therefore not applied, which is not bad if the SPF is SOFTFAIL.
If the domain aligned of DMARC is configured in a relaxed way, it will be a PASS for subdomains.
The problem about DMARC is that failures could be reported by email and be discovered.
Received email headers:
Received email with the hijacked subdomain:
Receiving emails:
By default it won’t be able to receive the Google mail servers are not configured for the subdomain.
If the MX records are configured with a wildcard we will be able to receive emails in our hijacked subdomain.
Another options could be if a wildcard is configured for all the subdomains (CNAME to the main domain) to forward to the main domain where it’s configured the MX server with the Google mail servers.
MX records of Google mail servers:
Inbox of the hijacked subdomain:
All this scenarios might seem very rare, but they are more usual than you think, specially when you mix CNAMEs and wildcards.
The best case scenario is a website redirecting (CNAME) all the subdomains to the main domain where GSuite is configured but as you imagine even if they have this wildcard the CNAME of the subdomain takeover will be pointing to the 3rd party service (Zendesk) in this case. So, the strategy will be to register the GSuite business email, report the subdomain takeover and expect that they remove the DNS record of the CNAME. Once this happens, we will maintain the validation of the domain in GSuite and the redirections to the Google mail servers for example will take effect 🙂
I know that it’s nothing new but the objective of this post was to show how the severity of a vulnerability could increase with some DNS configurations that are present in for example some of the Alexa top 100 domains.