📜 ⬆️ ⬇️

Where to look if the site is constantly hacked, or how I caught the malware on the site of one of the clients

image

This story began quite prosaic. One of the clients began to complain that on his website, working on the CMS Bitrix, the module settings or the website generally stop working with “spitting up errors” where they should not be. I changed the passwords to the client, restored the site from the night backup and calmly went about their business, writing off the situation to the usual password compromise and vandalism.

But not after a few hours, the symptoms reoccurred again, with chunks of PHP code being erased in random places, which made it possible to believe that they were trying to turn off the site on purpose. Conclusions who would need to extinguish a typical state site of a small settlement with an attendance of 5-6 people per day will be left to the staff of the competent authorities, I will tell you briefly for beginners how to act in this case.

1) We look at 2ip.ru or another similar service with our external ip address, and also ask all site administrators to send ip from which they are now connected to the Internet. Here the rule is simple - access to the administrative folders 1C-Bitrix should come only from these addresses.
')
2) Open the web server access log file, for apache web server, it usually lies on the server along the path /var/log/apache2/access.log . We are looking for requests for admin files from addresses not owned by site administrators. In my particular case, I was embarrassed by this line:
xxx.xxx.xxx.xxx - - [xx/xx/2015:xx:xx:xx +0300] "POST /bitrix/admin/htmleditor2/bitrix_log.php HTTP/1.0" 200 4 "http://xxxxxxxxxxxxx/bitrix/admin/htmleditor2/bitrix_log.php" "Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Firefox/31.0" 

Here it is not only that access to the admin file comes from an IP address that is not in the list from the first item, but also to the file that was not originally in the CMS delivery of Bitrix! When working with logs and files, it is advisable to deploy a separate reference copy of the CMS, on which the site works, so that you can compare files for changes or not.

3) Open the file /bitrix/admin/htmleditor2/bitrix_log.php. Eyes appears following a jumble of characters:

 <?php $auth_pass = "b1248f5dde2d214b74ef121288b61801"; $color = "#df5"; $default_action = 'FilesMan'; $default_use_ajax = true; $default_charset = 'Windows-1251'; $o='HZzFksNKuoQ';//   20    ,      //eval("\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65\x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28\x24\x6F\x29\x29\x29\x3B"); 

I immediately commented out the eval () function, which the attacker tried to hide behind a bunch of characters (as it turned out later, this text view of the zip archive).

In principle, for ordinary administrators, you could simply delete the file, search for the eval function for the remaining scripts, and where it should not be - delete it and finish your research. But I decided to see what this folk art work does with the site and the server.

First, pay attention to the line:

 eval("\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65\x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28\x24\x6F\x29\x29\x29\x3B"); 


HEX symbol substitutes are visible to the naked eye. Any HEX decoder will help to turn them into readable text with the naked eye, I used it .
After feeding the pants to the decoder, the characters turn into:

 eval(gzinflate(base64_decode($o))) 

in elegant family pants the execution of the code, which is decoded and unzipped from the $ o variable (which contains a bunch of "unknowns", or rather just contains archived information). The developer of this creation tried very hard to protect it from deobfuscation, namely, when trying to decrypt the variable $ o , we stumble again with eval (gzinflate (base64_decode ([CLEAR OF SYMBOLS]))) . But this can be circumvented.

The code was rewritten a bit, after the mash of the characters I add the decryption code:

 $string = gzinflate(base64_decode($o)); 

after that we know that the code cyclically unzips itself and runs the unzipped piece, i.e. you can simply go through the same cycle, but without executing the code, but dropping it into any of the variables until you completely unzip it. because in each “iteration” of the archive, the code contains the initial string eval (gzinflate (base64_decode ( after the unarchived version does not have this string, you can stop the cycle). Unpacked code is merged into some kind of file for further analysis.

Here is the implementation of this PHP code:

 while (substr_count($string,"eval(gzinflate(base64_decode(")>0) { $string = str_replace("eval(gzinflate(base64_decode('","",$string); $string = str_replace("')));",");",$string); $string =gzinflate(base64_decode($string)); } file_put_contents("unpacked.dat",$string); 

After the end of the script, open unpacked.dat and see the typical php shell (which sea) with the file manager and other "gingerbread". On the server, the site of each client operates under the rights of the user of this client, which are quite severely curtailed, plus the exec () command is prohibited. Therefore, the attacker sneered only at this site and could not crawl to the others.

And he chose a not very good method of obfuscating his shell - the eval function is used quite rarely in the bitrix, and this one was very easy to find using this function, plus “random symbols” immediately suggest suspicion. Because of this, the shell stands out in the overall structure of the site as a clown at a funeral.

The shell hit path also turned out to be quite non-trivial - earlier, the client had 2 copies of the site on the server, one of which was the old version of the site on the old and “leaky-sieve” version of Joomla. This version of the site was left for easy transfer of content to the new site. At that moment, a shell was loaded through a hole in Joomla (the sites were located under one user in neighboring folders).

Therefore, I always place old versions of sites on a separate virtual machine, which is not a pity. As I advise you.

UPD Removed the wording “govnosimvoly”, so as not to offend particularly impressionable.

Source: https://habr.com/ru/post/255899/


All Articles