Here we address the basic issues of the Subdomain Takeover vulnerability and examine how this vulnerability existed in the cafebazaar and is now patched.
Cafe Bazaar is an Iranian Android marketplace founded in April 2011, In April 2019 Cafe Bazaar announced it has surpassed 40 million users.
Subdomain Takover is the process of registering a non-existent domain to acquire all existing domains, if this vulnerability is discovered, the main domain as well as all subdomains of an organization will be compromised. (kind of)
To make the point more clear, let’s look at a basic topic in DNS.
Canonical Name Record is one of the DNS capabilities to build a pointer domain to another domain, so what does this mean? What is it good for?
Consider the following scenario for example
Consider that cafebazaar intends to launch a campaign for a limited time to receive user feedback about their organization’s website, now to design a survey form, you would prefer to use a survey form a third party system that has ready-to-go survey form templates. And it works in such a way that after registering in the website, you can easily design a survey form and then you can choose a domain address, but this domain is a subdomain of that company, for example, if the formmakers website address is formmakers.com and you create an account for yourself in that system and choose a username name, such as cafebazaar youre form will be available ar cafebazaar.formmakers.com website.
Using CNAME is useful here, you can create a CNAME record on your DNS server and say that every user who applied for form.cafebazaar.ir should be referred to cafebazaar.formmakers.com, but the difference is with redirecting the user.
The difference is that it is true that the displayed content belongs to the address cafebazaar.formmakers.com, but the address shown in the browser is form.cafebazaar.ir, and this issue increases the credibility of the organization and creates more trust for the user. See the iamge below:
As you can see in the image above, I designed the process of entering the address form.cafebazaar.ir in the browser until the final result in the image above.
Now that we understand the importance of the CNAME record and the rest is story, let’s look at how the vulnerability arises.
Follow the previous scenario we talked about. Now, cafebazaar will end its campaign and delete its account in the online form maker website, formmakers.com, and from now on, when people enter the address form.cafebazaar.ir Because the form-creating account related to the address cafebazaar.formmakers.com has been deleted, users will encounter the error “there is no such form-building account” and the site formmakers.com says that there is no such domain as cafebazaar.formmakers.com.
If you remember, at the beginning of the article we said that:
Subdomain Takover or subdomain acquisition is the process of registering a non-existent domain to acquire all existing domains, if this vulnerability is found, the main domain as well as all subdomains of an organization will be compromised.(kind of)
Did you understand? The site formmakers.com says that this account does not exist !!!! This means that we can create this account.
Now we have to get the name of the main account, Destination Domain, related to this Source Domain so that we can go and register it.
To get the original name, the domain name registered on formmakers.com, we have to ask the DNS Server for the form.cafebazaar.com domain to find out cafebazaar.ir refers to which subdomain of formmakers.com, to do this, we must request the CNAME record in the DNS Server of cafebazaar and see its value so that we can go and register it:
This means that if we register on the formmakers.com website and select the cafebazaar address for ourselves when choosing the domain name that I mentioned at the beginning of the article, the formmakers.com website will register the cafebazaar.formmakers.com address for us. And delivers to us.
But does that mean that from now on we will give the address cafebazaar.formmakers.com to people?
Answer: No, Because the cafebazaar DNS Server still has the old CNAME Record and is pointing to the address cafebazaar.formmakers.com and the value of this record is form.cafebazaar.ir, it means that we also own the form.cafebazaar.ir domain. And all this is due to the Misconfiguration applied to the DNS Server.
The following image is from the settings section of formmakers.com, where we apply the target domain name we want to takeOver:
Now why do we need to worry so much about subdomains? What happened now? Let me tell you what happened:
According to the browser cookie standard RFC6265, all cookies on a domain are sent to all subdomains, and all subdomains are readable.(kind of)
Ability to read secure cookies due to the presence of ssl on the acquired domain (in case of access to coming http requests, requires local file read or even rce)
Ability to submit a survey form and collect user information from the trusted domain form.cafebazaar.ir
Ability to exploit potential OpenRedirect vulnerabilities in Cafe Bazaar, which has a whitlist and allow redirects to YYY.cafebazaar.ir subdomains, and since we have acquired the form.cafebazaar.ir domain, we can replace YYY and according to the mechanism OAuth implemented in CafeBazaar and start AccountTakeOver
Distribution of malicious applications by the largest market for distributing Android applications by the trusted domain form.cafebazaar.ir
Spreading false news and damaging the credibility of the trusted domain form.cafebazaar.ir
And take more action with respect to infiltrator creativity
Well, in relation to the first topic, I must summarize that you can read cookies set on a domain by its subdomains (in certain condition)
It doesn’t matter how beautiful your theory is, it doesn’t matter how smart you are. If it doesn’t agree with experiment, it’s wrong. In that simple statement is the key to science. *Cornell University Lecture, 1964*
To make this vulnerability critical and to address the security vulnerabilities mentioned above, I started to find ZeroDay XSS on this platform, and after finding 5 Reflected XSS vulnerabilities, after 3 days, I still have the a vulnerability that was low because a link containing XSS exploit had to be given to the user and I did not want to interact with the user because the vulnerability was low. what do we do? giveup ?! No.
On day 7, after hours of testing, I was finally able to find the Stored XSS vulnerability, which was where the vulnerability was at its highest. Critical
After reporting the vulnerability to cafebazaar team, initially the’ve misunderstood the vulnerability was out of scope
What should we do now? give up? Noooooooo!
I started to check the In Scopes of CafeBazaar and realized the following:
As we talked about in the middle of the article, the vulnerability was not related to the form.cafebazaar.ir domain, but to the old DNS record, and it had to be fixed. The image above is the In Scope list, the image below shows that the DNS Server for the cafebazaar is in this IP range:
after sending the above information, they’ve approved and rewarded me, thanks cafebazaar ❤