Divulgación de Seguridad: XSS Almacenado en Jetpack

Nivel de Seguridad: Peligroso
Nivel de Explotación: Fácil/Remoto
DREAD Score: 8/10
Vulnerabilidad: XSS Almacenado
Versión Parcheada: 3.7.1
Durante una audición de rutina para nuestro WAF, descubrimos una vulnerabilidad XSS almacenada crítica que afecta al Plugin Jetpack para WordPress, uno de los plugins más populares para WordPress.

Línea del Tiempo de Divulgación de la Vulnerabilidad:
10 de septiembre de 2015 – Informe inicial para el equipo de seguridad Automattic
10 de septiembre de 2015 – El equipo de seguridad Automattic confirmó la recepción del informe y fijó una fecha para el parche: el 22 de septiembre
28 de septiembre de 2015 – Divulgación pública con el lanzamiento de parches Jetpack 3.7.1 e 3.7.2
01 de octubre de 2015 – Divulgación Pública de Vulnerabilidad por Sucuri

¿Su Sitio Está En Peligro?

La vulnerabilidad afecta a los usuarios de la versión 3.7 o más antigua de Jetpack que
usa el formulario de contacto de este plugin (activado por defecto). Un atacante puede aprovechar este problema al proporcionar una dirección de correo electrónico maliciosa en una de las páginas del formulario de contacto del sitio. A medida que el correo electrónico no fue verificado apropiadamente antes de entrar en la sección administrativa de ‘Feedback’, el atacante puede utilizar este error y su conocimiento de hacking de navegadores para ejecutar el código JavaScript para el administrador, lo que le permite hacer lo que quiera con el sitio (ocultar un backdoor para explorar en el futuro el sitio hackeado, inyectar spam SEO, etc.).

Detalles Técnicos

Encontramos el problema al comprobar cómo el plugin administraba correos electrónicos que fueron enviados a través de las páginas que contenían el formulario de contacto:

A primera vista, todo parecía bien. La dirección de correo electrónico pasaba a través del mismo filtro (pre_comment_author_email) que WordPress usa para desinfectar los correos electrónicos que se envían para su componente de revisión. Además, el resultado pasó por un método personalizado strip_tags() que hace lo que sigue:

Envía el código para wp_kses()
con una línea en blanco en el segundo parámetro, lo que nos impide de inyectar cualquier etiqueta HTML en la dirección del correo electrónico. Con esto en mente, insertamos caracteres ficticios hasta lograr este resultado al visitar la sección de comentarios en el panel de administración::

Logramos insertar una comilla simple no desinfectada en un atributo href. En un escenario de prueba regular, esto generalmente significaría que hay un tipo de ataque XSS, ya que podríamos insertar un payload como el siguiente para inyectar un script malicioso:

foo’ onmouseover=’alert(1);//@bar.com

Sin embargo, encontramos resultados diferentes al probar este payload:

Parece que el módulo encontró el formato de nuestra dirección de correo electrónico tanto en el lado del cliente como en el lado del servidor. Investigamos más a fondo cómo las cosas estaban sucediendo en el servidor. Comprobamos que el script validaría nuestra dirección de correo electrónico, usando la función is_email() de WordPress antes de guardarla en la base de datos. Sabíamos desde la investigación anterior que esta función permite caracteres que pueden ser peligrosos en algunos contextos, especialmente en la parte local de la dirección del correo electrónico (antes del símbolo ‘@’):

Esto nos da una buena lista de caracteres a utilizar, pero aún así tuvimos otro desafío:‘(‘, ‘)’, ‘:’,’;’y el caracter de espacio están bloqueados en esta expresión regular y se utilizan para bloquear la expresión regular y no son necesários para hacer un payload útil. El primer problema ocurrió cuando intentamos separar el href final del eventoonmouseover que intentávamos inyectar, algo fácilmente gerido para insertar barras diagonales (‘/’) entre los atributos, que funcionan como separadores en navegadores. Entonces, el comienzo del payload sería así:

foo’/onmouseover=’@bar.com

