WordPress: Cómo buscar {y encontrar} 0days en plugins con Taint Analysis

Cuando el equipo de Ideas Locas estaba en plena expansión, tocamos un tema derivado de algún trabajo anterior. La idea estaba relacionada con el mundo de la Seguridad en WordPress, el CMS más utilizado del mundo. La idea tenía de fondo el mundo de la seguridad, y la búsqueda de vulnerabilidades en primer plano, algo que nos podía ayudar a mejorar el servicio de Faast for WordPress de ElevenPaths.

Figura 1: WordPress: Cómo buscar {y encontrar} 0days en plugins con Taint Analysis

Me gusta explicar en las charlas que doy, qué es eso de Ideas Locas, pero éste es un claro ejemplo de la parte de: “Conociendo los detalles de nuestros productos y servicios se puede ayudar con alguna idea que los mejora”. El artículo de hoy pretende mostrar un trabajo que llevamos a cabo hace ya un año y algo, y que ahora continúan otros compañeros, en concreto en el centro Tegra de Galicia. Esta semana hemos liberado el artículo del trabajo que hicimos.

Figura 2: Libro de Máxima Seguridad en WordPress

En aquel entonces, Chema Alonso y yo habíamos estado trabajando con Daniel Martín para completar, y dejar como lo dejamos, el libro de Máxima Seguridad en WordPress de 0xWord, para lo que aportamos mucho trabajo de investigación. Dicho trabajo dio sus frutos con nuestro querido WordPress in Paranoid Mode, pero para lo que publicamos muchos artículos de cómo íbamos avanzando. En esta charla, se recogen muchos de lo que fuimos trabajando entonces, y que están incluidos todos en el libro.


Figura 3: Hardening WordPress like a hacker
La idea de este trabajo fue realizar diferentes comprobaciones sobre el código fuente de los diferentes plugins de Wordpress públicos. Este análisis nos puede permitir descubrir nuevas vulnerabilidades que puedan existir en estos plugins de cualquier tipo y que, por alguna razón, no han sido evaluados por sus desarrolladores de forma intensiva.

Encontrar vulnerabilidades en el core de Wordpress se hace cada vez más complejo, pero los sitios que utilizan Wordpress utilizan muchos plugins externos a éste, por lo que son estos plugins los vectores de ataque más utilizados. La idea inicial del estudio pretendía ser una pequeña estimación de lo que se podía lograr, pero acabó, como se verá, siendo otra cosa.

Buscando bugs en código fuente

Un día le enseñé a mi compañero de trabajo, por aquel entonces, Santiago Hernández Ramos, la investigación que hice tiempo atrás sobre búsqueda de vulnerabilidades en repositorios de código abierto. Esto acabó siendo un artículo que publiqué junto al Dr. Alfonso Muñoz - autor del libro de "Cifrado de las comunicaciones digitales: de la cifra clásica a RSA 2ª Edición" - llamado “Detección de funciones inseguras en repositorios de software libre” y que era una formalización del trabajo de OSB-Rastreator que publiqué en este blog.

Figura 4: Detección de funciones inseguras en repositorios de software libre

La idea era ir descargando el código fuente de los paquetes de software accesibles desde una distribución de GNU/Linux como, por ejemplo, Ubuntu. Ese código fuente descargado se iba analizando por patrones con el objetivo de descubrir funciones inseguras en Lenguaje C.


Figura 5: Conferencia en el CyberCamp sobre OSB-Rastreator
Una vez detectadas se buscaba la forma de automatizar la detección de la vulnerabilidad, ya que la función podía ser o no vulnerable. Los resultados se pueden consultar en el artículo y se puede ver alguna vulnerabilidad que se formalizó.

Figura 6: Vulnerabilidad descubierta por OSB-Rastreator

A Santiago, que es una persona con una gran inquietud y con muchas ganas de investigar, le resultó interesante y empezamos a darle una vuelta a una sugerencia del boss. Tras una comprobación que hizo Santiago, vimos que era viable descargar el código fuente de los plugins y, al final, es código PHP que se podría evaluar. Aquí comienza la historia de este trabajo.

Trabajando con los plugins de WordPress: Taint Analysis & Taint Propagation

La idea es sencilla, se propone un sistema de auditoría de código de los plugins existentes en el repositorio oficial de WordPress. Se podría extrapolar a plugins que se encuentren fuera del ‘repo’ oficial, por ejemplo, en Github.

El sistema realiza un recorrido por las extensiones y aplica diferentes técnicas de análisis estático sobre su código fuente. El objetivo principal consiste en la detección de un conjunto de patrones inseguros, los cuales, tal y como ocurría en el anterior trabajo, pueden desembocar en una potencial vulnerabilidad. Lo potente de esto es que descubrir vulnerabilidades en el código sobre versiones públicos y últimas hacían que con mucha probabilidad hablásemos de 0days.

Después de la detección del sistema, nuestra idea era que un experto analizase el resultado. Esto siempre debe ser así, ya que la herramienta automática puede provocar falsos positivos. A continuación, presentamos el artículo del trabajo el cual ha sido publicado recientemente.

Figura 7: Detección y estimación de vulnerabilidades en plugins de WordPress

En el paper se puede visualizar un apartado de ‘Estado del arte’ en el que se hablan de diferentes estudios sobre esta temática. Los resultados parecen ser en todos los casos más que interesantes. También hay una parte de introducción mostrando diferentes conceptos sobre diferentes análisis que el sistema va ir haciendo antes de lanzar las comprobaciones de seguridad o el análisis de código estático.

