Talk about hosting security: how could I hack tens of thousands of sites
Hello.
Today I would like to talk about the security of hosting and how bad things are in this area. In the middle of 2014, I was reading another article at the time about protecting sites from viruses and wondered how secure the hosting was, and whether vulnerabilities could be used for mass hacking of sites. In short, everything is much worse than I expected, and this story stretched for 3 years.
Most of the hosting looks like this
Back in 2014, I started by checking the hosting that I used at that time, and immediately found CSRF to change my account information. If you can talk about CSRF as simply as possible, this vulnerability allows forging requests on behalf of the user. When you send an HTML form from one domain to another, the browser will automatically add to the request your cookies set for the target domain. This allows an attacker, without access to your cookies, to send a request to the target domain on your behalf with your cookies. To protect against this attack, CSRF tokens, checking the referer header, or entering a password to confirm important requests are used (this is a very strange and insecure solution). You can read more about this on Wikipedia .
')
I quickly checked out 10 more major hosting sites, more than half found such a vulnerability. In fact, I could create a special page, after switching to an authorized user, his email address was changed to mine, and I could recover the password by mail and access to the account and all files. It sounds scary, but it's not deadly. To successfully execute an attack, you need to find the user, lure him to a special page, and the user must be authorized in the hosting control panel. This significantly reduces the chances of a successful mass hacking.
However, most hosting uses ready-made control panels. In this case, the administrator is the same user account with a bunch of additional rights: he often has access to all accounts on the server. For a successful attack, it was enough to create a page, the code on which will automatically send a request to change the administrator's mail, create a new account with additional rights, or perform any other action that is possible in the control panel. If you wish, you can change the extension of such a page to .jpg and place a screenshot on it to hide what is actually happening on it. After that, you can create a ticket "Help, the site does not work, here is a screenshot of the error" and attach a link to the page. After the administrator has moved to this page, the attacker gains access to all accounts of the hosting users.
To select hosting, I combined data from several ratings, after that I checked the targets for the presence of CSRF vulnerabilities. I usually checked the hosting only for the presence of CSRF, as this does not take a lot of time, but if I accidentally found something else, I reported these vulnerabilities too.
As I wrote above, out of ten major hosting sites, more than half were vulnerable. Out of a total of 100 web hosts tested in 2014, 63 were vulnerable. Usually these were simple CSRFs, although surprising vulnerabilities were met, which I will discuss later.
In the case of handwritten panels, you can usually use the CSRF to change mail, and then restore the password through the mail. The most popular of the vulnerable panels were ISPmanager, DirectAdmin, WHMCS and RootPanel. I can not call myself an expert in the hosting control panels, so I can be mistaken with the versions or other subtleties.
This is a very popular panel, while its current version does not contain CSRF. However, an extremely outdated and leaky old version of the panel is often used.
After finding the CSRF on different hosts using this panel, I wrote to the panel developers about this. However, they reported that for a long time there was protection against CSRF in the form of checking the referer header, however, it was turned off for most of the hosts.
A similar problem was with WHMCS. For some surprising reason, the CSRF token was not tested on many hosting systems, there was no protection against forgeries. Probably, someone incorrectly configured something.
And in this panel were present CSRF initially, the vulnerability was fixed by the developer after I wrote to him.
Perhaps the most correct would be to publish this information in 2014 and watch for mass hacks and hacker complaints. But then I decided that it was better to report the vulnerabilities to hosting, and began to do so. I told 63 vulnerable hosting about the problem, only 52 responded. After some time, 48 hosts fixed the vulnerability, the rest did not do anything.
The most interesting thing started later. After some time, I checked these hostings again, and part of them made the vulnerabilities magically appear again. In 2015 and in 2016, I selected another 20-30 hosting sites, checked them and wrote to companies about vulnerabilities. The situation is similar: more than half of the hosting sites are vulnerable, some time after the fix, some of the vulnerabilities reappear.
At some point, it all began to resemble a circus: I send the information, the vulnerability disappears. Often, especially in the case of samopisnymi panels, after six months, the vulnerability returns in the same or similar form.
Some companies were ready to fix the vulnerability only by installing an update of the control panel used (“We are using the latest version of the panel, this is a problem for developers”). At the same time, their panel generation has not been updated for a long time.
At some point I decided to end this circus and publish information about existing problems.
The number of sites that could be hacked using these vulnerabilities is difficult to calculate. If we proceed from the number of vulnerable hosting sites (of the order of 90-100) and the minimum number of hosted sites in 1000 on each hosting (I am pretty sure that the real number is much larger), then this is at least 100,000 sites. However, indirect signs (ID of accounts and sites in the system, own statements of hosting and information from ratings) suggest that more than a few million sites were in danger. It is clear that most of the sites are visited by a couple of people a month, but even so, the situation is scary.
In 2014 and 2015, the situation was frightening: more than half of the hosting sites, including some of the largest ones at that time, had simple vulnerabilities that allow access to user data. In the worst case, immediately to all accounts. Gradually, the situation began to improve: those who planned to close vulnerabilities corrected them, new hosting finally began to use newer control panels.
However, there is a barrel of tar: even now, a number of major hosting sites that are in the top 10–20 of the most popular ones contain simple CSRFs that allow you to access a user account. There is a suspicion that in a similar way you can perform queries on behalf of the administrator, but this is a separate issue (they use their control panels, I don’t know the format of the administrator requests). Among the smaller hosting companies, there are still quite a lot of those who for some reason have not fixed the vulnerabilities. In addition, there are many related vulnerabilities, the security level in the field of hosting is surprisingly low.
* Rewards . Usually they offered free hosting, and the conditions were very different: from the truly adequate 10,000 to 20,000 thousand to the personal account, before the discount of 120 rubles for 1 month, I was impressed by this generosity. Cash rewards were offered much less frequently, usually they were symbolic 1000-2000 rubles, although there were two much more pleasant times. But these are isolated situations, most did not offer anything.
* Adequacy . I have never faced rudeness or threats. The most annoying thing is to ignore messages or reply “We do not consider this a vulnerability.”
* Brilliant solutions to security problems . Several companies have decided to deal with the threat of CSRF in a strange way: "administrators will not follow links from users," and users must "take care of themselves."
* Other vulnerabilities . I only looked for CSRF, but sometimes there were other vulnerabilities. The most common is incorrect HTTPS configuration, sometimes it was absent altogether, there was a bunch of XSS, there were strange data leaks. It's funny that the hosting, which has positioned itself as the most secure (reliable systems, access control, round-the-clock monitoring), could get access to any account by simply sorting through identifiers. Apparently, the cost of PR is too high to make secure services.
* Publication of company names . For a long time I could not decide whether to publish the full results of the audit with all the company names and a detailed description of the vulnerabilities. However, given the check only for CSRF, its selectivity, still vulnerable hosting and some conditions for receiving remuneration, I did not publish this information.
If, after reading the article, you have a desire to do something, then I strongly urge you not to commit unlawful actions or break the hosting.
I hope that next week I will tell you something more interesting, for example, about unclosed vulnerabilities in Telegram.
UPD : The comments were requested to provide proofs. Under the spoiler there are screenshots of several hosting responses (in the screenshots I tried to hide all the data that uniquely identify the company) and the answer from the developers of DirectAdmin.
Today I would like to talk about the security of hosting and how bad things are in this area. In the middle of 2014, I was reading another article at the time about protecting sites from viruses and wondered how secure the hosting was, and whether vulnerabilities could be used for mass hacking of sites. In short, everything is much worse than I expected, and this story stretched for 3 years.
Most of the hosting looks like this
Back in 2014, I started by checking the hosting that I used at that time, and immediately found CSRF to change my account information. If you can talk about CSRF as simply as possible, this vulnerability allows forging requests on behalf of the user. When you send an HTML form from one domain to another, the browser will automatically add to the request your cookies set for the target domain. This allows an attacker, without access to your cookies, to send a request to the target domain on your behalf with your cookies. To protect against this attack, CSRF tokens, checking the referer header, or entering a password to confirm important requests are used (this is a very strange and insecure solution). You can read more about this on Wikipedia .
')
I quickly checked out 10 more major hosting sites, more than half found such a vulnerability. In fact, I could create a special page, after switching to an authorized user, his email address was changed to mine, and I could recover the password by mail and access to the account and all files. It sounds scary, but it's not deadly. To successfully execute an attack, you need to find the user, lure him to a special page, and the user must be authorized in the hosting control panel. This significantly reduces the chances of a successful mass hacking.
However, most hosting uses ready-made control panels. In this case, the administrator is the same user account with a bunch of additional rights: he often has access to all accounts on the server. For a successful attack, it was enough to create a page, the code on which will automatically send a request to change the administrator's mail, create a new account with additional rights, or perform any other action that is possible in the control panel. If you wish, you can change the extension of such a page to .jpg and place a screenshot on it to hide what is actually happening on it. After that, you can create a ticket "Help, the site does not work, here is a screenshot of the error" and attach a link to the page. After the administrator has moved to this page, the attacker gains access to all accounts of the hosting users.
To select hosting, I combined data from several ratings, after that I checked the targets for the presence of CSRF vulnerabilities. I usually checked the hosting only for the presence of CSRF, as this does not take a lot of time, but if I accidentally found something else, I reported these vulnerabilities too.
Results and technical details
As I wrote above, out of ten major hosting sites, more than half were vulnerable. Out of a total of 100 web hosts tested in 2014, 63 were vulnerable. Usually these were simple CSRFs, although surprising vulnerabilities were met, which I will discuss later.
In the case of handwritten panels, you can usually use the CSRF to change mail, and then restore the password through the mail. The most popular of the vulnerable panels were ISPmanager, DirectAdmin, WHMCS and RootPanel. I can not call myself an expert in the hosting control panels, so I can be mistaken with the versions or other subtleties.
This is a very popular panel, while its current version does not contain CSRF. However, an extremely outdated and leaky old version of the panel is often used.
After finding the CSRF on different hosts using this panel, I wrote to the panel developers about this. However, they reported that for a long time there was protection against CSRF in the form of checking the referer header, however, it was turned off for most of the hosts.
A similar problem was with WHMCS. For some surprising reason, the CSRF token was not tested on many hosting systems, there was no protection against forgeries. Probably, someone incorrectly configured something.
And in this panel were present CSRF initially, the vulnerability was fixed by the developer after I wrote to him.
Hosting Reaction
Perhaps the most correct would be to publish this information in 2014 and watch for mass hacks and hacker complaints. But then I decided that it was better to report the vulnerabilities to hosting, and began to do so. I told 63 vulnerable hosting about the problem, only 52 responded. After some time, 48 hosts fixed the vulnerability, the rest did not do anything.
The most interesting thing started later. After some time, I checked these hostings again, and part of them made the vulnerabilities magically appear again. In 2015 and in 2016, I selected another 20-30 hosting sites, checked them and wrote to companies about vulnerabilities. The situation is similar: more than half of the hosting sites are vulnerable, some time after the fix, some of the vulnerabilities reappear.
At some point, it all began to resemble a circus: I send the information, the vulnerability disappears. Often, especially in the case of samopisnymi panels, after six months, the vulnerability returns in the same or similar form.
Some companies were ready to fix the vulnerability only by installing an update of the control panel used (“We are using the latest version of the panel, this is a problem for developers”). At the same time, their panel generation has not been updated for a long time.
At some point I decided to end this circus and publish information about existing problems.
The scale of the problem
The number of sites that could be hacked using these vulnerabilities is difficult to calculate. If we proceed from the number of vulnerable hosting sites (of the order of 90-100) and the minimum number of hosted sites in 1000 on each hosting (I am pretty sure that the real number is much larger), then this is at least 100,000 sites. However, indirect signs (ID of accounts and sites in the system, own statements of hosting and information from ratings) suggest that more than a few million sites were in danger. It is clear that most of the sites are visited by a couple of people a month, but even so, the situation is scary.
Brief results and condition to date
In 2014 and 2015, the situation was frightening: more than half of the hosting sites, including some of the largest ones at that time, had simple vulnerabilities that allow access to user data. In the worst case, immediately to all accounts. Gradually, the situation began to improve: those who planned to close vulnerabilities corrected them, new hosting finally began to use newer control panels.
However, there is a barrel of tar: even now, a number of major hosting sites that are in the top 10–20 of the most popular ones contain simple CSRFs that allow you to access a user account. There is a suspicion that in a similar way you can perform queries on behalf of the administrator, but this is a separate issue (they use their control panels, I don’t know the format of the administrator requests). Among the smaller hosting companies, there are still quite a lot of those who for some reason have not fixed the vulnerabilities. In addition, there are many related vulnerabilities, the security level in the field of hosting is surprisingly low.
A few notes and funny situations
* Rewards . Usually they offered free hosting, and the conditions were very different: from the truly adequate 10,000 to 20,000 thousand to the personal account, before the discount of 120 rubles for 1 month, I was impressed by this generosity. Cash rewards were offered much less frequently, usually they were symbolic 1000-2000 rubles, although there were two much more pleasant times. But these are isolated situations, most did not offer anything.
* Adequacy . I have never faced rudeness or threats. The most annoying thing is to ignore messages or reply “We do not consider this a vulnerability.”
* Brilliant solutions to security problems . Several companies have decided to deal with the threat of CSRF in a strange way: "administrators will not follow links from users," and users must "take care of themselves."
* Other vulnerabilities . I only looked for CSRF, but sometimes there were other vulnerabilities. The most common is incorrect HTTPS configuration, sometimes it was absent altogether, there was a bunch of XSS, there were strange data leaks. It's funny that the hosting, which has positioned itself as the most secure (reliable systems, access control, round-the-clock monitoring), could get access to any account by simply sorting through identifiers. Apparently, the cost of PR is too high to make secure services.
* Publication of company names . For a long time I could not decide whether to publish the full results of the audit with all the company names and a detailed description of the vulnerabilities. However, given the check only for CSRF, its selectivity, still vulnerable hosting and some conditions for receiving remuneration, I did not publish this information.
If, after reading the article, you have a desire to do something, then I strongly urge you not to commit unlawful actions or break the hosting.
I hope that next week I will tell you something more interesting, for example, about unclosed vulnerabilities in Telegram.
UPD : The comments were requested to provide proofs. Under the spoiler there are screenshots of several hosting responses (in the screenshots I tried to hide all the data that uniquely identify the company) and the answer from the developers of DirectAdmin.
Screenshots
one) 
2)
3)
four)
five)
6)
2)
3)
four)
five)
6)
Source: https://habr.com/ru/post/337906/
All Articles