Another battle with web viruses
Good day, dear habrapayazhety. Finally, I had another client that allowed me to describe the solution to his problem on condition of anonymity. Under the cut there is a story about how the fight against the malicious code that appears on the customer’s sites in several ways at the same time. Due to the fact that many people do not like articles of large size, this time I tried to present everything as short as possible.
Baseline data were as follows. There is a virtual server running Ubuntu 10.04. The customer administers it on his own. On the server there are 13 sites, 12 of which are deployed on WordPress, and one consists of static html-pages. Management of their file contents goes via FTP, and only from 2 computers. One Mac, a second PC with Win7 and licensed KAV.
Regularly, once every 1-2 weeks, they get infected - obfuscated inserts appear in the code of php scripts. During the first conversation, the client said that the same iframe code constantly appears in the scripts, but as it turned out later, there were several malware. In the end, the sites povletlet of issuing Google and Yandex, and gradually the number of visitors has become equal to zero.
After the first inspection, several more interesting details emerged:
All this seriously added to the trouble. At this stage, it became clear that the problem is not simple, and in order to save the client from this trouble, it is necessary to work not only with FTP passwords and protection of client machines (as is often the case in such situations).
')
Next, a list of possible routes of infection was compiled, each of which needed to be checked. First of all, simply because of its prevalence, the option of infection with the help of previously stolen passwords from remote access services was considered. Of course, a fresh KAV on a Win-machine is a good argument, but passwords could be stolen before the antivirus was installed. And not the fact that the administrator will immediately replace them.
In second place put infection through all sorts of backdoors. Suppose that once the administrator has not updated WP at the right time and some shell has been flooded on the site, through which the malicious code now constantly makes itself felt.
And as the third option was considered infection through vulnerability in the scripts of sites. Due to the inability to upgrade for technical reasons, WP 2.9.2 was on some resources. At the time of performing the work for this version, only SQL injection was known in the TrackBack function, which was not used by the client on any site. But do not forget about plugins and themes. They also often find errors. In addition, phpBB version 3.0.8 was installed on one of the sites. It was not working (no connection to the database, incorrect data in the configuration file), but it was nevertheless decided to check it. I did not find information about the vulnerabilities of this version in public sources, but there is a topic on the official forum ( http://www.phpbb.com/community/viewtopic.php?f=46&t=2119662 ) which describes its hacking. At the same time, there are no flaws in details, as well as there is no guarantee that the forum of this version cannot be hacked without a connection to the database.
After that, the logs of the web and ftp servers for the last few days were checked. Curious things turned out. One robot once a day passed authorization to FTP and immediately disconnected. Apparently checking the validity of the account. Another one went to FTP every day, downloaded 12 always different scripts and, if there were no malicious inserts in them, corrected the situation. In the logs of the web server, a doorway appeared, where people came mostly from Yandex. There was also a strange redirect of users of mobile browsers that came from different points of sites. It was implemented through root .htaccess. In addition, 3 web shells were found that were sometimes sent to POST requests. In general, all 12 sites are simply killers of all sorts of malware.
At first, the client was asked not to touch the current dangerous inserts and simply roll a clean, as he thought, backup, which was made before all these troubles were noticed. But after a detailed study, it turned out that she, too, has all of the above in herself, just in a smaller quantity. Therefore, it was decided to deal with each problem separately.
Here it is necessary to make a digression and say that such a struggle is useless if the sources of infection are not eliminated. You can clean the code at least as much - malicious inserts will still come back. Therefore, the following work was done:
The calculation, after all these actions, was as follows. Once the malicious code and shells are cleaned up, we will just wait. If something is missed and the infection happens again, its source can be calculated instantly, because all sites are isolated from each other both in the file system and in the database.
Now should make a cleaning. First, a simple script was made, which is a signature code scanner. One after another obfuscated inserts were assembled and placed in its base. The script, in turn, had to clean up all damaged files at once on command. Thanks to this work, several variants of redirectors were found (they worked on people who came from search engines) and one iframe, about which the customer spoke at the very beginning. Then Cron was written, regularly checking the source codes of sites with the help of console utilities for the presence of phrases such as “system (”, “base64_decode (”, etc.). If they were found, it should have been reported to me and the administrator by mail. Here to say that not everything is a virus that is obfuscated. In the WP themes (and on each site they were not standard) a lot of such inserts were found. They were a kind of protection against copyright deletion. I had to bring them into a normal form in order to avoid false positives.
After that, the site codes were cleaned at once, the doorway pages and shells were removed, .htaccess's were fixed. After a few days, no changes in the files were observed, so the problem could be considered closed.
And one moment. In the course of research, the host was found, from which their content was loaded via http. On this host, on the web server, there were several directories named after other hacked sites. Quickly making sure that the domains found are also doorways, I wrote them to webmasters and administrators. Unfortunately, I have not received a single answer. The filling of doorways on them is still preserved. But managed to cope with the server-distributor. It turned out to be a VDS, rented from a Ukrainian company, which, upon receiving a complaint, conducted its test for a couple of days and then disconnected this server from the network.
Based on the above, I would like to give the following recommendations to webmasters, as well as to administrators of web resources:
Thank you for your time. I hope you learned something from this article for yourself.
Baseline data were as follows. There is a virtual server running Ubuntu 10.04. The customer administers it on his own. On the server there are 13 sites, 12 of which are deployed on WordPress, and one consists of static html-pages. Management of their file contents goes via FTP, and only from 2 computers. One Mac, a second PC with Win7 and licensed KAV.
Regularly, once every 1-2 weeks, they get infected - obfuscated inserts appear in the code of php scripts. During the first conversation, the client said that the same iframe code constantly appears in the scripts, but as it turned out later, there were several malware. In the end, the sites povletlet of issuing Google and Yandex, and gradually the number of visitors has become equal to zero.
After the first inspection, several more interesting details emerged:
- All blogs worked with MySQL as root.
- To manage websites from within on VDS, one user was created, in whose home folder all web directories were located at once.
- PHP was installed as an Apache module, because of which the latter worked with all sites from one name - www-data. Therefore, to influence each resource, it was enough to find a flaw in at least one of them.
- Every blog has a lot of security plugins installed - some WP scanners, checksums checkers and much more.
- In many files, the malicious code took up more than the native space - when re-infected, the robots did not check for the presence of their code in the scripts.
All this seriously added to the trouble. At this stage, it became clear that the problem is not simple, and in order to save the client from this trouble, it is necessary to work not only with FTP passwords and protection of client machines (as is often the case in such situations).
')
Next, a list of possible routes of infection was compiled, each of which needed to be checked. First of all, simply because of its prevalence, the option of infection with the help of previously stolen passwords from remote access services was considered. Of course, a fresh KAV on a Win-machine is a good argument, but passwords could be stolen before the antivirus was installed. And not the fact that the administrator will immediately replace them.
In second place put infection through all sorts of backdoors. Suppose that once the administrator has not updated WP at the right time and some shell has been flooded on the site, through which the malicious code now constantly makes itself felt.
And as the third option was considered infection through vulnerability in the scripts of sites. Due to the inability to upgrade for technical reasons, WP 2.9.2 was on some resources. At the time of performing the work for this version, only SQL injection was known in the TrackBack function, which was not used by the client on any site. But do not forget about plugins and themes. They also often find errors. In addition, phpBB version 3.0.8 was installed on one of the sites. It was not working (no connection to the database, incorrect data in the configuration file), but it was nevertheless decided to check it. I did not find information about the vulnerabilities of this version in public sources, but there is a topic on the official forum ( http://www.phpbb.com/community/viewtopic.php?f=46&t=2119662 ) which describes its hacking. At the same time, there are no flaws in details, as well as there is no guarantee that the forum of this version cannot be hacked without a connection to the database.
After that, the logs of the web and ftp servers for the last few days were checked. Curious things turned out. One robot once a day passed authorization to FTP and immediately disconnected. Apparently checking the validity of the account. Another one went to FTP every day, downloaded 12 always different scripts and, if there were no malicious inserts in them, corrected the situation. In the logs of the web server, a doorway appeared, where people came mostly from Yandex. There was also a strange redirect of users of mobile browsers that came from different points of sites. It was implemented through root .htaccess. In addition, 3 web shells were found that were sometimes sent to POST requests. In general, all 12 sites are simply killers of all sorts of malware.
At first, the client was asked not to touch the current dangerous inserts and simply roll a clean, as he thought, backup, which was made before all these troubles were noticed. But after a detailed study, it turned out that she, too, has all of the above in herself, just in a smaller quantity. Therefore, it was decided to deal with each problem separately.
Here it is necessary to make a digression and say that such a struggle is useless if the sources of infection are not eliminated. You can clean the code at least as much - malicious inserts will still come back. Therefore, the following work was done:
- For each of the sites a separate MySQL-user was created with access rights only to his database.
- For each site, a separate user was created in the OS and corresponding rights were set on its directory. No 777 for the directories listed in the WP installation documentation was out of the question. Maximum rights to write were only the owner.
- A bunch of Apache and PHP was redone with mod_php to php-cgi + suPHP in order to provide separate php.ini and an interpreter to work with site scripts on behalf of the owner-users.
- FTP access was allowed only from the provider’s networks used by the client.
- In the database of each site, the tables with accounts were checked for the presence of the administrators who came from.
- Removed, due to uselessness, all security plugins WP.
- Blocked access to the above forum.
- New passwords were set for the MySQL root, for the OS user who was previously used for administrative purposes, and also for the administrator accounts of each of the 12 sites.
The calculation, after all these actions, was as follows. Once the malicious code and shells are cleaned up, we will just wait. If something is missed and the infection happens again, its source can be calculated instantly, because all sites are isolated from each other both in the file system and in the database.
Now should make a cleaning. First, a simple script was made, which is a signature code scanner. One after another obfuscated inserts were assembled and placed in its base. The script, in turn, had to clean up all damaged files at once on command. Thanks to this work, several variants of redirectors were found (they worked on people who came from search engines) and one iframe, about which the customer spoke at the very beginning. Then Cron was written, regularly checking the source codes of sites with the help of console utilities for the presence of phrases such as “system (”, “base64_decode (”, etc.). If they were found, it should have been reported to me and the administrator by mail. Here to say that not everything is a virus that is obfuscated. In the WP themes (and on each site they were not standard) a lot of such inserts were found. They were a kind of protection against copyright deletion. I had to bring them into a normal form in order to avoid false positives.
After that, the site codes were cleaned at once, the doorway pages and shells were removed, .htaccess's were fixed. After a few days, no changes in the files were observed, so the problem could be considered closed.
And one moment. In the course of research, the host was found, from which their content was loaded via http. On this host, on the web server, there were several directories named after other hacked sites. Quickly making sure that the domains found are also doorways, I wrote them to webmasters and administrators. Unfortunately, I have not received a single answer. The filling of doorways on them is still preserved. But managed to cope with the server-distributor. It turned out to be a VDS, rented from a Ukrainian company, which, upon receiving a complaint, conducted its test for a couple of days and then disconnected this server from the network.
Based on the above, I would like to give the following recommendations to webmasters, as well as to administrators of web resources:
- Separate sites from each other both in the database and at the OS level - in the event of infection, you will immediately identify the vulnerable site, which means that the initial flaw through which the malicious code got to the server will be found quickly.
- If you work in a bundle of Apache2 + PHP, then install it so that the scripts of each site run on behalf of its owner (fcgi, cgi + suPHP, apache2-mpm-itk, etc.) - so the malicious code will not be able to get on one site infect others.
- Allow FTP access only for those addresses from which you work with the server. If suddenly you go on a trip or change the provider, you can always correct the IP whitelist over SSH.
- Remember about strong passwords. The network constantly operates a lot of robots select the details of access to FTP servers using standard links - admin: admin, website_name: ftppassword, etc.
- When installing web applications, do not mindlessly put 777 on those directories that are listed in the documentation. If the web server runs scripts on behalf of the owner, and writes something in these directories, then not everyone needs permission to write to them, but only the owner of the scripts (as a rule, this is the owner of directories, so even the rights 700 can enough).
- Well, the standard phrase (they say, if the same words are repeated to a person many times, then they will fall into the subconscious) - watch for updates of web applications installed on your websites. If possible, subscribe to their security newsletters or relevant sections of the support forum. There you can learn about the upcoming problem much earlier than the release of the patch.
Thank you for your time. I hope you learned something from this article for yourself.
Source: https://habr.com/ru/post/142933/
All Articles