Admin Menu Editor Pro reparte un backdoor a 1.500 sitios WordPress
El atacante comprometió la web del desarrollador y coló dos versiones maliciosas del plugin de pago, la 2.35 y la 2.36, con un web shell y una cuenta de usuario oculta.
Las versiones 2.35 y 2.36 de Admin Menu Editor Pro distribuyeron un backdoor entre los clientes de la edición de pago del plugin. El atacante comprometió la web del desarrollador, adminmenueditor.com, y publicó una actualización que instalaba un web shell y creaba una cuenta de usuario oculta en los sitios afectados.
El desarrollador, Janis Elsts, detectó el acceso no autorizado el lunes y subió la versión 2.35 al canal de actualizaciones. El encargado de instalar el web shell era el fichero includes/wp-user-consent.php, dentro del directorio admin-menu-editor-pro. Cuando se dio cuenta, Elsts retiró la actualización y publicó una versión limpia, la 2.36, ese mismo día a las 19:00 UTC. No sirvió de mucho: el atacante seguía teniendo acceso a la web y manipuló también esa segunda versión.
Qué se sabe del alcance
La ventana de exposición de la 2.35 fue de aproximadamente las 06:00 a las 13:00 UTC. Según Elsts, unos 230 clientes instalaron la actualización maliciosa en al menos 1.500 sitios. La cifra de víctimas puede ser mayor porque resulta difícil saber cuántos clientes llegaron a ejecutar la 2.36 trojanizada. "Varios cientos de clientes adicionales descargaron el plugin en la ventana relevante o cerca de ella, y podrían haberse visto afectados", ha explicado.
Los indicios que delatan una instalación comprometida son cuatro: el fichero includes/wp-user-consent.php en el directorio admin-menu-editor-pro, un directorio nuevo en /wp-content/object-cache/, un usuario que empieza por wp_ en la tabla wp_users (puede estar oculto en el panel de WordPress) y opciones con nombres del tipo wp_ocache* en wp_options.
La versión 2.34 se considera limpia, y la edición gratuita de Admin Menu Editor —el plugin base, presente en más de 300.000 sitios, que sirve para personalizar el menú del escritorio, ocultar plugins a otros usuarios y limitar accesos por rol— no parece afectada.
Elsts cree que el atacante tenía acceso a nivel de root en el servidor, así que ha mantenido la web fuera de línea hasta poder restaurarla con garantías. En su lugar ha dejado una página estática con los detalles del incidente y las recomendaciones. La recuperación más fiable, dice, es restaurar desde una copia de seguridad anterior al 14 de septiembre. Si no hay copia, toca borrar el plugin, el directorio /wp-content/object-cache/ y las entradas correspondientes en la base de datos.
El incidente se limita a su infraestructura, según el desarrollador, que ha pedido disculpas a los clientes afectados.
El caso es el escenario que más duele en el ecosistema de plugins: no hay un fallo que parchear, el canal de distribución era el arma. Y el doble compromiso de la 2.36 deja una lección incómoda: retirar la versión maliciosa no sirve de nada mientras el atacante conserve el acceso al servidor que la sirve.
