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!