Costo de encontrar vulnerabilidades frente a desarrollar exploits

Los costos relativos dependen mucho de lo que es la vulnerabilidad. Para demostrar esto, me referiré a dos vulnerabilidades semi-recientes: el error Bash "Shellshock" y el error glibc "Ghost" gethostbyname() .

Shellshock

El error de Shellshock fue causado por una falla intrincada en el análisis de la función de Bash que se podría usar para hacer que Bash ejecute el código directamente desde las variables de entorno. El error existió durante aproximadamente 22 años antes de que se encontrara públicamente.

Una comprobación de si el error existe es así:

$ env X="() { :;} ; echo vulnerable" /bin/sh -c ":"

Ahora, encontrar ese error requiere un cuidadoso escrutinio del código fuente o una buena sesión con un codificador de código. Pero tan pronto como se reduce a un caso de prueba como este, los exploits se producen fácilmente. Por ejemplo, si sabe que un servidor de destino está ejecutando un shellscript CGI:

$ nc vulnerable.example.com 80 <<__END
GET /path/to/cgi.sh HTTP/1.1
Host: localhost
User-Agent: () { x; }; printf "%s\n\n" "Content-type: text/plain"; /usr/bin/id
Accept: */*

__END

Shellshock fue difícil de encontrar, pero una vez encontrado, fue trivial de explotar.

Fantasma

La vulnerabilidad de glibc gethostbyname() , por otro lado, es una vulnerabilidad de desbordamiento de búfer que solo puede ocurrir bajo ciertas condiciones muy específicas. Un atacante puede sobrescribir como máximo 8 bytes de memoria en máquinas de 64 bits, o 4 en máquinas de 32 bits. El atacante debe configurar una entrada de DNS especialmente diseñada y luego engañar al objetivo para que la solicite.

Este error no se corrigió por alrededor de 13 años, y cuando se solucionó, no se reconoció como una vulnerabilidad de seguridad. Los investigadores de seguridad de Qualys que lo informaron como una vulnerabilidad pasaron una gran cantidad de tiempo probando los programas individuales para determinar su capacidad de explotación. Una gran mayoría no lo era, debido a la limitación de 8 bytes y los detalles de cómo se usa típicamente gethostbyname() . Tenga en cuenta también que simplemente desencadenar el error generalmente hará que el programa se bloquee: más una denegación de servicio que un exploit.

Su golpe de gracia, una completa explotación remota del servidor de correo Exim, es una cadena de Rube Goldberg diseñada meticulosamente que logró evitar las limitaciones usando propiedades específicas de cómo Exim pasa a organizar su memoria en situaciones específicas. Se describe detalladamente en la aviso de seguridad de Qualys y es demasiado complicado de usar en aquí.

Comparación

Admito que no estoy seguro de qué error fue más difícil de encontrar. Ambos permanecieron latentes en el código durante mucho tiempo. Qualys encontró el error Ghost "durante una auditoría de código"; Stéphane Chazelas encontró el error Shellshock extrapolando cosas que ya sabía sobre el comportamiento de Bash , y toda una serie de se encontraron errores relacionados muy rápidamente una vez que la gente supo dónde buscar, algunos con la ayuda de herramientas de eliminación de errores.

Sin embargo, la pregunta de cuál fue más difícil de explotar es mucho más fácil de responder. Creo que está claro que un nivel muy alto de ingeniería fue en encontrar una manera de convertir el error Ghost en un exploit de Exim que funcione. Se requirió mucho más trabajo que el exploit Shellshock anterior, que tomó aproximadamente 10 minutos para escribir y probar.

Escribir una utilidad de exploit no es nada para un programador experimentado. Y no es un software para usuarios finales, por lo que no necesita una interfaz fácil de usar, no hay necesidad de cosas elegantes. Es solo una utilidad sucia y rápida para explotar la vulnerabilidad, por lo que este no es un software costoso, es un software muy pequeño y barato. Y puedes hablar de una ETA. Sabes cuando recuperas tu inversión.

Descubrir una nueva vulnerabilidad es mucho más difícil en un software maduro, en comparación con el desarrollo del exploit. Y no sabe si puede encontrar pronto, o alguna vez, ninguna ETA, no sabe cuándo recuperará su inversión, o nunca. Estás buscando algo que los desarrolladores no quieren que exista. También hay una competencia, otros pueden descubrir antes que usted.

Si el software es importante (por ejemplo, OpenSSL), se vuelve increíblemente difícil debido a la competencia. Porque descubrir una vulnerabilidad crítica equivale a inventar una súper arma para las guerras cibernéticas, como HeartBleed . La NSA probablemente esté gastando toneladas de dinero cada año para este tipo de investigaciones, y probablemente ya tengan algunos 0 días graves.

Por lo tanto, el costo de escribir un exploit es insignificante en comparación con la búsqueda de una nueva vulnerabilidad.

¿Algún dato? Consulte algunas vulnerabilidades en enlace . Existen vulnerabilidades que no se detectaron durante varios años, sin embargo, su explotación es bastante simple y fácil con 100- 200 líneas de Python.

Hace 3-4 semanas, se descubrió públicamente una nueva vulnerabilidad en OpenSSH antes de 7.2p2 ( todas las versiones; se remonta a ~ 20 años ), que permite a los usuarios autenticados remotos eludir las restricciones de comandos de shell intencionadas a través de datos de reenvío X11 hechos a mano.

Y aquí está el exploit: enlace 150 líneas de Python .

Por cierto, no olvides revisar tu paquete de servidor openssh. Tengo instalado Ubuntu 14.04 y, después de actualizar los paquetes, todavía tengo la versión 6.9p1.