Ayer explicaba por qué se había producido la última vulnerabilidad (CVE-2015-5477) en el servidor DNS BIND, junto con una demostración de un exploit funcional publicado recientemente que tira el servicio en las versiones 9 hasta la 9.10.2-P2. Viendo el código fuente al realizar una segunda llamada a la función dns_message_findname para solicitar registros TKEY se inicializaba uno de los párametros de entrada cuando el programa esperaba un valor nulo, el resultado es una excepción que cierra el programa. Desde el blog de Cloudflare explican línea por línea de código el motivo de la vulnerabilidad.
Pero la pregunta de hoy es, ¿cómo consiguieron descubrir esta vulnerabilidad?. Hay muchas formas de encontrar vulnerabilidades en el software: Ingeniería inversa, análisis de código estático o como en este caso con un fuzzer.
Un Fuzzer es una herramienta de testing de software automatizada o semi-automatizada que tiene por objetivo introducir en los parámetros de entrada de los programas todo tipo de información con el fin de encontrar resultados diferentes a los esperados. Para ello se utilizan datos inválidos, no esperados o aleatorios. Es como realizar un ataque de fuerza bruta sólo que en este caso no se busca una contraseña o un listado de directorios de un servidor web sino una excepción en un programa. Hay fuzzers para protocolos como el JBroFuzz para web y otros que varían según el tipo de datos a testear. En la página de OWASP podemos encontrar más información sobre el Fuzzing.
En este caso la vulnerabilidad fue descubierta por Jonathan Foote utilizando el fuzzer American Fuzzy Lop. Este fuzzer ha sido capaz de encontrar diversas vulnerabilidades en más de 90 productos de software. Algunas de ellas tan importantes como las acontecidas en OpenSSL recientemente.
Este fuzzer funciona compilando sus librerías junto con el software que queremos testear. Para ello primero descargamos la herramienta desde su página web.
A continuación la instalamos con un make install una vez descomprimida.
root@kali:~/Downloads/afl-1.85b# make install [*] Checking for the ability to compile x86 code... [+] Everything seems to be working, ready to compile.
Para hacer una prueba he seguido uno de sus ejemplos con el software de FTP binutilis en su versión 2.25. Descargamos el código fuente de su repositorio y ésta vez añadimos en la opción del compilador CC el parámetro CC=afl-gcc ./configure para integrar el fuzzer.
root@kali:~/Downloads# cd binutils-2.25/ root@kali:~/Downloads/binutils-2.25# CC=afl-gcc ./configure checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu
Una vez esto se realiza el make como siempre.
root@kali:~/Downloads/binutils-2.25# make make[1]: Entering directory `/root/Downloads/binutils-2.25'
El siguiente paso es realizar el siguiente comando para que los crashes del programa vayan a un fichero en vez de a un manejador de excepciones.
root@kali:~/Downloads/binutils-2.25# echo core > /proc/sys/kernel/core_pattern
Ahora creamos una carpeta de entrada y otras de salida para el fuzzer. En la carpeta de entrada tenemos que introducir un archivo ELF que usará el fuzzer a modo de plantilla. En este caso se utiliza el comando «ps»
root@kali:~/Downloads/binutils-2.25# mkdir afl_in afl_out root@kali:~/Downloads/binutils-2.25# cp /bin/ps afl_in/
Por último se lanza el fuzzer.
root@kali:~/Downloads/binutils-2.25# afl-fuzz -i afl_in -o afl_out ./binutils/readelf -a @@
AFL ejecutándose
Podemos ver los crashes que va encontrando. Estos se guardan en la carpeta afl_out que hemos creado anteriormente. No he avanzado más con este fuzzer pero parece muy interesante, aunque la curva de aprendizaje debe de ser grande.