Faille de sécurité prestashop, avez vous recu le mail?

[Manu-41]

Bonjour, j'ai recu ce mail aujourd'hui, c'est quoi?

In order to maintain the quality of our services, we inform you that a security vulnerability has been identified.

This vulnerability is likely to affect stores that have not carried out the latest recommended software updates.

In case you are affected, we invite you to take note of the details of this vulnerability in order to fix it as soon as possible and take the necessary measures that you or your Data Protection Officer may deem necessary.

In case your shop is compromised and in order to allow you to notify this personal data breach to the supervisory authority on this page of the website of the Commission Nationale de l'Informatique et des Libertés (hereinafter the "CNIL"), we share with you below the course of the investigations carried out, together with the first technical evidence in our possession.

On July 19, 2022, at 2:00 pm, several members of the PrestaShop ecosystem notified PrestaShop employees of security incidents.

A few hours later, it was confirmed by PrestaShop's technical teams that a malicious code ("payload") was inserted by a malicious third party on several e-commerce stores.

The same day at 10:00 pm, PrestaShop technical teams were able to understand and reproduce the attack and could confirm the existence of the security flaw that would allow a malicious third party to insert malicious code into the scripts of e-commerce stores hosted by the PrestaShop company and created with its solution.

The insertion of this malicious code, likely to allow this (these) third party (ies) to take control of the sites concerned seems to have been made possible by an "SQL injection", coupled with a security flaw found in the operators of these stores who have not performed the latest software updates recommended by the company PrestaShop.

On the morning of July 20, 2022, a report was written by the members of the crisis unit to describe the cyber attack, its causes and consequences identified, as well as the resolution and communication measures to be implemented.

To date, a criminal complaint is being filed as well as a declaration to the National Agency for the Security of Information Systems.

In case you need additional information, please contact us at our email address: [email protected].

For all purposes, we remind you that it is your responsibility to make the necessary software updates to ensure that the systems remain protected against security vulnerabilities.

In order to know more about "how the attack works, what to do to keep you shop safe and how to tell if you have been infected" please read the following article: here

Please be assured that we will do our utmost to assist you in the completion of your project.

Best regards,

PrestaShop

 

En Français:

Afin de maintenir la qualité de nos services, nous vous informons qu'une faille de sécurité a été identifiée. Cette vulnérabilité est susceptible d'affecter les magasins qui n'ont pas effectué les dernières mises à jour logicielles recommandées. Dans le cas où vous seriez concerné, nous vous invitons à prendre connaissance du détail de cette vulnérabilité afin d'y remédier au plus vite et de prendre les mesures nécessaires que vous ou votre délégué à la protection des données jugerez nécessaires. Dans le cas où votre boutique serait compromise et afin de vous permettre de signaler cette violation de données personnelles à l'autorité de contrôle sur cette page du site de la Commission Nationale de l'Informatique et des Libertés (ci-après la « CNIL »), nous partageons avec vous présente ci-dessous le déroulement des investigations menées, ainsi que les premières preuves techniques en notre possession. Le 19 juillet 2022 à 14h00, plusieurs membres de l'écosystème PrestaShop ont notifié aux employés de PrestaShop des incidents de sécurité. Quelques heures plus tard, il était confirmé par les équipes techniques de PrestaShop qu'un code malveillant (« payload ») avait été inséré par un tiers malveillant sur plusieurs boutiques e-commerce. Le même jour à 22h00, les équipes techniques de PrestaShop ont pu comprendre et reproduire l'attaque et ont pu confirmer l'existence de la faille de sécurité qui permettrait à un tiers malveillant d'insérer du code malveillant dans les scripts des boutiques e-commerce hébergées par la société PrestaShop et créé avec sa solution. L'insertion de ce code malveillant, susceptible de permettre à ce(s) tiers(s) de prendre le contrôle des sites concernés semble avoir été rendue possible par une « injection SQL », doublée d'une faille de sécurité constatée chez les opérateurs de ces les boutiques n'ayant pas effectué les dernières mises à jour logicielles recommandées par la société PrestaShop. Le 20 juillet 2022 au matin, un rapport a été rédigé par les membres de la cellule de crise pour décrire la cyberattaque, ses causes et ses conséquences identifiées, ainsi que les mesures de résolution et de communication à mettre en place. A ce jour, une plainte pénale est en cours de dépôt ainsi qu'une déclaration auprès de l'Agence Nationale de la Sécurité des Systèmes d'Information. Si vous avez besoin d'informations supplémentaires, veuillez nous contacter à notre adresse e-mail : [email protected]. À toutes fins utiles, nous vous rappelons qu'il est de votre responsabilité d'effectuer les mises à jour logicielles nécessaires pour vous assurer que les systèmes restent protégés contre les failles de sécurité. Pour en savoir plus sur « comment fonctionne l'attaque, que faire pour assurer la sécurité de votre magasin et comment savoir si vous avez été infecté », veuillez lire l'article suivant : ici Soyez assuré que nous ferons tout notre possible pour vous accompagner dans la réalisation de votre projet. Meilleures salutations, PrestaShop

Edited July 22, 2022 by Manu-41 (see edit history)

[Gu1llaume]

Bonjour,

Une traduction a été faites par @Mediacom87 :  https://www.mediacom87.fr/vulnerabilite-majeure-de-securite-sur-les-sites-prestashop/

Appliquer le correctif mentionné dans l'article sur le fichier config/smarty.config.inc.php

Mon conseil supplémentaire, désinstaller et supprimer le module wishlist (blockwishlist) si pas utilisé, genre chez moi il été désactivé mais pas désinstallé, donc toujours présent/accessible.

Bon vendredi

[NicolasV]

Oui, on a reçu aussi.

[gouna]

Reçu également, je vais appliquer le correctif en attendant, merci pour l'info!

[gtul]

44 minutes ago, Gu1llaume said:

Bonjour,

Une traduction a été faites par @Mediacom87 :  https://www.mediacom87.fr/vulnerabilite-majeure-de-securite-sur-les-sites-prestashop/

Appliquer le correctif mentionné dans l'article sur le fichier config/smarty.config.inc.php

Mon conseil supplémentaire, désinstaller et supprimer le module wishlist (blockwishlist) si pas utilisé, genre chez moi il été désactivé mais pas désinstallé, donc toujours présent/accessible.

Bon vendredi

Sais-tu si ce correctif peut affecter en quelque sort les modules? et aussi sais-tu où on doit aller pour regarder le journal d'accès? 

[Mediacom87]

il y a 41 minutes, gtul a dit :

Sais-tu si ce correctif peut affecter en quelque sort les modules

Non, aucune incidence

il y a 41 minutes, gtul a dit :

aussi sais-tu où on doit aller pour regarder le journal d'accès

vous renseigner auprès de votre hébergeur

[Manu-41]

Merci pour le correctif

 

[mandrake]

Bonsoir, merci pour l'information !

Le fichier config/smarty.config.inc.php de la version 1.6.0.8 est différent.

On n'y trouve pas la portion de code indiquée à supprimer.

Quelqu'un a une idée sur la partie à supprimer dans cette version ?

Merci.

<?php
/*
* 2007-2014 PrestaShop
*
* NOTICE OF LICENSE
*
* This source file is subject to the Open Software License (OSL 3.0)
* that is bundled with this package in the file LICENSE.txt.
* It is also available through the world-wide-web at this URL:
* http://opensource.org/licenses/osl-3.0.php
* If you did not receive a copy of the license and are unable to
* obtain it through the world-wide-web, please send an email
* to [email protected] so we can send you a copy immediately.
*
* DISCLAIMER
*
* Do not edit or add to this file if you wish to upgrade PrestaShop to newer
* versions in the future. If you wish to customize PrestaShop for your
* needs please refer to http://www.prestashop.com for more information.
*
*  @author PrestaShop SA <[email protected]>
*  @copyright  2007-2014 PrestaShop SA
*  @license    http://opensource.org/licenses/osl-3.0.php  Open Software License (OSL 3.0)
*  International Registered Trademark & Property of PrestaShop SA
*/

define('_PS_SMARTY_DIR_', _PS_TOOL_DIR_.'smarty/');

require_once(_PS_SMARTY_DIR_.'Smarty.class.php');

global $smarty;
$smarty = new Smarty();
$smarty->setCompileDir(_PS_CACHE_DIR_.'smarty/compile');
$smarty->setCacheDir(_PS_CACHE_DIR_.'smarty/cache');
if (!Tools::getSafeModeStatus())
	$smarty->use_sub_dirs = true;
