Distributed brute-force attack on the CMS from the point of view of the hoster
It’s no secret that brute force brute force attempts are a constant phenomenon. Pick up passwords to servers and virtual machines, to adminkam sites and FTP-accounts, to mailboxes and social networks.
Usually, brute force goes in the background and is almost not noticeable for resource owners, because does not create a significant load and does not interfere with the work of the site, at least until the villains will not penetrate the server :)
On August 1, perhaps the most powerful brute-force attack on websites created by the most common free CMS started in runet: Wordpress, Joomla! and etc.
')
And that's how it was:
A similar attack on Wordpress sites was undertaken in April of this year. This attack affected mainly Western resources, and Russian users and hosting providers did not notice it. At this time, the botnet is aimed primarily at hacking Russian-language sites.
The first public reports of the attack appeared on 2 August. In fact, the anomalous activity in our monitoring system was still noticeable on the first date. Prior to this, the load created by the bots was not so noticeable. Perhaps these were trial launches, but we assume that active work began with a small number of infected machines. As new participants joined, the load on the infrastructure grew and by August 2, all Russian hosting providers and their clients felt it.
On the chart above it may seem that something started to happen on July 31, I even highlighted this moment with a red line. As further research has shown, this was a local anomaly caused not by the onset of an attack, but by the load on one of the nodes. According to this graphics with detail, it is easy to identify the source of the anomaly:
Knowing the node, you can go further and find out who exactly creates the load:
As you can see, increased activity in one of the client virtual servers. At the same time, the server neighbors are fine and on other nodes everything is normal. From here we conclude that the case has nothing to do with the attack under investigation, i.e. Big Bruteforce began on August 1st.
The behavior of the bots was standard: they turned to the typical CMS authorization page. For example, for WP this is the wp-login.php page. In the first phase of the attack, appeals were rather clumsy: the bots immediately made a POST login and password into the form without first receiving a page (GET). Thus, at this stage it was very easy to distinguish them from real users, who first received the page, and then entered their login and password.
Using this feature, bots were quickly blocked. Naturally, after that, the attackers made adjustments to the behavior of bots. They learned how to do GET-POST and work with cookies.
After this, of the possible cover options remained:
1) rename the login page;
2) restricting access to the admin section by ip-address (white list, geographical or other division principle);
3) dual authorization.
Renaming the authorization page is well suited specifically for Wordpress, because as a result, nothing breaks and you can continue to work. But not the fact that this method works well for other CMS. The system may well be binding to a specific script name.
Thus, this method was not suitable for us as a hosting provider, since we simply cannot go and rename files to all clients without their knowledge. This can only be done by the client.
Restricting access to the admin on the white list of ip-addresses does not suit everyone, because first, Internet providers almost always provide a dynamic address, which can vary from session to session, and secondly, it excludes the possibility of access to the admin from outside, for example, from a mobile device. This option was also flagged as non-working.
The restriction on the geographical affiliation of ip only works if the botnet has a pronounced "region of residence", for example, Vietnam or India. Again, this method is not suitable for taking unified measures on a large hosting, since Immediately there are foreign customers who are subject to these filters.
Dual authorization is a method that we eventually applied to sites prone to attacks on our shared hosting. We have established an additional authorization page, which is issued when trying to access the admin panel without certain cookies. Having passed our additional authorization once, the legitimate user receives a special cookie and can easily enter the CMS admin area. At the same time, bots cannot go through the page and not only cannot select a password for the CMS, but they do not create a heavy load on the server.
Judging by the news of the hosting providers, many used a similar method, but set terribly secret passwords, which the client could find out only upon request to technical support or in a personal e-mail list.
We considered such a super-secret approach redundant and incorrect with respect to customers. Sometimes access to the admin panel is needed urgently, and it may be very inconvenient to write a request, call or search for the desired email from the host. Therefore, the data for additional authorization, we indicated on the page in an explicit form, based on the simple assumption that bots do not know how to read and think, and teaching them specifically for our case is too laborious and ungrateful villainous task.
This is how the page with additional authorization looks like (sorry, it wasn’t nice page decoration):
We also refused to use classic http authorization due to the fact that a pop-up window asking for a username and password is not the most convenient way to tell the client what happened to his CMS and why he sees this request. Such a window blocks the browser, scares and interferes with the orientation.
In addition to fighting bots, it was very interesting for us to observe how their efforts are coordinated and distributed. Judging by the analytics from our system, the number of simultaneous requests for 1 hosting ip-address stably kept no more than 30 for each CMS, regardless of the number of attacked sites on this address. Thus, if on one ip-address were placed sites on both Wordpress and Joomla !, then the number of simultaneous downloads was kept at the level of 60 pieces. This is quite a lot for shared hosting.
If the site ceased to respond - requests to it instantly ceased. This is reasonable because It is more profitable for attackers to leave the victim alive. However, 60 simultaneous requests are large enough to be guaranteed to be noticed by site owners and hosting providers. There is an opinion that it would be wiser for villains to be brutalized by 3-4 times less flow of requests. In this case, botnet activity would be much less noticeable.
The active phase of the attack began in the evening and lasted all night. The addresses of the bots were given in alphabetical order.
Thus, in the evening the sites with the letter A began to suffer, and closer to the morning - the sites on Z. In this sense, they were lucky a little more.
Now the attack is still ongoing, albeit at a significantly reduced pace. We managed to minimize the damage from attacks for users of shared-hosting. Users of dedicated physical and virtual servers remain at risk, as centralized access to the CMS admin panel in this case is impossible and protection measures must be taken by the server administrator.
Thanks for attention! :)
All success in the fight against bots. ways for self-defense voiced above. If you have a cool ready-made recipe - please in the comments!
Usually, brute force goes in the background and is almost not noticeable for resource owners, because does not create a significant load and does not interfere with the work of the site, at least until the villains will not penetrate the server :)
On August 1, perhaps the most powerful brute-force attack on websites created by the most common free CMS started in runet: Wordpress, Joomla! and etc.
')
And that's how it was:
The fashion for mega-brutfors has reached us
A similar attack on Wordpress sites was undertaken in April of this year. This attack affected mainly Western resources, and Russian users and hosting providers did not notice it. At this time, the botnet is aimed primarily at hacking Russian-language sites.
The first public reports of the attack appeared on 2 August. In fact, the anomalous activity in our monitoring system was still noticeable on the first date. Prior to this, the load created by the bots was not so noticeable. Perhaps these were trial launches, but we assume that active work began with a small number of infected machines. As new participants joined, the load on the infrastructure grew and by August 2, all Russian hosting providers and their clients felt it.
On the chart above it may seem that something started to happen on July 31, I even highlighted this moment with a red line. As further research has shown, this was a local anomaly caused not by the onset of an attack, but by the load on one of the nodes. According to this graphics with detail, it is easy to identify the source of the anomaly:
Knowing the node, you can go further and find out who exactly creates the load:
As you can see, increased activity in one of the client virtual servers. At the same time, the server neighbors are fine and on other nodes everything is normal. From here we conclude that the case has nothing to do with the attack under investigation, i.e. Big Bruteforce began on August 1st.
Fighting bots
The behavior of the bots was standard: they turned to the typical CMS authorization page. For example, for WP this is the wp-login.php page. In the first phase of the attack, appeals were rather clumsy: the bots immediately made a POST login and password into the form without first receiving a page (GET). Thus, at this stage it was very easy to distinguish them from real users, who first received the page, and then entered their login and password.
Using this feature, bots were quickly blocked. Naturally, after that, the attackers made adjustments to the behavior of bots. They learned how to do GET-POST and work with cookies.
After this, of the possible cover options remained:
1) rename the login page;
2) restricting access to the admin section by ip-address (white list, geographical or other division principle);
3) dual authorization.
Renaming the authorization page is well suited specifically for Wordpress, because as a result, nothing breaks and you can continue to work. But not the fact that this method works well for other CMS. The system may well be binding to a specific script name.
Thus, this method was not suitable for us as a hosting provider, since we simply cannot go and rename files to all clients without their knowledge. This can only be done by the client.
Restricting access to the admin on the white list of ip-addresses does not suit everyone, because first, Internet providers almost always provide a dynamic address, which can vary from session to session, and secondly, it excludes the possibility of access to the admin from outside, for example, from a mobile device. This option was also flagged as non-working.
The restriction on the geographical affiliation of ip only works if the botnet has a pronounced "region of residence", for example, Vietnam or India. Again, this method is not suitable for taking unified measures on a large hosting, since Immediately there are foreign customers who are subject to these filters.
Dual authorization is a method that we eventually applied to sites prone to attacks on our shared hosting. We have established an additional authorization page, which is issued when trying to access the admin panel without certain cookies. Having passed our additional authorization once, the legitimate user receives a special cookie and can easily enter the CMS admin area. At the same time, bots cannot go through the page and not only cannot select a password for the CMS, but they do not create a heavy load on the server.
Judging by the news of the hosting providers, many used a similar method, but set terribly secret passwords, which the client could find out only upon request to technical support or in a personal e-mail list.
We considered such a super-secret approach redundant and incorrect with respect to customers. Sometimes access to the admin panel is needed urgently, and it may be very inconvenient to write a request, call or search for the desired email from the host. Therefore, the data for additional authorization, we indicated on the page in an explicit form, based on the simple assumption that bots do not know how to read and think, and teaching them specifically for our case is too laborious and ungrateful villainous task.
This is how the page with additional authorization looks like (sorry, it wasn’t nice page decoration):
We also refused to use classic http authorization due to the fact that a pop-up window asking for a username and password is not the most convenient way to tell the client what happened to his CMS and why he sees this request. Such a window blocks the browser, scares and interferes with the orientation.
Observations
In addition to fighting bots, it was very interesting for us to observe how their efforts are coordinated and distributed. Judging by the analytics from our system, the number of simultaneous requests for 1 hosting ip-address stably kept no more than 30 for each CMS, regardless of the number of attacked sites on this address. Thus, if on one ip-address were placed sites on both Wordpress and Joomla !, then the number of simultaneous downloads was kept at the level of 60 pieces. This is quite a lot for shared hosting.
If the site ceased to respond - requests to it instantly ceased. This is reasonable because It is more profitable for attackers to leave the victim alive. However, 60 simultaneous requests are large enough to be guaranteed to be noticed by site owners and hosting providers. There is an opinion that it would be wiser for villains to be brutalized by 3-4 times less flow of requests. In this case, botnet activity would be much less noticeable.
The active phase of the attack began in the evening and lasted all night. The addresses of the bots were given in alphabetical order.
Thus, in the evening the sites with the letter A began to suffer, and closer to the morning - the sites on Z. In this sense, they were lucky a little more.
The battle continues again
Now the attack is still ongoing, albeit at a significantly reduced pace. We managed to minimize the damage from attacks for users of shared-hosting. Users of dedicated physical and virtual servers remain at risk, as centralized access to the CMS admin panel in this case is impossible and protection measures must be taken by the server administrator.
Thanks for attention! :)
All success in the fight against bots. ways for self-defense voiced above. If you have a cool ready-made recipe - please in the comments!
Source: https://habr.com/ru/post/190020/
All Articles