Web shells en PrestaShop: qué son, dónde se esconden y cómo encontrarlas

Cuando alguien entra en una tienda, lo primero que hace casi nunca es robar. Lo primero es asegurarse de que puede volver. Para eso deja una web shell: un fichero PHP que, pedido por URL, le permite listar carpetas, editar ficheros, lanzar consultas a la base de datos o ejecutar órdenes en el servidor. Con eso, aunque parchees la vulnerabilidad por la que entró y cambies todas las contraseñas, él seguirá dentro.

Este artículo va de cómo son, dónde se meten en PrestaShop y cómo buscarlas sin perderte entre falsos positivos.

Qué es exactamente una web shell

Es un programa pequeño escrito en el mismo lenguaje que la tienda, que se ejecuta con los permisos del usuario web. No necesita explotar nada más: si el servidor ejecuta PHP en esa carpeta, la shell funciona. Las hay de muchos tamaños:

• Cargadores de una línea. Treinta o cuarenta bytes que solo incluyen otro fichero. El código malicioso está en ese otro fichero, que muchas veces lleva extensión de imagen.
• Gestores de ficheros completos. Una interfaz para navegar por el servidor, editar, subir, renombrar y borrar, protegida con una contraseña escrita en el propio fichero.
• Ejecutores de órdenes. Reciben un parámetro y lo pasan al sistema operativo.
• Módulos enteros. Una carpeta con estructura de módulo de PrestaShop, fichero principal impecable y la carga escondida en un controlador.

Dónde se esconden en PrestaShop

El atacante busca sitios donde un fichero nuevo no llame la atención. En PrestaShop hay varios clásicos:

Ficheros de más en módulos nativos

Un ajax.php o un config.php dentro de la carpeta de un módulo oficial que, en el paquete original, no tiene ese fichero. Nadie mira dentro de los módulos que vienen con la tienda, y el nombre parece de toda la vida. La única forma de verlo es comparar la carpeta con el paquete que publicó su autor.

Módulos huérfanos

Carpetas de módulos desinstalados que siguen en disco. No salen en el gestor de módulos, nadie las actualiza y su PHP sigue siendo accesible por URL. Son un escondite cómodo y, a la vez, una puerta de entrada.

El núcleo y vendor/

Una línea pegada al final de un fichero del núcleo (las clases de producto, el despachador, el autocargador) o de una librería de vendor/. Muchos escáneres excluyen vendor/ porque es ruidoso, y justo por eso es buen sitio. En incidentes reales se han encontrado más de una decena de puertas en ficheros legítimos de una misma tienda, todas añadidas al final y sin ninguna palabra sospechosa a la vista.

Imágenes con PHP dentro

Un JPEG o un PNG perfectamente válido, que se ve en cualquier visor, con código PHP añadido al final. Por sí solo no se ejecuta; lo ejecuta un cargador que lo incluye. Por eso, si encuentras uno, busca también al otro.

Carpetas de datos

upload/, download/, img/ o translations/ no deberían tener nunca un .php ejecutable. Si aparece uno, no hay explicación inocente.

Cómo se camuflan

Las shells que duran meses no son las que gritan eval(base64_decode(...)). Son las que parecen código normal:

• Llevan la cabecera de licencia de PrestaShop copiada de otro fichero, con su bloque de comentarios y su guarda de versión al principio.
• Se llaman como algo inofensivo: uninstall.php, index.php, cron.php, o un título que habla de un lector de códigos QR.
• Montan los nombres de las funciones peligrosas en tiempo de ejecución, cogiendo letras sueltas de una cadena larga. En el texto no aparece ninguna función prohibida.
• Contestan 404 si no reciben la clave correcta, igual que una URL que no existe. Barrer la tienda pidiendo rutas no las encuentra.
• Conservan la fecha de modificación del fichero original, para no salir al ordenar por fecha.

Cómo buscarlas con criterio

El orden importa. Ve de lo más concluyente y barato a lo más caro:

1. ¿Es idéntico al que publicó su autor? Compara el núcleo con el ZIP oficial de tu versión exacta (el de la release, no el repositorio, que trae carpetas de desarrollo y produce cientos de diferencias falsas) y cada módulo con su paquete. Un fichero idéntico byte a byte no está infectado.
2. ¿Estaba en el paquete? Lo que no estaba lo puso alguien después. Esta pregunta encuentra ficheros que ningún patrón detectaría, porque pueden estar impecablemente escritos.
3. ¿Ha cambiado desde la última vez? Si tienes una línea base de integridad de cuando la tienda estaba limpia, cualquier cambio sin actualización detrás es una respuesta.
4. ¿Qué sabe hacer? Para lo que no tiene referencia: listar directorios y escribir ficheros con una ruta que llega por parámetro, ejecutar órdenes, leer ficheros del sistema, contraseñas comparadas con un hash guardado en el propio código.
5. ¿Desde dónde se alcanza? Un controlador controllers/front/ de un módulo se pide desde Internet sin sesión; uno de controllers/admin/ exige sesión de empleado. Eso decide si hay que actuar esta noche o mañana.

Y una regla para el ruido: si marcas algo como seguro, hazlo por el hash del contenido, no por la ruta. Una excepción por ruta seguirá tapando ese fichero el día que alguien lo sustituya.

Por qué no basta con borrarla

Borrar la shell es el último paso, no el primero. Antes de tocarla:

• Guarda una copia de la tienda tal cual está, para saber qué hizo y desde cuándo.
• Mira si ha dejado otras puertas. Claves en authorized_keys de las cuentas del servidor, empleados nuevos en el back-office, cuentas de webservice con permisos amplios y tareas programadas que descargan y ejecutan algo cada pocos minutos. Borrar un fichero no cierra una clave SSH ni un cron.
• Busca la vía de entrada. Un módulo vulnerable, una contraseña de FTP robada, una versión de PrestaShop sin parchear. Si no la cierras, la shell vuelve en días.
• Cambia credenciales después de limpiar, no antes: base de datos, FTP, panel, empleados y la clave de cookies si sospechas que han leído la configuración.

Y una vez limpia, toca lo de siempre: PrestaShop, PHP y módulos al día. La inmensa mayoría de las entradas aprovechan fallos ya corregidos en versiones que la tienda no había instalado.

Cómo resolverlo en PrestaShop

RKR Security Alert escanea los ficheros de la tienda en busca de skimmers, puertas traseras y web shells, incluidas las que no tienen firmas peligrosas: detecta las shells por lo que saben hacer, los cargadores que incluyen una imagen, el PHP escondido dentro de imágenes válidas y los ficheros con nombres de función montados por índices. Compara el núcleo con el ZIP oficial, indica en cada hallazgo si se alcanza por URL y sin sesión, y mantiene una línea base de integridad que solo se construye cuando das por revisada la primera auditoría, para no dar por buena una infección previa. Avisa por Telegram y guarda los avisos en la tienda, y no envía ningún fichero fuera del servidor. RKR Sentinel complementa la vigilancia avisándote de errores de PHP, respuestas 500 y pagos que no acaban en pedido, que a menudo son el primer síntoma visible de que algo se ha tocado.