Seguridad en Magento 2: parchear, detectar y bloquear ClickFix, PolyShell y CosmicSting

Las tiendas basadas en Magento 2 y Adobe Commerce son un objetivo permanente de las campañas de explotación automatizadas. Cada nueva versión 2.4.x incluye una tanda de parches de seguridad, y los atacantes analizan esos parches en cuestión de días para construir exploits funcionales contra las tiendas que aún no se han actualizado. Este artículo describe las amenazas más relevantes observadas en los últimos meses, cómo reconocer las huellas que dejan en un servidor y qué pasos prácticos seguir para eliminarlas y evitar la próxima intrusión.

Por qué las instalaciones 2.4.x sin parchear son el objetivo principal

Adobe publica con regularidad boletines de seguridad para Magento Open Source y Adobe Commerce, y cada boletín enumera las vulnerabilidades corregidas en esa versión. El intervalo entre la publicación de un parche y la aparición de una prueba de concepto pública se mide hoy en horas, no en semanas. Una tienda que se queda en un nivel de parche antiguo está ejecutando, de hecho, vulnerabilidades ya publicadas y armadas. La primera contramedida es siempre la misma: actualizar el núcleo a la última versión segura y aplicar todos los parches y hotfix oficiales publicados para su rama.

ClickFix: la falsa casilla de verificación humana

ClickFix es una técnica de ingeniería social que no explota Magento directamente, sino que abusa de la confianza que los visitantes depositan en una interfaz conocida. En una tienda comprometida, la página de pago o la página de aterrizaje se modifica para mostrar un falso widget de Cloudflare con el texto 'verifique que es humano'. El visitante marca la casilla exactamente igual que en una página de verificación legítima y un script se copia silenciosamente en el portapapeles. En ese momento no ocurre nada dañino y la página puede incluso parecer que continúa con normalidad.

El peligro llega en el segundo paso. La página falsa indica al visitante que abra una ventana de terminal en macOS o Windows y pegue el contenido copiado para completar la verificación. Si el visitante obedece, el comando pegado descarga y ejecuta una carga de segunda fase en el equipo del cliente. La regla para los usuarios es simple y absoluta: nunca pegar en un terminal comandos procedentes de una página web. La regla para los administradores es encontrar el script inyectado, eliminarlo y cerrar el punto de entrada que permitió la modificación.

Compromiso del lado del servidor: PolyShell, CosmicSting y env.php

Varias familias de vulnerabilidades han dominado los informes de incidentes de Magento 2. PolyShell abusa de las cargas de archivos sin restricciones a través de la API REST para colocar archivos políglota que son a la vez imágenes válidas y PHP válido. CosmicSting ataca el motor de plantillas y puede provocar ejecución remota de código sin autenticación. StyleSmuggler y BlockStrap siguen patrones similares de inyección en plantillas y omisión de filtros. En los casos más graves, el atacante lee env.php, extrae las claves criptográficas almacenadas y falsifica tokens de administrador válidos, lo que le otorga acceso persistente al panel de administración incluso después de cerrar la ruta vulnerable.

Buscar código ofuscado en app, vendor y cache

El código malicioso rara vez es evidente. Los atacantes lo esconden dentro de plantillas .phtml estándar, dentro de módulos del núcleo y dentro de archivos generados en los directorios cache y var. Una búsqueda de texto de las palabras clave habituales a menudo no devuelve nada, porque la carga se ensambla en tiempo de ejecución a partir de cadenas base64 o de varios fragmentos concatenados. Un caso reciente afectaba a un archivo .phtml infectado en la carpeta vendor, modificado solo ligeramente, con la cadena maliciosa repartida entre varias variables.

Compare su instalación con una copia limpia de la misma versión. Utilice una comprobación de integridad de archivos, revise las fechas de modificación e inspeccione cualquier archivo que difiera del paquete oficial. Cuando encuentre un archivo infectado, no se limite a borrar la carga: restaure la versión original desde el archivo oficial y después actualice o bloquee la ruta vulnerable que permitió la escritura.

pub/media nunca debe contener PHP

El directorio media está pensado para almacenar imágenes, PDF y otros recursos estáticos. No existe ninguna razón legítima para que un archivo .php, .php7, .phtml o .phar se encuentre bajo pub/media. Aun así, los atacantes los suben constantemente, y los escondites preferidos son pub/media/custom_options/ y pub/media/custom_options/quote/, donde se guardan los archivos de opciones subidos. Analice estos directorios de forma recursiva, elimine todos los archivos ejecutables que encuentre y verifique que la configuración de subida rechaza las extensiones inesperadas.

Bloquear en el perímetro con Cloudflare, Nginx y Apache

Limpiar el servidor no basta si el punto de entrada sigue abierto. Bloquee las rutas vulnerables antes de que la petición llegue a Magento. En Cloudflare puede crear una regla WAF que deniegue las peticiones a /pub/media/custom_options/ y directorios similares, o que aplique un desafío a cualquier petición que intente alcanzar un archivo PHP dentro de la ruta media. En el servidor de origen, añada reglas equivalentes en Nginx o Apache para que la protección siga funcionando cuando el tráfico evite la CDN.

Recuerde que una regla en el perímetro solo detiene las peticiones que ya conoce. Combínela con el parche, con la monitorización de archivos y con una auditoría periódica del código.

Lista de comprobación de remediación

Conclusión

La seguridad de Magento es un ciclo, no una tarea única. Aplique los parches con rapidez, verifique la integridad de sus archivos, mantenga el código ejecutable fuera del directorio media y bloquee las rutas que no necesite. Si sospecha una inyección de ClickFix, avise de inmediato a sus clientes: la forma más rápida de detener el daño es asegurarse de que nadie pegue nada en un terminal.