Inyección SQL en módulos de PrestaShop: cómo detectar administradores falsos

Entras en la lista de empleados del back-office y ves cuentas que no has creado. A veces una, a veces varias seguidas, con correos parecidos y todas con el perfil de superadministrador. No ha entrado nadie con tu contraseña: las ha escrito un programa directamente en la base de datos, aprovechando un módulo con un fallo de inyección SQL.

Es uno de los patrones de ataque más repetidos contra PrestaShop. Vamos a ver cómo funciona, cómo detectarlo y qué hacer.

Qué es una inyección SQL, en una tienda

Un módulo recibe un dato de la petición (un identificador, un texto de búsqueda, un filtro) y lo mete en una consulta a la base de datos sin limpiarlo. Si en vez del número esperado llega un trozo de SQL, la base de datos lo ejecuta. En PrestaShop la defensa básica es sencilla: convertir a entero lo que debe ser un número y pasar por pSQL() lo que es texto. El problema es que no todos los módulos lo hacen en todos sus puntos de entrada.

Los más peligrosos son los controladores front de los módulos: URLs públicas, accesibles sin iniciar sesión, pensadas para el carrito, para una búsqueda por Ajax, para un filtro o para el retorno de una pasarela. Si uno de ellos tiene el fallo, cualquiera en Internet puede explotarlo.

Cómo es la campaña típica

1. Escaneo masivo. Un robot recorre miles de tiendas buscando la presencia de módulos con vulnerabilidades conocidas. No te elige: le basta con que tengas instalada la versión vulnerable.
2. Explotación. Envía la petición que inyecta un INSERT en la tabla de empleados, o un UPDATE que sube de perfil una cuenta existente.
3. Ráfaga. Como el robot no sabe si funcionó, repite. Por eso es habitual encontrar varias cuentas creadas casi a la vez, con identificadores consecutivos.
4. Uso posterior. Con la cuenta, alguien entra al back-office, instala un módulo que es en realidad una puerta trasera, cambia los datos de una forma de pago o inyecta un skimmer en la plantilla del checkout.

Cómo detectarlo en ps_employee

La tabla de empleados (con el prefijo de tu tienda, normalmente ps_) es pequeña y fácil de revisar. Desde phpMyAdmin o la herramienta de base de datos de tu hosting:

SELECT id_employee, firstname, lastname, email, id_profile, active, last_passwd_gen FROM ps_employee ORDER BY id_employee DESC;

Qué mirar:

• id_profile = 1 es el perfil de superadministrador. Cuenta cuántos tienes y si reconoces a todos.
• Identificadores consecutivos al final de la lista que nadie de tu equipo ha dado de alta.
• Correos que no son de tu dominio o con nombres genéricos.
• Nombres y apellidos vacíos o repetidos, que un alta desde el back-office no deja pasar.
• last_passwd_gen con fechas que no encajan con ningún alta que recuerdes.
• Cuentas antiguas que han cambiado de perfil: un empleado de logística que de repente es superadministrador.

Mira también, en la misma visita, las cuentas de webservice (Parámetros avanzados → Webservice). Una clave de API nueva con permiso de escritura sobre la configuración es una puerta que sobrevive a cambiar todas las contraseñas y que no sale en el menú de empleados.

Qué hacer si encuentras uno

1. No borres todavía: desactiva. Pon la cuenta inactiva y guarda sus datos. Te servirán para saber desde cuándo y qué hizo.
2. Revisa qué ha tocado. Módulos instalados recientemente, cambios en la configuración de los métodos de pago (IBAN de la transferencia, claves de pasarela), plantillas del checkout, empleados y webservice, y las URLs de la tienda.
3. Busca ficheros nuevos. Lo habitual es que, con el acceso, se haya dejado una puerta trasera en disco. Compara el núcleo y los módulos con sus paquetes originales.
4. Identifica el módulo vulnerable. Los registros de acceso del servidor suelen mostrar peticiones extrañas a un controlador de módulo justo antes de la aparición de la cuenta. Ese módulo hay que actualizarlo o retirarlo.
5. Cambia credenciales: las contraseñas de todos los empleados, las claves de webservice y, si hay indicios de que han leído la configuración, la contraseña de la base de datos.
6. Revisa los pedidos recientes contra el banco o la pasarela, por si el dinero se ha desviado.

Por qué la prevención es actualizar módulos

Las campañas masivas casi nunca usan fallos desconocidos. Usan vulnerabilidades publicadas, a menudo con parche disponible desde hace meses. El robot funciona porque muchas tiendas no actualizan sus módulos, o porque el módulo vulnerable está abandonado por su autor y nadie lo ha sustituido.

Algunas medidas concretas:

• Inventario de módulos con su versión y su origen. Saber qué tienes es el primer paso para saber qué te afecta cuando se publica un aviso.
• Actualiza primero en una copia y luego en producción, pero actualiza. Un módulo sin actualizar dos años es una apuesta.
• Retira lo que no usas, incluidas las carpetas de módulos desinstalados que siguen en disco.
• Sigue los avisos de seguridad de PrestaShop y de los autores de tus módulos.
• Mantén PrestaShop y PHP en versiones con soporte. Muchos módulos dejan de recibir parches para versiones antiguas: si tu tienda sigue en 1.6 o en una 1.7 temprana, cada aviso nuevo tiene más probabilidades de quedarse sin solución para ti, y la migración pasa a ser también una medida de seguridad.

Un cortafuegos de aplicación puede frenar parte de los intentos, pero no sustituye al parche: las variantes de una misma inyección son muchas, y basta una que pase.

Cómo resolverlo en PrestaShop

RKR Security Alert guarda una foto de los empleados, los módulos, la configuración, las URLs de la tienda y las cuentas de webservice, y la compara con el estado actual en cada carga del back-office y por cron. Por eso detecta un superadministrador creado por inyección SQL aunque no haya pasado por ningún hook, y lo avisa por Telegram como alerta máxima, separado del resto; también cuando una cuenta existente se escala a superadministrador o aparece una cuenta de webservice nueva. Su escáner incluye un analizador de inyección SQL que señala valores de la petición que llegan a una consulta sin conversión ni escapado. Si ya tienes la sospecha o el incidente encima, con un bono de horas de soporte de Rekire hacemos la auditoría, localizamos el módulo por el que han entrado, limpiamos y dejamos la tienda actualizada.