$smarty->setConfigDir(_PS_SMARTY_DIR_.'configs');
$smarty->caching = false;
$smarty->force_compile = (Configuration::get('PS_SMARTY_FORCE_COMPILE') == _PS_SMARTY_FORCE_COMPILE_) ? true : false;
$smarty->compile_check = (Configuration::get('PS_SMARTY_FORCE_COMPILE') >= _PS_SMARTY_CHECK_COMPILE_) ? true : false;

/* Use this constant if you want to load smarty without all PrestaShop functions */
if (defined('_PS_SMARTY_FAST_LOAD_') && _PS_SMARTY_FAST_LOAD_)
	return;

if (defined('_PS_ADMIN_DIR_'))
	require_once (dirname(__FILE__).'/smartyadmin.config.inc.php');
else
	require_once (dirname(__FILE__).'/smartyfront.config.inc.php');

smartyRegisterFunction($smarty, 'modifier', 'truncate', 'smarty_modifier_truncate');
smartyRegisterFunction($smarty, 'modifier', 'secureReferrer', array('Tools', 'secureReferrer'));

smartyRegisterFunction($smarty, 'function', 't', 'smartyTruncate'); // unused
smartyRegisterFunction($smarty, 'function', 'm', 'smartyMaxWords'); // unused
smartyRegisterFunction($smarty, 'function', 'p', 'smartyShowObject'); // Debug only
smartyRegisterFunction($smarty, 'function', 'd', 'smartyDieObject'); // Debug only
smartyRegisterFunction($smarty, 'function', 'l', 'smartyTranslate', false);
smartyRegisterFunction($smarty, 'function', 'hook', 'smartyHook');
smartyRegisterFunction($smarty, 'function', 'toolsConvertPrice', 'toolsConvertPrice');
smartyRegisterFunction($smarty, 'modifier', 'json_encode', array('Tools', 'jsonEncode'));
smartyRegisterFunction($smarty, 'modifier', 'json_decode', array('Tools', 'jsonDecode'));
smartyRegisterFunction($smarty, 'function', 'dateFormat', array('Tools', 'dateFormat'));
smartyRegisterFunction($smarty, 'function', 'convertPrice', array('Product', 'convertPrice'));
smartyRegisterFunction($smarty, 'function', 'convertPriceWithCurrency', array('Product', 'convertPriceWithCurrency'));
smartyRegisterFunction($smarty, 'function', 'displayWtPrice', array('Product', 'displayWtPrice'));
smartyRegisterFunction($smarty, 'function', 'displayWtPriceWithCurrency', array('Product', 'displayWtPriceWithCurrency'));
smartyRegisterFunction($smarty, 'function', 'displayPrice', array('Tools', 'displayPriceSmarty'));
smartyRegisterFunction($smarty, 'modifier', 'convertAndFormatPrice', array('Product', 'convertAndFormatPrice')); // used twice
smartyRegisterFunction($smarty, 'function', 'getAdminToken', array('Tools', 'getAdminTokenLiteSmarty'));
smartyRegisterFunction($smarty, 'function', 'displayAddressDetail', array('AddressFormat', 'generateAddressSmarty'));
smartyRegisterFunction($smarty, 'function', 'getWidthSize', array('Image', 'getWidth'));
smartyRegisterFunction($smarty, 'function', 'getHeightSize', array('Image', 'getHeight'));
smartyRegisterFunction($smarty, 'function', 'addJsDef', array('Media', 'addJsDef'));
smartyRegisterFunction($smarty, 'block', 'addJsDefL', array('Media', 'addJsDefL'));
smartyRegisterFunction($smarty, 'modifier', 'boolval', array('Tools', 'boolval'));

function smartyDieObject($params, &$smarty)
{
	return Tools::d($params['var']);
}

function smartyShowObject($params, &$smarty)
{
	return Tools::p($params['var']);
}

function smartyMaxWords($params, &$smarty)
{
	Tools::displayAsDeprecated();
	$params['s'] = str_replace('...', ' ...', html_entity_decode($params['s'], ENT_QUOTES, 'UTF-8'));
	$words = explode(' ', $params['s']);

	foreach($words AS &$word)
		if(Tools::strlen($word) > $params['n'])
			$word = Tools::substr(trim(chunk_split($word, $params['n']-1, '- ')), 0, -1);

	return implode(' ',  Tools::htmlentitiesUTF8($words));
}

function smartyTruncate($params, &$smarty)
{
	Tools::displayAsDeprecated();
	$text = isset($params['strip']) ? strip_tags($params['text']) : $params['text'];
	$length = $params['length'];
	$sep = isset($params['sep']) ? $params['sep'] : '...';

	if (Tools::strlen($text) > $length + Tools::strlen($sep))
		$text = Tools::substr($text, 0, $length).$sep;

	return (isset($params['encode']) ? Tools::htmlentitiesUTF8($text, ENT_NOQUOTES) : $text);
}

function smarty_modifier_truncate($string, $length = 80, $etc = '...', $break_words = false, $middle = false, $charset = 'UTF-8')
{
	if (!$length)
		return '';

	$string = trim($string);

	if (Tools::strlen($string) > $length)
	{
		$length -= min($length, Tools::strlen($etc));
		if (!$break_words && !$middle)
			$string = preg_replace('/\s+?(\S+)?$/u', '', Tools::substr($string, 0, $length+1, $charset));
		return !$middle ? Tools::substr($string, 0, $length, $charset).$etc : Tools::substr($string, 0, $length/2, $charset).$etc.Tools::substr($string, -$length/2, $length, $charset);
	}
	else
		return $string;
}

function smarty_modifier_htmlentitiesUTF8($string)
{
		return Tools::htmlentitiesUTF8($string);
}
function smartyMinifyHTML($tpl_output, &$smarty)
{
	if (in_array(Context::getContext()->controller->php_self, array('pdf-invoice', 'pdf-order-return', 'pdf-order-slip')))
		return $tpl_output;
    $tpl_output = Media::minifyHTML($tpl_output);
    return $tpl_output;
}

function smartyPackJSinHTML($tpl_output, &$smarty)
{
	if (in_array(Context::getContext()->controller->php_self, array('pdf-invoice', 'pdf-order-return', 'pdf-order-slip')))
		return $tpl_output;
    $tpl_output = Media::packJSinHTML($tpl_output);
    return $tpl_output;
}

function smartyRegisterFunction($smarty, $type, $function, $params, $lazy = true)
{
	if (!in_array($type, array('function', 'modifier', 'block')))
		return false;

	// lazy is better if the function is not called on every page
	if ($lazy)
	{
		$lazy_register = SmartyLazyRegister::getInstance();
		$lazy_register->register($params);

		if (is_array($params))
			$params = $params[1];

		// SmartyLazyRegister allows to only load external class when they are needed
		$smarty->registerPlugin($type, $function, array($lazy_register, $params));
	}
	else
		$smarty->registerPlugin($type, $function, $params);
}

function smartyHook($params, &$smarty)
{
	if (!empty($params['h']))
	{
		$id_module = null;
		$hook_params = $params;
		$hook_params['smarty'] = $smarty;
		if (!empty($params['mod']))
		{
			$module = Module::getInstanceByName($params['mod']);
			if ($module && $module->id)
				$id_module = $module->id;
			unset($hook_params['mod']);
		}
		unset($hook_params['h']);
		return Hook::exec($params['h'], $hook_params, $id_module);
	}
}

function toolsConvertPrice($params, &$smarty)
{
	return Tools::convertPrice($params['price'], Context::getContext()->currency);
}

/**
 * Used to delay loading of external classes with smarty->register_plugin
 */
class SmartyLazyRegister
{
	protected $registry = array();
	protected static $instance;

	/**
	 * Register a function or method to be dynamically called later
	 * @param string|array $params function name or array(object name, method name)
	 */
	public function register($params)
	{
		if (is_array($params))
			$this->registry[$params[1]] = $params;
		else
			$this->registry[$params] = $params;
	}

	/**
	 * Dynamically call static function or method
	 *
	 * @param string $name function name
	 * @param mixed $arguments function argument
	 * @return mixed function return
	 */
	public function __call($name, $arguments)
	{
		$item = $this->registry[$name];

		// case 1: call to static method - case 2 : call to static function
		if (is_array($item[1]))
			return call_user_func_array($item[1].'::'.$item[0], array($arguments[0], &$arguments[1]));
		else
		{
			$args = array();
			
			foreach($arguments as $a => $argument)
				if($a == 0)
					$args[] = $arguments[0]; 
				else
					$args[] = &$arguments[$a]; 
			
			return call_user_func_array($item, $args);
		}
	}

	public static function getInstance()
	{
		if (!self::$instance)
			self::$instance = new SmartyLazyRegister();
		return self::$instance;
	}
}

 

