iodine: tunel DNS para saltarnos un portal cautivo
En ocasiones, y cada vez más, encontramos redes Wi-Fi públicas y abiertas (sin codificación de datos) que requieren autenticación. Cuando te conectas y accedes a cualquier dirección Web, salta un portal cautivo donde tienes que introducir un login, controlan el tráfico HTTP.
Algunas están restringidas a cierto público cerrado, como estudiantes de una universidad o empleados de una empresa. Y otras son de pago, del estilo: envía un SMS y te dejamos navegar durante 30 minutos. ¿Existe alguna manera de vulnerar dicha restricción? La respuesta es ¡si!, la gran mayoría de esas redes tienen un pequeño fallo de seguridad que seguidamente explicamos como explotar.
--------------------------------------------------------------------------------
La puerta trasea
El funcionamiento del portal cautivo, a grandes rasgos, es este:
1. El cliente asocia con el AP, y obtiene una configuración de red
2. El cliente hace una petición DNS, y le es resuelta (por ejemplo google.com)
3. Cuando el cliente intenta acceder a la IP de google.com, el AP (normalmente asociado a un servidor RADIUS), le deniega el acceso y lo redirecciona al portal cautivo, donde deberá introducir su login.
4. Si el login es correcto, el AP deja que navege libremente. Sino, a cada petición redireccionará al portal.
En esos 4 puntos, ya podemos ver donde está la puerta que nos permitirá gozar de una conexión libre: las peticiones DNS. Son el único protocolo que esos sistemas dejan utilizar sin estar autenticado. Ahora bien, ¿como lo explotamos?
--------------------------------------------------------------------------------
Explotación
Los paquetes DNS (que utilizan el protocolo UDP), disponen de un pequeño payload de datos, 512 Bytes donde va almacenada información. La gracia está en utilizarlo para comunicarte con un servidor exterior (previamente configurado ) que nos hará de router para comunicarnos con Internet. Dicho en otras palabras, un tunel DNS
IOdine
Iodine es un pequeño software para *nix y windows, compuesto por dos partes. El servidor escucha en el puerto UDP 53, a la espera de peticiones DNS. El cliente que se conecta a él, crea una interfaz de red virtual IPv4 asociada al servidor, mediante el tunel TUN/TAP, por donde enviará las peticiones para que las enrute. Realmente bello!!
Web de iodine: http://code.kryo.se/iodine
--------------------------------------------------------------------------------
El servidor
¡Cuidado! Necesitamos un server conectado a internet, y un dominio que podamos gestionar. Como ejemplo utilizaremos: foo.com, y supondremos que hace referencia a la ip de nuestro server.
Código:
foo.com -> 77.44.33.22
En la gestión del dominio, tenemos que introducir una entrada del tipo NS:
Código:
tunel.foo.com NS foo.com
[En lugar de foo.com podría ser también la dirección IP del servidor]
Con la que indicamos que las peticiones a tunel.foo.com las resuelve el servidor de nombres instalado en foo.com.
Hay que tener en cuenta que el servidor no debería ser quien resuelva la DNS foo.com, ya que no podriamos tener iodine escuchando en el puerto UDP 53. O si no nos importa que la resolución de nuestro dominio foo.com quede "inaccesible", podemos utilizar el mismo dominio.
Lógicamente necesitamos tener instalado iodine en nuestro sistema, para ello podemos utilizar nuestro gestor de paquetes. En caso de debian/ubuntu:
Código:
aptitude install iodine
o descargarlo de la web.
Procedimiento
Iniciamos iodine y activamos forwarding para enrutar las peticiones.
Código:
iodined -f 10.0.0.1 tunel.foo.com
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A POSTROUGING -t nat -s 10.0.0.0/255 -o eth0 -j MASQUERADE
[Suponiendo que eth0 es nuestra interfaz de salida a internet]
Nos pedirá un password, nos lo inventamos y lo conservamos en mente (luego será necesario). Ahora iodine se quedará escuchando en el puerto 53 UDP, lo podemos verificar con:
netstat -anup
--------------------------------------------------------------------------------
El cliente
Bien, ahora hemos salido a la calle, y estamos conectados a una red Wi-Fi con portal cautivo que requiere autenticación. Ya hemos asociado y obtenido la configuración de red mediante dhcp.
La tabla de rutas, quedaría algo así:
Código:
Destino Pasarela Genmask Indic Métric Ref Uso Int
10.182.0.0 0.0.0.0 255.254.0.0 U 0 0 0 ath0
0.0.0.0 10.182.1.1 0.0.0.0 UG 0 0 0 ath0
Suponemos la ip del AP es 10.182.1.1
Procedimiento
Eliminamos el default gateway que nos ha asignado, y añadimos entradas manuales para poder acceder a nuestro servidor y a los servidores DNS que nos ha asignado el AP:
Código:
route add -host 77.44.33.22 gw 10.182.1.1
route add -host DNS1 gw 10.182.1.1
route add -host DNS2 gw 10.182.1.1
route del default gw 10.182.1.1
Donde 77.44.33.22 es la IP de foo.comm, y DNS1/2 son los dos servidores de nombres que nos han asignado por dhcp (cat /etc/resolv.conf).
Ahora mismo, mediante el AP sólo podemos comunicarnos con los 2 servidores DNS, y nuestro server.
Nos quedará una tabla similar a esta:
Código:
Destino Pasarela Genmask Indic Métric Ref Uso Int
DNS1 10.182.1.1 255.255.255.255 UGH 0 0 0 ath0
77.44.33.22 10.182.1.1 255.255.255.255 UGH 0 0 0 ath0
DNS2 10.182.1.1 255.255.255.255 UGH 0 0 0 ath0
10.182.0.0 0.0.0.0 255.254.0.0 U 0 0 0 ath0
Ahora iniciamos el cliente de iodine, que se conectará mediante peticiones DNS a nuestro servidor y creará una interfaz virtual dns0.
Código:
iodine -f 94.23.44.214 tunel.foo.com
Como podemos ver automaticamente el servidor iodine nos ha asignado una dirección ip
Código:
ifconfig dns0
...
Direc. inet:10.0.0.3 P-t-P:10.0.0.3 Másc:255.255.255.0
...
Ya tenemos el tunel creado! Podemos utilizar dns0 para comunicarnos con el exterior. Sólo nos falta añadir como ruta por defecto la IP del servidor.
Código:
route add default gw 10.0.0.1
Y nos quedará la tabla así:
Código:
DNS1 10.182.1.1 255.255.255.255 UGH 0 0 0 ath0
77.44.33.22 10.182.1.1 255.255.255.255 UGH 0 0 0 ath0
DNS2 10.182.1.1 255.255.255.255 UGH 0 0 0 ath0
10.182.0.0 0.0.0.0 255.254.0.0 U 0 0 0 ath0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 dns0
0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 dns0
Como resumen, podemos ver que por la interfaz ath0 utilizamos el AP para comunicarnos únicamente con los servidores DNS (las puertas que usamos para llegar hasta iodine), y nuestro server foo.com.
La interfaz dns0 para el resto de peticionies, incluidas las de internet.
Un esquema de como han quedado las conexiones sería este:
Veamos el resultado de un ping
Código:
root@tr4v313r:~# ping google.com
PING google.com (209.85.227.147) 56(84) bytes of data.
64 bytes from wy-in-f147.1e100.net (209.85.227.147): icmp_seq=1 ttl=56
time=865 ms
64 bytes from wy-in-f147.1e100.net (209.85.227.147): icmp_seq=2 ttl=56
time=250 ms
64 bytes from wy-in-f147.1e100.net (209.85.227.147): icmp_seq=3 ttl=56
time=1047 ms
64 bytes from wy-in-f147.1e100.net (209.85.227.147): icmp_seq=4 ttl=56
time=262 ms
Funciona!!
El test adsl de velocidad.info ha dado los siguientes resultados:
Código:
405 Kbit/s bajada
41 Kbit/s subida
No está nada mal!
Iodine nos permite jugar con el tamaño del MTU, podemos hacer varias pruebas para ver cual nos da mejores resultados.
--------------------------------------------------------------------------------
Ética
He disfrazado un poco el artículo para que resulte más "llamativo" e "interesante". Pero el propósito de este no es incitar a hacer nada ilegal. El tunel DNS es una tecnología más que nos proporciona el mundo de la informática. La podemos utilizar en infinitas utilidades prácticas, sin que ello conlleve a vulnerar ninguna ley.
Enlaces:
http://foro.hackhispano.com/showthread.php?t=35763
http://dabax.net/tunel_dns
