26 de noviembre de 2012

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.


4 de noviembre de 2012

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.