[mandrake]

Bonsoir, merci pour l'information !

Le fichier config/smarty.config.inc.php de la version 1.6.0.8 est différent.

On n'y trouve pas la portion de code indiquée à supprimer.

Quelqu'un a une idée sur la partie à supprimer dans cette version ?

Merci.

[Mediacom87]

Il y a 2 heures, mandrake a dit :

Le fichier config/smarty.config.inc.php de la version 1.6.0.8 est différent.

Citation

Dans l'état actuel de nos connaissances, ce problème semble concerner les boutiques basées sur les versions 1.6.0.10 ou supérieures, sujettes à des vulnérabilités d'injection SQL.

 

[Sbot78]

oui reçu aussi....

 

[Eolia]

Concernant le dernier hack #prestashop, un script de nettoyage (Ouvrez le zip, prenez le fichier cleaner.php et placez-le à la racine de votre site, puis vous l'appelez avec cette url: https://votresite.com/cleaner.php)

https://devcustom.net/public/scripts/cleaner.zip

** Edit**

Le script se met à jour automatiquement.

Pour info, la description que donne prestashop n'a pas grand chose à voir avec le hack actuel^^

L'avis de @doekia sur la question

 

 

cleaner.zip

Edited August 16, 2022 by Eolia (see edit history)

[Gu1llaume]

C'est vraiment inquiétant de ne pas savoir précisément ce qu'il faut rechercher dans les logs parce que bon blm.php ...

[Florent]

Il y a 3 heures, Eolia a dit :

Concernant le dernier hack #prestashop, un script de nettoyage (à placer à la racine de votre site et à appeler avec: https://votresite.com/cleaner.php)

https://devcustom.net/public/scripts/cleaner.zip

Merci pour les infos et le script de nettoyage.
Juste une question, le script nettoie les fichiers corrompus, mais est-ce qu'il protège contre une nouvelle attaque ?

[Eolia]

Non, car si vous avez été infecté c'est que vous avez une porte d'entrée (un module avec la fonction move_uploaded_files()) mal protégé.

[manolo]

On 7/22/2022 at 9:59 PM, mandrake said:

Bonsoir, merci pour l'information !

Le fichier config/smarty.config.inc.php de la version 1.6.0.8 est différent.

On n'y trouve pas la portion de code indiquée à supprimer.

Quelqu'un a une idée sur la partie à supprimer dans cette version ?

Merci.

Bonjour, j'ai le meme probleme, ma version est 1.6.0.6 et le fichier config/smarty.config.inc.php est similaire a le tien (mon français ecrit n'est pas tres bone, je change a l'anglais)

When I try to enter the admin panel, I put the email and the password, it takes me to index.php?controller=AdminLogin&token=a26cBLABLABLA...&redirect=AdminDashboard  but no message or screen change. I'm not a prestashop developer so I don't know exactly what is the problem because it seems to log into prestashop but the screen maybe does not change because smarty is corrupt.

I have analyzed previous days logs and I have seen some suspicious GET/POST from IP 92.205.110.171 using a python script, here is the sequence..

92.205.110.171 - - [18/Jul/2022:03:53:11 +0000] "GET /en//modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 67207 "-" "python-requests/2.27.1"
92.205.110.171 - - [18/Jul/2022:03:53:13 +0000] "GET /en//modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/XsamXadoo_Bot_Rce.php HTTP/1.1" 404 67211 "-" "python-requests/2.27.1"
92.205.110.171 - - [18/Jul/2022:03:53:17 +0000] "GET /en//modules/ps_facetedsearch/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 67205 "-" "python-requests/2.27.1"
92.205.110.171 - - [18/Jul/2022:03:53:19 +0000] "GET /en//modules/ps_facetedsearch/vendor/phpunit/phpunit/src/Util/PHP/XsamXadoo_Bot_Rce.php HTTP/1.1" 404 67209 "-" "python-requests/2.27.1"
92.205.110.171 - - [18/Jul/2022:03:53:23 +0000] "GET /en//modules/gamification/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 67205 "-" "python-requests/2.27.1"
92.205.110.171 - - [18/Jul/2022:03:53:26 +0000] "GET /en//modules/gamification/vendor/phpunit/phpunit/src/Util/PHP/XsamXadoo_Bot_Rce.php HTTP/1.1" 404 67211 "-" "python-requests/2.27.1"
92.205.110.171 - - [18/Jul/2022:03:53:29 +0000] "POST /en//modules/smartprestashopthemeadmin/ajax_smartprestashopthemeadmin.php HTTP/1.1" 404 67205 "-" "python-requests/2.27.1"
92.205.110.171 - - [18/Jul/2022:03:53:32 +0000] "POST /en//modules/jmsslider/ajax_jmsslider.php?action=addLayer&id_slide=XSam-XAdoo&data_type=image HTTP/1.1" 404 67325 "-" "python-requests/2.27.1"
92.205.110.171 - - [18/Jul/2022:03:53:36 +0000] "GET /en//modules/jmsslider/views/img/layers/xsam_xadoo_bot.php HTTP/1.1" 404 67207 "-" "python-requests/2.27.1"
92.205.110.171 - - [18/Jul/2022:03:53:39 +0000] "POST /en//modules/groupcategory/GroupCategoryUploadImage.php HTTP/1.1" 404 67205 "-" "python-requests/2.27.1"
92.205.110.171 - - [18/Jul/2022:03:53:43 +0000] "POST /en//modules/verticalmegamenus/VerticalMegaMenusUploadImage.php HTTP/1.1" 404 67209 "-" "python-requests/2.27.1"
92.205.110.171 - - [18/Jul/2022:03:53:47 +0000] "GET /en//modules/verticalmegamenus/images/temps/xsam_xadoo_bot.php HTTP/1.1" 404 67211 "-" "python-requests/2.27.1"
92.205.110.171 - - [18/Jul/2022:03:53:48 +0000] "POST /en//modules/fieldvmegamenu/ajax/upload.php HTTP/1.1" 404 67211 "-" "python-requests/2.27.1"
92.205.110.171 - - [18/Jul/2022:03:53:51 +0000] "GET /en//modules/fieldvmegamenu/uploads/xsam_xadoo_bot.php HTTP/1.1" 404 67203 "-" "python-requests/2.27.1"
92.205.110.171 - - [18/Jul/2022:03:53:55 +0000] "POST /en//modules/vtemskitter/uploadimage.php HTTP/1.1" 404 67207 "-" "python-requests/2.27.1"
92.205.110.171 - - [18/Jul/2022:03:53:57 +0000] "GET /en//modules/vtemskitter/img/xsam_xadoo_bot.php HTTP/1.1" 404 67209 "-" "python-requests/2.27.1"
92.205.110.171 - - [18/Jul/2022:03:53:59 +0000] "POST /en//modules/blocktestimonial/addtestimonial.php HTTP/1.1" 404 67205 "-" "python-requests/2.27.1"
92.205.110.171 - - [18/Jul/2022:03:54:03 +0000] "GET /en//upload/xsam_xadoo_bot.php HTTP/1.1" 404 67205 "-" "python-requests/2.27.1"
92.205.110.171 - - [18/Jul/2022:03:54:06 +0000] "POST /en//modules/blocktestimonial/addtestimonial.php HTTP/1.1" 404 67207 "-" "python-requests/2.27.1"

The files changed (excluding smarty ones) are the following

cache/push/activity
cache/push/trends
config/xml/default_country_modules_list.xml
config/xml/tab_modules_list.xml
config/xml/must_have_modules_list.xml
modules/paypal
modules/paypal/views/img/logos/ES_PayPal_logo_80x35.gif
modules/paypal/views/img/logos/FR_pp_cc_mark_37x23.jpg
modules/paypal/views/img/logos/ES_PayPal_logo_100x45.gif
modules/paypal/views/img/logos/default_PayPal_logo_80x35.gif
modules/paypal/views/img/logos/ES_PayPal_mark_60x38.gif
modules/paypal/views/img/logos/default_PayPal_logo_150x65.gif
modules/paypal/views/img/logos/ES_PayPal_mark_50x34.gif
modules/paypal/views/img/logos/default_PayPal_logo_100x45.gif
modules/paypal/views/img/logos/default_PayPal_mark_37x23.gif
modules/paypal/views/img/logos/FR_pp_cc_mark_111x69.jpg
modules/paypal/views/img/logos/default_PayPal_mark_50x34.gif
modules/paypal/views/img/logos/ES_vertical_solution_PP.gif
modules/paypal/views/img/logos/default_PayPal_mark_60x38.gif
modules/paypal/views/img/logos/ES_PayPal_mark_37x23.gif
modules/paypal/views/img/logos/ES_horizontal_solution_PP.gif
modules/paypal/views/img/logos/ES_PayPal_logo_150x65.gif
modules/paypal/views/img/logos/FR_pp_cc_mark_74x46.jpg
modules/paypal/views/img/logos/FR_logo_paypal_moyens_paiement_fr.jpg
modules/gamification/data/data_ES_EUR_ES.json

