Inicio
Servicios
Vulnerabilidad en el pago de PrestaShop

Vulnerabilidad en el pago de PrestaShop

Le aconsejamos que actúe ya y proteja su negocio frente a este ataque.

En los últimos meses hemos visto muchas más tiendas PrestaShop pirateadas de lo habitual, a pesar de que el sistema es conocido por su seguridad. En los últimos 10 años solo tuvimos unos pocos casos (3 o 4) de tiendas PrestaShop pirateadas; en los últimos 4 meses hemos recibido más de 10 solicitudes para analizar o reparar una tienda atacada.

El objetivo principal de estos ataques es inyectar skimmers de JavaScript en las páginas de pago de las tiendas online.

Para ello, los atacantes acceden al sitio web, directamente o a través de servicios de terceros, e inyectan JavaScript malicioso que roba los datos que los clientes introducen en el formulario de pago.

Las tiendas online rara vez tienen visibilidad sobre las partes de su web expuestas a estos ataques. A menudo, la víctima no sabe que el JavaScript de su sitio ha sido alterado, y el código malicioso puede quedarse ahí indefinidamente. En los ataques a la cadena de suministro, lo habitual es que la víctima desconozca que está ejecutando JavaScript de un tercero comprometido.

En los casos que hemos visto, los atacantes modificaron la página de pago y sustituyeron el formulario de tarjeta estándar por uno propio.

Estas son algunas de las consecuencias que puede tener:

Robo de datos personales: aunque el objetivo principal son los datos de las tarjetas, los atacantes también pueden robar información personal. Millones de consumidores podrían verse afectados.
Pérdida de ingresos: las ventas online de una tienda pequeña o mediana que ha sufrido uno de estos ataques pueden caer de forma notable, porque los clientes dejan de confiar en que la tienda sepa evitar nuevos incidentes.
Más infecciones: si los atacantes roban los datos de acceso del administrador y de los usuarios, pueden extender el ataque a otros sitios web; por ejemplo, no solo al sitio principal de una marca, sino también a sus sitios secundarios.
Consecuencias legales: un ataque expone a la empresa a reclamaciones de sus clientes, a sanciones si está sujeta a normas como el RGPD y a medidas del sector, como una auditoría PCI DSS o la imposibilidad de aceptar pagos con tarjeta.

¿Qué se puede hacer?

Revisar a fondo los archivos de la tienda para detectar intrusiones e identificar cualquier modificación no deseada.
Instalar Imunify en el servidor, que impide que se ejecuten los archivos comprometidos.
Usar Clarity Module Pro, que nosotros empleamos a fondo para localizar los problemas y saber si los datos de las tarjetas se han visto comprometidos.
Activar la autenticación en dos pasos en el panel de administración, algo que recomendamos.

Estas medidas tienen una tarifa única de 200 EUR y un coste mensual de 15 EUR.

Siempre es mejor prevenir un problema que tener que solucionarlo. Le recomendamos encarecidamente que tome estas precauciones para mantener su tienda segura.

Precio200 EUR

Caso de estudio

01
El problema
El propietario de una tienda se dio cuenta de que llevaba horas sin recibir ningún pedido, algo muy raro, porque normalmente recibía más de 60 al día.
02
La reacción
Acudió a nosotros para arreglar el proceso de pago, pensando que se trataba de un error sencillo y fácil de corregir.
03
Nuestro enfoque
Al principio pensamos que el fallo lo causaba un módulo instalado en los días anteriores y empezamos a investigarlo. Enseguida encontramos cambios importantes en el código y descubrimos que el formulario de pago original había sido sustituido por completo por uno fraudulento.
04
La solución
Según si su servidor cuenta o no con la defensa proactiva de Imunify360, hay dos opciones:
1. Eliminación automática con la defensa proactiva de Imunify360. El escáner en tiempo real analiza cada archivo en cuanto se sube al servidor y, si es malicioso, lo limpia o lo elimina de inmediato. Así se reduce el daño en un sistema desprotegido, y es especialmente útil en uno que ya está infectado. Más información: primeros pasos con la defensa proactiva y cómo funciona.
2. Localización manual de los archivos maliciosos. Se revisan a mano los archivos del servidor en busca de cadenas de código codificadas en base64 y se eliminan sin detener la tienda. Estos son los 6 archivos que suelen estar infectados:
  - classes/db/Db.php: el código está al final del archivo y envía el valor del parámetro statistics_hash a la dirección IP 106.15.179.255.
  - classes/controller/FrontController.php: se modifica para que la página de pedido cargue un archivo JavaScript adicional con un nombre aleatorio, como /js/HQf6b.js, que sustituye la parte de pago por un formulario de tarjeta falso.
  - /public_html/js/NOMBRE-ALEATORIO.js: este es el archivo que se carga en la página de pedido y cambia la parte de pago por un formulario propio que probablemente envía el dinero a la cuenta del atacante. Es el archivo más importante: elimínelo en cuanto descubra la infección.
  - classes/module/Module.php: también hay que limpiarlo, porque contiene código PHP codificado que permite recibir parámetros y ejecutar más código.
  - controllers/admin/AdminLoginController.php: este código envía la URL del panel de administración, junto con el correo electrónico y la contraseña de acceso, a 45.197.141.250/statystics.php.
  - app/Mage.php: contiene un código similar al de classes/module/Module.php. Hay que eliminar este archivo.
Si en su servidor o alojamiento está instalada la versión gratuita, ImunifyAV, tendrá que lanzar el análisis de archivos de forma periódica y eliminar a mano el código malicioso, porque esa versión no tiene protección activa. Consulte las diferencias entre ImunifyAV, ImunifyAV+ e Imunify360.