Es importante hacer hincapié en el Taint Analysis. Este tipo de técnica permite conocer qué variables dentro de una aplicación tiene interacción directa o indirecta con el usuario. En otras palabras, conocer qué valores puede controlar o manipular un atacante se conoce como Taint Propagation. Es importante conocer cómo la información entra en la aplicación y fluye a través del mismo. De este modo se podrá identificar y validar los datos de entrada de una aplicación. El Taint Analysis es fundamental en esta idea y en este sistema.

Arquitectura del sistema

La arquitectura básica del sistema se puede desglosar en la siguiente imagen. En esta imagen se puede observar diferentes partes. La arquitectura se puede dividir en diferentes subsistemas, como vamos a ir haciendo.

Figura 8: Subsistemas de la arquitectura del sistema creado para el paper

Lo primero es entender la importancia en el sistema del crawler que permitirá recopilar todo el código fuente que habrá que modelar y, posteriormente, analizar. En el sistema completo éste es el subsistema más sencillo, que se encarga de localizar el repositorio y realizar la descarga del plugin.

El segundo susbsitema es el modelado. Éste necesita de un lexer y un parser. El lexer se encargará de generar tokens del código fuente obtenido por el crawler. Cada uno de los tokens devueltos es un array con un identificador, el valor del token y el número de línea.

Además, del lexer se implementa el parser. En este caso, se recorre la liste de tokens producida en el paso anterior, identificando mediante el campo “nombre” los tokens más importantes. Para cada uno de los ficheros analizados, se crea una pila de dependencias que permitirá determinar el ámbito de la función o estructura del lenguaje en la que se encuentran dos variables distintas.

Figura 9: Flujo de ejecución de los subsistemas

Posteriormente, se realiza el análisis de control de flujo y el análisis de flujo de datos. En este último es dónde interviene el Taint Analysis. Eso sí, con algunos matices.

Evaluación y resultados

En el paper se puede encontrar un estudio sobre 60 plugins de Wordpress que han sido analizados a través de este sistema.

Figura 10: Plugins evaluados en el estudiio

Los resultados fueron bastante reveladores encontrando algunas vulnerabilidades. Como solo era un estudio, buscamos ejemplos de las vulnerabilidades en tecnologías web más comunes, que se utilizan en ataques como son SQL Injection, por supuesto, ataques de Client-Side basados en Cross-Site Scripting, y algunos ataques comunes en el Hacking de Web Technologies. Se buscaron de forma automática las siguientes:

• Patrones XSS.
• Patriones SQLi.
• Patrones LFI y RFI.
• Patrones de ejecución de código.

Con este análisis sobre solo un número reducido de plugins, se descubrieron 5 vulnerabilidades de tipo 0day con este motor desarrollado para el estudio, que fuero reportadas para que se corrigieran.

Figura 11: 0days descubiertos durante el estudio

Las vulnerabilidades tienen su CVE, como puede verse en el cuadro anterior. Lo interesante es ver que hay plugins que se encontraban en más de 1 millón de instalaciones de Wordpress. Digo interesante por la ayuda a la mejora de la seguridad que este tipo de sistemas proporciona.

Faast for Wordpress

Como ya sabéis, hace tiempo que en ElevenPaths se lanzó una versión especial de Faast - nuestro servicio de pentesting persistente, para dominios con WordPress al que llamamos Faast For WordPress y del que hablamos por aquí en el blog en el artículo titulado: "Faast for WP: Pentesting as a Self Service para tu WordPress".


Figura 12: Demo de Faast for WordPress
A día de hoy, el trabajo de análisis de plugins de WordPress en búsqueda de 0days se utiliza para alimentar el conocimiento de este producto, y de manera continua reportamos los bugs que vamos descubriendo, por lo que aquel trabajo se ha convertido en algo que sirve no solo para nosotros sino para todos los que usan los plugins con vulnerabilidades que se van parchenado, y eso es reconfortante.

Más Referencias:

[Libro] Máxima Seguridad en WordPress
[Libro] Hardening GNU/Linux
[Paper] WordPress in Paranoid Mode (Parte 1)
[Paper] WordPress in Paranoid Mode (Parte 2)
[Paper] Detección y estimación de vulnerabilidades en WordPress
[Vídeo] Proteger WordPress con Latch
[Vídeo] Proteger WordPress con Latch Cloud TOTP
[Vídeo] MyWordPress in Paranoid Mode (conferencia Chema Alonso)
[Vídeo] MyWordPress in Paranoid Mode (ElevenPaths Talks de Pablo González)
[Vídeo] Ejemplo de uso de Latch en WordPress
[Vídeo] Hardening WordPress like a hacker
[Vídeo] WordPress Demo XSS en WP-UserAgent
[BlogPost] My WordPress in Paranoid Mode
[BlogPost] Máxima Seguridad en WordPress
[BlogPost] Hackear un WordPress con Network Packet Manipulation
[BlogPost] Fortificar comunicación entre WordPress y MySQL
[BlogPost] WordPress Latch Enforcement
[BlogPost] WordPress aún más seguro con Latch Lock After Request
[BlogPost] Fortificar WordPress frente a ataques de fuerza bruta
[BlogPost] Ataques (al corazón) de tu WordPress
[BlogPost] Cómo robarle las contraseñas a los administradores de WordPress
[BlogPost] Agrupar el control de varios WordPress con un solo Latch
[BlogPost] WordPress: Time-Based XSPA (Cross-Site Port Attack)
[BlogPost] Cómo debería ser un WordPress un poco más seguro
[BlogPost] WPHardening: Automatizar fortificación de WordPress
[BlogPost] Protege los borradores de los artículos de tu WordPress
[BlogPost] Registro de cuentas en WordPress públicos
[BlogPost] Riesgos en la ejecución de tareas de Cron
[BlogPost] WordPres: XSS en plugin WP-UserAgent
[BlogPost] Listar los plugins de WordPress en un pentest
[BlogPost] WordPress: SQL Injection en Scarcity Builder Plugin
[BlogPost] Docker WordPress in Paranoid Mode
[BlogPost] Faast for WordPress

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.

KRACK Attack o cómo reventar WPA2 y de paso nuestra confianza en la seguridad WiFi

Uno de los pocos bastiones que aún quedaban hoy día en la seguridad WiFi con más de 14 años en funcionamiento, nuestro querido protocolo WPA2, acaba de ser vulnerado. Esta es la primera vulnerabilidad que se ha encontrado en este protocolo durante todo ese tiempo que ha estado implantado, pero es lo suficientemente crítica como para activar todas las alarmas y no es para menos, ya que hasta el momento solo existían ataques de fuerza bruta a las claves de cifrado en modo WPA2-PSK [Atacar WPA/WPA2-PSK & Crackear WPA/WPA2-PSK], que se podían evitar con relativa normalidad mientras no llegasen los afamados equipos cuánticos.

Figura 1: KRACK Attack o como reventar WPA2 y de paso nuestra confianza en la seguridad WiFi

Explotar esta vulnerabilidad podría permitir a un atacante dentro del rango de la WiFi, insertar un virus a la red o incluso interceptar cierto tipo de comunicaciones y por lo tanto, tener acceso a información sensible que hasta ahora considerábamos segura. Además, afecta a todas y cada una de las redes WiFi actuales protegidas y a todos los dispositivos que utilicen dicho protocolo, y esto significa un gran agujero de seguridad para los entornos domésticos y empresariales, lo que harán tensar a los equipos de seguridad de las compañías con planes específicos.

Esta vulnerabilidad ha sido encontrada recientemente por el investigador Mathy Vanhoef, de la universidad belga KU Leuven, que ha bautizado como KRACK, Key Reinstallation Attacks. Afecta en una u otra manera a cualquier plataforma como Android, Linux, Windows, OpenBSD, MediaTek, Linksys, etc.... El paper será presentado formalmente en la conferencia CCS, Computer and Communication Security el día 1 de Noviembre.

Figura 2: Paper de KRACK ATTACK

La única prueba que tenemos hasta ahora donde se pueda confirmar que esta vulnerabilidad puede ser explotada, es la demostración PoC que ha realizado y que ha publicado en su blog a modo de vídeo. Dicha PoC se basa en un ataque KRACK contra un dispositivo Android, donde el atacante es capaz de descifrar la información que están transmitiendo la víctima (al parecer KRACK es especialmente efectivo contra Linux y Android 6.0 o superior). De hecho, cuando se utilizan otras plataformas, es más complicado de descifrar todos los paquetes e incluso algunos no se pueden descifrar. Éste es el vídeo donde se puede observar el ataque en funcionamiento:


Figura 3: PoC de KRACK ATTACK
El eje principal vector del ataque se centra en four-way handshake del protocolo WPA2. Resumiendo, este procedimiento (handshake) se utiliza para comprobar las credenciales cuando un usuario está intentando unirse a una red WiFi. Durante este proceso se generan claves nuevas de cifrado, las cuales se instalan después de recibir el Mensaje 3 de los 4 y que sirven para proteger la sesión del usuario que está intentando conectarse a la WiFi. Los Mensajes se definen mediante tramas tipo EAPOL (EAP over LAN) las cuales tienen la siguiente estructura:

Figura 4: Formato simplificado de una tram EAPOL mostrado en el paper de KRACK ATTACK

La vulnerabilidad que explota KRACK permite al atacante manipular o repetir de nuevo este tercer Mensaje, permitiendo reinstalar la clave criptográfica que ya se ha utilizado. Y esto es importante para poder salvaguardar la seguridad del protocolo WPA2 ya que una clave criptográfica sólo puede ser utilizada una vez durante este proceso. El paper publicado explica en detalle todo el procedimiento KRACK. Éste sería un resumen simplificado del ataque:

1. El atacante intenta unirse a una red WiFi. 

2. Comienza el proceso four-way handshake. 

3. Se negocia una nueva clave de cifrado en el Mensaje 3 del proceso. 

4. No se envía la señal de acknowledgment (reconocimiento) que verifica que se ha recibido el Mensaje 3 correctamente. 

5. Esto fuerza que el punto de acceso (AP) retrasmita de nuevo el Mensaje 3 varias veces. 

6. Este proceso repetido varias veces, siempre instalará la misma clave de cifrado y por lo tanto reseteará a cero nonce (número aleatorio el cual precisamente se encarga de evitar que se pueda repetir ataques y que actúa como contador de los paquetes transmitidos, ver figura 4). 

7. El atacante puede en este punto forzar estos reseteos nonce recolectándolos y repitiendo retrasmisiones del Mensaje 3. 

8. Reutilizando estos nonce es posible repetir los paquetes y descifrarlos ya que la misma clave de descifrado se utiliza con valores nonce que ya se han utilizado en el pasado (reutilizando los llamados “keystream” cuando se cifran paquetes). 

9. En función del análisis de los paquetes descifrados, sería posible insertar un programa malicioso en la red o simplemente analizar el tráfico generado por los usuarios de la red.

Ahora mismo no existe ningún parche de seguridad que pueda solucionar este problema (así que atentos para cuando salgan). De momento, el CERT ha enviado un comunicado advirtiendo del problema, así como un listado del hardware y el software afectado (ojo a los fabricantes afectados, CISCO, Google o Apple son sólo algunos de ellos). Prácticamente cualquier dispositivo que tenga WiFi tendrá que ser parcheado, desde dispositivos móviles pasando por routers.

Figura 5: Flujo del proceso "4-way handshake" y en rojo Mensaje 3, donde KRACK efectúa su ataque

¿Y qué podemos hacer para protegernos? De momento esperar a que aparezca algún parche para cada uno de los dispositivos. Cambiar de router o de contraseña de la WiFi no ayudará. La única protección fiable que tenemos es utilizar VPNs dentro de nuestra red o utilizar siempre cifrado SSL/TLS (páginas web HTTPS por ejemplo). Por otro lado, parece que Microsoft se ha dado prisa y ya tiene un parche para solucionar este problema para Windows.

Figura 6: Parche para KRACK Attack de Microsoft

Para terminar, no podemos olvidar que los dispositivos afectados no se limitan a portátiles y ordenadores de empresas o de usuarios particulares. También tenemos que tener en cuenta que otros dispositivos más cotidianos como televisiones, relojes o incluso coches también están afectados por esta vulnerabilidad. Y mucho más preocupante podría ser pensar en ¿cuántos dispositivos IoT utilizan WPA2 dentro de redes WiFi pertenecientes a procesos industriales? Esperemos que todos los fabricantes se den prisa en aplicar los parches correspondientes lo antes posible, porque de momento, el poder parece que lo tienen sólo los chicos buenos …

Autor: Fran Ramírez (@cyberhadesblog) escritor de libro "Microhistorias: anécdotas y curiosidades de la historia de la informática" e investigador en ElevenPaths

Brutal Kangaroo y la infección por USB de equipos aislados

Las técnicas de infección de equipos y distribución de malware usando discos USB no es algo nuevo. Se conocía desde antes, pero saltó a los titulares de todo el mundo con la ciberarma Stuxnet, - atribuido popularmente a la NSA - que, en pocas palabras, fue un malware especialmente creado para distribuirse por medio de discos USB hasta llegar a unos equipos muy concretos de una central de enriquecimiento de uranio en Iran.

Figura 1: Brutal Kangaroo y la infección por USB de equipos aislados

Desde entonces, los exploits y los payloads para, desde un disco USB infectar a un equipo y viceversa, desde un equipo infectar a un USB, han ido apareciendo a lo largo del tiempo. Desde payloads para copiar todos los datos que están en un disco USB conectado y llevarlos a la nube, hasta exploits que ejecutan código arbitrario en el servidor por medio de 0days que se han ido descubriendo.

Figura 2: USB Dumping para OS X

Este es un tema que a mí personalmente me gusta mucho, ya que los discos USB pintan en una organización una Hidden Network que puede ser utilizada para filtrar datos o para infectarte equipos mediante un sistema de polinización. Si tienes el mapa de la Hidden Network creada por discos USB en tu organización, probablemente podrás descubrir qué discos son los responsables de las últimas alertas de seguridad en tus sistemas antimalware o por donde te entró un software malicioso en tu organización.

Figura 3: Bug CVE-2017-8484 en ficheros .LNK

Como he dicho antes, desde Stuxnet todo el mundo puso mucha atención a estas técnicas de infección, y los 0days y payloads se han ido desarrollando a lo largo del tiempo. Sobre todo, porque en los equipos denominados Air-Gapped, es decir, totalmente desconectados de cualquier red, hay siempre dos trabajos a realizar. Primero conseguir llegar a él e infectar el equipo para ejecutar código malicioso y llegar a los datos o el sistema de control que protege ese servidor, y segundo, sacar la información o conectarse remotamente con un panel de control remoto.

Brutal Kangaroo de Vault7

Para el segundo trabajo, los estudios han ido apareciendo en los últimos tiempos, y se han utilizado desde sistemas de Radio Frecuencia, hasta la temperatura de máquinas cercanas, para conseguir esa comunicación entre un malware instalado en un servidor Air-Gapped (asilado) y el panel de control del atacante. Sin embargo, parece una canal muy rápido utilizar también el el propio canal USB, y eso es lo que parece que la CIA estaba utilizando.

Figura 4: Filtraciones de Brutal Kangaroo

La herramienta que ha sido publicada por Wikileaks dentro de las filtraciones de Vault7, lleva por nombre Brutal Kangaroo, y es, como se puede ver, un programa que permite implantar en un servidor aislado un software para infectar cualquier disco USB que se conecte al mismo. Brutal Kangaroo no está pensada para infectar al servidor aislado, sino para estar residente en él e infectar todos los discos USB que se conecten. Por supuesto, se podrían instalar las capacidades de este software malicioso también  por medio de un disco USB.

Figura 5: Brutal Kangaroo Configuration Tool

Una vez que el servidor aislado es infectado - al que denominan en la documentación "Emotional Simian", se utilizan varios 0days para Windows que hoy en día están cerrados por Microsoft en todas sus versiones soportadas (nota a esto, versiones soportadas), para infectar los discos USB. La lista de exploits no es muy larga, pero contaba con el 0day de los ficheros .LNK que Microsoft ha vuelto a revisitar hace dos días o con EzCheese que cuenta con soporte para diferentes versiones. En la imagen se puede ver cómo el creador de la instancia puede elegir su target correctamente.

Figura 6: EZsurvey para configurar payloads de EzCheese

Son más de 150 páginas de documentación, que para los investigadores van a abrir unas cuantas horas de análisis, para entender mejor cómo funcionan las herramientas de ciberespionaje que sacan partido de los 0days y payloads que se van descubriendo.