So it seems they are hacking paypal module to pick the data typed by the payer. And also gamification module was changed but I'm not sure if this is because of the hackers.

 

Today monday 25 july after analyzing I think that the shop was not attacked. I have reviewed the backup files and only some gif and jpg at modules/paypal/views/img/logos were changed and their content are images (so probably paypal module updated the logos). Also gamification module changed a json but I think is the same, just some update done by the module.

Therefore my conclusion is that in this particular shop case there was no attack, maybe the version is too old to be attacked..

 

Edited July 25, 2022 by manolo (see edit history)

[Florent]

Il y a 2 heures, Eolia a dit :

Non, car si vous avez été infecté c'est que vous avez une porte d'entrée (un module avec la fonction move_uploaded_files()) mal protégé.

Ok merci.
Donc si je comprends bien, pour le moment, on sait nettoyer les fichiers infectés avec le script. Mais, on ne sait pas quels sont les modules potentiellement vulnérables, ni comment corriger cette vulnérabilité ?

[Eolia]

On a une liste ici: https://bb.enter-solutions.net/topic/1075/des-modules-et-des-hacks-liste-non-exhaustive-des-modules-présentant-un-risque/2

[Eolia]

il y a 25 minutes, Florent a dit :

Ok merci.
Donc si je comprends bien, pour le moment, on sait nettoyer les fichiers infectés avec le script. Mais, on ne sait pas quels sont les modules potentiellement vulnérables, ni comment corriger cette vulnérabilité ?

Si vous avez une porte blindée mais que vous laissez la fenêtre ouverte aucune protection ne peut être efficace.Exemple de code dangereux permettant l'upload de fichiers:

if (isset($_POST["datasvgrect"])) {

    if (isset($_POST["datapng"])) {
          $url_img ='upload/png/'.$_POST["nimage"];

          $img = str_replace('data:image/png;base64,', '', $_POST["datapng"]);
            $img = str_replace(' ', '+', $img);
            $preview = base64_decode($img);
      file_put_contents($url_img, $preview);
    }
}

Si le hacker envoie une requête Curl avec datapng et nimage en $_POST (datapng est un fichier encodé en base64, nimage est son nom) celui-ci est décodé en conservant son nom dans le répertoire d'upload.

Celui-ci étant accessible depuis l'extérieur, si le fichier encodé contenait un malware, c'est mort^^

A aucun moment il n'est vérifié que la personne est loguée en tant qu'admin ni que le fichier envoyé est bien une image...

[gtul]

21 hours ago, Eolia said:

Concernant le dernier hack #prestashop, un script de nettoyage (à placer à la racine de votre site et à appeler avec: https://votresite.com/cleaner.php)

https://devcustom.nethttps://votresite.com/cleaner.php)

 

Pour info, la description que donne prestashop n'a pas grand chose à voir avec le hack actuel^^

L'avis de @doekia sur la question

 

 

Si cela ne vous dérange pas. Pourriez-vous nous guider pour faire les étapes par nous même? Cela pourrait également aider d'autres "perdus" comme nous.

Si on comprends bien on doit placer le zip dans le dossier scripts qui se trouve: https://notresite.com/public/scripts/cleaner.zip?

En suite, vous mentionnez "appeler avec le fichier cleaner.php", mais comment faire? 

Un aide serait grandement apprécié.

 

[pokerman]

1/ vous devez télécharger sur votre ordinateur le fichier cleaner.zip
2/ décompresser le fichier pour obtenir  :  cleaner.php
3/ placer ce fichier cleaner.php sur la racine de votre site en FTP
4/ lancer le script en saisissant dans votre navigateur l'url :   https://www.mon-site.com/cleaner.php 
en remplaçant mon-site par le nom de votre site.

[gtul]

16 minutes ago, pokerman said:

1/ vous devez télécharger sur votre ordinateur le fichier cleaner.zip
2/ décompresser le fichier pour obtenir  :  cleaner.php
3/ placer ce fichier cleaner.php sur la racine de votre site en FTP
4/ lancer le script en saisissant dans votre navigateur l'url :   https://www.mon-site.com/cleaner.php 
en remplaçant mon-site par le nom de votre site.

Merci!

- J'ai placé le fichier cleaner.php dans le dossier "public_html" de mon site

- Ensuite, j'ai lancé dans le navigateur https://www.mon-site.com/cleaner.php

- Ça n'a même pas pris 1 second que c'est affiché DONE. C'est ok que cela ne prend pas de temps?

 

[pokerman]

Si vous avez done, tout est ok 

[Eolia]

En fait c'est écrit^^

[gtul]

41 minutes ago, Eolia said:

En fait c'est écrit^^

Oui, exactement le message qu'on a eu. Merci.

[Eolia]

La dernière version (1.0.12) ajoute un contrôle MD5 des fichiers principaux par rapport aux originaux de votre version^^

[doekia]

Toute personne ayant une version 1.6 inférieure à 1.6.1.22 doit IMPERATIVEMENT corriger dans son  <admin>/filemanager/*

C'est d'autant plus vrai si vous soupçonnez que vos url/login/pass BO ont put être affectés. (attaque par phar deserialize)

ICI une version saine de ce répertoire. https://github.com/PrestaShop/PrestaShop/tree/1.6.1.24/admin-dev/filemanager

Remplacez simplement les fichiers

Edited July 25, 2022 by doekia (see edit history)

[Gu1llaume]

6 minutes ago, doekia said:

ICI une version saine de ce répertoire. https://github.com/PrestaShop/PrestaShop/tree/1.6.1.24/admin-dev/filemanager

 

Merci mais attention il y a une coquille dans le lien (dans le href) c'est bien la version 1.6.1.24 à récupérer et non la 1.6.1.23

https://github.com/PrestaShop/PrestaShop/tree/1.6.1.24/admin-dev/filemanager

 

[doekia]

C'est 2 versions  (.23 et .24) ont un contenu strictement identique concernant filemanager

[Gu1llaume]

Parfait merci, mais peux-tu corriger ton lien pour la cohérence ? Car afficher 1.6.1.24 et quand on clique on tombe sur 1.6.1.23 ça peut créer une confusion

[mandrake]

Bonjour et merci pour ces informations ô combien précieuses !

Otez-moi d'un doute ... Le dossier filemanager sur un 1.6.1.4 peut être remplacé lui aussi par celui du lien github ?

[Prestasec]

5 hours ago, doekia said:

Toute personne ayant une version 1.6 inférieure à 1.6.1.22 doit IMPERATIVEMENT corriger dans son  <admin>/filemanager/*

C'est d'autant plus vrai si vous soupçonnez que vos url/login/pass BO ont put être affectés. (attaque par phar deserialize)

ICI une version saine de ce répertoire. https://github.com/PrestaShop/PrestaShop/tree/1.6.1.24/admin-dev/filemanager

Remplacez simplement les fichiers

 

 

 

Pouvez-vous expliquer quelle est la principale différence entre le code de 1.6 mais inférieur à 1.6.1.22, de sorte que le code du gestionnaire de fichiers de 1.6.1.24 doit être utilisé ? Est-ce utile si l'attaquant n'a pas accès à la page de connexion de l'administrateur ? J'ai restreint cela.

Can you explain what is the main difference between the code of 1.6 but below 1.6122 so that filemanager code from 1.6.1.24 needs to be used ?

Does it help if the attacker does not have acces to the admin login page ? I have restricted that.

 

[Eolia]

La dernière version du script (1.0.15) contrôle /filemanager et propose le patch automatique

Edited July 25, 2022 by Eolia (see edit history)

[Cécile NVM]

Merci à @eolia et tous ceux qui nous aident à comprendre et vérifier, corriger après l'annonce de cette faille qui nous laisse bien dans l'embarras. 
Je suis en 1.7.6.8 avec tous mes modules à jour, j'ai vérifié mes fichiers, désactivé smarty, passé au cleaner (RAS).. Pensez-vous que je doive mettre à jour sur la dernière version comme ils le préconisent (avec tout ce que cela implique de sueur et de risques  ) 

--> En fait cela va être réglé puisque je n'arrive pas à faire de mise à jour... et que Prestashop m'invite à payer du support ou une assistance mise à jour à 899€ --- Je crois que je vais vraiment finir par refaire toute ma boutique en WP 

Edited July 25, 2022 by Cécile NVM
Mise à jour impossible (see edit history)

[Mediacom87]

il y a 5 minutes, Eolia a dit :

La dernière version du script (1.0.15) contrôle /filemanager et propose le patch automatique

Salut,

La version en téléchargement actuellement disponible semble être la version 1.0.10, mais peut-être n'as-tu pas encore eu le temps de modifier les lignes de version.

[pokerman]

Je suis en 1.7.8.6 et j 'ai un message d'erreur comme quoi ma version 1.6  répertoire admin/filemanager n'est pas patché et me propose de patcher , que dois-je faire ?

 

[Eolia]

il y a 8 minutes, Mediacom87 a dit :

Salut,

La version en téléchargement actuellement disponible semble être la version 1.0.10, mais peut-être n'as-tu pas encore eu le temps de modifier les lignes de version.

Le script se met à jour au lancement

[Eolia]

il y a 5 minutes, pokerman a dit :

Je suis en 1.7.8.6 et j 'ai un message d'erreur comme quoi ma version 1.6  répertoire admin/filemanager n'est pas patché et me propose de patcher , que dois-je faire ?

 

Non, oubliez, je n'ai pas effectué le diff des 1.7 sur ce répertoire.

[pokerman]

ok, merci

[gtul]

On 7/23/2022 at 2:39 PM, Eolia said:

Concernant le dernier hack #prestashop, un script de nettoyage (à placer à la racine de votre site et à appeler avec: https://votresite.com/cleaner.php)

https://devcustom.net/public/scripts/cleaner.zip

** Edit**

Le script se met à jour automatiquement.

Pour info, la description que donne prestashop n'a pas grand chose à voir avec le hack actuel^^

L'avis de @doekia sur la question

 

 

Alors, on n'a pas besoin de replacer à nouveau le fichier php dans notre racine mais on le lance encore une fois dans votre navigateur l'url ? C'est bien ça?

[Eolia]

Oui, le script va contrôler la version et se mettre à jour si nécessaire.

[Eolia]

Cet ajout est une information.

En effet, le seul moyen d'ajouter des fichiers sur votre hébergement passe par 2 fonctions php: move_uploaded_file ou file_put_contents

Si ces fonctions sont dans une classe ou un controleur, pas de souci. Si c'est un fichier seul genre upload.php il est bon d'aller y jeter un oeil pour s'assurer que les données sont bien contrôlées avant d'être écrites.

exemple de fichier qui ne contrôle rien découvert aujourd'hui:

<?php
$output_dir = "uploads/";
if(isset($_FILES["myfile"]))
{
	$ret = array();
	
//	This is for custom errors;	
/*	$custom_error= array();
	$custom_error['jquery-upload-file-error']="File already exists";
	echo json_encode($custom_error);
	die();
*/
	$error =$_FILES["myfile"]["error"];
	//You need to handle  both cases
	//If Any browser does not support serializing of multiple files using FormData() 
	if(!is_array($_FILES["myfile"]["name"])) //single file
	{
 	 	$fileName = $_FILES["myfile"]["name"];
 		move_uploaded_file($_FILES["myfile"]["tmp_name"],$output_dir.$fileName);
    	$ret[]= $fileName;
	}
	else  //Multiple files, file[]
	{
	  $fileCount = count($_FILES["myfile"]["name"]);
	  for($i=0; $i < $fileCount; $i++)
	  {
	  	$fileName = $_FILES["myfile"]["name"][$i];
		move_uploaded_file($_FILES["myfile"]["tmp_name"][$i],$output_dir.$fileName);
	  	$ret[]= $fileName;
	  }
	
	}
    echo json_encode($ret);
 }
 ?>

trouvé dans /modules/nvn_excel_import/upload.php...

[olivier666]

salut a tous

Je suis pas un crack en prestashop mais j aurai une petite question .

Voila je suis sous 1.7.7.8 et je suis pas chaud pour passez en dernière version corrigée qui vient de sortir .

Est ce que le fait d avoir supprimer les 4 lignes ( 43 a 46 ) comme le préconise prestashop suffit à protéger la boutique contre cette faille?

Si cela ne suffit pas, quelles sont les autres alternatives s il y en a ?

Désolé pour ma question qui va vous paraitre un peu simple mais je tourne un peu en rond !

 

merci d avance

 

olivier 

[passionimaux59]

Bonjour nous avons rencontré une erreur lors d'une tentative de mise a jour : 1.7.8.5 -> 1.7.8.7

lorsque que nous tentons de mettre PrestaShop a jour une erreur de permission s'affiche (voir capture d'écran) a l'enregistrement des fichier (environs 45k restants) 

savez vous comment pallier a ce problème ? merci d'avance!

 

 

[Carllama]

Bonsoir tout le monde,

Tout d'abord merci pour la création, mise en place et partage du cleaner. C'est appréciable. 

Je voulais savoir si le script cleaner php ne détecte rien (aucun fichier rouge) c'est que tout est ok ?

Si on a un prestashop en 1.7.7.7 est il nécessaire de la passer en 1.7.8.7 avec tous les aleas que cela peut comporter ^^

Je remercie par avance les personnes qui prendront le temps de me répondre.

Belle soirée à vous tout.

 

[Mediacom87]

Il y a 12 heures, passionimaux59 a dit :

Bonjour nous avons rencontré une erreur lors d'une tentative de mise a jour : 1.7.8.5 -> 1.7.8.7

lorsque que nous tentons de mettre PrestaShop a jour une erreur de permission s'affiche (voir capture d'écran) a l'enregistrement des fichier (environs 45k restants) 

savez vous comment pallier a ce problème ? merci d'avance!

 

 

Bonjour,

votre souci de mise à jour n'a pas de lien avec le sujet du topic mais sachez que dans tous les cas, pour utiliser convenablement 1-click upgrade il faut effectuer la sauvegarde intégrale de votre boutique manuellement (Fichier et base de données) avec une procédure que vous maîtrisez pour effectuer la restauration en cas de problème lors de la mise à jour.

Une mise à jour se test toujours sur une version de Test de votre boutique avant de la reproduire sur votre boutique en production.

Et donc pour faire la mise à jour avec 1-click upgrade il faut désactiver l'option de backup proposé par ce module.

[yama]

@olivier666 Ca semble pas etre le meme bug

@passionimaux59 C'est pas le sujet ici

@Carllama Oui mais pas a 100%

Edited July 26, 2022 by yama (see edit history)

[Eolia]

Il y a 11 heures, Carllama a dit :

Bonsoir tout le monde,

Tout d'abord merci pour la création, mise en place et partage du cleaner. C'est appréciable. 

Je voulais savoir si le script cleaner php ne détecte rien (aucun fichier rouge) c'est que tout est ok ?

Si on a un prestashop en 1.7.7.7 est il nécessaire de la passer en 1.7.8.7 avec tous les aleas que cela peut comporter ^^

Je remercie par avance les personnes qui prendront le temps de me répondre.

Belle soirée à vous tout.

 

La "Faille" patchée par Prestashop pour les 1.7 concerne un risque d'injection SQL, aucun rapport avec le hack recherché par le script de nettoyage.

Pour info, les 1.6 n'ont pas cette faille d'injection SQL.

[Carllama]

Merci pour le retour @Eolia

De ce fait ce script ne fait pas suite au mail envoyé par Prestashop ?

Il y a donc deux problèmes la faille injection XSS où il faut enlever les lignes de codes données et la faille patchee par ce script ?

 

[HeineFR]

18 minutes ago, Carllama said:

Merci pour le retour @Eolia

De ce fait ce script ne fait pas suite au mail envoyé par Prestashop ?

Il y a donc deux problèmes la faille injection XSS où il faut enlever les lignes de codes données et la faille patchee par ce script ?

 

Ce script est utile si la boutique a été hackée.

Le "patch", lui, ne sert qu'à éviter la manipulation du cache smarty en changeant la valeur de la configuration VIA une injection SQL.

[EsteEstabaLibre]

Hola,

je viens de recevoir le mail, que puis-je faire pour fermer cette porte dans 1.6.1.6?

Merci.

[Carllama]

Merci @HeineFR

Et dans ce cas, si tout est ok,  il n'est pas forcement nécessaire de passer la boutique en 1.7.8.7 (boutique actuellement en 1.7.7.7) ou il faut que toutes les boutiques passent en 1.7.8.7 ? Je suis désolé si ma question parait stupide mais j'avoue être perdu ^^

 

[Mediacom87]

il y a 25 minutes, HeineFR a dit :

Ce script est utile si la boutique a été hackée.

