Te desactivan los pagos y activan un Stripe ajeno: caso real

Un compañero del grupo se encontró esto en enero de 2024: alguien había desactivado los métodos de pago habituales de su tienda (transferencia, PayPal y tarjeta) y había activado Stripe con la cuenta de otra persona. Los clientes compraban con normalidad y el dinero iba al atacante. Lo contamos porque es un ataque silencioso: la tienda funciona, los pedidos entran y nadie se da cuenta hasta que el dinero no llega.

Las señales que hubo

• Días antes, le llegó un correo de la propia tienda con su contraseña escrita tal cual. La cambió, pero el aviso ya decía que alguien tenía acceso.
• Después del cambio de pagos, ya no podía entrar al back-office.
• En el servidor apareció un fichero PHP que descargaba código de un repositorio externo y lo ejecutaba con eval después de decodificarlo en base64: una puerta trasera clásica, que permite al atacante volver cuando quiera.

Cómo pudieron entrar

Rekire apuntó a las dos vías más probables: que un virus en algún equipo robara la contraseña del back-office, o que entraran por alguna de las vulnerabilidades de PrestaShop y sus módulos publicadas en esos meses, si la tienda no estaba en la última versión; la suya era una 1.7.6.2. Otro miembro le preguntó precisamente si tenía parcheada una vulnerabilidad que se había publicado meses antes. Gustavo, de la comunidad, se inclinaba por un fallo humano con robo de accesos: sin entrar en el back-office es difícil quitar todos los pagos e instalar otro.

Qué hacer, en este orden

1. Pon la tienda en mantenimiento para que nadie más pague al atacante.
2. Cambia todas las contraseñas, como insistieron Rekire y Gustavo: back-office (todos los empleados), panel del hosting, FTP o SFTP, base de datos y correo. Hazlo desde un equipo limpio.
3. Recupera el acceso. Si te han cambiado tu empleado, Rekire sugirió restaurar la tabla de empleados desde una copia anterior o revisar si han tocado la clave de cifrado de la instalación.
4. Mira los registros: con qué empleado se entró y desde cuándo, y qué módulos se instalaron o configuraron.
5. Da por hecho que hay más puertas traseras. Busca ficheros PHP modificados recientemente, sobre todo en carpetas donde no debería haber código (imágenes, subidas, caché). Una búsqueda rápida por el servidor:

   grep -rl --include=*.php "base64_decode" .
   grep -rl --include=*.php "eval(" .

   Muchos módulos legítimos usan estas funciones: revisa cada resultado, no borres a ciegas. Y no te quedes solo en eso: el fichero de este caso escribía el nombre de la función troceado para que no apareciera tal cual, así que busca también file_get_contents con direcciones externas y ficheros PHP que no reconozcas.
6. Actualiza PrestaShop y los módulos a sus últimas versiones y borra los módulos que no uses.
7. Revisa la configuración de cada módulo de pago: cuentas, claves y URL de notificación.

Si el atacante ha podido ver datos de clientes, valora con tu asesor si tienes que notificarlo a la Agencia Española de Protección de Datos y a los afectados. Y los clientes que pagaron al atacante necesitan saberlo.

Cómo enterarte a tiempo

En este caso hubo un aviso, el correo con la contraseña, pero llegó como un correo más. Lo que te salva es saber en el momento que algo cambia:

• Un aviso cuando se instala o se configura un módulo, se crea un empleado o se cambia un método de pago.
• Revisar cada semana que los cobros de cada pasarela cuadran con los pedidos.
• Una comprobación periódica de ficheros modificados en el servidor.

Para lo primero y lo último, Rekire tiene el módulo Security Alert por Telegram, que avisa de cambios en los datos de pago, los módulos y los empleados y busca puertas traseras en los ficheros, y el módulo Centinela avisa de los errores de la web. Si ya te ha pasado, te ayudamos a limpiar la tienda dentro de nuestros bonos de horas: contacta con Rekire.

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