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. Y otras son 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, mediante un tunel DNS.
|
etiquetas: software libre , seguridad , hacking , dns , linux 
Concretamente este caso concreto tiene un par de puntos flacos:
a) Muchos puntos de acceso no solo sirven de gateway, sino que proveen tambien la resolucion DNS. Eso implica que el administrador de turno pueda bloquear el trafico a servidores DNS externos.
b) Puede ser que haya instalado en la red un sistema IPS que detecte el trafico DNS modificado y lo considere sospechoso, bloqueándolo en consecuencia.
Y en segundo lugar, los portales cautivos requieren de resolución de DNS, ya que sinó cuando desde un cliente web accedes a google.com, este no es capaz de resolver la IP, y tampoco se le podrá redireccionar la petición hacia al portal.
Punto 1:
DNS funciona bajo ambos, me he dejado la regla para UDP, pero es la misma que para TCP
Punto 2:
Se supone que tienes tu propio servidor DNS, evidentemente tienes una regla configurada para que tu DNS pueda salir, pero no permites el tráfico desde cualquier otra ip, daba por sentado que era evidente, pero es tan fácil como poner antes de la regla anteriormente mencionada, la siguiente:
iptables -A OUTPUT -p tcp --dport 53 -s ip_servidor_dns -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -s ip_servidor_dns -j ACCEPT
Lo puedes complicar todo lo que quieras, poniendo direcciones MAC, ESTABLISHED,RELATED, etc ...
Punto 2, si quieres que tu portal cautivo funcione, y quieres dejar únicamente acceso a tu propio servidor dns, este tiene que permitir RECURSIVIDAD, ya que sino, no podría resolver las direcciones como google.com, ebay.es, etc... Y si permite recursividad, entonces sigue siendo vulnerable.
La única solucion es controlar el tráfico DNS (inspeccionar los paquetes), cosa que a la práctica no se hace.
Respecto a lo que me comentas sobre permitir la recursividad en las zonas, eso funcionaría si tu servidor DNS no hiciera cache de las peticiones y te pasara directamente la información tal cual de los servidores raíz, pero eso en la práctica no se hace (o no se debería hacer, ya que incrementas el tráfico hacia afuera).
1. 74.125.77.99 es uno de los servidores DNS de google.
netcat -vv -u 74.125.77.99 53
ew-in-f99.1e100.net [74.125.77.99] 53 (domain) open
netcat -vv 74.125.77.99 53
...
timeout
Como verás, tiene el puerto TCP 53 CERRADO. Por lo tanto da igual que los clientes windows hagan peticiones por TCP, los servidores DNS de internet no las van a resolver...
2. Tu puedes hacer cache de google.com -> XXX.XXX.XXX.XXX pero luego si te piden test.google.com deberá volver a hacer la peticion, y si luego te piden test2.google.com otra vez... Y asís succesivamente, por lo que la cache no sirve de nada.
Y no! tampoco puedes "descargar" de una vez lo referente a todos los subdominios, ese sería un grave fallo de seguridad para un servidor DNS.
Aviso, no he probado el IODine, solo estoy teorizando.
HOlAESTEESUNMENSAJEQUEESTOYENVIANDOAMISERVIDORDNSIONIZADO.foo.com
Entonces? Puedes o no comunicarte con el servidor? Funciona o no con recursividad?
Llegar llegara la peticion, otra cosa es que llegue con el payload o sin el
El artículo muy interesante, y los comentarios también
Meneo
¿No hay este tipo de servidores "en Internet"? ¿Sin tener que crearnos nosotros uno?
Para la gente que en su empresa le han puesto un proxy (le han capado el accedo a ciertas páginas) yo he usado con gran éxito:
www.privoxy.org/
Monta un proxy local tuneleando a tu servidor fuera de la red.
ssh -p80 -ND 1234 usuario@servidor (obviamente el servidor tiene ssh en el puerto 80)
luego configuro un proxy socks v5 en el navegador (localhost:1234) y listo!
www.ultrareach.com/download_en.htm
Doble click y navegando en Windows.
En la guia de especificaciones de implementación de DNS, en el apartado 4.2.2 aparece el texto siguiente:
www.faqs.org/rfcs/rfc1035.html
4.2.2. TCP usage
Messages sent over TCP connections use server port 53 (decimal). The
message is prefixed with a two byte length field which gives the message
length, excluding the two byte length field. This length field allows
the low-level processing to assemble a complete message before beginning
to parse it.
Several connection management policies are recommended:
- The server should not block other activities waiting for TCP
data.
- The server should support multiple connections.
- The server should assume that the client will initiate
connection closing, and should delay closing its end of the
connection until all outstanding client requests have been
satisfied.
- If the server needs to close a dormant connection to reclaim
resources, it should wait until the connection has been idle
for a period on the order of two minutes. In particular, the
server should allow the SOA and AXFR request sequence (which
begins a refresh operation) to be made on a single connection.
Since the server would be unable to answer queries anyway, a
unilateral close or reset may be used instead of a graceful
close.
Read more: www.faqs.org/rfcs/rfc1035.html#ixzz0gSUKtVoG
supongo que queda claro ¿no?
Así que en este caso la regla o cualquier cosa que haga referencia a TCP no sirve para aplicarlo en este caso.