Même si la boutique est encore saine puisqu'il permet d'identifier les fichiers des modules à analyser pour éviter de conserver une porte ouverte, encore faut-il avoir les compétences pour analyser ce code est comprendre si une porte est ouverte, ce qui ne peut se faire automatiquement.

[Asu34]

Bonjour à tous, 

Je suis en train sécuriser quelque un de mes sites et sur l'un d'eux j'ai ce formulaire qui apparaît sur la page commande

 

...

ça ressemble à ce hack ? Qu'en pensez-vous ?

 

 

[j-charles]

Alors pour amener de l'eau au moulin, et si ça peut aider...
Prestashop 1.6.1.24
Le 13/07 je remarque un soucis sur la page de paiement "order-payment.tpl" les liens de paiements avaient été remplacés par un formulaire qui ressemble a un stripe. 
C'était 10 jours avant le mail de prestashop, je n'avais aucune idée que cela pouvait être un hack... 
J'ai cru au début que c'était une maj sur un de mes modules de paiement qui avait tout cassé.
Impossible de rétablir, et je me suis rendu compte que le nouveau formulaire remplaçait en js tout ce qu'il y avait dans #HOOK_PAYMENT
Pensant toujours qu'il s'agissait d'un problème de maj sur un module de paiement, j'ai fait en sorte que le formulaire n'apparaisse plus, et que les bons liens soient affichés.
J'ai donc, sans le savoir "masqué" le hack.
Aujourd'hui je lance le cleaner d'Eolia et tout s'éclaire... merci énormément Eolia.

En regardant les logs c'est un peu terrifiant de voir le nombre de modules qu'ils testent pour trouver la faille...

[Gu1llaume]

1 minute ago, j-charles said:

En regardant les logs c'est un peu terrifiant de voir le nombre de modules qu'ils testent pour trouver la faille...

Merci pour ton retour d'expérience, peux-tu nous faire voir à quoi ressemble les logs ? En tous cas, je constate que si hack il y a, on doit très vite s'en apercevoir, dès qu'une commande est passé en fait...

[HeineFR]

1 minute ago, Gu1llaume said:

on doit très vite s'en apercevoir, dès qu'une commande est passé en fait...

Si le hacker bypass de façon bourrine le formulaire de paiement, comme là, effectivement tu remarqueras que tu n'as plus de commandes.

Mais, s'il décide d'intercepter X commandes sur 100 tu ne le sauras que lorsque les clients diront qu'ils sont étonnés de ne rien avoir reçu...
En étant encore plus malin il pourrait demander une première saisie, faire semblant d'avoir un échec et rediriger le visiteur sur la vraie page de paiement comme si de rien était... 

Apres, il y a aussi purement le dump de ta Base de données pour que les hackers s'en servent de base de fishing avec nom prénom adresse etc... 
Tu ne remarqueras rien et les hackers se serviront de ton site pour s'alimenter...

[j-charles]

21 minutes ago, Gu1llaume said:

Merci pour ton retour d'expérience, peux-tu nous faire voir à quoi ressemble les logs ? En tous cas, je constate que si hack il y a, on doit très vite s'en apercevoir, dès qu'une commande est passé en fait...

Pour le coup le formulaire était là à chaque test, quelque soit l'IP utilisée ou le nombre de tests de ma part. Il suffit de checker la page de choix de paiement pour le voir apparaitre.
Mais j'imagine qu'il y a pas un seul hack et que ça doit changer..

Pour les logs c'est comme décrit sur le mail de prestashop:
POST /modules/***/uploadimage.php
suivi d'un
GET /modules/***/***.php

Ca teste une vingtaine de modules différents, avec à chaque fois le même pattern.

[Eolia]

il y a 47 minutes, Ric34 a dit :

Bonjour à tous, 

Je suis en train sécuriser quelque un de mes sites et sur l'un d'eux j'ai ce formulaire qui apparaît sur la page commande

 

...

ça ressemble à ce hack ? Qu'en pensez-vous ?

 

 

C'est exactement le hack contrôlé par cleaner.php

[gtul]

Ça pourrait aider plusieurs d’entre nous.

SVP quelqu’un pourrait décrire exactement quoi faire en cas qu’on trouve de code malveillant?

 

[mandrake]

Bonjour, moi je viens de trouver ça dans le répertoire www/config/xml d'un de mes prestashop sous 1.6.0.4, je l'ai aussi trouvé sur un autre et cela ne s'y trouvait pas avant le 22/07 :

 

[mandrake]

C'est un sacré bordel ce piratage. Aucune version n'a l'air d'y échapper.

[Eolia]

Ben ça c'est normal, c'est la mise à jour de la liste des modules récupérée depuis addons.prestashop.com^^

[Eolia]

il y a 16 minutes, gtul a dit :

Ça pourrait aider plusieurs d’entre nous.

SVP quelqu’un pourrait décrire exactement quoi faire en cas qu’on trouve de code malveillant?

 

utilisez cleaner.php qui va vous nettoyer les codes malveillants et vous donner la liste possible des modules ayant permis l'intrusion.

[mandrake]

Ah Eolia, qu'est-ce que je ferai sans toi, j'ai le cerveau d'un poisson rouge depuis quelques années déjà, mais là je me sens vraiment bête...Faut que je vienne respirer l'air breton, ça me ferait sûrement beaucoup de bien 😉

Edited July 26, 2022 by mandrake (see edit history)

[EsteEstabaLibre]

Eolia ¿puedes ayudarme?

2 hours ago, EsteEstabaLibre said:

Hola,

je viens de recevoir le mail, que puis-je faire pour fermer cette porte dans 1.6.1.6?

Merci.

 

[Asu34]

1 hour ago, Eolia said:

C'est exactement le hack contrôlé par cleaner.php

Mais du coup qu'est ce qu'ils font via ce formulaire ?

