Vulnerabilidad crítica en PrestaShop 1.6.0.10 a 1.7.8.6 (caché MySQL de Smarty)

El 22 de julio de 2022 PrestaShop alertó de un ataque masivo contra tiendas desde la versión 1.6.0.10. Los atacantes usan una inyección SQL (del núcleo o de un módulo) para activar la caché de Smarty en MySQL y, a través de ella, ejecutar código en la tienda. Con eso suelen instalar un formulario de pago falso que roba las tarjetas de los clientes.

• PrestaShop 1.7.8.7 refuerza la caché de Smarty contra este ataque. Las versiones 8 y 9 ya lo incluyen.
• PrestaShop 1.6 no recibió ninguna corrección: hay que aplicar el parche de este artículo.
• El módulo blockwishlist (lista de deseos) de la versión 2.0.0 a la 2.1.0 tenía una de las inyecciones SQL usadas. Actualízalo.

Solución definitiva: actualizar

Mira tu versión en Parámetros avanzados > Información. Si es una 1.7 anterior a la 1.7.8.7, actualiza. Lo ideal es pasar a una versión con soporte: hoy la última es la 9.2.0, y la rama 8 sigue recibiendo correcciones (8.2.8). Actualiza también todos los módulos, sobre todo los de terceros: la inyección SQL suele venir de un módulo.

Las guías error al actualizar con 1-Click Upgrade y error de conexión al actualizar PrestaShop cubren los fallos más habituales. Haz una copia completa (ficheros y base de datos) antes.

Parche para tiendas que no pueden actualizar ya

Si tu tienda es 1.6, o es una 1.7 que no puedes actualizar de inmediato, desactiva la caché de Smarty en MySQL. Prácticamente nadie la usa (la caché en ficheros es más rápida), así que quitarla no afecta al funcionamiento de la tienda.

1. Abre el fichero config/smarty.config.inc.php de la tienda desde el Administrador de archivos de cPanel.
2. Busca este bloque (está hacia la línea 40-43 en PrestaShop 1.6 y 43-46 en 1.7):

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

3. Bórralo entero, las cuatro líneas, y guarda.
4. Comprueba que la tienda carga con normalidad.

Además, en Parámetros avanzados > Rendimiento, en el apartado Smarty, comprueba que Tipo de caché está en Sistema de archivos y no en MySQL.

Este parche corta la vía de ejecución de código, pero no corrige la inyección SQL de origen. Sigue siendo necesario actualizar.

Aplicarlo a muchas tiendas a la vez por SSH

Si administras varias tiendas, primero localiza los ficheros que tienen el bloque (cambia RUTA por la carpeta donde están las tiendas, por ejemplo /home/usuario):

grep -rl --include=smarty.config.inc.php "PS_SMARTY_CACHING_TYPE') == 'mysql'" RUTA

Y bórralo en todos ellos (elimina la línea del if y las tres siguientes):

grep -rl --include=smarty.config.inc.php "PS_SMARTY_CACHING_TYPE') == 'mysql'" RUTA \
  | xargs sed -i "/PS_SMARTY_CACHING_TYPE') == 'mysql'/,+3d"

Comprueba después que los ficheros siguen siendo PHP válido:

find RUTA -name smarty.config.inc.php -exec php -l {} \;

Comprobar si la tienda ya fue atacada

Busca estas señales:

• Un fichero llamado blm.php en la carpeta principal de la tienda.
• En los registros de acceso: una petición POST a un módulo, seguida un segundo después de una visita a la portada y de una petición a /blm.php.
• Un formulario de pago con tarjeta que no has puesto tú en la página de pago, o clientes que reportan cargos fraudulentos.
• Ficheros PHP modificados recientemente que no corresponden a ninguna actualización tuya. Por SSH, find RUTA_TIENDA -name "*.php" -mtime -30 lista los cambiados en los últimos 30 días.

Que no aparezca blm.php no descarta un ataque: los atacantes cambian los nombres. Si encuentras cualquiera de estas señales, pon la tienda en mantenimiento, haz una copia de cómo está y abre un ticket: te ayudamos a localizar los ficheros afectados. Borrar el bloque de Smarty no limpia una tienda ya infectada; cuando esté limpia, cambia las contraseñas del panel de PrestaShop, de la base de datos y de FTP.