Figura 1: Demos de la presentación de Enrique Rando en el Asegur@IT 9 de 2011
El analizar los proyectos
Open Source no es nuevo, y las empresas de búsqueda de bugs que se
dedican profesionalmente a esto, tienen sus analizadores de código conectados a todos los repositorios para revisarlos constantemente, ya que ahí puede salir de todo. Nosotros lo hicimos también tras publicar las técnicas de
Blind LDAP Injection para
localizar proyectos vulnerables.
En la última
Hack.Lu 2013 los investigadores
Dennis Pellikaan y
Thijs Houtenbos de la
Universidad de Amsterdam han impartido
una charla analizando los proyectos de de
GitHub y
SourceForge para localizar vulnerabilidades
SQL Injection,
Remote File Injection y de
Command Injection, utilizando para ello
dorks para localizar instrucciones como estas.
|
Figura 2: instrucciones vulnerables a buscar en los proyectos de GitHub y SourceForge |
Por supuesto, de los resultados iniciales han tenido que ir filtrando todo para quitar los que tengan protecciones extras que invaliden la vulnerabilidad, para lo que se implementan una especie de
analizador de código estático utilizando expresiones regulares que filtren los que tienen alguna protección de los que no tienen ninguna.
|
Figura 3: Expresiones regulares para localizar los bugs en el código |
Una vez tienen esto, el resto es automatizar la búsqueda de estos proyectos por medio de
dorks en
Google o
BING para hacer un poco más de
hacking con buscadores, saltándose para ello los
captcha del motor de búsquedas haciendo uso de
Round Robin sobre 13 distintas direcciones
IP y realizando una petición cada
8segundos, lo que les permitió localizar unas
122.000 URLs vulnerables y explotables indexadas por los buscadores.
|
Figura 4: Por tipo, los bugs más localizados siguen siendo SQL Injection |
|
Figura 5: Proyectos vulnerables y distribución de ellos en repositorios de código |
En la presentación hay también resultados de porcentajes de proyectos vulnerables o no con estas tres vulnerabilidades analizadas, y los resultados son bastante malos, tal y como se puede ver en estas gráficas, así que si vas a poner un proyecto Open Source, procura que sea uno mantenido y cuidado – que los hay – y no uno subido y abandonado en su repositorio de código – que los hay -.
Saludos Malignos!