Qué hacer si hackean tu PrestaShop: la primera hora

La primera hora

1. Comprueba el pago. Haz una compra de prueba y fíjate en el paso de pago: ¿aparece un formulario de tarjeta en tu propia página cuando tu pasarela normalmente redirige o muestra el suyo? ¿Hay un paso de más, o un error tras meter la tarjeta y después el pago «bueno»? Si sospechas de un skimmer, desactiva ese método de pago mientras lo investigas. Cada pedido con el skimmer activo es una tarjeta robada.
2. Haz una copia completa de archivos y base de datos tal como están. Guarda también los logs de acceso del servidor: algunos hostings solo conservan unos días. Es tu prueba y tu vuelta atrás.
3. Cambia las contraseñas: hosting, FTP, base de datos, empleados del back-office y la cuenta de la pasarela de pago. Desde un ordenador limpio. Si cambias la de la base de datos, actualízala en app/config/parameters.php (1.7, 8 y 9) para que la tienda no se caiga.
4. No borres nada todavía. Lo que encuentres te dice por dónde entraron.
5. Anota fechas: cuándo empezaron las quejas o los cargos fraudulentos. Te harán falta para el banco y, si aplica, para el RGPD.

Cómo suelen entrar: casos reales

Conviene conocer los patrones documentados, porque se repiten. Todos los que cito tienen aviso público y enlace a la fuente.

La campaña de blm.php (2022)

En julio de 2022, el equipo de PrestaShop alertó de una campaña que encadenaba una inyección SQL (en un módulo o en el propio núcleo) con la función de caché de Smarty en MySQL para ejecutar código. El patrón en los logs era una petición POST al punto vulnerable, un GET / un segundo después y, a continuación, peticiones a un archivo nuevo, blm.php, en la raíz. Con ese control, los atacantes inyectaban un formulario de pago falso en el checkout. Se corrigió en PrestaShop 1.7.8.7 con el identificador CVE-2022-31181 (crítico, 9,8).

El mismo aviso señalaba que las versiones 2.0.0 a 2.1.0 del módulo de lista de deseos blockwishlist eran vulnerables a inyección SQL (CVE-2022-31101).

Módulos de terceros con inyección SQL o subida de archivos

La asociación Friends of Presta publica avisos de seguridad de módulos, y en varios indica expresamente que el fallo se está usando para instalar skimmers: por ejemplo, el módulo de pago con Stripe stripejs antes de 4.5.5 (CVE-2023-23315), el importador simpleimportproduct hasta 6.7.0 (CVE-2024-25846) o el checkout de una página supercheckout hasta 6.0.6 (CVE-2023-45384). Tengo la lista ampliada en módulos de PrestaShop con vulnerabilidades conocidas.

Un detalle importante de esos avisos: muchos ataques usan un controlador de módulo y ocultan la ruta, así que en el log normal solo verás POST /. Que no aparezca el nombre del módulo no descarta nada.

Dónde buscar

Archivos modificados recientemente

Con acceso SSH, desde la raíz de la tienda. Estos comandos solo leen, no cambian nada:

# PHP modificados en los últimos 15 días (sin contar la caché)
find . -name "*.php" -mtime -15 -not -path "./var/cache/*" -printf "%TY-%Tm-%Td %TH:%TM  %p\n" | sort -r | head -50

# PHP en carpetas que no deberían tenerlo (salvo los index.php de protección)
find img upload download -name "*.php" ! -name "index.php"

# Funciones típicas del código ofuscado
grep -rlE "eval\(|base64_decode\(|gzinflate\(|str_rot13\(" --include=*.php . | grep -vE "^\./(vendor|var/cache)/"

El último comando da falsos positivos: hay librerías legítimas que usan esas funciones. Lo que buscas son archivos de la tienda o de módulos que no las usaban, o con líneas larguísimas sin sentido. Las fechas de modificación también se pueden falsear, así que no te fíes solo de ellas.

Archivos del núcleo modificados

Los skimmers de PrestaShop suelen tocar archivos que intervienen en el pedido: classes/Cart.php, classes/PaymentModule.php, controladores del checkout o la plantilla del paso de pago. La forma fiable de encontrarlos es comparar cada archivo con el original de tu versión exacta de PrestaShop (descargada de la web oficial o de su repositorio de GitHub). El conector de solo lectura hace esa comparación archivo por archivo.

La carpeta override/

Los overrides permiten que un módulo o un desarrollador cambie el comportamiento del núcleo sin tocarlo. Son legítimos, pero también un buen escondite. Revisa cada archivo de override/classes/ y override/controllers/: deberías saber qué módulo o qué desarrollador lo creó. Después de cambiar algo ahí, borra var/cache/ (o cache/class_index.php en 1.6) para que PrestaShop lo vuelva a leer.

Módulos

Revisa en modules/ las carpetas que no reconozcas y las fechas de modificación recientes. Y, sobre todo, la versión de cada módulo de terceros frente a los avisos publicados: un módulo con un fallo conocido es la entrada más habitual. Un módulo desactivado sigue en el servidor y sus archivos siguen respondiendo, así que también cuenta.

Base de datos: configuración, hooks y empleados

Desde phpMyAdmin o la consola de MySQL. Cambia ps_ por tu prefijo si es otro (está en app/config/parameters.php):

-- Scripts guardados en la configuración
SELECT name, LEFT(value, 120) FROM ps_configuration
WHERE value LIKE '%<script%' OR value LIKE '%eval(%' OR value LIKE '%atob(%';

-- Tipo de caché de Smarty: si vale 'mysql' y no lo pusiste tú, mala señal
SELECT name, value FROM ps_configuration WHERE name = 'PS_SMARTY_CACHING_TYPE';

