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.

¿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!

Robando 0days a los programadores de Mozilla Foundation

Una de las cosas que la comunidad de investigadores de seguridad empezó a utilizar hace tiempo fue la búsqueda de bugs de seguridad corregidos en proyectos Open Source que pudieran terminar en 0days con un tiempo de vida limitado, pero útil. Básicamente, la idea consiste en ver qué bugs se están arreglando en el código fuente de un producto Open Source en tiempo real. Si esos bugs son de seguridad, entonces se pude hacer un exploit que tome ventaja de ellos antes de que el usuario tenga esa actualización instalada.

Figura 1: Robando 0days en Bugzilla

Hay que tener en cuenta que, desde que un bug de seguridad es arreglado, es necesario hacer las compilaciones, pasar los test de QA, pasar a distribuciones y al proceso planificado de actualizaciones. Por el contrario, para un exploiter basta con que le señalen donde está el bug y construya el exploit. 

El robo de bugs de Bugzilla

Es por eso que, los proyectos importantes mantienen ciertos bugs de seguridad que gestionan vía Bugzilla - generalmente reportados por canales de Responsible Disclosure - están totalmente cerrados, y solo un círculo de desarrolladores de confianza que han adquirido un determinado nivel en la escala de meritocracia, pueden acceder a ellos.

Figura 2: Nota de Bugzilla sobre el robo de la cuenta

En el caso de Mozilla Foundation, han reconocido que les robaron una cuenta a uno de esos desarrolladores que tienen acceso a los bugs de seguridad privados. El robo de la identidad, según explican, parece provenir de:

1) Una reutilización de la contraseña en otro foro que fue vulnerado.
2) Ausencia de un sistema de Segundo Factor de Autenticación que hubiera prevenido de que pudiera utilizarse la password.

Al final, se han dado cuenta del uso fraudulento de esa identidad, y han echado los cálculos de los bugs que ha podido robar - para vender por canales alternativos o para utilizarlos - y cuáles han sido las ventanas de tiempo de las que ha podido disponer desde que se supo la primera información del bug y estuvo en manos de los usuarios solucionado el bug.

Figura 3: Análisis de bugs a los que tuvo acceso y las ventanas de tiempo

Como se puede ver, uno en concreto le ha dado una ventana de tiempo de casi un año de ventana de tiempo, lo que es un gran resultado para un exploit. Si estás haciendo software, las credenciales de tus desarrolladores deben estar protegidas. Nosotros usamos Redmine para el seguimiento de bugs y los proyectos, y por eso desarrollamos un plugin de Latch para Redmine - que puedes poner en tu propia instalación - para controlar el acceso a esa información.

Saludos Malignos!

HackerOne: Un "Broker" para reportar bugs y ganar dinero con Bug Bounties

Hoy os quiero hablar HackerOne, una plataforma que facilita la comunicación entre el equipo de seguridad de una empresa con profesionales o con principiantes en la seguridad informática también llamados hackers. Gracias a HackerOne se han corregido miles de fallos y actualmente se ha pagado 2.49 Millones de Dólares o 2.30 Millones de Euros.

Figura 1: HackerOne: Un "Broker" para reportar bugs y ganar dinero con bug bounties

Entre las empresas que podemos encontrar hay algunas muy famosas como Twitter, Yahoo!, Dropbox y la propia HackerOne inclusive. Además, hay un programa financiado por organizaciones preocupadas por la seguridad de los demás llamado Internet Bug Bounty, que básicamente está enfocado al reporte de bugs que afectan a todo Internet, como los casos de Heartbleed o ShellShock.

Funcionamiento de HackerOne

Del dinero que se paga por los bugs descubiertos un 20% se lo lleva HackerOne, como broker de reporte. A cambio de ese 20% HackerOne se hace responsable de que al hacker le llegue todo el dinero, evitando los formularios de impuestos y demás quebraderos de cabeza. Por lo que tu equipo no tiene que preocuparse en que los hackers sean pagados y puede centrarse en trabajar. A día de hoy estas son las estadísticas de la web:

Figura 2: Estadísticas de HackerOne

Supongo que estaréis pensando, ¿solo hay 83 empresas registradas? En realidad no, además de programas públicos en los que cualquiera puede participar también hay programas en los que solo se puede acceder por invitación, ya sea porque  quieren tener controlados el número de usuarios, estén probando HackerOne o simplemente no quieran aparecer en la lista de programas.

Muchas de las empresas dan recompensas que van desde los 10 a 20.000 dólares y ese dinero lo puedes pasar a una cuenta de Paypal, un monedero de BitCoins o donarlo a una organización de caridad. La edad mínima para cobrar un premio es de solo 13 años.

Figura 3: Interface de reporte de bugs

Os dejo una captura de pantalla en la que se muestra un reporte realizado a HackerOne por un usuario. Como podéis observar la interfaz es simple. Si ponemos el cursor encima de un nombre de usuario veremos información básica sobre el: el número de bugs encontrados - sólo los aceptados -, las veces que le han dado las gracias y la reputación que tiene.

Gestión de la reputación en HackerOne

La reputación es calculada en base al número de reportes aceptados, los no aceptados por duplicados o porque el bug no existe.

Ganas reputación si:

● Tu reporte es cerrado como “Resuelto”: +7 (Si te han premiado aumenta)
● Tu reporte es cerrado como “Duplicado ( Resuelto) “ Solo se aplica si se envio antes de que el otro reporte fuera solucionado.
● Tu reporte es cerrado como “No se va a resolver” +1
● Tu reporte es cerrado como “Duplicado (No se va a resolver) “ +1

Pierdes reputación si:

● Tu reporte es cerrado como “No aplicable” ­5
● Tu reporte es cerrado como “Duplicado (No aplicable)” ­5
● Tu reporte es cerrado como “Necesita más información” ­1

Si tienes mucha reputación obtendrás algunos privilegios como poder ser invitado a programas antes de que estén disponibles al público por otro lado, si tu reputación baja se limitará el número de reportes que podrás enviar en un periodo de tiempo.

Ventajas de utilizar HackerOne como plataforma de reporte de bugs

Para mi las ventajas de usar HackerOne son estas:

● Evita el papeleo a los equipos de seguridad
● Permite que cualquier persona reporté siendo reconocido por su trabajo y premiado por ello.
● Fomenta la búsqueda de fallos que puedan afectar a todo Internet
● Servicio gratuito que asegura la seguridad de los reportes y anonimato de los usuarios.

Mi conclusión personal es que HackerOne es una herramienta que fomenta la búsqueda de fallos gracias a que cualquier persona interesada puede participar y ser reconocida por su trabajo. Es gracias a esa motivación que las empresas registradas se vuelven más seguras haciendo que Internet sea un lugar más seguro.

Autor: Daniel Sesé

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!

¿Es Google Project Zero (i)rresponsable publicando 0days y exploits de Windows y OS X?

El año pasado, concretamente durante el mes de Julio, se anunció el nacimiento de Google Project Zero, una iniciativa de seguridad de Google para auditar en busca de vulnerabilidades en aplicaciones de otros fabricantes, incluyendo en esta lista software libre y software de código cerrado. El año pasado fue especialmente vertiginoso en términos de seguridad informática, todavía convulso por las revelaciones de todos los hackeos provenientes de la NSA, la aparición de fallos como Heartbleed, ShellShock, Poodle o el resto de bugs en software criptográfico, hicieron que las inversiones en seguridad empezaran a crecer.

Google montó su equipo en busca de fallos en el software que ellos utilizan que, dicho sea de paso, pensando en una compañía del tamaño de Google es algo así como decir casi todo el software importante del planeta. En sus filas hay hackers de gran nivel y reconocimiento internacional, con varios Pwnie Awards entre ellos, e incluso GeoHot ha pasado a formar parte de este equipo que se dedica a buscar vulnerabilidades.

Figura 1: Es Google Project Zero (i)rresponsable publicando 0days y exploits?

La polémica viene con este grupo ha venido por otro lado, no con la búsqueda de los bugs, sino con la "medida de responsabilidad" que han añadido a la publicación de sus descubrimientos, en 0days de Windows y de OS X recientemente.

Un resumen de la publicación de bugs

Recordemos que hace años atrás, los hackers eran acusados con el dedo por la publicación de sus descubrimientos en Full Disclosure, es decir, se encuentra un fallo de seguridad y se publica. Los fabricantes de software se quejaban de que no estaban ayudando a la seguridad de sus clientes con esta forma de publicar, sino que los estaban poniendo en riego porque cualquier atacante podría con ese conocimiento publicado hacer daño a sus usuarios.

La posición de los investigadores era que los que estaban poniendo en riesgo a sus clientes eran ellos no auditando correctamente el software, además de que no tenían ninguna garantía de que antes de que se hiciera público este fallo no estuviera siendo utilizado por ningún malo de verdad. Ahora que se conoce el fallo, todo el mundo deberá trabajar en pro de solucionarlo. El gran investigador argentino Juliano Rizzo, en la presentación que hizo en Ekoparty del bug BEAST en SSL lo explicó con una de las frases que quedará para la historia:

Figura 2: Juliano Rizzo sobre la publicación del bug BEAST en SSL

En aquel entonces el mundo de Internet estaba preocupado por las consecuencias en el e-commerce que pudiera tener la publicación de un bug en la capa de cifrado, y lo que consiguieron los investigadores publicando el bug es que todo el mundo se preocupara por el fallo y lo subsanara.

Los fabricantes de software siempre reclaman el Responsible Disclosure, es decir, que los investigadores les comuniquen a ellos el fallo y les dejen tiempo para arreglarlo antes de hacerlo público. Esto tiene dos preguntas a responder por parte de los fabricantes de software:

1) ¿Por que una investigación que ha llevado tiempo y dinero te la voy a tener que dar a ti y no a otros?

Los hackers comenzaron una campaña llamada "No more free bugs" en la que exigían que se reconociera su esfuerzo de investigación y el valor que tenía para todos el descubrimiento de los bugs. En Internet había empresas de todo tipo de reputaciones dispuestas a pagar a los investigadores por ese conocimiento, así que los grandes software vendors deberían ponerse las pilas. 

Figura 3: Alex Sotirov y Dino Dai Zovi apoyando al campaña No More Free Bugs

Esto llevó a la aparición de brokers (empresas que compran bugs y luego negocian su venta con los fabricantes de software) y a las famosas Bug Bountys que algunas empresas pagan por los bugs reportados, como hace Google, Facebook y en algunos productos puntuales Microsoft. Por supuesto, para sacar una Bug Bounty, primero las empresas deberían auditar mucho más el software de su compañía con equipos de auditoría mucho más formados lo que llevó a que las grandes empresas se "pelearan" por conseguir tener en sus filas a los mejores hackers del panorama internacional trabajando para ellos.

2) ¿Cuál es exactamente la medida de responsabilidad?

Cuando un investigador encuentra un bug se hace un time-stamp. Ese día el hacker toma constancia de que hay un bug en un producto que pone en riesgo muchas cosas. Tal vez incluso cosas críticas que afectan a nuestra seguridad como ciudadanos si hablamos de un bug en un software que se usa en instalaciones críticas. Ese día, por desgracia, no es el tiempo que tiene ese bug. Ese bug es mucho más viejo y existe desde el día que alguien lo introdujo por error o conscientemente. Ese sería el tiempo de verdad que tiene el bug.

Entre el tiempo que va desde que el bug se introdujo hasta el tiempo en el que el hacker lo descubrió hay por medio a veces mucho tiempo, lo que aumenta las posibilidades de que otro hacker lo haya encontrado antes y lo haya usado para vendérselo a los malos o para explotarlo en su provecho.

Figura 4: Tiempos, riesgo y responsabilidades

En el momento en que el hacker lo comunica al fabricante de software empieza a correr otro cronómetro hasta que se arregla, lo que obligará al fabricante a meter personas y trabajo en pro de solucionar este fallo. A veces esto puede costar mucho, por lo que los fabricantes prefieren acumular"varios parches en cada actualización para ahorrar esfuerzos y dinero.

Sin embargo, mientras sucede este parcheo masivo del fallo, el tiempo sigue creciendo. Crece el tiempo desde que se introdujo, crece el tiempo desde que el hacker lo descubrió y crece el tiempo desde que el fabricante es consciente de él. Pero lo más importante, también puede crecer el tiempo en el que otro lo esté utilizando - por ejemplo una agencia de inteligencia internacional o un grupo de cibermalos que lo quiere usar para cibermalas cosas -. Y esto debe tener un límite.

La medida de responsabilidad para Google Zero Project

¿Cuándo debe parchearse algo? La respuesta es cuanto antes, y es el fabricante del software el que lo debe hacer. ¿Cuál es el límite de tiempo que el investigador debe darle al fabricante antes de decir basta? Pues el equipo de Google Project Zero ha determinado que 90 días.

A partir de ese momento, para forzar a la actualización se hace público, aumentando masivamente el riesgo de los clientes, pero al mismo tiempo dándoles la oportunidad de poner workarounds, es decir, medidas de mitigación del bug en WAF, Firewalls, configuraciones de software, políticas de seguridad e el Active Directory o directamente deshabilitando componentes en piezas del sistema como los navegadores. Es decir, transfiere a los clientes la responsabilidad, y al mismo tiempo la oportunidad, de hacer algo para protegerse contra un fallo que puede que esté siendo explotado actualmente.

Figura 5: Exploit publicado por Google Project Zero para atacar OS X

¿Es necesario que publique también exploits? ¿Es 90 días el tiempo adecuado para publicar? Cada cuál tendrá sus opiniones. ¿Cuál es la tuya?

Saludos Malignos!

GM01: Cámara de seguridad que te pone en alto riesgo

La historia que vengo a contaros en este artículo tiene que ver con una cámara de seguridad, que lejos de ayudarte a estar más seguro, pone en alto riesgo tu privacidad. Esto, por desgracia, ya no es algo nuevo en este mundo y debemos casi a esta acostumbrados a que esto suceda, ya que hemos visto muchas veces en el pasado cómo cámaras de seguridad permitían acceder a tu intimidad o cómo un mal diseño de seguridad permitía que cualquiera accediera a la contraseña de la cámara de seguridad, tal y como se pudo ver en el 0day que llevaba el libro de Hacker Épico. 

Figura 1: Cámara de seguridad GM01

En esta ocasión es GM01, una cámara de seguridad que se define a sí misma como una "Easy Cam", lo que no parece nada halagüeño cuando de seguridad estamos hablando. Esta es la historia de su seguridad y cómo aún es posible tener problemas con ellas, pese a haber intentado contactar varias veces con ellos.

GM01: Introducción al funcionamiento

Esta cámara de seguridad es una cámara inalámbrica que funciona con una SIM con la que se conecta con el panel de control. El uso de conexiones móviles en las cámaras de seguridad no es algo tan raro, sobre todo debido a que los ladrones solían cortar cables de teléfono o electricidad para cortar cualquier comunicación con el exterior. Esta cámara viene provista con un SIM y una conexión directa al panel de control en la nube para su gestión.

Además, cada vez que detecta movimiento, toma una fotografía de forma silenciosa y la sube a la nube, a un panel de control en el que el dueño de la cámara puede revisar qué ha sido lo que ha provocado la alerta de seguridad.

Figura 2: Configuración de credenciales y panel de control en la tarjeta de memoria de la cámara

La configuración de la conexión, que viene por defecto sin que mucha gente lo sepan, está un tarjeta de memoria introducida en la cámara de seguridad que, si sacas y montas, podrás ver que hay un fichero que contiene la ruta de conexión al panel de control en aneasycam.com, el número de teléfono y la contraseña por defecto, que como se puede ver es 123456.

Figura 3: El panel de control de la cámara CM01

En esta primera inspección ya se puede ver que seguramente muchos usuarios tendrán la misma contraseña, lo que simplificaría para cualquier atacante el acceso a cámaras de seguridad en las casas particulares de las personas solamente habiendo hecho uso de esta contraseña. Hay que recordar que, por desgracia, la mayoría de las cámaras de seguridad acaban con contraseñas por defecto, incluso en los lugares más insospechados.

Acceso al panel de control como Administrador

Los bugs de este sistema son enormes, pero para empezar veremos lo sencillo que es para cualquier usuario del sistema convertirse en administrador de cualquier cámara de seguridad - incluida la mía -. Para ello basta con entrar una vez con el IMEI de mi Cámara de Seguridad GM01 y la contraseña por defecto. Esto nos lleva a un panel de administración donde el usuario puede ver la configuración de la cámara, cambiar la password, ver las fotos que ha tomado.

Figura 4: Acceso de cualquier usuario a la gestión de su cámara de seguridad

Lo más importante en este caso es que se puede ver que hay un directorio, y ese directorio tiene un Directory Listing como un pino, así que basta con pedir la carpeta sin el archivo aspx y ver qué otros archivos hay en esa ubicación.

Figura 5: El listado de los ficheros de ese directorio

Como se puede ver están todos los ficheros que dan soporte a este panel de control. Entre otros, uno que se llama SuperAdmin.apsx y que si se hace clic en el se abre sin realizar ninguna validación de usuario. 

Figura 6: Acceso al panel de SuperAdmin sin validación alguna

A partir de ese momento se tiene la posibilidad de acceder a todos los IMEI de todas las cámaras de seguridad. Esto permitiría - si el usuario no ha cambiado la password por defecto - acceder a sus fotos y su configuración. En el peor de los casos, se puede cambiar la contraseña y resetear el dispositivo, además de forzar la toma de fotografías en cualquier momento.

Un bug de IIS ShortName como añadido

No hubiera sido necesario tener este Directoy Listing de libro para poder acceder a estos ficheros, ya que además de este, tiene un bug de IIS ShortName Listing que también permite acceder al listado de los ficheros.

