Limpiar una tienda hackeada partiendo de un PrestaShop limpio

Una tienda PrestaShop 1.7.8.7 con un formulario de tarjetas falso en el pago y el back-office inutilizado: nadie podía iniciar sesión. Un compañero de la comunidad la limpió sin intentar desinfectar ficheros uno a uno: montó la tienda sobre un PrestaShop recién descargado y llevó solo lo imprescindible. Así lo contó, con los avisos que añadieron Rekire y Gustavo.

Qué se encontró

• Un formulario de pago incrustado (un iframe) en la página de pago, que recogía los datos de tarjeta antes de la pasarela real. En otra tienda atacada esas mismas semanas estaba metido dentro de los ficheros de un módulo de checkout.
• El acceso al back-office roto: además de las tarjetas, el código robaba contraseñas.
• En otros casos del grupo aparecieron imágenes falsas: ficheros .png con nombre aleatorio dentro de img/ que en realidad contenían código, y ficheros con nombres que no pintan nada en PrestaShop (uno se llamaba como un fichero de Magento).

El método: código limpio y traer solo lo tuyo

1. Copia de seguridad completa de ficheros y base de datos, tal como está. Es la prueba de lo que pasó y tu red si algo sale mal.
2. Descarga PrestaShop de la web oficial y descomprímelo en una carpeta nueva. El paquete trae otro zip dentro: descomprime también ese.
3. Sobre ese código limpio, copia solo dos cosas de la tienda atacada: la carpeta img/ (fotos de productos, categorías, logos) y app/config/parameters.php (la conexión a la base de datos).
4. Actualiza la base de datos desde la consola. En la 1.7 el compañero usó el script que trae el propio paquete: php install/upgrade/upgrade.php. Ojo: ese script venía en los paquetes de la 1.7; en la 9.2 ya no está, y la actualización se hace con el módulo oficial de actualización.
5. Cambia el nombre de la carpeta de administración, cambia la contraseña del administrador principal y desactiva al resto de empleados hasta revisarlos.
6. Regenera el .htaccess (guardando en Parámetros de la tienda → Tráfico y SEO) y borra la carpeta install/.
7. Entra, comprueba que todo funciona y pasa los módulos de uno en uno desde la copia vieja, revisando cada uno. Para ver qué módulos hay en una y no en otra: diff -q vieja/modules nueva/modules. Mejor todavía: descarga cada módulo otra vez de su origen en lugar de copiarlo.
8. Lo mismo con el tema: el de serie viene limpio en el paquete; si usas uno comprado, descárgalo de nuevo y vuelve a aplicar tus cambios en un tema hijo.

Tres avisos que no hay que saltarse

La carpeta img/ también puede estar infectada

El paso 3 trae img/ de la tienda vieja, y ahí es justo donde se escondían los .png falsos. Antes de copiarla, busca lo que no sea una imagen:

grep -rlE '<\?php|eval\(|base64_decode' img/
find img/ -name '*.php'

Una imagen de verdad no contiene <?php. Lo que salga, fuera.

Hay ficheros que regeneran a otros

Rekire avisó de que algunos ataques dejan ficheros «maestros» que vuelven a crear el código malicioso cuando lo borras. Si limpias una carpeta y a los días está igual, no has encontrado el origen. Por eso funciona mejor partir de código limpio que limpiar encima.

Restaurar una copia no basta

Gustavo se lo explicó a otro miembro al que la infección le volvía después de restaurar: si subes la copia encima de lo que hay, los ficheros que añadió el atacante siguen ahí, porque la copia no los borra. Elimina todo antes de restaurar, y asegúrate de que la copia es de antes de la infección.

Después de limpiar

• Cambia todas las contraseñas: base de datos, FTP o SFTP, panel del hosting y empleados.
• Actualiza PrestaShop a la última versión de tu rama y cada módulo a la suya.
• Revisa empleados y claves del webservice: borra lo que no reconozcas.
• Si había un formulario de tarjetas, avisa a tu pasarela y valora tus obligaciones de notificación: se han robado datos de clientes.

Si te ha tocado y no sabes por dónde empezar, en Rekire limpiamos tiendas dentro de nuestros bonos de horas.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación