Hacking IPv6 III – IPv6 Spoofing en túneles 6in4
-
------------------------------------------------------------------------
# Hacking IPv6 I - Breve introducción al protocolo IPv6
# Hacking IPv6 II - Interceptación de tráfico mediante envenenamiento de caché (MITM) - (1ª parte)
# Hacking IPv6 III - IPv6 Spoofing en túneles 6in4
# Hacking IPv6 IV - Redirección de tráfico IPv6 mediante el uso de mensajes Router Advertisment(RA)
# Hacking IPv6 V- DoS mediante mensajes Neighbor Solicitation (NS)
# Hacking IPv6 VI - Conclusiones
------------------------------------------------------------------------
Aquellos que sigáis este blog desde hace tiempo, os habréis dado cuenta de que ha habido un cambio respecto a la planificación esperada para la entrega III de esta serie. La razón es simple, tratar de aportar algo que fuera nuevo y más interesante que lo planificado.
En esta entrega vamos a exponer la materialización de un riesgo real actual en Internet relacionado con los túneles IPv6. Concretamente, hemos detectado que algunos de los principales proveedores de túneles 6in4 no controlan adecuadamente el filtrado IPv6 origen en los accesos que aprovisionan a sus clientes. Esta situación genera un nuevo riesgo ya que facilita la ejecución de ataques que requieran de suplantación de dirección IP origen.
Para situar al lector brevemente sobre los riesgos que implica no controlar el IP spoofing en los accesos a Internet, a continuación se muestra una breve lista de ataques que se aprovechan de este riesgo:
SYN flooding desde direcciones IP falseadas.
Connection hijacking averiguando el número de secuencia TCP
Bypass firewall
IDLE scan
Smurf attack
DNS Cache Poisoning
...
Este estudio se limita a un tipo en concreto de túneles IPv6, el 6in4. Estos túneles proveen un acceso IPv6 a Internet desde un acceso común IPv4. Estos accesos suelen ser gratuitos y algunos incluso permiten sesiones anónimas.
Este tipo de túneles puede acabar siendo un quebradero de cabeza desde el punto de vista de la seguridad en distintos ámbitos de Internet.
Los colaboradores de Iniqua han realizado un breve estudio sobre los tres principales proveedores de túneles IPv6 actuales. El resultado de este estudio fue que en ninguno de los tres casos se controlaba adecuadamente el filtrado IP en origen y, por tanto, permitían inyectar tráfico desde sus accesos de cliente con dirección IPv6 origen falsificada.
Las siguientes imágenes muestran evidencias de los resultados positivos obtenidos en cada uno de los tres operadores probados. Primero se envían paquetes ICMPv6 de tipo "Echo Request" con la dirección IP origen legítima a otra máquina controlada por el equipo de pruebas, a continuación se envían paquetes del mismo tipo pero con una dirección IP origen falseada.
- IP Spoofing desde un acceso de cliente del proveedor de túneles A:
Dirección IPv6 origen legítima: 2a01:d0:ffff:141::2
Dirección IPv6 origen falseada: 2001:2222:3333:4444:5555:6666:7777:8888 (dirección inventada)
- IP Spoofing desde un acceso de cliente del proveedor de túneles B:
Dirección IPv6 origen legítima: 2001:470:1f08:1812::55
Dirección IPv6 origen falseada: 2a00:1450:4001:c01::67 (dirección de ipv6.google.com)
En este caso, se puede observar la respuesta con un paquete ICMPv6 de tipo "Destination Unreachable". Esto se debe a que se recibió un paquete ICMPv6 Echo Reply no esperado.
- IP Spoofing desde un acceso de cliente del proveedor de túneles C:
Dirección IPv6 origen legítima: 2001:5c:0:1400:a:8000:0:580:3aa
Dirección IPv6 origen falseada: 2a00:1450:4001:c01::93 (dirección de ipv6.google.com)
En este ejemplo, también se puede observar los paquetes de respuesta de tipo ICMPv6 de tipo "Destination Unreachable".
Con esta publicación, solamente hemos tratado de mostrar de forma práctica un riesgo real de seguridad relacionado la llegada de IPv6. No supone ninguna vulnerabilidad nueva ni nada relacionado directamente con el protocolo IPv6. Sin embargo, sí encontramos interesante destacar que la llegada de IPv6 está suponiendo y supondrá una serie de cambios tecnológicos que deben ser abordados adecuadamente desde el punto de vista de la seguridad.
Previamente a la publicación de esta entrada, el equipo de Iniqua ha estado en contacto con los tres proveedores de túneles estudiados para informar de la situación detectada. En algún caso, el proveedor era consciente de la situación pero por dificultades técnicas transitorias no podían aplicar el filtrado correspondiente.
Si algún otro proveedor de túneles estuviera interesado en conocer el estado de sus accesos de cliente, el equipo de Iniqua está dispuesto repetir esta prueba y colaborar para ayudar a evaluar la seguridad de cualquier acceso IPv6 a Internet.
Conlusión:
La implantación de IPv6 supone una serie de retos de seguridad que deben ser abordados cuanto antes para planificar e implantar medidas de seguridad apropiadas.
Youtube: La guerra de Movistar
El viernes hacia las 11:00, hora española, publican en Banda Ancha la siguiente noticia:
http://bandaancha.eu/articulo/7958/saltarse-capado-movistar-videos-youtube
La noticia indica que, como ya ha ocurrido años atrás, comienzan los problemas para acceder a los contenidos de Youtube desde los accesos de Movistar. Esto lleva a la pregunta "¿Está capando Telefónica a Youtube?". Independientemente de la respuesta que se pueda dar en base a datos del enlace con la cache de Google etc... a nosotros nos interesa, por un lado los DNS de RedIRIS que se proponen como alternativa y si existe un rate-limit. Nuestra intención es aportar algunos datos que creemos son interesantes para cualquier usuario.
La entrada de Bandaancha titula "DNS de RedIRIS: Solución para los problemas de lentitud en los vídeos de Youtube", ante esta afirmación es conveniente estar seguros de qué servidores van a ser los encargados de resolver nuestras consultas DNS. Por ello hemos preparado un pequeño análisis de los servidores DNS; consideremos que es muy interesante conocer el estado de los mismos si van a pasar a ser nuestros "resolvers".[DNS Caché].
El resultado indica que el primero de los DNS es potencialmente peligroso, utilizando un solo puerto para realizar las consultas sobre los servidores autoritarios [Kaminsky]. El segundo sería el recomendable en caso de utilizar estos DNS como solución al problema que indica "Bandaancha".
| IP | Version | Open Emitter | Peticiones | Puertos |
| 193.145.66.2 | "BIND 8.2.4" | yes | 9981 | 1 [32784] |
| 193.146.141.130 | - | yes | 10114 | 2452 [49163-65520] |
Por otro lado nos gustaría mostrar un TEST que hemos realizado desde un acceso de Movistar a distintas horas del día. [Glasnost]. Los resultados no se corresponden con un estudio ni mucho menos, pero muestran que según la herramienta que hemos utilizado no se detecta ninguna influencia sobre el tráfico por parte del operador. Si alguien se anima a realizar el test desde su acceso, por favor, que nos indique en los comentarios los resultados obtenidos (Tipo de acceso, hora).
A continuación algunas capturas de los resultados obtenidos desde accesos ADSL.
Test realizado a las 13:30h. Resultado negativo.
Test realizado a las 17:30h. Resultado negativo.
Test realizado a las 00:00h. Resultado negativo.
Apéndice: Measurement Lab
M-Lab [http://www.measurementlab.net/] es una plataforma pensada para albergar herramientas/proyectos de investigadores. Su objetivo es avanzar en la investigación de la red y proporcionar a los usuarios herramientas que les den información sobre sus conexiones a Internet. En definitiva mantener la transparencia en la red.
Uno de los proyectos albergados en sus servidores es el proyecto “Glasnost” dedicado a realizar pruebas sobre los accesos de cliente. Concretamente analiza posibles “modificaciones” por parte del ISP en el uso de algunos protocolos desde los accesos contratados.
The goal of the Glasnost project is to make ISPs’ traffic shaping policies transparent to their customers. To this end, we designed Glasnost tests that enable you to check whether traffic from your applications is being rate-limited (i.e., throttled) or blocked.
Nos proporciona una serie de protocolos que pueden ser analizados, categorizados como P2P apps, Standard apps y Video-on-Demand. Los protocolos que analiza están relacionados con las transferencias de ficheros, no solo P2P.
Listado de test disponibles.
Eludiendo el filtrado de contenidos web
Muchos de los que nos leéis (y algunas veces nosotros también) tenemos filtrado el acceso a ciertos contenidos web, y no me refiero a páginas de esas "naturistas" de gente con poca ropa.
Cuando quieres entrar a ciertos sitios para leer algún tipo de información o noticia da mucha rabia ver como te han restringido el acceso a esos contenidos, como elhacker.net, ha.ckers.org, etc.
Existen en internet muchas web que se encargan de hacer de proxy por ti y servirte la información, de esta forma no accederemos directamente y evitaremos el filtrado. Nos ha llamado mucho la atención el sitio http://driverzone.nl, que hace de proxy con una transparencia increíble para el usuario.
El susodicho sitio es muy simple de usar. Si accedemos a su web nos encontramos que la interfaz, aunque algo recargada por la publicidad, uso es bastante simple:
