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.
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.
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.
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ó.
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.
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.
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.
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.
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:
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
 |
| 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.
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.
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.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.
• Patriones SQLi.
• Patrones LFI y RFI.
• Patrones de ejecución de código.
 |
| 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.
No hay comentarios:
Publicar un comentario