Ils récupèrent les coordonnées bancaires des clients ?
Ils récupèrent les paiements effectués via ce dernier ? (car aucun client ne s'est à ce jour manifesté).

Et on a sur prestashop des commandes qui continuent à s'enregistrer sur lesquelles on reçoit bien les paiements...

Merci

[mandrake]

@eolia : je viens de te répondre mais ma réponse est masquée. Encore un truc que je ne connaissais pas sur le forum, faut dire que cela fait un bail que je n'y étais pas revenu...

[HeineFR]

Si vous avez un accès SSH vous pouvez aussi vérifier la liste des fichiers modifiés depuis les 15 derniers jours :

find . -mtime -15 -not -path "./var/cache/*"

 

[Prestasec]

9 minutes ago, HeineFR said:

Als je SSH-toegang hebt, kun je ook de lijst met bestanden bekijken die in de afgelopen 15 dagen zijn gewijzigd :

 

To save it to a file: 

 find . -mtime -5 -not -path "./var/cache/*" > filechanges.txt

[Mediacom87]

il y a 35 minutes, mandrake a dit :

@eolia : je viens de te répondre mais ma réponse est masquée. Encore un truc que je ne connaissais pas sur le forum, faut dire que cela fait un bail que je n'y étais pas revenu...

C'est de la magie 🙂 -> []

[doekia]

il y a 37 minutes, HeineFR a dit :

Si vous avez un accès SSH vous pouvez aussi vérifier la liste des fichiers modifiés depuis les 15 derniers jours :

find . -mtime -15 -not -path "./var/cache/*"

 

Ceci ne fonctionne pas. Ici, mais dans nombre de hack, les hackers modifient les fichiers et remettent les dates. Ce genre de test n'est absolument pas fiable.

[Eolia]

Il y a 3 heures, Ric34 a dit :

Mais du coup qu'est ce qu'ils font via ce formulaire ?

Ils récupèrent les coordonnées bancaires des clients ?
Ils récupèrent les paiements effectués via ce dernier ? (car aucun client ne s'est à ce jour manifesté).

Et on a sur prestashop des commandes qui continuent à s'enregistrer sur lesquelles on reçoit bien les paiements...

Merci

Il récupèrent toutes les info de la commande, créent un produit au même prix sur une boutique chinoise ayant le même nom que la votre, présentent leur formulaire de paiement, envoient celui-ci à leur banque chinoise qui valide le paiement (et éventuellement vous envoient un code 3DSecure du bon montant que vous validez) et le client pensent que tout est ok.

Sauf que:

- Vous n'avez pas de commande de votre coté

- Votre client s'est fait pirater ses codes de CB

- Vous êtes responsable du vol de données et de la somme escroquée (c'est votre site qui a permis le vol)

[Eolia]

Il y a 3 heures, EsteEstabaLibre a dit :

Eolia ¿puedes ayudarme?

 

Lancez cleaner.php et contrôlez la liste des modules permettant un upload de fichier

[Asu34]

6 minutes ago, Eolia said:

Il récupèrent toutes les info de la commande, créent un produit au même prix sur une boutique chinoise ayant le même nom que la votre, présentent leur formulaire de paiement, envoient celui-ci à leur banque chinoise qui valide le paiement (et éventuellement vous envoient un code 3DSecure du bon montant que vous validez) et le client pensent que tout est ok.

Alors j'ai fait des tests et j'ai l'impression que de mon côté le hack est un peu différent car quand on arrive sur la page commande, nos moyens de paiements sont masqués et ils n'affichent que le leur.
J'ai rentré des numéros CB bidon, validé, et une popup m'indique : "désolé ce moyen de paiement est momentanément indisponible veuillez en choisir un autre". Ensuite leur formulaire disparaît pour afficher mes moyens de paiement d'origine. Le client paie alors sa commande, elle remonte chez nous (avec son paiement), mais c'est trop tard il s'est fait véroler ses coordonnées.

Edited July 26, 2022 by Ric34 (see edit history)

[Gu1llaume]

1 minute ago, Ric34 said:

Alors j'ai fait des tests et j'ai l'impression que de mon côté le hack est un peu différent car quand on arrive sur la page commande, nos moyens de paiements sont masqués et ils n'affichent que le leur.
J'ai rentré des numéros CB bidon, validé, et une popup m'indique : "désolé ce moyen de paiement est momentanément indisponible veuillez en choisir un autre". Ensuite leur formulaire disparaît pour afficher mes moyens de paiement d'origine. Le client paie alors sa commande, elle remonte chez nous (avec son paiement), mais c'est trop tard il s'est fait véroler ses coordonnées.

Effectivement, c’est hyper élaboré, je suis stupéfait 😧 

[Eolia]

Ca dépend des fois leurs P chinoises sont un peu en vrac...

https://106.15.179.255

https://45.197.141.250/statystics.php

https://45.197.141.250/

[Asu34]

9 minutes ago, Gu1llaume said:

Effectivement, c’est hyper élaboré, je suis stupéfait 😧 

Clair. De plus, si le client s'est déjà fait véroler ses coordonnées CB ils ne verra plus leur formulaire (s'il passe une 2eme commande) mais directement les moyens de paiement d'origine ^^...

[EsteEstabaLibre]

mais si nous faisons cela, nous sommes sauvés?

To do so, locate the file config/smarty.config.inc.php on your PrestaShop install, and remove lines 40-43 (PrestaShop 1.6):

if (Configuration::get('PS_SMARTY_CACHING_TYPE') == 'mysql') { include _PS_CLASS_DIR_.'Smarty/SmartyCacheResourceMysql.php'; $smarty->caching_type = 'mysql'; }

 

[Mediacom87]

il y a 13 minutes, EsteEstabaLibre a dit :

mais si nous faisons cela, nous sommes sauvés?

To do so, locate the file config/smarty.config.inc.php on your PrestaShop install, and remove lines 40-43 (PrestaShop 1.6):

if (Configuration::get('PS_SMARTY_CACHING_TYPE') == 'mysql') { include _PS_CLASS_DIR_.'Smarty/SmartyCacheResourceMysql.php'; $smarty->caching_type = 'mysql'; }

 

pas dans le cas exposé ici de vol de CB par moyen de paiement fictif.

[Asu34]

2 minutes ago, Mediacom87 said:

pas dans le cas exposé ici de vol de CB par moyen de paiement fictif.

Le script d'Eolia (cleaner.php) permettrait nettoyer cela ?

[gouna]

Bonjour, personnellement je n'ai pas d'inscription en rouge, mais des remarques en orange par rapport à mes modules, par exemple :

#Fonction sensible à contrôler: move_uploaded_file => modules/contentbox/contentbox.php

 

[Eolia]

Si la fonction est dans le fichier du module lui-même (ou dans une classe) pas de risque. (Le script ne détecte pas cette subtilité)

Par contre, si c'est un chemin du genre /module/nom_du_module/upload.php il faut ouvrir ce fichier pour voir comment est traité l'upload.

[gouna]

il y a 17 minutes, Eolia a dit :

Si la fonction est dans le fichier du module lui-même (ou dans une classe) pas de risque. (Le script ne détecte pas cette subtilité)

Par contre, si c'est un chemin du genre /module/nom_du_module/upload.php il faut ouvrir ce fichier pour voir comment est traité l'upload.

Merci pour votre aide.

Effectivement la plupart des modules concernés semblent hors de porté, j'ai juste un doute sur ces lignes :
 

#Fonction sensible à contrôler: file_put_contents => modules/autoupgrade/classes/Cookie.php
#Fonction sensible à contrôler: file_put_contents => modules/autoupgrade/classes/Tools14.php
#Fonction sensible à contrôler: file_put_contents => modules/autoupgrade/classes/Upgrader.php
#Fonction sensible à contrôler: file_put_contents => modules/ets_oneclicktomigrate/classes/DataExport.php
#Fonction sensible à contrôler: file_put_contents => modules/ets_oneclicktomigrate/classes/DataImport.php
#Fonction sensible à contrôler: move_uploaded_file => modules/ets_oneclicktomigrate/classes/Uploader.php
#Fonction sensible à contrôler: file_put_contents => modules/magiczoomplus/admin/magictoolbox.settings.editor.class.php

 

Edited July 26, 2022 by gouna (see edit history)

[Bertrand57]

16 hours ago, Eolia said:

Si la fonction est dans le fichier du module lui-même (ou dans une classe) pas de risque. (Le script ne détecte pas cette subtilité)

Par contre, si c'est un chemin du genre /module/nom_du_module/upload.php il faut ouvrir ce fichier pour voir comment est traité l'upload.

Merci pour le script cleaner 👍

Comment peut-on vérifier que les fichiers du type upload.php traitent l'upload sans problème de sécurité ?

Merci

[Mediacom87]

il y a 38 minutes, Bertrand57 a dit :

Comment peut-on vérifier que les fichiers du type upload.php traitent l'upload sans problème de sécurité ?

Il faut ouvrir le fichier, regarder le code correspondant à l'alerte sur les function file_put_contents ou move_uploaded_file pour s'assurer que les données inscrites dans les fichiers sont bien sécurisées et ne peuvent pas être détournés.

Après, il y a beaucoup de méthode pour sécuriser donc on ne peut pas dire que vous devez telle ou telle chose précisément.

Je viens de faire l'analyse pour un client et chaque module a sa méthode en fonction de ce qu'il récupère comme donnée.

[Eolia]

il y a 48 minutes, Bertrand57 a dit :

Merci pour le script cleaner 👍

Comment peut-on vérifier que les fichiers du type upload.php traitent l'upload sans problème de sécurité ?

Merci

Le but premier de ce script est de sécuriser les sites par rapport au dernier hack rencontré.

Pour le reste on a rajouté des informations.

Si vous ne les comprenez pas ou que le code est du chinois pour vous, demandez conseil à votre développeur ou a quelqu'un qui s'y connait.

Les prochaines versions vont vous sortir un zip des fichiers à contrôler.

[joseantgv]

19 hours ago, Mediacom87 said:

pas dans le cas exposé ici de vol de CB par moyen de paiement fictif.

Je comprends que vous voulez dire que cette modification est inutile si vous êtes déjà infecté.
Mais c'est valable pour prévenir l'attaque (pour autant que l'on sache).

[doekia]

Petit complément d'explication concernant la faille PS_SMARTY_CACHING_TYPE == 'mysql' (toutes versions PS)

 

D'abord sans patcher, il suffit de désactiver cette option dans Paramètres > performance (ce réglage est d'ailleurs quelque chose de rarement utilisé car inutile).

 

Maintenant l'explication réelle (car désolé mais le communiqué Prestashop ressemblait vraiment à n'importe quoi)
Quand le cache est active, smarty stocke ce dernier dans la table smarty_cache (colonne content)
Si une faille d'injection SQL (ailleurs donc) existe elle permet d'injecter n'importe quel contenu dans la colonne content.
De fait smarty fait après lecture un eval() de cette colonne, donc permet l'exécution de n'importe quel code arbitraire.
La faille fonctionne donc SEULEMENT à cause d'un autre vecteur (celui qui permet l'injection SQL).
Le code arbitraire peut bien sur créer un fichier avec un simple file_put_contents()

 

Comme quasiment à chaque fois (en 1.6), la faille est induite par un module annexe au coeur. Le premier niveau de protection est donc bien de s'assurer de la qualité des modules que vous mettez dans vos boutique. Ici c'est de l'injection SQL, ailleurs c'est des downloader écrit sans contrôle. Je différencie la 1.6 des 1.7 car avec cette dernière le framework symfony (bien que très mature), de par sa complexité n'est pas exempt de faille possible. (php-unit, test, ...). Toujours bien garder cela à l'esprit quand on parle sécurité.

 