Saludos Malignos!

¿Has encontrado Oro o Plata? El precio de los 0days en forma de Tabla Periódica

La empresa Zerodium saltó a la fama en Internet por haber ofrecido un precio de 1.000.000 USD por un 0day en Apple iOS que permitiría tomar control remotamente de un terminal iOS. La idea de ese exploit es la posible construcción de un JailbreakMe 4.0 que, como ya hiciera el investigador José Selvi con JailbreakMe 3.0, agencias de inteligencia podrían convertir en un JailOwnMe 4.0 tal y como se explica en el libro de Hacking iOS: iPhone & iPad.

Figura 1: ¿Qué 0day es Oro y cuál es plata?

Por supuesto, ya anunciaron que habían pagado ese Millón de Dólares por un exploit que cumplía las características pero que NO lo iban a publicar. Es parte de su negocio, ya que ellos luego venden este conocimiento a empresas que quieren estar más seguras que el resto. O esa es la idea.

Figura 2: El cartel con la recompensa de 1.000.000 USD inicial

Ahora, ya conocido su negocio por todos, han puesto en Internet una tabla periódica con los precios que van a pagar por exploits en los principales productos. La estrella sigue siendo Apple iOS, con pagos de hasta 500.000 USD por 0days en su plataforma, seguido por Android y Windows Phone que llegan hasta las 100.000 USD. Luego baja ya a los plugins y navegadores con Adobe PDF, Flash Player y Google Chrome llegando a los 80.000 USD. La lista es larga y deja, por ejemplo, los exploits de Windows, Mac OS X y Linux en un precio de 30.000 USD. Puedes buscar tu software favorito en ella.

Figura 3: Lista de precios por exploits y tecnologías

Una cosa interesante es que no se pagan todos los exploits y buscan exploits detallados en cada cuadrito. Por ejemplo, los RCE (Remote Code Executation) son los que se buscan en los plugins y navegadores. En los sistemas operativos de escritorio bastan con un LPE (Local Privilege Escalation) siempre que tenga un SBX (SandBox Escape) asociado, ya que con pedir la ayuda al usuario para que haga un clic en un enlace sería suficiente para conseguir el RCE final.

Figura 4: Zerodium Preguntas Frecuentes

Por supuesto en Apple iOS se busca el RJB (Remote Jailbreak) para poder tomar control total del dispositivo. Es decir, no solo ejecutar código, sino hacer la elevación de privilegios, cargarse el CodeSigning y controlar totalmente el dispositivo.Si queréis más información de qué se paga y qué no se paga, o como reportar un exploit de 0day, lo mejor es que os leáis las FAQs.

Saludos Mglignos!

Bug en OpenSSL: Alternative chains certificate forgery

Llevábamos unos días analizando qué podría ser el nuevo bug que había sido anunciado en el proyecto OpenSSL en un parche nuevo. Después de un año y medio movido, con HeartBleed de por medio, todos estábamos listos para ver qué podría ser este fallo. En Eleven Paths habíamos incluso organizado una vigilancia especial por si en había que sacar una Prueba de Concepto rápido para nuestros sistema de pentesting persistente. Pero al final, aunque es de riesgo muy alto, no será tan crítico como lo fue Heartbleed que permitía robar datos masivamente.

Figura 1: Alternative Chains Certificate Forgery en OpenSSL

El fallo que se ha anunciado en OpenSSL se ha bautizado como Alternative Chains Certificate Forgery y se le ha asignado el CVE-2015-1793. El problema se encuentra en la forma en la que algunas versiones de OpenSSL verifican la cadena de confianza de un certificado digital. Es decir, salvo que se haga una implementación de un proceso de Certificate Pinning, un certificado digital se da por bueno si está firmado por una cadena de certificados que lleva a una raíz de confianza.

Verificación de la cadena de confianza

En un certificado A, si esté está firmado por un certificado B, emitido por una entidad certificadora de primer nivel C de la que se confía, entonces se dará por correcto y no se lanzará ninguna alerta de seguridad. Esta validación de certificados se produce tanto cuando un navegador cliente tiene que verificar el certificado de un servidor web, como cuando un servidor tiene que verificar el certificado de un cliente en un proceso de autenticación de usuarios basado en certificados digitales.

Figura 2: Bug de Alternative Chains Certificate Forgery en OpenSSL

Sin embargo, el bug de Alternative Chains Certificate Forgery permite que, en determinadas condiciones y en 4 versiones en concreto de OpenSSL, se pueda hacer que esa verificación de cadena de confianza hasta un certificado raíz se de por buena aún no siendo correcta del todo la cadena de certificación.

Entornos de explotación

En otras palabras, alguien podría usurpar la identidad de un servidor si el cliente utiliza el software de OpenSSL en el cliente (no lo usan Apple Safari, Internet Explorer, Chrome o Firefox, pero sí muchas aplicaciones móviles o de escritorio clientes) que combinado con un ataque de phishing o pharming ayudarán a robar datos de cliente, o lo que es más peligroso aún, alguien podría suplantar el certificado de un cliente en un entorno de autenticación de usuarios basado en certificados digitales como si se pudiesen crear todas las credenciales a gusto -

Figura 3: Configuración de autenticación de cliente SSL en servidor NGINX con OpenSSL

Este último escenario es el realmente peligroso, ya que se podría conseguir acceder a sistemas informáticos creando los certificados adecuados de los usuarios que tienen acceso a la plataforma. Por esto, es necesario que se actualice cuanto antes el software si estás haciendo uso de este tipo de autenticación en tus plataformas.

Saludos Malignos!