Figura 7: Existe un fichero que empieza por s. True

Así que, cualquiera que use FOCA contra este servidor podrá detectar la vulnerabilidad y usando los plugins de IIS Short Name acceder a un listado más o menos completo de todos los ficheros.

Figura 8: No existe ningún fichero que empiece por x. False.

Vamos, que no es complejo para nadie descubrir este panel de Super Admin que no pide ni una contraseña y que lo que deben hacer es validar a los usuarios, y a ser posible con un segundo factor de autenticación como mandan los cánones.

Acceso a todas las fotos de todos los usuarios

Lo peor de todo está aún por llegar, ya que, como se ha dicho al principio, en el panel de control del usuario, cualquiera puede ver sus fotografías de alarmas. También puede ampliarlas y verlas en una pestaña aparte.

Figura 9: Fotos de alarma

Cuando se abren en una pestaña aparte se puede ver que las imágenes se cuelgan en otro servidor web, organizadas por directorios en los que el nombre del directorio es el IMEI de la cámara de seguridad. El nombre de la foto es un time-stamp de cuándo se hizo.

Figura 10: Ruta pública a la fotografía fuera del panel

Como era de esperar, tiene también un Directory Listing - y también un bug de IIS Short Name - que permite acceder a todas las fotografías de todas las cámaras de seguridad de todos los usuarios. Algo muy poco deseable para la privacidad de nadie.

Figura 11: Fotografías de todas las cámaras de seguridad que han vendido por el mundo

Y no hay ninguna protección. Desde que descubrí este bug y me puse en contacto con ellos, han seguido subiéndose fotografías sin que se pueda evitar y ya no sé que hacer.

El antiguo panel, ¿más seguro?

Viendo todo esto, y tirando del hilo, resulta que hay un panel de administración web anterior que no solo vale para cámaras de seguridad, sino para cualquier dispositivo de esta empresa que lleva control remoto por SIM. 

Figura 12: El panel antiguo indica cuál es la password por defecto para los dispositivos

Por supuesto, desde ahí también se pueden administrar las cámaras de seguridad, y aunque internamente este panel es más seguro, como se puede ver, para todos los demás dispositivos dejan claro en la web cuál es la contraseña por defecto.

Sin cifrado ni doble factor de autenticación

Con todo lo que hemos visto de ataques a la privacidad, como en el caso de las famosas y sus fotos personales de iCloud, o con el gran número de casos de cámaras de seguridad con fallos de seguridad por contraseñas por defecto, el poner un sistema que no utilice tan siquiera un cifrado SSL para la comunicación de las fotografías y el acceso al panel de control, es una locura.

Por supuesto, deseable sería ya que pusieran un segundo factor de autenticación como Latch a mi cuenta, ya que si un dispositivo va a tomar fotografías de mi casa, me gustaría poder saber cuándo alguien ha accedido a mi cuenta. Ni que decir tiene que para ello, las fotografías deben estar protegidas por una sesión y no accesibles como ficheros cualquiera en el servidor web.

Figura 13: Correo electrónico enviado al fabricante por varios medios

Me puse en contacto con ellos hace tiempo y no he recibido ni respuesta, y viendo que la gente sigue cayendo en estos problemas y que yo tengo una cámara de seguridad que no me atrevo a utilizar, he decidido hacer públicos los fallos para alertar a los usuarios y posibles compradores y meter presión a la empresa para que solucione todos estos fallos.

Actualización: Tras escribir un mensaje con copia a todas las direcciones que localicé de empleados de la empresa, no tardaron ni 24 horas en responderme, y es que estaba muy cabreado porque el fabricante sin haber corregido absolutamente nada había publicado un anuncio de la cámara de marras, lo cual me parecía casi una burla.

Afortunadamente el mensaje llegó a la persona adecuada y de inmediato sus ingenieros han hecho lo que debería haber hecho desde el principio. Según ellos la excusa era que era un portal beta en estadio de pre-venta. Les he dicho que me parece bien, pero en ese caso se comprueba a fondo que funcione, se securiza y luego se lanza, no se lanza primero y comprueba después.

Confío en que tomen nota de mis sugerencias y sigan trabajando añadiendo medidas de seguridad, entre ellas la más importante en los tiempos que corren: añadir la capa SSL en el tráfico de estos dispositivos. Seguramente muchos clientes no saben absolutamente nada de este asunto, pero al menos me siento muy aliviado porque mi insistencia nos ha beneficiado a los miles de compradores de la GM01.

Autor: Retro-Maligno