[EsteEstabaLibre]

45 minutes ago, doekia said:

Petit complément d'explication concernant la faille PS_SMARTY_CACHING_TYPE == 'mysql' (toutes versions PS)

 

D'abord sans patcher, il suffit de désactiver cette option dans Paramètres > performance (ce réglage est d'ailleurs quelque chose de rarement utilisé car inutile).

 

Maintenant l'explication réelle (car désolé mais le communiqué Prestashop ressemblait vraiment à n'importe quoi)
Quand le cache est active, smarty stocke ce dernier dans la table smarty_cache (colonne content)
Si une faille d'injection SQL (ailleurs donc) existe elle permet d'injecter n'importe quel contenu dans la colonne content.
De fait smarty fait après lecture un eval() de cette colonne, donc permet l'exécution de n'importe quel code arbitraire.
La faille fonctionne donc SEULEMENT à cause d'un autre vecteur (celui qui permet l'injection SQL).
Le code arbitraire peut bien sur créer un fichier avec un simple file_put_contents()

 

Comme quasiment à chaque fois (en 1.6), la faille est induite par un module annexe au coeur. Le premier niveau de protection est donc bien de s'assurer de la qualité des modules que vous mettez dans vos boutique. Ici c'est de l'injection SQL, ailleurs c'est des downloader écrit sans contrôle. Je différencie la 1.6 des 1.7 car avec cette dernière le framework symfony (bien que très mature), de par sa complexité n'est pas exempt de faille possible. (php-unit, test, ...). Toujours bien garder cela à l'esprit quand on parle sécurité.

 

Comme j'ai prestahop en espagnol ce n'est pas clair pour moi. Que dois-je désactiver ?

Parametros Avanzados > Rendimiento > Qu'est-ce que je désactive ici ?

Merci doekia

[Eolia]

Ca doit être comma ça:

ne jamais sélectionner là où j'ai mis la croix rouge

[EsteEstabaLibre]

Si, c'est comme ça que je l'ai eu. j'ai marqué *Système de fichier

Je pense que ça n'a rien à voir mais...tu as marqué: Recompilar las plantillas cuando los archivos sean modificados

et j'ai marqué:  Nunca recompilar los archivos de las plantillas

aucun conseil ou dépend de chaque prestashop? Je suis à 1.6.1.6

Merci Beacoup @Eolia

 

[Eolia]

si vous avez "Nunca recompilar los archivos de las plantillas" vous ne verrez jamais les modifications que vous pourriez effectuer dans vos fichiers tpl.

[HeineFR]

On 7/26/2022 at 2:03 PM, mandrake said:

C'est un sacré bordel ce piratage. Aucune version n'a l'air d'y échapper.

C'est normal, le piratage actuel a "juste" révélé que si vous avez une faille de type injection SQL depuis X temps (donc qu'un pirate peut pomper les données de votre site), aujourd'hui il peut aussi changer un paramètre de la configuration de la boutique qui lui permet d'injecter un code malicieux pour, comme ici, en détourner le moyen de paiement.

[gusman126]

Siento escribir en español, pero realmente estoy alucinando de lo poco preocupados que está la gente que dice aquí que ha encontrado el formulario de robo de tarjetas.

Pero a ver , que a los clientes de vuestras tiendas le han robado los datos de sus tarjetas de pago!!!

Han robado datos de tarjetas, pero a qué esperáis a llamar a un profesional y pagar por la limpieza.

Parece como si las tiendas infectadas siguieran en marcha y sin preocuparse , que sigan robando datos.

En otros países no lo se pero una denuncia por tener un sistema infectado y sabiendo que lo está es mucho dinero.

Cerrar las tiendas ostias.

[joseantgv]

18 hours ago, doekia said:

Petit complément d'explication concernant la faille PS_SMARTY_CACHING_TYPE == 'mysql' (toutes versions PS)

 

D'abord sans patcher, il suffit de désactiver cette option dans Paramètres > performance (ce réglage est d'ailleurs quelque chose de rarement utilisé car inutile).

 

Maintenant l'explication réelle (car désolé mais le communiqué Prestashop ressemblait vraiment à n'importe quoi)
Quand le cache est active, smarty stocke ce dernier dans la table smarty_cache (colonne content)
Si une faille d'injection SQL (ailleurs donc) existe elle permet d'injecter n'importe quel contenu dans la colonne content.
De fait smarty fait après lecture un eval() de cette colonne, donc permet l'exécution de n'importe quel code arbitraire.
La faille fonctionne donc SEULEMENT à cause d'un autre vecteur (celui qui permet l'injection SQL).
Le code arbitraire peut bien sur créer un fichier avec un simple file_put_contents()

 

Comme quasiment à chaque fois (en 1.6), la faille est induite par un module annexe au coeur. Le premier niveau de protection est donc bien de s'assurer de la qualité des modules que vous mettez dans vos boutique. Ici c'est de l'injection SQL, ailleurs c'est des downloader écrit sans contrôle. Je différencie la 1.6 des 1.7 car avec cette dernière le framework symfony (bien que très mature), de par sa complexité n'est pas exempt de faille possible. (php-unit, test, ...). Toujours bien garder cela à l'esprit quand on parle sécurité.

 

 

Attention à ne pas dire "D'abord sans patcher, il suffit de désactiver cette option dans Paramètres > performance (ce réglage est d'ailleurs quelque chose de rarement utilisé car inutile)", car selon PrestaShop :

 

According to our current understanding of the exploit, attackers might be using MySQL Smarty cache storage features as part of the attack vector. This feature is rarely used and is disabled by default, but it can be enabled remotely by the attacker. Until a patch has been published, we recommend physically disabling this feature in PrestaShop’s code in order to break the attack chain.

https://build.prestashop.com/news/major-security-vulnerability-on-prestashop-websites/

[Bertrand57]

20 hours ago, doekia said:

Quand le cache est active, smarty stocke ce dernier dans la table smarty_cache (colonne content)
Si une faille d'injection SQL (ailleurs donc) existe elle permet d'injecter n'importe quel contenu dans la colonne content.

Donc, un autre moyen de contrôler que la boutique n'ait pas été victime est de vérifier que la table smarty_cache est vide ?

[Mediacom87]

Il y a 23 heures, Bertrand57 a dit :

Comment peut-on vérifier que les fichiers du type upload.php traitent l'upload sans problème de sécurité ?

Pour cela, il faut apprendre à lire du code et donc à coder, mais voici un article dans lequel j'essaye de donner des pistes : https://www.mediacom87.fr/comment-se-premunir-du-piratage-sur-prestashop-et-thirty-bees/

Le sujet est vaste, mais il faut tout de même faire les choses étape par étape.

Certains membres de la communauté comme @doekiaou @Eoliaont déjà prouvé leur expertise et celle-ci ne s'est pas acquise en 2 jours.

Il faut bien se rendre compte qu'il existe de bonnes pratiques avant tout et qu'il faut les appliquer pour éviter tout problème à l'avenir, malheureusement, l'essor de PrestaShop a amené son lot de développeurs plus soucieux de faire du beau que du bon.

[Prestasec]

Salut, Existe-t-il également un script qui ne montre que les vulnérabilités au lieu d'apporter directement les modifications pour résoudre les problèmes ? Je voudrais faire un scan seulement dans un premier temps.

 

Hi, 

Is there also a script that only shows the vulnerabilitys instead of directly making the changes to fix the issues? 

I would like to do a scan only at first.

[SAKSCM]

Bonjour,

Désolé pour la traduction, je ne parle pas français et j'utilise le google translate, j'espère que vous me comprenez bien.

Tout d'abord merci pour le nettoyeur.

J'ai eu un magasin infecté en janvier et il m'a fallu 6 mois (le mois dernier) pour le nettoyer (et un mois après toute cette souffrance tout ça sort, tant mieux pour moi hahaha)

Le magasin en question était un 1.7, le nettoyeur fonctionne également pour cette version ou avec la mise à jour la plus récente, cela vaudra s'il y a une faille (elle n'a pas encore été sautée mais on ne sait jamais)

Dans le reste des prestashops 1.7 (ou 1.6) qui apparemment n'ont pas été infectés, serait-il bon de le transmettre quand même ?

Merci beaucoup pour tout.

salutations

 

Edit : J'ai utilisé correctement le cleaner.php dans ps1.7 (dans plusieurs) et tout est correct

Merci @Eolia pour le scénario

salutations

Edited July 28, 2022 by SAKSCM (see edit history)