WordPress: vulnerabilidad permite ejecución remota de código sin autenticar.
Una nueva vulnerabilidad, descubierta por el investigador Simon Scannell de RIPS, en el popular gestor de contenidos (CMS) WordPress, permite la ejecución remota de código sin necesidad de autenticación en versiones anteriores a 5.1.1.
El impacto de la vulnerabilidad, según el autor, permite aprovechar el sistema de comentarios del CMS – característica que viene habilitada por defecto – para combinar un ataque por CSRF y varias configuraciones erróneas en las partes del código encargadas de sanear los inputs del usuario. La combinación de ambos factores permite una ejecución remota de código (RCE).
En tanto que un adminstrador está autorizado por WordPress para publicar comentarios que contengan código HTML – etiquetas [script] incluidas – esto puede llevar de manera plausible a un ataque por inyección de HTML.
La manera en la que WordPress pretende solventar este riesgo, es utilizar un identificador único (nonce) para los administradores en el formulario de comentarios. Si la petición del administrador suministra correctamente el nonce, entonces el comentario es creado sin ningún tipo de saneamiento. Si el nonce es inválido, el comentario se publica igualmente, pero pasa previamente por la función para sanearlo.
Esto permite que un atacante publique comentarios que contienen muchas más etiquetas y atributos HTML de lo que normalmente se debería permitir. Sin embargo, aunque wp_filter_post_kses () es mucho más permisivo, elimina las etiquetas HTML y los atributos que podrían conducir a vulnerabilidades XSS.
Un atacante puede crear un comentario que contenga una etiqueta [a] y establecer, por ejemplo, el atributo de título del enlace a title = ‘XSS “onmouseover = alert (1) id =”‘. Este atributo es válido y la función de saneamiento lo dejaría pasar. Esto funciona debido a que el valor de title usa comillas simples. Cuando los atributos se concatenan, el valor de [title] se ajusta entre comillas dobles (línea 3018). Esto significa que un atacante puede inyectar atributos HTML adicionales al inyectar una comilla doble adicional que cierra el atributo title.
Por ejemplo:
Aquí puede verse un análisis y paso a paso completo: WordPress 5.1 CSRF + XSS + RCE – Poc.
Fuente: Hispasec
El impacto de la vulnerabilidad, según el autor, permite aprovechar el sistema de comentarios del CMS – característica que viene habilitada por defecto – para combinar un ataque por CSRF y varias configuraciones erróneas en las partes del código encargadas de sanear los inputs del usuario. La combinación de ambos factores permite una ejecución remota de código (RCE).
Del CSRF a la inyección HTML
WordPress no utiliza ningún sistema de evaluación de CSRF cuando un usuario publica un comentario, lo que significa que un atacante puede publicar comentarios suplantando a un usuario con permisos administrativos.En tanto que un adminstrador está autorizado por WordPress para publicar comentarios que contengan código HTML – etiquetas [script] incluidas – esto puede llevar de manera plausible a un ataque por inyección de HTML.
La manera en la que WordPress pretende solventar este riesgo, es utilizar un identificador único (nonce) para los administradores en el formulario de comentarios. Si la petición del administrador suministra correctamente el nonce, entonces el comentario es creado sin ningún tipo de saneamiento. Si el nonce es inválido, el comentario se publica igualmente, pero pasa previamente por la función para sanearlo.
Esto permite que un atacante publique comentarios que contienen muchas más etiquetas y atributos HTML de lo que normalmente se debería permitir. Sin embargo, aunque wp_filter_post_kses () es mucho más permisivo, elimina las etiquetas HTML y los atributos que podrían conducir a vulnerabilidades XSS.
De la inyección HTML al XSS persistente
El hecho de poder inyectar HTML adicional, lleva directamente a la posibilidad de un ataque XSS con persistencia, en tanto que muchas de las etiquetas HTML que normalmente no podrían incluirse, son ahora manipuladas y parseadas de una manera defectuosa que nos llevan, según el autor, a una inyección arbitraria de atributos.Por ejemplo:
[a title='XSS "onmouseover=evilCode() id="'][a title="XSS "onmouseover=evilCode() id=" "]Ejecutando XSS directamente de un iframe
El siguiente paso para obtener la RCE requiere que el administrador ejecute el JavaScript inyectado visitando el sitio malicioso. El comentario se muestra en la interfaz del blog de WordPress. Dado que la interfaz no está protegida por el encabezado X-Frame, el comentario con el payload se puede mostrar en un iframe oculto en el sitio web del atacante. Dado que el atributo inyectado es un controlador de eventos onmouseover, el atacante puede hacer que el iframe active el XSS instantáneamente con el movimiento del ratón de la víctima. Toda la ejecución del JavaScript ocurre en segundo plano, sin que el administrador de la víctima se haya dado cuenta.De JavaScript a la RCE final
Con la posibilidad de ejecutar código JavaScript arbitrario con la sesión del administrador, la ejecución remota de código es prácticamente trivial. De forma predeterminada, WordPress permite a los administradores de un blog editar directamente los archivos .php de temas y complementos desde el panel de administración. Simplemente insertando una puerta trasera PHP, el atacante puede obtener la ejecución de código PHP arbitrario en el servidor remoto.Aquí puede verse un análisis y paso a paso completo: WordPress 5.1 CSRF + XSS + RCE – Poc.
Fuente: Hispasec
0 Comments:
Publicar un comentario
Gracias por dejar un comentario en Segu-Info.
Gracias por comentar!