Ataque de fuerza bruta al back-office de PrestaShop: el caso

Una tienda de la comunidad empezó a recibir, sin parar, avisos de inicios de sesión fallidos en su back-office, siempre desde la misma IP extranjera. Lo resolvió en una tarde con cuatro medidas: cambiar el nombre de la carpeta de administración, bloquear la IP, revisar los registros y dejar un aviso que salte con cada intento.

Qué pasó

La tienda tenía instalado un módulo de seguridad que avisa de los accesos fallidos, y los avisos no paraban: alguien probaba usuarios y contraseñas contra el formulario de entrada del back-office, todo el rato y desde la misma dirección. Es un ataque de fuerza bruta: no explota ningún fallo de PrestaShop, solo prueba combinaciones hasta acertar o hasta que lo frenan.

Que el atacante llegara al formulario quiere decir que conocía la URL de administración. Puede haberla sacado de un enlace que circuló de más, de un correo reenviado, de una captura o de un equipo infectado.

Lo que hizo, por orden

1. Cambiar el nombre de la carpeta de administración

Fue lo primero que le recomendaron, y lo más eficaz: si la URL cambia, el ataque se queda llamando a una puerta que ya no existe. Se hace por FTP o desde el gestor de archivos del hosting, renombrando la carpeta adminXXXX a un nombre difícil de adivinar. En PrestaShop 8 y 9, si después el back-office da error, vacía var/cache antes de nada. Pasa la nueva dirección a quien trabaje en la tienda por un canal que no se quede a la vista.

2. Bloquear la IP

Otro compañero propuso bloquearla en el .htaccess de la raíz. Es un parche (el atacante puede cambiar de IP), pero corta el ruido al momento. En Apache 2.4 la sintaxis actual es esta:

<RequireAll>
    Require all granted
    Require not ip 203.0.113.45
</RequireAll>

La IP del ejemplo es de documentación: pon la que veas en tus registros. Coloca tus reglas fuera del bloque que genera PrestaShop, antes de la línea # ~~start~~: PrestaShop conserva lo que está fuera de ese bloque cuando vuelve a generar el fichero. Mejor aún, pide al hosting que bloquee la IP en su cortafuegos, para que la petición ni siquiera llegue a PHP. La tienda del caso hizo las dos cosas.

3. Revisar los registros

En Parámetros avanzados → Registros revisa lo que haya quedado anotado: según la versión, PrestaShop apunta ahí las conexiones de los empleados al back-office (en la 9.2 ya no lo hace, así que mira también los registros de acceso del hosting). Busca accesos correctos que no reconozcas, y en Parámetros avanzados → Equipo comprueba que no hay empleados nuevos. Si encuentras algo raro, ya no es un intento: cambia las contraseñas de todos los empleados y cierra sus sesiones.

4. Dejar un aviso que salte

Lo que permitió reaccionar rápido fue enterarse en el momento. Un aviso por correo o por Telegram con cada intento fallido, con cada empleado nuevo y con cada módulo instalado convierte un ataque silencioso en uno que ves llegar.

Lo que conviene tener hecho antes

• Doble factor para todos los empleados (con un módulo, si tu versión no lo trae): con una contraseña adivinada no basta para entrar.
• Contraseñas largas y únicas, sin reutilizar las de otros servicios.
• Si el equipo trabaja desde IP fijas, limita la carpeta de administración solo a esas IP.
• Una URL de administración que no se parezca a admin, backoffice ni al nombre de la tienda.

Bloquear la IP calma el problema; cambiar la URL, el doble factor y los avisos son lo que lo resuelve.

Si quieres recibir en Telegram los avisos de seguridad de tu tienda, el módulo Security Alert por Telegram de Rekire está hecho para esto.

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