Nueva vulnerabilidad en WordPress permite ejecución remota de código sin autenticar.

Una nueva vulnerabilidad, descubierta por el investigador Simon Scannell, 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).
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.

El siguiente bloque de código muestra como WordPress maneja este proceso:

⋮
if ( current_user_can( ‘unfiltered_html’ ) ) {
if (! wp_verify_nonce( $_POST[‘_wp_unfiltered_html_comment’], ‘unfiltered-html-comment’ )) {
$_POST[‘comment’] = wp_filter_post_kses($_POST[‘comment’]);
}
} else {
$_POST[‘comment’] = wp_filter_kses($_POST[‘comment’]);
}
⋮

Como puede observarse, el comentario es saneado a través de la función wp_filter_kses() a no ser que el usuario que postea el comentario sea un administrador que tenga habilitado unfiltered_html. Si esa primera condición se cumple y se verifica también la segunda, a saber, ningún nonce ha sido provisto en la petición, entonces el comentario es saneado con la función wp_filter_post_kses().

La diferencia entre wp_filter_post_kses () y wp_filter_kses () radica en su rigor. Ambas funciones incorporan el comentario no saneado y dejan solo una lista seleccionada de etiquetas y atributos HTML. Por lo general, los comentarios se eliminan con wp_filter_kses () que solo permite etiquetas y atributos HTML muy básicos, como la etiqueta <a> en combinación con el atributo href.

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.

Debido al modo en que WordPress parsea los enlaces para optimizar el SEO, se crea un array asociativo de los atributos de la etiqueta HTML que posteriormente son concatenados de un modo inseguro.

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:

<a title=’XSS “onmouseover=evilCode() id=”‘>

se convertiría en:

<a title=”XSS “onmouseover=evilCode() id=” “>

Como el comentario ya se ha saneado en este punto, el atributo que controla eventos de ratón, en este caso, onmouseover, se almacena en la base de datos y no se elimina. Esto permite a los atacantes realizar un XSS con persistencia en el sitio web de destino al encadenar este defecto de la función de saneamiento con la vulnerabilidad CSRF.
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.

Ver información original al respecto en Fuente>