WordPress: 0day XSS almacenado en plugin WP-UserAgent

Hace ya un tiempo me acuerdo de haber leído un post en el blog de Chema Alonso sobre cómo explotar vulnerabilidades XSS (Cross-Site Scripting) utilizando el User Agent en sitios que permiten mostrar esta información en una página web. Desde ese instante me pareció bastante interesante óomo algunos sitios webs utilizaban la información provista en las cabeceras de las peticiones para personalizar el contenido dependiendo del tipo de navegador que utilicemos. Tomando en consideración este escenario se me ocurrió la idea de ver si este tipo de ataque se podía replicar en otras plataformas, no siendo muy complejo lograr encontrar casos similares.

Figura 1: Bug 0day de XSS en  el plugin WP-UserAgent de WordPress

Lo primero que se me ocurrió fue buscar algún plugin que realizara esta tarea, llegando a WP-UserAgent. Este plugin de WordPress permite insertar un icono en cada comentario puesto por un usuario, en el que se indican además el sistema operativo y la versión navegador - entre otros parámetros - que utiliza dicho usuario.

Figura 2: Plugin WP-UserAgent

WP-useragent con más de 600 instalaciones activas.

Una vez descargado el código fuente comencé a revisar el código para ver cómo extraía la información desde el campo de User Agent y estudiar cómo la procesaba, encontrado algo bastante interesante. El siguiente fragmento de código muestra cómo se buscan cadenas dentro del valor de User Agent.

elseif(preg_match('/Xandros/i', $useragent))
{
  $link="http://www.xandros.com/";
  $title="Xandros";
  $code="xandros";

  if(preg_match('/x86_64/i', $useragent))
  {
    $title.=" x64";
    }
  }

Figura 3: Ejemplo tipo de identificación useragent

En general el funcionamiento es bastante simple, se detecta una cadena específica y se asignan textos ya preestablecidos, así no se utiliza directamente la información del valor de User Agent salvo por un caso particular para los dispositivos Mac OS X.

elseif(preg_match('/Mac/i', $useragent) || preg_match('/Darwin/i', $useragent))
{
  $link="http://www.apple.com/macosx/";

  if(preg_match('/Mac OS X/i', $useragent))
  {
    $title=substr($useragent, strpos(strtolower($useragent), strtolower("Mac OS X")));
    $title=substr($title, 0, strpos($title, ")"));

    if(strpos($title, ";"))
    {
      $title=substr($title, 0, strpos($title, ";"));
      }

    $title=str_replace("_", ".", $title);
    $code="mac-3";
    }
  elseif(preg_match('/Mac OSX/i', $useragent))
  {
    $title=substr($useragent, strpos(strtolower($useragent), strtolower("Mac OS X")));
    $title=substr($title, 0, strpos($title, ")"));

    if(strpos($title, ";"))
    {
      $title=substr($title, 0, strpos($title, ";"));
      }

    $title=str_replace("_", ".", $title);
    $code="mac-2";
    }
  }

Figura 4: Código fuente de WP-useragent para identificar la versión exacta de OS X

En el caso de los dispositivos Mac OS X el proceso de identificación es distinto. En primer lugar si el User Agent contiene la cadena "Mac" o "Darwin" entra en la sección vulnerable. Luego se revisa si en $useragent posee la cadena "Mac OS X" o "Mac OSX", en ambos casos se ejecuta la misma porción de código duplicado. Se limpia el inicio del valor de useragent hasta la ocurrencia de la cadena "Mac OS X" (en el caso de "Mac OSX" no funciona). Luego limpia la parte final de useragent, sin embargo se utiliza como identificador el carácter ")", eso significa que todo código que este antes de este carácter no será filtrado. Ya en última parte se intenta acortar el string title utilizando como identificador el carácter ";" y reemplazar todos los guiones bajos por puntos.

Explotación del bug de XSS en WP-UserAgent

Este escenario nos permite desarrollar con cualquier plugin para cambiar queuseragent custom como por ejemplo el siguiente:

Mozilla/4.0 (Macintosh; U; PPC Mac OS X <img http:="" onerror="javascript:document.location.href=" site.com="" src="1" /&gt 10_5_8;
zh-cn) AppleWebKit/533.20.25 (KHTML, like Gecko) Version/5.0.4
Safari/533.20.27

El cual se salta las restricciones y filtros generando un Stored-XSS que se ejecuta cada vez que visualiza el comentario asociado que se generó con el plugin WP-UserAgent activo. Acá una pequeña PoC sobre este ejemplo:


Figura 5: Prueba de Concepto de Stored-XSS en plugin WP-UserAgent de WordPress
Consideraciones finales sobre la explotación del XSS almacenado

• El código a inyectar no debe utilizar el string ")".
• El código a inyectar no debe utilizar el string ";".
• El código a inyectar cambiará todos los "_" por ".".
• La versión 1.0.5 del plugin (única) es vulnerable.

Una vez encontrada la vulnerabilidad notifiqué al desarrollador y a la gente de WordPress de forma inmediata, sin embargo no obtuve respuesta hasta esta semana, donde me contactó la gente de WordPress indicando que por el gran volumen de correos que les llega normalmente no habían podido responder antes.

Figura 6: WP-UserAgent ha sido deshabilitado en WordPress.org

Como acciones a tomar han notificado al desarrollador sobre la vulnerabilidad  - ojalá les responda a ellos al menos - y momentáneamente lo han dado de baja de la lista de plugins de WordPress. Si lo tienes configurado en tu servidor WordPress, anúlalo temporalmente.

Autor: Marcelo Clavel G.
Ing. Civil Informático de Chile

