How I hacked one hosting provider



    Recently, I began to receive a proposal to check the operation of various services for errors and vulnerabilities. And in such sentences I try to work for the result and get maximum pleasure from the process. But the result of the last "project" shocked me to put it mildly.

    I was asked to test the hosting provider.

    I will not disclose the name. And in my story I will use the name Hoster. With the site hosting service was all 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 steve.jobs@apple.com. Or even better - support@hoster.com.

    But fortunately, by analogy with this story , the disclosure of sensitive information service support services did not happen.

    However, it did happen when I created a test request for support and immediately checked the availability of the neighboring IDs of other support requests. Surprisingly, they were available. And it was possible to observe who and what registers with the hoster. And what problems are facing users. In general, the standard IDOR vulnerability, which now surprise no one. She certainly instantly fixed.

    There were also a few places with Stored XSS. There was also a Blind XSS that returned the Service Administrator Cookie to me. Thanks to this XSS, I was able to find out where the administrator interface is located, well, in general, I discovered a lot of interesting information.

    • How many active users.
    • How many domains are in control.
    • How many VDS deployed.

    And much more ...



    There were various errors with CSRF tokens that allowed you to do many dangerous things on your account on behalf of the user. And if there were places where CSRF tokens were transferred, then they were simply transferred. 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.

    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. I as QA could not pass by like. As a result, my issue tracker reached the number - 22. So many problems in the aggregate, I found and fixed (only noteworthy).

    The results were more than convincing. And I already planned to complete 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 he began to come up with situations in which this could create maximum problems for the hosting and its owners. At some point, I began to think about the links of the owners of this hosting service with other projects of the same company, which I was aware of. After a couple of minutes, I registered an account with the email address of another project of the same company (let it be support@example.com). Then I managed to link the domain example.com to my created account suppot@example.com. But I still could not control the content of the linked domain.

    But he could perfectly e-mail him on behalf of the example.com service.



    Until the end it is not clear 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 support@example.com.

    And here something happened for the sake of which 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 added and I could control the contents of this subdomain. And the content was displayed.



    But the same can not be! How so? After all, the classic subdomain takeover vulnerability works only with existing subdomains.

    This situation absolutely did not fit in my head. Ie, okay, I was able to bypass the validation levels of my relationship to example.com, which is never mine (probably due 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 records A, TXT, CNAME ...?

    Usually I meet like this - we'll add a subdomain to you, only you prove that you can do it. Go and add the given hash ololopyshpyshpyshbdysh123 to TXT .

    But there was no such thing. Do you want admin.example.com subdomain? No problem!



    As if the vulnerability Subdomain Takeover V2.

    Thanks to the ability to quickly communicate with the owners of the hosting service being tested - I opened this 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 in simple words.

    Roughly speaking, I tell you, go to me, I will host you. Delegate your domains to me.
    And then all incoming calls indiscriminately I send to CloudFlare, considering them to be correct.
    And if I was entrusted with the vasya.ru domain, and a neighbor came and filed a website with test.vasya.ru and also gave it to me for hosting, then my server, having access to CloudFlare and already having rights to vasya.ru, added the third level domain for a neighbor and all the rules, quickly and without question. For all DNS correct information from CloudFlare came. And CloudFlare trusts me.

    Of course, hosting providers of course configure their DNS services. But here it turns out to be clever and just transfer everything to CloudFlare from one user.

    So we have a subdomain takeover god_mode. True, it worked only with those addresses that are already controlled by hosting. But in conjunction with the previously discovered admin service - this could play a cruel 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 on such architectural delights after reading this story.

    PS: Comments and suggestions for the article are welcome. Special thanks to Patriot2k for the technical advice! I am also open to suggestions for testing something interesting.

    Also popular now: