Se ha detectado una nueva cadena de ataque que pone en riesgo a los administradores de WordPress que mantienen su panel de control abierto en el mismo navegador que usan para navegar habitualmente. Investigadores han documentado el uso de un cargador de JavaScript que, al detectar una sesión activa de administrador en una página comprometida, aprovecha dicha confianza del navegador para instalar un backdoor de PHP oculto en el sitio.

Los administradores de WordPress suelen mantener su panel de control abierto en el mismo navegador que utilizan para su navegación diaria. Una nueva cadena de ataque demuestra por qué ese hábito es arriesgado.

Varios investigadores han documentado un cargador de JavaScript que espera a que un administrador con sesión iniciada visite una página comprometida y, acto seguido, utiliza la sesión confiable de ese navegador para instalar una puerta trasera (backdoor) de PHP oculta en el sitio web.

El atacante nunca necesita la contraseña del administrador, ya que el propio navegador del administrador hace el trabajo. Casos recientes apuntan al mismo patrón.

Un ejemplo es una campaña de malware de WordPress activada por el administrador que expuso a más de 1,2 millones de sitios web a un posible compromiso.

El malware que se activa únicamente durante las sesiones iniciadas es difícil de detectar mediante escaneos rutinarios, lo que lo convierte en una preocupación creciente para los propietarios de sitios.

Investigadores de seguridad de Securonix Threat Research, Akshay Gaikwad y Aaron Beardslee, identificaron el malware y nombraron la cadena TRUST#GRAFT.

Su análisis muestra que el JavaScript no rompe el inicio de sesión de WordPress. En su lugar, comprueba si el visitante ya ha iniciado sesión como administrador y luego reutiliza esa sesión para añadir código nuevo al sitio. Securonix también señala que no ha confirmado cómo llegó el primer script a la página comprometida.

Abusar de las sesiones iniciadas de administrador de WordPress

La infección comienza con un falso control de seguridad. El script coloca un marco de pantalla completa sobre la página que parece una pantalla de verificación de Cloudflare de "Solo un momento".

Mientras el visitante espera, el script recopila detalles como el tamaño de la pantalla, datos gráficos, la zona horaria y el número de plugins instalados. También busca indicios de herramientas de análisis automatizadas.

Después de resolver un pequeño rompecabezas, el navegador envía estos datos a un servidor controlador, que decide si enviar la siguiente etapa. A continuación ocurre el paso clave.

El script solicita la página de subida de plugins de WordPress utilizando las cookies de inicio de sesión existentes del navegador y, después, lee un token de seguridad de WordPress, llamado nonce, de esa página.

Descarga un archivo ZIP llamado wm.zip desde un servidor de preparación y lo sube a través del punto de acceso estándar de instalación de plugins.

Si la subida funciona, el script abre la página de plugins y activa el nuevo plugin. WordPress acepta cada solicitud porque el navegador ya ha iniciado sesión con permisos de plugin.

Securonix subraya que esto no es un bypass de inicio de sesión independiente. La cuenta ya debe ser de administrador y tener permiso para instalar plugins.

Aun así, el riesgo es grave para cualquiera que navegue por sitios web públicos mientras tiene iniciada la sesión en wp-admin, o que utilice un único perfil de navegador tanto para la navegación diaria como para la gestión del sitio.

Una puerta trasera de PHP persistente se oculta en los plugins "Must-Use"

El archivo ZIP contiene un plugin de PHP llamado Web Media Optimizer, versión 2.1. El nombre sugiere una herramienta inofensiva de imágenes o medios, pero Securonix lo describe como una puerta trasera.

Inyecta JavaScript remoto en páginas públicas, desactiva las comprobaciones de certificados TLS cuando obtiene su script controlador y puede establecer una cookie de inicio de sesión de administrador para la primera cuenta de administrador mediante un token predefinido.

El plugin también protege su propia presencia. Al activarse, se copia a sí mismo en wp-content/mu-plugins/wmedia-recovery.php.

WordPress carga automáticamente cada archivo de esa carpeta, y esos archivos no aparecen en la página normal de Plugins. Ya se han reportado casos similares de malware de plugins ocultos "must-use", lo que demuestra por qué eliminar solo el plugin visible no es suficiente.

Los propietarios de los sitios también deben tomarse en serio la limpieza. Es necesario eliminar el plugin visible, la copia de mu-plugins y cualquier fuente de script remoto restante para detener la reinfección.

Tú, como administrador, también deberías revisar los casos recientes de malware de puertas traseras que se autorestauran en WordPress, que muestran cómo pueden volver a aparecer los archivos eliminados.

Securonix recomienda utilizar un perfil de navegador separado para wp-admin, cerrar la sesión después de una actividad sospechosa, rotar las credenciales de administrador, limitar los derechos de subida de plugins y vigilar la aparición de nuevos archivos PHP en mu-plugins.