Recently, I began to receive a requests to make pentest work for some projects (aka private bug bounty). And in such projects I do my best with results for customer and get maximum pleasure from the process. But the result of the last project just shocked me.
I was asked to make a pentest for one Hosting Provider.
I will not disclose the name of that company. And in my story I will use the name "Hoster". With hosting service webpage everything was standard. Offers to buy VDS, Domains, SSL certificates.
First of all, I was surprised at how the user’s personal account was implemented. Proof of ownership of the email address during registration was not required. Ie it was possible to register with the email address firstname.lastname@example.org. Or even better — email@example.com.
But fortunately, by analogy with such story, the disclosure of sensitive information support services didn't happen.
However, it did happen when I created a test request for support and immediately checked the availability of neighbouring ID's of other support requests. Surprisingly, they were available. And it was possible to observe who and what registered with that Hoster. And what kind of problems are facing users. In general it's a usual IDOR vulnerability, which no one surprise for now . It was fixed asap.
There were also several places with Stored XSS. There was also a Blind XSS which returned the Service Administrator Cookie to me. Thanks to this XSS, I was able to find out where the administrator interface is located, well, and in general I revealed a lot of interesting information.
- How many active users.
- How many domains are in control.
- How many VDS deployed.
- Payment history.
And some other things…
There were various problems with CSRF tokens that allowed to do a lot of dangerous things on my account on behalf of the user. And if there were places where CSRF tokens was implemented. Nobody planned to check them on the backend. As a result of my findings, some of the functionality was completely disabled. So for example, 2FA authentication was decided to temporarily remove as not implemented well.
In the course of my work, I paid attention not only to security problems, but also to implementation errors or problems in the operation of some functionality. As a QA engineer I couldn't passing by this. In total, my issue tracker reached the number — 22. So many problems I found.
The results were more than convincing. And I already planned to finish this project. But for some reason I remembered again the problem of the lack of confirmation of the owner of the email address during registration. And here I began to invent situations in which this could create maximum problems for the hosting company and its owners. At some point, I began to think about the connections of the owners of this hosting service with other projects of the same company. After a couple of minutes, I registered an account with the email address of another project of that company (let it be firstname.lastname@example.org). Then I managed to link the domain example.com to my created account email@example.com. But I still could not control the content of the linked domain.
But could perfectly send e-mails on behalf of the example.com service. Nice thing for phishing attack.
I don't know where the reply letters came. Because I answered one such test letter to myself. But I did not get the answer. Probably it went back to the real owner of the email box firstname.lastname@example.org.
And here something interesting happened and I decided to write this article.
I managed to resolve the forgotten subdomain. Classic subdomain takeover vulnerability. You can read about it in great detail here.
I do not know why, but I tried to add a binding to a nonexistent domain.
And I did it!!! The subdomain was successfully created/added and I could control the contents of this subdomain!!! And the content was displayed!
Wait a minute. How so? After all, the classic subdomain takeover vulnerability only works with already existing subdomains. And we are not allow to make a new one…
This situation wasn't clear. Ie, okay, I was able to bypass the levels of validation of my relationship with example.com, which was never be mine (probably thanks to example.com in my account name). But how is it possible to add subdomains at all and control them without any checking components in the DNS A, TXT, CNAME records …?
Usually it works like this — we’ll add a subdomain to you, only you prove that you can do it. Go to DNS and add that hash omnomnomtom0110 to TXT.
But there was no such thing. Do you want admin.example.com subdomain? No problem!
As if the vulnerability — Subdomain Takeover V2.
I was able to communicate with the owners of the hosting service being tested and they opened a bit pandora’s box.
It turned out the following. Hosting worked through CloudFlare. And he worked in a very tricky way.
I will try to explain you in simple words.
Roughly speaking, I am tell you, go to me, I will host you. Just delegate your domains to me.
And then all incoming calls I send to CloudFlare, considering them to be correct.
And if I was entrusted with the president.com domain, and one neighbour came and did a website with notour.president.com and also gave it to me for hosting, then my server, having access to CloudFlare and already having all rights to president.com, will add third level domain for a neighbour quickly and without any question. For all DNS informations which came from CloudFlare are correct. And CloudFlare trusts me as a Hoster.
Of course, most hosting providers configure their own DNS services. But that company just transferred everything to CloudFlare from one configured user.
So we have a Subdomain Takeover V2. For sure this worked only with those addresses that are already controlled by Hosting service. But in conjunction with the previously discovered admin service — this could play expensive joke with both the Hoster and the hosting service clients.
At the moment, almost all critical vulnerabilities and bugs have been fixed. And I hope that no one else will decide to make such architectural delights after reading this story.