First Happy new year to fellow Hackers,

I was planning to write on my blog regularly for the last few months, but I could not do that due to my lack of time and laziness. So here’s a new year gift for you guys ?

Back in October 2022, I was testing a really old private program on HackerOne and they were running a bug bounty program when I started my journey on this platform. So I thought let’s take a look at this target.

Their scope was *.target.com and you know what to do next! After doing Subdomain Enumeration I always check all subdomains based on the below points –

• Print all DNS records. I mostly use – for sub in $(cat subdomains.txt);do dig $sub +noquestion +noauthority +noadditional +nostats | grep -wE "CNAME|A"
• Print live subdomain titles and status codes. I mostly use – cat subdomains.txt |httpx -status-code -content-length -title -tech-detect -follow-redirects

Nothing special caught my attention. But few of the subdomains were pointing to <subdomain>.target.info and this time I passively enumerated subdomains for this .info TLD from project sonar FDNS datasets as this .info TLD is not listed in the target’s scope and I don’t want to create any unwanted incident. Also, I was only interested to take a look at this .info TLD as the program scope was a wildcard and I know most of the wildcard programs accept DNS Hijacking issues for any of their assets. Then I noticed two of the subdomains are pointing to the CNAME record custom-domains.qwilr.com

This caught my attention as visiting these domains was responding like the below screenshot – 

This error looks suspicious. So I quickly googled available docs on Qwilr’s custom domain setup and I found this page where they mentioned only enterprise plan users can set up a custom domain. I registered a trial account and tried to use the custom-domain feature from https://app.qwilr.com/#/settings/ and it always gives a popup like the below –

So no way to check if our target’s subdomains were actually claimed or not. While I was quitting on this I noticed they have the option at https://app.qwilr.com/#/settings/subdomain to get a subdomain of your choice like <your_subdomain>.qwilr.com and serve your pages on that subdomain. 

As you can get a subdomain of qwilr.com and the custom domain setup required CNAME record is  custom-domains.qwilr.com which is also a subdomain of that domain, so what will happen if I can claim this custom-domains prefix from my trial account? Most of the time if vendors offer such subdomains as services they blacklist or reserve a few keywords like admin, support, app, login, etc for their usage or security purposes. But in the case of Qwilr’s they didn’t take any such steps that allowed me to use the custom-domains prefix from my trial account.

We all know CNAME records can be used to alias one name to another and our target subdomain’s CNAME is custom-domains.qwilr.com which is claimed by me and I can serve contents on it. So technically my Qwilr pages should be accessible from all domains which are pointing to the CNAME unless there is any additional configuration in place in the backend.

So I created a PoC page from https://app.qwilr.com/#/pages and copied the shareable URL what looks like https://custom-domains.qwilr.com/0xPrial-3tI11SSQiC5z. The next thing I did was replaced the subdomain with <subdomain>.target.info and visited the URL and boom –

Again I replaced the subdomain with the other subdomain partnerships.target.info and it’s also reflecting my PoC.

So I again used the project sonar FDNS datasets to look for all DNS records that are pointed to CNAME  custom-domains.qwilr.com 

300+ subdomains using that record and I confirmed all of them are vulnerable and I can access my PoC from all of those subdomains. A few of the PoC are listed below –

I created two submissions on HackerOne and they Triaged both reports and forwarded the issue to the Qwilr support team immediately. I also forwarded this to a few other bug bounty programs and one of them confirmed they have an active working service. So this proves I can hijack and serve my PoC content on both claimed and non-claimed subdomains.

Another program replied with additional info that confirms my theory –

Timeline

• Discovered the vulnerability – 25 October, 2022 
• Created HackerOne Submissions – 25 October, 2022
• HackerOne Triaged both reports – 26 October, 2022
• Created other Bug Bounty Submissions – 27 October, 2022
• The vulnerability was Fixed By Vendor – Nov 01, 2022
• Both HackerOne report was rewarded – Nov 09, 2022
• Got a few rewards & cool swags from other programs.

Remarks

• Never test OOS assets actively. If you want to do it ask for proper permission and try to reduce the noise.
• Never test a 3rd party vendor unless they have a responsible disclosure policy.
• Always read 3rd party vendor docs and look into all options of their services.
• Think out of the box.

./logout