Google Project Zero te lo quiere poner MUY difícil para encontrar 0days

Entre las conferencias de la pasada CanSecWest Vancouver 2015, tuvo lugar una realizada por el equipo de Google Project Zero. Como muchos sabéis, este proyecto de Google ha protagonizado algunas polémicas en los últimos tiempos debido a la publicación de bugs y 0days en sistemas Apple y Microsoft. Esta polémica ha sido especialmente dura cuando la publicación de los bugs en otros fabricantes coincidió con la aparición de 0days en su propio sistema Android, lo que para muchos es un contrasentido. No obstante, para explicar su trabajo, en la CanSecWest 2015 han dado una charla y aquí está su presentación con todos los detalles de su ideario.

Figura 1: Google Project Zero te lo quiere poner MUY difícil para encontrar 0days

Según ellos definen su proyecto, el objetivo es "Make 0day Hard", o lo que es lo mismo, hacer que en el futuro encontrar 0days tipo HeartBleed, ShellShock, Rosetta o el famoso Rootpipe que Apple se ha olvidado de parchear en OS X Mavericks y OS X Mountain Lion, no sea fácil para nadie en el pasado. Para lograrlo, su idea es buscar buscar ellos todos los 0days que sea posible encontrar de esas características, hacer los exploits para ver la criticidad real y forzar su corrección con un proceso basado en hacer públicos los datos a los 90 días exactos de haber sido notificados los fallos a los desarrolladores - o fabricantes - del software.

Figura 2: Un 0Day de Apple que fue a Public Disclosure antes del parche

Su idea de ir a Full Disclosure a los 90 días según su presentación se basa en la conocida existencia del mercado negro de venta de exploits y 0days que hay en Internet y que el único objetivo de este mercado es de realizar acciones ofensivas, por lo que para acabar con él hay que tomar acciones pro-activas en la localización y erradicación de todos los 0days que pudieran tener ya, y así forzar su corrección. Para ello, se toman 90 días de "Responsible Disclosure", para que el fabricante tenga tiempo de corregir los bugs antes de ir a Public Dicsclosure.  Ese periodo lo han elegido porque en la industria es más o menos un tiempo razonable en la mayoría de los casos.

Según sus estadísticas, en los más de 150 0days que han publicado en este periodo, solo en el 15.2 % de los casos el desarrollador o fabricante NO llegó a tiempo de proporcionar un parche a tiempo, mientras que en la gran mayoría de los casos el tiempo fue más que suficiente, con lo que se consiguió erradicar un fallo de seguridad que pudiera estar vendiéndose en el mercado negro en esos 90 días.

Figura 3: Estadísticas de bugs que fueron parcheados antes de ir a Public Disclosure

La estrategia técnica para hacer que encontrar 0days sea mucho más difícil se basa en localizarlos ellos mismos aplicando todas las técnicas posibles para "recoger la fruta madura" en primera instancia. Esto es, localizar todos los fallos tontos que se pueden encontrar aplicando técnicas automatizadas y fuzzing sencillo. Muchos proyectos muy populares adolecen de no contar con un proceso de auditoría basada en técnicas de búsqueda de bugs automatizadas, y permiten estrategias sencillas como OSB-Rastreator para localizar bugs evidentes o como el trabajo de Breaking AV que hizo Joxean Koret y que le llevó a localizar una gran cantidad de fallos en software de antivirus gracias a sus herramientas de fuzzing.

Figura 4: Estadísticas del feedback recibido

Por supuesto, su objetivo no solo es acabar con esos bugs sencillos, sino subir el nivel de seguridad haciendo búsqueda progresiva de bugs de seguridad en piezas clave del software pare conseguir aplicar soluciones de defensa en profundidad a los programas que dan soporte a los principales sistemas. Todo este trabajo, con toda la controversia que se generó, ha tenido opiniones a favor y encontradas y han sacado unos resultados de cómo perciben que ha sido el feedback recibido. Curioso. A mí, personalmente, me gusta el proyecto y la iniciativa.

Saludos Malignos!

JavaRuleSetter: Un "firewall" para los Applets de Java

Si llevas algo de tiempo en seguridad, con certeza habrás visto cómo el mundo de los Exploits Kits o el malware han utilizado bugs de Java para conseguir la ejecución de código remotamente. Muchos de esos exploits están en los arsenales de los Metasploit de los pentesters para que estos puedan conseguir acceso a los equipos que no han tomado la precaución de mantener actualizado el framework de Java. Aún así, el riesgo de que aparezca un 0day y te afecte es muy alto, y por eso Java ha intentado poner medidas paliativas para que un administrador gestione listas blancas de sitios a los que va a permitir que ejecuten Applets de Java o no.

Figura 1: JavaRuleSetter, un "firewall" para los Applets de Java

Las medidas que actualmente se pueden aplicar para crear listas de seguridad son dos, tal y como se explica en el blog de Eleven Paths y vamos a ver cómo funcionan y cómo se pueden configurar cómodamente con JavaRuleSetter.

Deployment Rule Set y Exception Site List 

Para que nos hagamos una idea, la primera de ellas es una forma de conseguir que un Applet se ejecute automáticamente sin generar ninguna alerta por medio de la firma digital del mismo. No son sencillas de configurar ya que hay que generar un fichero XML con un formato concreto, hay que firmarlo digitalmente y ubicar los ficheros en determinadas ubicaciones, pero permiten que se hagan despliegues de aplicaciones a través de Internet por medio de Applets en modo lista blanca. Esta configuración requiere permisos de administrador en la máquina y está disponible a partir de Java 7u51.

