Auditando VPNs (III): Fingerprinting

  ****************************************************
    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
  ****************************************************

Una vez que hemos detectado que la VPN se está ejecutando, conviene saber el tipo de dispositivo con el que estamos trabajando.

Existen dos mecanismos principales para identificar el tipo de servidor que está ejecutando el servicio de VPN. El primero de ellos consiste en la manera que tiene el servidor de responder a las peticiones de un cliente de establecer una conexión con él. Me explico...

IKE funciona bajo UDP, que es un protocolo no orientado a conexión. Por este motivo, no hay ninguna manera de saber si un paquete ha llegado a su destinatario más allá que esperar a recibir la respuesta a dicho paquete. Si la respuesta no se recibe, se puede entender que el paquete se perdió, en cuyo caso podría ser necesario reenviarlo.

El primer método de fingerprinting, por tanto, consiste en enviar un paquete al servidor y esperar su respuesta. En una conexión normal, el cliente debería continuar la comunicación con el servidor pero, ¿qué pasa si no se continúa? El servidor esperará un tiempo determinado y reenviará el paquete. Así un número determinado de veces hasta que deje de intentarlo.

La RFC de IKE no establece cómo se debe llevar a cabo el reenvío de paquetes (backoff en inglés), por lo que cada fabricante implementa su propio algoritmo, cambiando los tiempos entre un reenvío y el siguiente y el número de reenvíos total. Esto permite identificar el tipo de servidor que está ofreciendo el servicio de VPN.

A este mecanismo se le conoce como UDP Backoff Fingerprinting.

Ike-scan tiene una base de datos con los diferentes tiempos de respuesta de diferentes fabricantes, por lo identificar el fabricante puede resultar bastante sencillo con la opción --showbackoff:

$ sudo ike-scan --showbackoff  --multiline 10.48.226.227
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
10.48.226.227   Main Mode Handshake returned
        HDR=(CKY-R=a7a845233446a9e5)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=4f45755c645c6a795c5c6170
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

IKE Backoff Patterns:

IP Address      No.     Recv time               Delta Time
10.48.226.227   1       1351694781.627450       0.000000
10.48.226.227   2       1351694791.638280       10.010830
10.48.226.227   3       1351694811.659880       20.021600
10.48.226.227   Implementation guess: Linux FreeS/WAN, OpenSwan, strongSwan

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

Hay que tener paciencia con este comando, ya que el reenvío entre paquetes puede tardar bastante. Si te fijas en la columna "Delta Time", el primer reenvío se hace tras esperar 10 segundos, pero entre el segundo y el tercero, el servidor se espera 20 segundos.

Finalmente, ike-scan determina que el servicio VPN lo está ofreciendo Linux FreeS/WAN, OpenSwan ó strongSwan. Como aporte decir que, al menos en este caso, no se equivoca ya que el servidor con el que realicé las pruebas es un OpenSwan.

El segundo mecanismo para identificar el tipo de servidor que está ejecutando el servicio VPN está ligado al Vendor ID o VID.

El VID es un identificador único que determina la implementación de IKE que está siendo usada. Cada fabricante (vendor) utiliza un VID único, por lo que conociéndolo debería ser suficiente para identificarlo.

En el ejemplo anterior, el VID es "4f45755c645c6a795c5c6170" que, si buscamos en Internet podemos comprobar que está asociado a OpenSwan.

Así parece sencillo identificar el fabricante. El problema es que lo habitual es que el servidor no indique el VID a menos que el cliente lo envíe previamente y, para ello, hay que conocer el fabricante. En la documentación oficial de ike-scan se puede obtener un listado de VIDs con los que probar:

http://www.nta-monitor.com/wiki/index.php/IKE_Implementation_Analysis

La opción "--vendor" de ike-scan permite indicar el fabricante con el que queremos probar a la espera de que sea el usado por el servidor y éste nos lo confirme devolviéndolo de nuevo en su respuesta.

Auditando VPNs (II): Enumeración

  ****************************************************
    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
  ****************************************************

Tras el rápido repaso que hice sobre IPsec en la entrada anterior, vamos a ver cómo identificar un concentrador/servidor de VPNs basado en IPsec.

Por defecto, el protocolo IKE se ejecuta en el puerto 500 UDP, por lo que en principio un simple escáner de puertos debería bastar para identificarlo:

$ sudo nmap -sU -p 500 -P0 -n -sV 10.48.226.227

