Banner 1

Técnicas de evasión de "portales cautivos" Cap2 (iodine: tunel DNS para saltarnos un portal cautivo)

Publicado por Unknown en 15:16 viernes, 23 de mayo de 2014 Etiquetas: , , , ,
Buenas.

En vista que el anterior post se trataba de técnicas de evasión de portales cautivos y ha sido el capitulo 1, buscando no encontré el capitulo 2 por el mismo autor, lastimosamente al parecer actualmente se encuentra inactivo.

Debo reconocer que tenia muy buenos aportes y en su tiempo siempre leía sus aportes. Como es claro no podemos dejar el tema tirado así que vamos a seguir con una técnica mas "reciente" para saltar los portales cautivos y también sirve para dar Internet gratis en pc y móviles.

_______________________________________________________________________________

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

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.
foo.com -> 77.44.33.22
En la gestión del dominio, tenemos que introducir una entrada del tipo NS:
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:
aptitude install iodine
o descargarlo de la web.

Procedimiento

Iniciamos iodine y activamos forwarding para enrutar las peticiones.
iodined -f 10.0.0.1 tunel.foo.com
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A POSTROUTING -t nat -s 10.0.0.0/24 -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í:
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:
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:
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.
iodine -f 77.44.33.22 tunel.foo.com
Como podemos ver automaticamente el servidor iodine nos ha asignado una dirección ip
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.
route add default gw 10.0.0.1
Y nos quedará la tabla así:
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
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:
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.
Fuente:
http://dabax.net/tunel_dns

Links de interés:
http://dabax.net/tunel_dns
http://www.securitybydefault.com/2013/03/sobre-wifi-robar-y-los-portales-cautivos.html
http://www.securitybydefault.com/2010/01/tunelizando-dns-otra-opcion-con-iodine.html
http://c1b3rh4ck.blogspot.com/2011/10/portal-cautivo-comcel-3g-1-de-2.html
http://foro.hackhispano.com/showthread.php?35768-iodine-tunel-DNS-para-saltarnos-un-portal-cautivo
http://foro.hackhispano.com/showthread.php?35763-IoDine-t%FAnel-DNS-para-saltarse-un-portal-cautivo

No hay comentarios:

Publicar un comentario

Suscribirse a: Enviar comentarios (Atom)
Powered by Bad Robot
Helped by Blackubay