Figura 2: Configuración de nivel de seguridad en Java y Exception Site List

La segunda de las configuraciones de seguridad es la Exception Site List, que permite indicar un conjunto de sitios de lista blanca a los que se les permitirá rebajar el nivel de seguridad. El número de alertas y las restricciones que tendrán esos Applets dependerán del nivel de seguridad que se haya elegido en la configuración de Java en el sistema. Estas configuraciones se pueden hacer a nivel de usuario y están disponibles a partir de la versión de Java en Enero de 2014. Su funcionamiento es muy similar al bloqueo de ActiveX que introdujo Internet Explorer 8 hace tiempo.

Figura 3: Árbol de decisión en la ejecución de Applets dependiendo de la configuración de seguridad

Al final, el árbol de decisión sobre la ejecución de un Applet Java hoy en día es bastante complejo, y dependiendo de la configuración del nivel de seguridad de Java, la lista de sitios de excepción y las Deployment Rule Set que se hayan configurado, el resultado a la hora de proteger el sistema contra la explotación de un ataque proveniente de un Applet malicioso puede ser muy distinto.

JavaRuleSetter

Para hacer esto mucho más sencillo, desde el laboratorio de Eleven Paths hemos publicado una herramienta llamada JavaRuleSetter que permite gestionar las listas blancas como si de un firewall se tratara. Para ello, la herramienta configura una regla por defecto en la que se activa el nivel alto o muy alto de seguridad en Java y cualquier Applet que venga a ejecutarse debe cumplir los requisitos de esos niveles o estar en la lista blanca.

Figura 4: Configuración de bloqueo de Applets en JavaRuleSetter

En este ejemplo, con la regla por defecto que activa el máximo nivel de seguridad, cualquier intento de ejecución de un Applet será bloqueado, tal y como se aprecia en la imagen siguiente donde se intenta ejecutar un Applet proveniente de Java.com.

Figura 5: Mensaje de alerta de bloqueo de ejecución de un Applet de java.com

Para conseguir que se pueda ejecutar, basta con meter una regla con la excepción para ese sitio, tal y como se ven en la imagen siguiente.

Figura 6: Adición de una regla de excepción para ejecución del Applet desde Java.com

A partir de este momento, con esta herramienta, cualquier administrador que requiera utilizar Java en su día a día, puede reducir cualquier riesgo de ataque añadiendo únicamente el permiso de ejecución de Applets Java en las URLs de los sitios con los que deban trabajar sus empleados. Por supuesto, si se quiere configurar una regla de despliegue para que no salga absolutamente ninguna alerta, se puede crear una regla en Advanced Mode para ajustar la granularidad que se quiera.

Figura 7: Configuración de una regla de despliegue en modo avanzado

La herramienta está escrita en Java - faltaría más - y por tanto es totalmente funcional en plataformas OS X y GNU/Linux, con las que el equipo de QA de Eleven Paths ha hecho las pruebas pertinentes. Esperamos que os sea de utilidad y consigáis fortificar un poco más vuestros equipos de trabajo.

Saludos Malignos!

WordPress: SQL Injection Bug en Scarcity Builder Plugin

Hacer unas semanas, un joven investigador de seguridad venezolano llamado KelvinSecurity se puso en contacto conmigo para contarme que se había topado con un bug de SQL Injection en un plugin para WordPress llamado Scarcity Builder, que se utiliza para generar contadores de marketing en sitios web creados sobre WordPress con el objetivo de que generen presión en los visitantes para forzar una acción. Cosas de la gente de marketing, ya sabéis.

Figura 1: Bug de SQL Injection en Scarcity Builder para WordPress

El caso es que el bug era un 0day porque incluso la web del propio fabricante era vulnerable a este fallo, así que decidimos ponernos en contacto con los desarrolladores y se abrió un ticket de soporte. La empresa que está detrás de él, llamada Digital KickStart, solucionó el fallo y respondió con una nueva actualización del mismo, tal y como podéis ver en la siguiente imagen.

Figura 2: Confirmación de que han solucionado el bug en la versión 2.2.10

Sin embargo, el bug, que es un SQL Injection de libro y que se encuentra fácilmente usando Havij o cualquier otro escanner de vulnerabilidades web, está aún por desgracia en muchas páginas web con WordPress, ya que la empresa no ha hecho un Security Advisory o similar.

Figura 3: Explotación del bug en un WordPress vulnerable con Havij

El SQL Injection se encuentra en concreto en: 

wp-content/plugins/scarcitybuilder/shortcode/index.php?edit=

Por supuesto, con un SQL Injection como esté, se puede extraer toda la información de WordPress, incluidos, usuarios, contraseñas e información confidencial que se encuentre guardada en la base de datos o accesible desde ella en el servidor.

Figura 4: Extracción de información con el bug en el plugin Scarcity Builder

El plugin no es demasiado común - seguramente porque es un plugin de pago - y solo aparecen algo más de 800 sitios indexados en Google que lo tengan funcionando, pero el bug es tan fácil de localizar y explotar de forma automatizada que espero que hagan un aviso directo a los clientes haciéndoles entender el riesgo de no actualizar a esta versión.

Figura 5: Número de WordPress con este plugin instalado, localizados vía Google

Si tienes WordPress con este plugin, actualízalo ya. Si tienes clientes con WordPress, avísales de este riesgo de seguridad para que tomen medidas urgentes y, a ser posible, que tengan procedimientos y herramientas para actualizar automáticamente los plugins. No olvides que tienes herramientas como WPHardening para fortificar WordPress, y que tú además puedes puedes fortificar WordPress con configuraciones más seguras.

Saludos Malignos!