Starting Nmap 6.02 ( http://nmap.org ) at 2012-10-31 16:25 CET
Nmap scan report for 10.48.226.227
Host is up (0.00088s latency).
PORT    STATE SERVICE VERSION
500/udp open  isakmp
MAC Address: 08:00:27:12:F5:94 (Cadmus Computer Systems)

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.56 seconds

Nmap nos dice que el servicio está ahí, pero no nos aporta mucha más información. Herramientas más específicas como ike-scan o IKEProbe nos pueden aportar más información de una sola pasada:

$ sudo ike-scan  --multiline 10.48.226.227
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
10.48.226.227   Main Mode Handshake returned
        HDR=(CKY-R=8d0a997d0846794f)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=4f45755c645c6a795c5c6170
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

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

Nota: La opción --multiline (-M) de ike-scan tan sólo sirve para que la información la presente en varias líneas y seas más legible.

En el ejemplo anterior, vamos que se ha podido establecer una conexión utilizando el Main Mode. Además, se han negociado los atributos que se utilizarían para definir el túnel (Security Association ó SA) que se utilizará en la segunda fase del protocolo IKE.

Los atributos seleccionados son 3DES como algoritmo de cifrado, SHA1 como algoritmo de hash, PSK como método de autenticación y el grupo 2 (modp1024) para el algoritmo Diffie-Hellman. Al conjunto de todos los atributos se le denomina transform.

Sin embargo, no siempre obtenemos una respuesta parecida a la anterior cuando lanzamos ike-scan. Veamos un ejemplo:

$ sudo ike-scan --multiline 10.48.226.228
10.48.226.228   Notify message 14 (NO-PROPOSAL-CHOSEN)
        HDR=(CKY-R=03c337535f8887a3)

En este caso, vemos que el servidor nos devuelve una notificación con el mensaje NO-PROPOSAL-CHOSEN. Esto significa que el servicio está ahí pero estamos en alguno de los dos siguientes escenarios:

• El servidor de VPNs tiene filtrado por IP, por lo que no nos podremos conectar mientras no sea desde alguna de las que tiene en su lista de direcciones permitidas.
• No estamos usando ninguna transform soportada por el servidor. 

Fíjate que he dicho "ninguna" y no "una". Esto es así porque por defecto, ike-scan envía 8 transforms para que el servidor escoja una. Las opciones que manda son las ocho combinaciones posibles que salen con los siguientes parámetros:

• Para algoritmo de cifrado: DES y 3DES
• Para algoritmo de hash: MD5 y SHA-1
• Para grupo de Diffie-Hellman: 1 (modp768) y 2 (modp1024)

Además, el método de autenticación siempre es PSK y la duración del túnel (SA Lifetime) 28800 segundos.

Si nos encontráramos en este caso, tendríamos que probar diferentes transforms hasta que diéramos con la adecuada. Si no lo conseguimos, entonces no hay mucho más que hacer porque estaríamos en el caso de que existe una lista de IPs permitidas desde las que se puede establecer la conexión con el servidor.

Pero en este caso, en el que el servidor de VPN nos devuelva una notificación, ¿nmap también detecta el servicio? Pues la respuesta es que no siempre:

$ sudo nmap -sU -p 500 -P0 -n -sV 10.48.226.228

Starting Nmap 6.02 ( http://nmap.org ) at 2012-10-31 17:16 CET
Nmap scan report for 10.48.226.228
Host is up (0.43s latency).
PORT    STATE SERVICE VERSION
500/udp open  isakmp?

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 113.35 seconds

Sí, nos dice que el puerto está abierto, pero no es capaz de identificar el servicio. Moraleja: cuando tengas duda de si realmente es un servicio VPN, utiliza ike-scan.

Nota: El cómo probar con diferentes transforms lo veremos más adelante, en la cuarta entrega, cuando hablemos del cifrado.

En la próxima parte veremos cómo identificar el tipo de servidor que está sirviendo el servicio de VPN.

Auditando VPNs (I): Introducción a IPsec

  ****************************************************
    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
  ****************************************************

Durante las auditorías externas es muy común encontrarse con concentradores de VPN y no siempre sabemos qué tipo de pruebas realizar sobre estos sistemas.

En una serie de entradas voy a tratar las pruebas más frecuentes que se deben realizar sobre este tipo de dispositivos, centrándonos siempre en las VPN basadas en IPsec (no las basadas en SSL).

En esta entrada voy a comenzar hablando por el principio, introduciendo los conceptos básicos con los que trataremos en el resto de entradas.

Según Wikipedia, IPsec (Internet Protocol security) es un conjunto de protocolos cuya función es asegurar las comunicaciones sobre el Protocolo de Internet (IP) autenticando y/o cifrando cada paquete IP en un flujo de datos además de proveer de un mecanismo para el establecimiento de claves de cifrado.

IPsec, por tanto, está formado por tres protocolos:

• Authentication Header (AH): Este protocolo se utiliza para proporcionar integridad a nivel de paquete por medio de un checksum que se envía junto al paquete. Otros servicios que proporciona son autenticación del origen de los datos y, opcionalmente, protección frente a ataques de replay.
• Encapsulating Security Payload (ESP): Este protocolo cifra la comunicación punto a punto, proporcionando confidencialidad. También proporciona autenticación del origen de los datos, protección frente a ataques de replay e integridad.
• Internet Key Exchange (IKE): Es el encargado de llevar a cabo el intercambio de claves que serán utilizadas por cualquiera de los otros dos protocolos. 

De la información anterior nos quedamos con que:

1. IKE se ejecuta primero y, de llegar a realizar correctamente la autenticación, entonces se realiza un túnel (ESP) o simplemente se autentican los paquetes (AH). Por lo que frente a un concentrador de VPNs, tendremos que comenzar analizando el protocolo IKE.
2. AH no cifra las comunicaciones. Tan sólo ESP proporciona cifrado. Por lo que si la VPN funcionara tan sólo con AH, no se estaría cifrando ninguna comunicación entre los clientes y el concentrador de VPNs.

El protocolo IKE funciona en dos fases. En la primera de ellas, se lleva a cabo la autenticación y se crea un canal seguro que será utilizado durante la fase dos. En la segunda fase se configura un canal diferente que será el utilizado para todas las comunicaciones realizadas a través de ESP o AH.

La primera de las fases IKE, soporta dos modos de funcionamiento diferentes: el Main Mode y el Aggressive Mode. El Main Mode es el modo principal (evidentemente) y todos los concentradores de VPN deben soportarlo. En este modo se utiliza el algoritmo Diffie-Hellman para llevar a cabo el intercambio de claves entre el cliente y el servidor.

El Aggressive Mode, a diferencia, no tiene por qué estar implementado en todos los servidores de VPN y se suele utilizar para permitir el uso de claves pre-compartidas (Pre-Shared Key, PSK), ya que el Main Mode no soporta el uso de PSK (actualización 27/01/2014: El Main Mode sí soporta PSK, aunque es menos habitual que en el Aggressive Mode). Este modo tiene ciertas debilidades que iremos viendo a lo largo del resto de entradas.

Publicado el código fuente de mimikatz

Hace ya un tiempo que descubrí la herramienta mimikatz pero no había nunca escrito sobre ella porque ya lo hicismos desde aquí y no quería repetir la noticia. También la gente de SbD habló hace muy poco de ella.

El caso, es que a día de hoy la herramienta no es muy conocida. En parte porque su autor, que es un investigador francés, no ha querido traducirla a otro idioma, pero quizá también porque otra gente que ya tiene cierta influencia en este tipo de herramientas se ha dedicado a copiarla y a publicar sus propios derivados por los siete mares, dejando la original en el anonimato.

La herramienta, para quien no la conozca, permite recuperar las contraseñas en claro de todos los usuarios que hayan iniciado sesión en una máquina Windows. Esto significa que no hace falta recurrir al crackeo de los hashes o al Pass-the-Hash para acceder a otros sistemas.

Tiene más funcionalidades como exportar certificados digitales que están marcados con el flag de "No exportables", extraer el hash de los usuarios locales, realizar Pass-the-Hash, hacer trampas en el buscaminas sabiendo dónde están las minas antes de jugar (una de mis favoritas :D), etc. Recuerdo que para que pueda extraer las contraseñas en claro el usuario debe haber iniciado sesión, así que para el resto de usuarios serán necesarios los hashes y el resto del procedimiento que esto implica.

La buena noticia es, que depués de varias entradas en su blog explicando resumidamente cómo accedía a las contraseñas cifradas a través de WDigest y las descifraba utilizando la API de Windows, Gentilkiwi ha acabado publicando el código fuente de la herramienta:

https://code.google.com/p/mimikatz/

Desde luego es una buena noticia ya que nos permitirá adaptar la herramienta y utilizar sus técnicas en otros proyectos además de aprender su funcionamiento interno.

¿Qué os parece, ya tenéis alguna idea?

DNS Spoofing en Android (CVE-2012-2808)

Ayer se publicó una vulnerabilidad de DNS Spoofing (CVE-2012-2808) que afecta a todos los dispositivos Android con versiones del sistema operativo 4.0.4 y anteriores (la última versión 4.1.1 Jelly Bean que a día de hoy tan sólo usa el Nexus 7 no es vulnerable a este ataque).

El ataque consiste en el uso de un algoritmo de generación de números pseudoaleatorios (PRNG) débil para calcular el puerto de origen del paquete que realiza la consulta DNS y el identificador TXID de dicha petición.

Recordando cómo funciona el protocolo DNS, cada vez que se realiza una consulta DNS se genera un paquete que tiene un identificador único, el TXID, y se envía desde un puerto origen diferente cada vez. Ambos valores deben de ser aleatorios para evitar que un posible atacante pueda responder al cliente antes de que lo haga el servidor DNS legítimo.

Ambos valores tienen una longitud de 32 bits que "asegura" que no se pueden predecir, pero investigadores de IBM han determinado que, con el algoritmo que utiliza Android, tan sólo 21 de esos bits son realmente aleatorios. La causa, que se utiliza la hora en milisegundos del dispositivos como una de las bases para generar el valor final. Esto unido a que cada consulta DNS tiene dos valores aleatorios (el TXID y el puerto) es relativamente sencillo estimar uno a partir del otro.

Es más, depués de un determinado tiempo (en la PoC que han realizado es de unos 10 minutos), es posible predecir con una certeza suficientemente alta los próximos valores. A partir de ese momento es cuando se produciría el ataque DNS Spoofing ya que el atacante podría comenzar a responder al dispositivo móvil con el TXID y en el puerto origen correctos.

Os dejo el vídeo con la PoC y el enlace con el advisory oficial: 

Resumen: http://blog.watchfire.com/wfblog/2012/07/android-dns-poisoning-randomness-gone-bad-cve-2012-2808.html
Paper: http://blog.watchfire.com/files/androiddnsweakprng.pdf

Client Side Attacks (IV): Clickjacking

  ****************************************************
    Client Side Attacks (I): Introducción
    Client Side Attacks (II): Infectando Navegadores
    Client Side Attacks (III): Sacando provecho
    Client Side Attacks (IV): Clickjacking
  ****************************************************

Cerrando el tema que empecé hace ya tiempo sobre ataques del lado del cliente, hoy os voy a hablar del Clickjacking. Un concepto acuñado a finales de 2008 a partir de un paper publicado por Jeremiah Grossman y Robert Hansen.

El concepto de Clickjacking es bastante sencillo, tan sólo consiste en incluir una página (vulnerable) dentro de otra (que trata de sacar provecho de la primera) por medio de un iframe.

Imaginad una página web en la que se realice una determinada tarea pulsando sobre tres botones numerados del 1 al 3. Un sitio malicioso podría incluir en un iframe a la página anterior y situar sobre el mismo iframe un panel que lo oculte con un contenido atractivo que haga que el usuario pulse en los botones en el orden que debe de hacerlo.

Para seguir con el ejemplo, se podría solicitar al usuario que pulsara sobre los tres robots por orden: azul, rojo, verde (una vez se cuadraran ambos marcos):

Ejemplo de Clickjacking.

Como os decía, el concepto es muy simple, el problema es llevarlo a la práctica ya que no basta con identificar sitios vulnerables, sino crear un contenido que resulte interesante a una posible víctima para que caiga en el engaño y ejecute la tarea oculta.

Algunos ejemplos de posibles usos son hacer que se pulse sobre anuncios de publicidad (muchas empresas de publicidad pagan por pulsaciones), sobre botones "+1" o "Me gusta" (lo que se conoce como Likejacking), etc.

Un ejemplo más interesante es el del siguiente vídeo, que bien podría ser un jueguecillo de matar marcianos, bastante cutre, en el que hay que ir pulsando sobre cada una de las naves que van apareciendo de manera aleatoria en el espacio:

Ahora vemos lo que realmente está sucediendo cada vez que el usuario hace un click sobre cada una de las naves:

Como veis, lo que el usuario está realmente haciendo es:

1. Habilitar el chat de iGoogle
2. Agregar un nuevo contacto que ya le había mandado una invitación previa (éste sería el atacante).
3. Abrir un chat con el contacto que acaba de añadir.
4. Invitarle a realizar una video-llamada, lo que automáticamente acaba encendiendo la web cam del usuario cuando el atacante acepta la llamada.

Todo ello transcurre sin que el usuario sea consciente de lo que está haciendo...

Por desgracia, poca gente toma en serio esta vulnerabilidad y aun menos webmasters implementan medidas para evitarla (que pasa por incluir la cabecera HTTP X-Frame-Options en las URLs que se desean proteger).


¿A vosotros también os parece una vulnerabilidad que menospreciar?

OAuzz, el fuzzer de OAuth

Después de todo este tiempo que he estado "desaparecido" por diversos motivos, he querido volver a lo grande, así que os presento en lo que he estado trabajando últimamente: OAuzz.

Hace ya un tiempo os presenté el protocolo de autenticación OAuth [1][2][3][4] y cómo de necesario era en la época actual, donde gran parte de las aplicaciones que podemos encontrar en markets usan servicios de otras grandes empresas (Google, Facebook, Twitter...) para ofrecer su servicio.

El acceso a los servicios finales suele llevarse a cabo por medio de APIs que los proveedores de servicio ofrecen y es ahí donde se exige OAuth para llevar a cabo la autenticación.

A la hora de tratar de analizar la seguridad de dichas APIs, nos encontramos un problema ya que cada petición tiene que ser firmada y hacerlo manualmente es realmente tedioso aunque existen herramientas que te ayudan a hacerlo... Creedme, pasar unos 3 minutos para generar cada petición hace que se te quiten las ganas de realizarlo de manera manual (lo he vivido).

Por ello me vi obligado a desarrollar OAuzz, un fuzzer que permite auditar aplicaciones basadas en OAuth, ya que ella sola se encarga de firmar todas las peticiones que va realizando.

Interfaz de OAuzz.

OAuzz proporciona una consola desde la que se van introduciendo los diversos comandos o se puede llamar haciendo referencia a un script en donde ya estén definidos dichos comandos:

Llamando a OAuzz con un script.

Al principio puede resultar un poco compleja, pero esto se debe a que hay que familiarizarse con los concepto de OAuth. Una vez se tenga claro cómo funciona el protocolo, OAuzz es muy sencilla de utilizar.

Realizando el fuzzing sobre una URL.

Podéis encontrar la herramienta y un pequeño manual de cómo utilizarla en su sitio de Google Code:

http://code.google.com/p/oauzz/

En las próximas semanas iré publicando más información sobre esta herramienta y su funcionamiento.

Cisco7 ¿encryption?

De rato en rato, trato de sacar tiempo para ir desarrollando la versión 2.0 de findmyhash. Una de las muchas mejoras que tendrá la próxima versión es no consultar ningún servicio online para los algoritmos reversibles que soporta.

El algoritmo del que os voy a hablar hoy es uno de los que Cisco utiliza para cifrar las contraseñas que almacena en la configuración de sus dispositivos y que se suele conocer como Cisco 7 porque al consultar la configuración del dispositivo se muestra algo como:

username admin password 7 080d4d7604181714130e00083f2c253a

Donde el '7' indica el tipo de algoritmo utilizado.

Cisco 7 está basado en el cifrado de Vigenère, utilizando como clave la cadena:

d s f d ; k f o A , . i y e w r k l d J K D H S U B s g v c a 6 9 8 3 4 n c x

A primera vista podemos decir que es bastante robusta, por lo que alguno podría pensar que lo que se cifre con esta clave debería estar seguro. Pero recordemos que tan sólo estará seguro si no conociéramos la clave con la que se está cifrando y en este caso se utiliza la cadena anterior en TODOS los dispositivos Cisco... por lo que ahora veremos que no sirve de mucho.

Para descifrar la contraseña, vamos a trabajar siempre en hexadecimal, por lo utilizaremos tan sólo la versión codificada de la clave:

d	s	f	d	;	k	f	o	A	,
64	73	66	64	3b	6b	66	6f	41	2c
.	i	y	e	w	r	k	l	d	J
2e	69	79	65	77	72	6b	6c	64	4a
K	D	H	S	U	B	s	g	v	c
4b	44	48	53	55	42	73	67	76	63
a	6	9	8	3	4	n	c	x
61	36	39	38	33	34	6e	63	78

La contraseña cifrada que aparecía en el ejemplo con el que empezaba el post ya está en formato hexadecimal, así que la utilizaremos tal cual:

080d4d7604181714130e00083f2c253a

Esta contraseña se divide en dos partes, el primer byte (08) es un desplazamiento en la clave de cifrado. Es decir, en este caso vamos a obviar los 8 primeros caracteres de la clave, por lo que comenzaríamos en 412c2e69... y utilizaremos tantos caracteres como tiene la contraseña cifrada. Es decir, lo que en la tabla anterior he marcado en azul.

La segunda parte (el resto: 0d4d7604181714130e00083f2c253a) es la contraseña cifrada. Esta parte fue calculada con un XOR entre la contraseña original y la clave de cifrado, que en nuestro caso recordamos que empieza con un desplazamiento de 8 caracteres. Es decir:

Clave de cifrado:	41	2c	2e	69	79	65	77	72	6b	6c	64	4a	4b	44	48
Contraseña original:	??	??	??	??	??	??	??	??	??	??	??	??	??	??	??
	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--
Contraseña cifrada:	0d	4d	76	04	18	17	14	13	0e	00	08	3f	2c	25	3a

Como la operación XOR es reversible, nos basta con calcular el XOR entre la misma clave que se utilizó y la contraseña cifrada para obtener la contraseña en texto claro:

Clave de cifrado:	41	2c	2e	69	79	65	77	72	6b	6c	64	4a	4b	44	48
Contraseña cifrada:	0d	4d	76	04	18	17	14	13	0e	00	08	3f	2c	25	3a
	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--
Contraseña original:	4C	61	58	6D	61	72	63	61	65	6C	6C	75	67	61	72

Que se corresponde con la cadena:

LaXmarcaellugar

Como veis, aunque la contraseña se almacena cifrada, no sirve de mucho si el algoritmo que se utiliza es reversible y la clave de cifrado conocida.

Ésta es la principal razón por la cual nunca se debe almacenar una contraseña cifrada (y mucho menos en texto claro...). En su lugar se debe almacenar el hash de la contraseña, utilizando alguna función como SHA-1 y tratando de evitar el uso del MD5, que se considera débil desde hace muchos años.

Client Side Attacks (III): Sacando Provecho

  ****************************************************
    Client Side Attacks (I): Introducción
    Client Side Attacks (II): Infectando Navegadores
    Client Side Attacks (III): Sacando provecho
    Client Side Attacks (IV): Otros ataques
  ****************************************************

En las con entradas anteriores hemos visto en qué consisten los ataques del lado del cliente y cómo hacernos con el control de los navegadores de nuestras víctimas. Ahora es el turno de ver cómo sacar provecho de estos navegadores una vez están bajo nuestro control.

Como ya dijimos también, el Cross Site Scripting (XSS) es el rey de los ataques del lado del cliente. Por ello voy a comenzar por él, continuando con el Cross Site Request Forgery (CSRF ó XSRF) y dejando otros ataques para la última entrada de la serie.

Uno de los problemas de explotar un XSS es que el exploit hay que programarlo en Javascript, que es un lenguaje que puede resultar un tanto desagradable para aquellos que no están acostumbrados a trabajar con él. Por suerte, del mismo modo que existe Metasploit para la explotación de (prácticamente todos los tipos de) exploits; para la explotación de XSS está BeEF, un potente framework que nos ofrece multitud de distintas posibilidades.

The Browser Exploitation Framework (BeEF)

El objetivo de esta entrada no es describir en profundidad esta herramienta, ya que ello me podría llevar varias entradas. Tan sólo voy a resumiros algunas de las posibilidades que ofrece y que, personalmente, considero de las más interesantes para nuestro propósito de hoy.

Partiendo de la hipótesis de que hubiéramos conseguido "infectar" a una serie de víctimas por medio de un Cross Site Scripting y dependiendo del navegador que éstas utilicen, BeEF nos permite:

• Obtener información como la versión del sistema operativo y del navegador que utilizan los usuarios, además de los diferentes plugins que puedan tener instalados.

• Modificar parte o todo el contenido del sitio web  (Website Defacement) por el que la víctima está  navegando y que se corresponde con el sitio en donde hemos conseguido explotar el XSS.

• Analizar el sitio en busca de otras vulnerabilidades como inyecciones de código SQL o Cross Site Request Forgery (XSRF).

• Analizar la red en la que se encuentra la víctima en busca de nuevos equipos y servidores y la posibilidad de realizarles un escáner de puertos. (Esto ya es bastante INTERESANTE).

• Utilizar el navegador de la víctima como proxy para navegar dentro del dominio afectado por el XSS utilizando la sesión de la propia víctima (Session Hijacking).

• Explotación de vulnerabilidades conocidas en servidores JBoss, vTiger CRM, algunos sistemas Linksys...

• Integración con Metasploit para la explotación de todo tipo de exploits en los navegadores web de los usuarios.

Es decir, a partir de un inocente Cross Site Scripting en cualquier servidor podemos, por ejemplo, analizar la red local de un empleado de una empresa mediante barridos de ping y análisis de puertos, lo que desde el punto de vista de un pentester podría significar una primera impresión de la red.

Lógicamente, desde este mismo punto de vista es mucho más interesante la integración con Metasploit, que nos proporcionaría el paso que nos faltaría dar para entrar del todo al interior de la LAN corporativa.

Por desgracia, en los test de intrusión no es habitual que se permita atacar al usuario ya que esto normalmente está más pensado para auditorías técnicas que se mezclen con técnicas de Ingeniería Social.

Os dejo un vídeo algo largo, pero muy completo, para que veáis BeEF en acción y os anime a probarlo:

Cross Domain y Cross Site Request Forgery

Pasando a otro tipo de ataque, si decía que el XSS era el rey, podríamos decir que el Cross Site Request Forgery es casi la oveja negra de los ataques del lado de cliente. Esto no lo digo porque no sea útil ni peligroso, sino porque apenas se le hace caso o incluso se infravalora, ignorando el riesgo real de este tipo de ataque.

Para explicar en qué consiste voy a poneros como ejemplo la vulnerabilidad de XSRF que se detectó en Gmail allá por el 2009 por lo visual que es al encontrarse en un formulario de cambio de contraseña. Imaginad que al hacer un cambio de contraseña en Gmail, la URL que se enviara al servidor fuera la siguiente:

https://mail.google.com/changePassword?user=pepito&oldpassword=123456&newpassword=qwerty

Al saber que esta URL no está protegida de ataques de XSRF, podríamos hacer un ataque de fuerza bruta haciendo que nuestra víctima entre a una URL maliciosa en donde hubiera miles (es un ataque por diccionario) de tags HTML como los siguientes:

<img src="https://mail.google.com/changePassword?user=víctima&oldpassword=pass1&newpassword=mypassword" />

<img src="https://mail.google.com/changePassword?user=víctima&oldpassword=pass2&newpassword=mypassword" />

<img src="https://mail.google.com/changePassword?user=víctima&oldpassword=pass3&newpassword=mypassword" />

[...]

Al ser un tag "img", la URL que hay dentro del atributo "src" se acaba ejecutando para tratar de cargar la imagen pero, en este caso, lo que realmente se está haciendo es tratar de cambiar la contraseña del usuario "víctima" por una que nosotros conocemos (mypassword). Para ello, como veis, lo que se hace es ir cambiando el campo "oldpassword" de manera que si alguna de las que probamos da la casualidad que es la de nuestra víctima, Gmail creerá que es la víctima la que realmente está haciendo el cambio de contraseña y, por tanto, procederá al cambio. Habríamos robado la cuenta de correo de la víctima. (Imagino que no hace falta decir que esto ya está más que corregido... así que no hace falta que lo probéis (en Gmail)).

Vale, ya sabemos qué es eso del XSRF pero ¿y lo del Cross Domain? Pues bien, el Cross Domain es un ataque bastante antiguo por el cual se permitía acceder a través de Javascript (o cualquier otro lenguaje script) a información de otros dominios. Es decir, si el atacante tenía el dominio "atacante.com", podía incluir en su página web código script que accediera a Facebook y le enviara la cookie de sesión del usuario que había accedido.

Por suerte, los navegadores modernos (cualquiera a partir de IE6 o FF2) implementan la política de mismo origen (same origin policy). Esta política evita que desde código script, ya sea Javascript, Flash o cualquier otra tecnología soportada por el navegador, se pueda acceder a páginas de diferentes dominios.

Pero existe un problema con la manera que tienen los navegadores de implementar esta política que hace que aún se pueda utilizar este viejo método para realizar ataques de tipo Cross Site Request Forgery. Me explico...

La mayoría de navegadores (al menos en los que lo he probado que han sido Chrome y Firefox), al realizar una petición con XMLHttpRequest a otro dominio, envían la petición correctamente al servidor en cuestión y es al recibir la respuesta cuando se produce una excepción que hace que no se pueda interpretar.

Esto, como digo, se puede utilizar para realizar peticiones a sitios que sean vulnerables a XSRF, ya sea por GET o por POST. De manera que si nos encontráramos con una Intranet vulnerable que tuviera una URL para crear usuario como:

http://www.intranet.com/admin/createUser?username=nuevousuario&password=[valor_md5]

Bastaría con incluir un fragmento de código Javascript como los de antes en una URL y hacer que el administrador de la Intranet vulnerable acceda a ella:

<img src="http://www.intranet.com/admin/createUser?username=attacker&password=5f4dcc3b5aa765d61d8327deb882cf99" />

En esta entrada hemos visto dos de los ataques del lado del cliente más peligrosos (y frecuentes), pero no son los únicos. Por lo que dejo para la próxima un ataque que, personalmente, me gusta bastante aunque resulte un tanto complejo de explotar en un entorno real... ¿adivináis cuál?

Client Side Attacks (II): Infectando Navegadores

  ****************************************************
    Client Side Attacks (I): Introducción
    Client Side Attacks (II): Infectando Navegadores
    Client Side Attacks (III): Sacando provecho
    Client Side Attacks (IV): Otros ataques
  ****************************************************

En la entrada anterior vimos en qué consistían los ataques del lado del cliente con un ejemplo práctico que permitía robar la sesión de un usuario que se viera afectado por un Cross Site Scripting. Pero, ¿cómo sacar provecho de este tipo de ataques en un caso real como podría ser un test de intrusión?

Teniendo en cuenta que hasta ahora nos estamos centrando únicamente en los XSS, cuando intentamos responder a la pregunta anterior, se nos plantean dos grandes problemas. El primero de ellos es tener el conocimiento suficiente de Javascript como para ser capaces de programar un exploit y el segundo es cómo conseguir infectar al mayor número de usuarios posible o al menos a aquellos que nos interesan para conseguir nuestro objetivo.

Esta entrada la voy a dedicar al segundo de estos problemas...

Infectando Navegadores

Lo habitual es pensar en enviar un correo electrónico o publicar el enlace en algún blog o red social para que la gente pinche sobre él. Pero en estos casos nos encontramos con el problema que ya planteamos en la entrada anterior con soft: en el momento que el usuario abandone la URL con el XSS inyectado, perderemos el control sobre el navegador del usuario.

Una manera de solucionarlo es publicar el código malicioso en sitios como foros (cada vez en más difícil encontrar foros vulnerables a Cross Site Scripting) o incluso en algún dominio que controlemos y atraer a los usuarios hasta él... Aunque puestos a desear, está claro que lo mejor es inyectar el código en donde los usuarios ya están y donde pasan la mayor parte de su tiempo; es decir, en las redes sociales o páginas de inicio típicas como motores de búsqueda o escritorios web.

Esto puede parecer bastante difícil. ¿Un Cross Site Scripting en Google? Sí, los hay, pero se puede obtener el mismo resultado de maneras más fáciles y, sobretodo, duraderas.

Yo, al igual que otra mucha gente que conozco, utilizo iGoogle como página de inicio. Tanto éste como otros escritorios web se componen de gagdets, que no son más que iframes con alguna URL dentro... Es decir, que si alguien se entretiene y publica un gadget con un contenido atractivo además del código malicioso y lo comienza a distribuir... es muy fácil que la gente se lo instale en su escritorio web y cada vez que entren (que debería ser bastante a menudo) tendremos nuestro script/exploit en sus navegadores.

Además, para compartir un gadget para iGoogle, ni siquiera hace falta publicarlo en su directorio de gadgets. Basta con distribuir una URL como la siguiente que, además, pertenece a Google y parece totalmente inofensiva, facilitando ser publicada y distribuida a través de redes sociales:

http://www.google.es/ig/directory?hl=es&type=gadgets&url=www.sitiomalicioso.com/gadget.xml

El contenido del fichero XML que muestra la URL anterior (gadget.xml) es el siguiente:

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
    <ModulePrefs
        author="Attacker"
        author_email="fakemail@gmail.com"
        author_location="123 Fake Street"
        description="This gadget is a PoC for La X marca el lugar"
        title="La X marca el lugar Gadget!!"
        directory_title="La X marca el lugar Gadget!!"
        thumbnail="http://www.sitiomalicioso.com/LaX_trans.png">
        <Require feature="views" />
    </ModulePrefs>
    <Content type="url" view="home" href="http://www.sitiomalicioso.com/index.html" />
</Module>

Con él se definen cada uno de los campos que luego se muestran en la imagen anterior y se especifica (línea 13, tag Content) la URL que estará dentro del iframe del gadget final. Si os interesa saber más sobre cómo diseñar vuestros gadgets podéis consultarlo en la Guía del desarrollador de iGoogle.

Si desde la URL anterior pulsamos en el botón "Añadir ahora",  el gadget se instala, pasando a formar parte de nuestro iGoogle:

Una vez instalado funciona como cualquier otro gadget "oficial", permitiendo incluso que los propios usuarios lo compartan por el procedimiento habitual desde el enlace que se proporciona en iGoogle.

Llevando esta idea un poco más al extremo y ya puestos... ¿por qué no implementar un jueguecillo de esos que enganchan para Facebook y que incluya nuestro script? Con un FarmVille o similar podríamos llegar a tener miles (millones) de usuarios infectados al cabo de unas semanas.

Por tanto, ya hemos conseguido solucionar el segundo de nuestros problemas. Infectar a muchos usuarios de una manera sencilla y sin llamar la atención con spam. En la próxima entrada, veremos qué hacer desde los navegadores una vez que ya los controlamos ;)

Client Side Attacks (I): Introducción

  ****************************************************
    Client Side Attacks (I): Introducción
    Client Side Attacks (II): Infectando Navegadores
    Client Side Attacks (III): Sacando provecho
    Client Side Attacks (IV): Otros ataques
  ****************************************************

Hace unas semanas publiqué un artículo en el número 1/12 de la revista Hakin9. En el artículo hablaba de cómo sacar provecho de vulnerabilidades del lado del cliente (XSS, CSRF, Cross Domain...). Para aquellos que no tengan acceso a la revista original o no se sientan cómodos leyendo en la lengua de Shakespeare, voy a contar en una serie de entradas la mayor parte de lo que trataba el artículo.

Para empezar, cuando en Seguridad Web nos referimos a Client Side Attacks, o Ataques del Lado del Cliente, nos estamos refiriendo a todas aquellas técnicas que permiten explotar una vulnerabilidad que afecta a los usuarios del servidor web.

Para entenderlo mejor, veamos dos ejemplos de inyección de código:

• Una inyección de código SQL. En este caso, la vulnerabilidad afecta a una aplicación / base de datos que se encuentra en el servidor, por lo que esta vulnerabilidad se considera que es del lado del servidor.


• Una inyección de código HTML / script (es decir, un Cross Site Scripting). En este caso, aunque la aplicación vulnerable se encuentra hospedada en el servidor (obvio), al explotar la vulnerabilidad, los que se ven afectados son los usuarios o clientes de la aplicación. Por ejemplo, si utilizáramos el XSS para modificar el contenido de una página web, el servidor no sufre cambio alguno pero los clientes que accedan a la URL con la inyección de código se verían afectados por la vulnerabilidad que no permitiría visualizar el contenido original. En este caso estamos ante una vulnerabilidad del lado del cliente.

Existen muchos tipos diferentes de ataques del lado del cliente aunque, sin duda alguna, el más conocido es el Cross Site Scripting (XSS).

Cuando la gente piensa en un XSS, suele pensar en una ventana de error con la palabra "XSS" o, como mucho, con la cookie del usuario:

Por este motivo, es habitual que los desarrolladores web o incluso los responsables de seguridad de las empresas no se tomen esta vulnerabilidad en serio y no consideren que merezca la pena invertir esfuerzos en corregirla.

Cierto es, que es muy llamativa para los medios de comunicación y muy fácil de distribuir. Por ello también es muy habitual encontrar noticias como ésta, de hace un par de años, en la que se afirma que han hackeado la web de la Presidencia Europea subiendo una foto de Mr. Bean. ¡Nada más lejos de la realidad! Como decía antes, los XSS no afectan a los servidores, por lo que ni el servidor ha sido "hackeado" ni se ha subido nada

Entonces... además de porque son divertidos y pueden llegar a ser un quebradero de cabeza si sale en algún medio de comunicación, ¿para qué pueden servir?

La primera posibilidad que os voy a mostrar es Shell of the Future (sotf), de Attack and Defense Labs. Una curiosa herramienta que te permite robar sesiones de usuario (Session Hijacking) de una manera interactiva y bastante cómoda.

La herramienta, desarrollada para Windows, consta de un servidor y de un proxy web que permiten la interacción con la misma. Pero lo más interesante de ella son dos scripts en Javascript que son los que hay que inyectar en el navegador de nuestras víctimas y que permiten robar la sesión de los usuarios. Los scripts envían toda la información necesaria al servidor web de soft, que es con el que nosotros, como atacantes, utilizamos.

Para que os hagáis una idea, el procedimiento es el siguiente:

1. Arrancaríamos el servidor web y el proxy.
2. Accederíamos a la consola de sotf pasando a través del proxy (que suele ser la URL http://127.0.0.1/sotf.console si dejamos la configuración por defecto).
3. Inyectamos alguno de los dos scripts en el navegador de nuestras víctimas. Por ejemplo publicando la URL con la inyección en un foro.

Una vez hecho esto, en la consola de sotf veríamos las sesiones de las víctimas que han pinchado en el enlace con la inyección y desde la misma consola podríamos elegir la que queremos suplantar. Al estar pasando por el proxy, es éste el que se encarga de sustituir nuestra cookie por la de la víctima, haciendo que el proceso de suplantación sea bastante transparente.

Lo mejor creo que es que la veáis en acción:

Lógicamente, la sesión tan sólo se mostrará en la consola de sotf mientras dure la inyección en la víctima. Es decir, que si el usuario "infectado" pulsa sobre cualquier enlace de la página y se sale de la URL maliciosa, dejaríamos de tener el control a través de sotf. Ésta es precisamente la diferencia entre los dos scripts. El que se llama "e1.js" no hace nada para resolver esto, por lo que es muy posible que la sesión nos dure poco. Sin embargo, "e2.js" hace que pulse donde pulse el usuario, abra una nueva pestaña en el navegador pasando el foco a esta pestaña y dejando la "infectada" en segundo plano. Con un poco (bastante en realidad) de suerte, el usuario no notará nada y permitiría mantener la sesión durante más tiempo.

Si probáis a jugar con la herramienta, veréis que tiene muchas deficiencias. No obstante, considero que es una herramienta interesante y, desde mi punto de vista, creo que puede ser útil para hacer presentaciones sobre lo que se puede llegar a hacer por medio de la explotación de un Cross Site Scripting.

Hasta aquí esta primera entrada, en la que os he presentado en qué consisten los ataques del lado del cliente con un ejemplo. A partir de la próxima entrada de la serie veremos cómo sacar más partido a este tipo de técnica tratando, además, de pasar desapercibidos.

Crackeando un Hash Cracker (Contribución)

Los que sigáis a José Selvi en su blog "Pentester.es", habréis comprobado que he comenzado el año con una colaboración que vamos a publicar en varias entradas.

Tanto en esta primera entrada como en las siguientes, trataré diferentes tipos de vulnerabilidades web con el objetivo de que veáis lo peligroso que puede llegar a ser cometer fallos de programación que permitan realizar inyecciones de código.

La primera vulnerabilidad de la que hablo es un Cross Site Scripting bastante "curioso" pero que es totalmente explotable y, como tal, debe ser evitado:

Crackeando un Hash Cracker (I): XSS con MD5
Crackeando un Hash Cracker (II): CMDi
Crackeando un Hash Cracker (III): SQLIi con MD5

¡Espero que os resulten interesantes!