El último problema que tuvimos que resolver fue el hecho de que no pudimos agregar ningun punto y coma. La primera idea que teníamos era insertar entidades de HTML en el atributo onmouseover, pero eso causó otro problema: entidade de HTML con punto y coma.

Observamos el HTML5 Tokenizer de Mozilla para descobrir algo que nos ayudaría a resolver esa situación, usando la entidade de HTML decimal (A por exemplo).

Simplificando, el snippet hace eso:

1. Si es una entidad HTML decimal asegúrese que el byte actual que estamos analizando tiene un valor entre ‘0′ y ‘9’ (esencialmente, un número decimal) si necesario, agregue valor a la variable’value‘.
2. Si es un punto y coma, haga lo siguiente:
   1. Si ya ha armazendo decimales previamente, vaya aNS_HTML5TOKENIZER_HANDLE_NCR_VALUE y convirta la variable ‘value’ por su caracter correspondiente.
   2. O, caso no sea una variable, ignórela.
3. Si no hay un punto y coma y no hemos analizado um numeral decimal, haga lo siguiente
   1. Si no habíamos almacenado la variable ‘value’ anteriormente, haga lo mismo del paso 2.2 e ignore esa entidad corrompida.
   2. Si hay una variable, entonces haga como en el paso 2.1, vaya hasta elNS_HTML5TOKENIZER_HANDLE_NCR_VALUE y envíe un mensaje de error de debug notificando al desarrollador del problema que él causó.

Esto significa que, si en lugar de escribir un punto y coma, por ejemplo, escribimos una entidad de contrapartida decimal ; y cambiamos el punto y coma por algo diferente&#59/**/, eso funcionaría también y evitaría los límites del is_email(), porque nos permitía usar solamente algunos caracteres específicos.

Desse ponto em diante, o atacante tem um vetor de ataque XSS completo para comprometer a segurança do usuário desse site ainda mais, algo que você, definitivamente, não gostaria que acontecesse.
A partir de este momento, el atacante tiene un vector de ataque XSS completo para comprometer la seguridad del usuario de este sitio algo que, definitivamente, usted no quiere que suceda.

Actualice Pronto

Debe tener en cuenta un par de cosas acerca de esta vulnerabilidad. Hay cross-site scripting (XSS) en diversas formas, algunos son más graves que otros. En la mayoría de los casos, las vulnerabilidades que se asignan a XSS son, en realidad, vulnerabilidades XSS refletidas. En este caso, el usuario puede hacer que algo funcione en el navegador a través de un URL desarrollada con precaución, pero esto se produce en la superficie pre-verbal del sitio.

En este caso, sin embargo, nos referimos a una vulnerabilidad XSS almacenada; lo que significa que um visitante de su sitio puede pasar códigos arbritarios para el servidor web y esperar hasta que alguien acceda a su panel de WordPress. Esto es fundalmentamente diferente. Los usuarios que inician sesión pueden ser abonados, autores e incluso administradores. Los atacantes simplemente tienen que esperar hasta que el usuario correcto aparezca sin introducir ningún otro indicador que pueda alertar al administrador (una campaña de phishing, por ejemplo). Ese problema se intensifica debido a la popularidad de un plugin, como el Jetpack, instalado por defecto en muchas instalaciones a través de hosts o de paquetes de instalación.

Esto también trae al lector un ejemplo que ilustra cómo, con el tiempo y la energía de sobra, bugs pueden se identificar y explotar contenido malicioso. En la mente del atacante, el objetivo es conquistar a uno, para conquistar a todos. Extensiones de ataque para aplicaciones CMS, como Jetpack (que tiene una base de instalación de más de 1 millón de instalaciones activas), es una mina de oro para el atacante. No se olvide de actualizarlo. Si por alguna razón no puede actualizarlo, ofrecemos nuestro paquete de seguridad que proporciona una defensa proactiva contra este problema y contra otros problemas aún desconocidos. Vea nuestras plataformas de protección, como nuestro Firewall de Sitios o otra tecnología equivalente que agrega alguna forma de parche y hardening virtual para ayudarlo a quitar esas amenazas.

Source:https://blog.sucuri.net