-- Qué módulos se cuelgan de la cabecera, el pie y el pago
SELECT h.name AS hook, m.name AS modulo, m.version, m.active
FROM ps_hook_module hm
JOIN ps_hook h ON h.id_hook = hm.id_hook
JOIN ps_module m ON m.id_module = hm.id_module
WHERE h.name IN ('displayHeader', 'actionFrontControllerSetMedia',
                 'displayBeforeBodyClosingTag', 'paymentOptions', 'displayPaymentTop')
ORDER BY h.name, hm.position;

-- Empleados del back-office
SELECT id_employee, email, firstname, lastname, active FROM ps_employee;

En la consulta de hooks, cualquier módulo que no reconozcas enganchado a displayHeader o al pago merece una visita a su carpeta. Busca también <script en las páginas CMS (ps_cms_lang) y en los módulos de bloques HTML personalizados.

Tareas programadas y accesos al servidor

Mira las tareas cron del usuario del hosting (crontab -l o la sección Cron del panel) y las del propio PrestaShop si usas un módulo de tareas programadas. Una tarea que descarga un archivo de un dominio desconocido o ejecuta un PHP con nombre raro es la forma típica de que la infección vuelva. Revisa también las cuentas FTP del panel y las claves de ~/.ssh/authorized_keys: cualquier acceso que nadie sepa explicar, fuera.

Logs de acceso

Busca peticiones POST a archivos dentro de modules/ o a archivos PHP de la raíz que no conoces, y los accesos inmediatamente posteriores:

grep -E "POST /modules/|POST /[a-z0-9_-]+\.php|blm\.php" access.log | tail -50

Configuración peligrosa

• _PS_MODE_DEV_ en true en producción (config/defines.inc.php): muestra errores con rutas y datos internos.
• La carpeta de administración con un nombre fácil de adivinar.
• La carpeta install/ sin borrar tras la instalación.
• Copias de seguridad .zip o .sql en la raíz o en carpetas públicas.

Antes de volver a abrir

Cuando creas que está limpia, compruébalo como lo haría un cliente y no como administrador: una compra de prueba completa desde un navegador sin sesión, con las herramientas del navegador abiertas en la pestaña Network para ver a qué dominios se conecta el pago. Repite las búsquedas de archivos y de base de datos de arriba: no debe salir nada nuevo. Y deja activa alguna forma de vigilar los cambios de archivos durante las semanas siguientes, porque si quedó una puerta trasera se notará pronto.

Si hay datos de clientes afectados

Si el ataque ha podido exponer datos personales (nombres, direcciones, emails, y no digamos tarjetas), el RGPD obliga al responsable del tratamiento, es decir, a ti, a notificarlo a la Agencia Española de Protección de Datos sin dilación indebida y, si es posible, en un máximo de 72 horas desde que lo sabes, salvo que sea improbable que suponga un riesgo para las personas. Si el riesgo es alto, también hay que informar a los afectados. Lo explico con detalle en brecha de datos en tu tienda online.

Si hubo robo de tarjetas, avisa también a tu pasarela de pago o a tu banco: tienen procedimientos para estos casos. Consulta la parte legal con tu asesor; la parte técnica (qué datos, desde cuándo, cómo entraron) es lo que debe contar el informe de la limpieza. Cómo se detecta un skimmer y dónde se esconde, en robo de tarjetas en tu tienda.

Cómo evitar que vuelva a pasar

1. Actualiza el núcleo y los módulos. PrestaShop 1.7 dejó de recibir parches cuando salió la versión 9.0; si sigues en 1.7 o en 1.6, planifica el salto. Te lo explico en actualizar PrestaShop.
2. Quita los módulos que no usas, aunque estén desactivados: sus archivos siguen en el servidor y pueden ser explotables.
3. Vigila la integridad de los archivos. Saber al día siguiente que alguien ha tocado classes/Cart.php es la diferencia entre un susto y meses de tarjetas robadas. Es lo que hace cada día el mantenimiento de PrestaShop con el conector.
4. Revisa los empleados del back-office y usa contraseñas largas y distintas para cada uno. El resto de comprobaciones de una tienda, en seguridad PrestaShop.
5. Haz copias de seguridad fuera del servidor y comprueba de vez en cuando que se pueden restaurar.

Si prefieres que lo haga yo

La limpieza de una tienda PrestaShop cuesta 349 € (IVA no incluido). Empiezo por cortar la fuga en el pago, reviso núcleo, overrides, módulos y base de datos, cierro la entrada y te entrego un informe técnico que sirve para el banco y para el RGPD. Tiene 90 días de garantía. Si necesitas que tenga prioridad sobre el resto de trabajos, la prioridad se añade por +100 € (IVA no incluido). Más detalles en PrestaShop hackeado.

Fuentes

• PrestaShop: aviso de la campaña de julio de 2022 (cadena de inyección SQL y caché de Smarty en MySQL, blm.php, formulario de pago falso, blockwishlist 2.0.0 a 2.1.0 y corrección en 1.7.8.7).
• Aviso GHSA-hrgx-p36p-89q4 del núcleo de PrestaShop (CVE-2022-31181, crítico, 9,8, corregido en 1.7.8.7).
• NVD: CVE-2022-36408 (rechazado como duplicado de CVE-2022-31181 por un error tipográfico).
• Friends of Presta: avisos de stripejs, simpleimportproduct y supercheckout (módulos usados para instalar skimmers).
• PrestaShop 1.7.8 en soporte extendido (el mantenimiento de seguridad de 1.7.8 termina con la salida de PrestaShop 9.0.0).
• Reglamento (UE) 2016/679, RGPD, artículos 33 y 34 (BOE) y AEPD: notificación de brechas de datos personales (plazo de 72 horas).