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!