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.
Hacking IPv6 I – Breve introducción al protocolo IPv6
Esta es la primera entrega de una serie de artículos donde se estudiarán diversas técnicas de hacking sobre el protocolo IPv6 en entornos LAN.
Estas entradas pretenden ser una guía didáctica para comenzar a conocer algunos detalles prácticos del protocolo IPv6 con sus riesgos y amenazas. Siempre, por supuesto, desde un punto de vista de Hacking Ético.
Los distintos artículos se irán publicando periódicamente cada varios días. El índice de entradas es el siguiente:
------------------------------------------------------------------------- # 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 - Interceptación de tráfico mediante envenenamiento de caché (MITM) - (2ª parte) # 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 -------------------------------------------------------------------------Todas las entradas (menos esta) tratarán de presentar la información de la forma más práctica posible, ya que creo que es la mejor forma de entender cómo funcionan las cosas. En estos artículos no se considerarán aspectos de seguridad relacionados con la tunelización de tráfico IPv6 e IPv4, el uso de IPsec, o SEcureNeighborDiscovery (SEND).
Comencemos pues con una introducción a los conceptos principales del protocolo.
- Introducción a IPv6
En esta entrada me limitaré a presentar información sobre los conceptos necesarios para entender las entradas que se publicarán más adelante. Si en cualquier momento necesitáis más información sobre el protocolo, podéis encontrarla fácilmente en Internet en multitud de sitios donde se explica el protocolo en profundidad.
Todo apunta a que IPv6 podría empezar a desplegarse en breve en diferentes entornos, sobre todo debido al reciente agotamiento del rango de direcciones públicas IPv4 por parte de IANA. Es posible que con la ayuda de los fabricantes, las distintas operadoras comiencen pronto a usar este protocolo en entornos residenciales. Siendo así, no sería raro que dentro de unos meses comenzaran a distribuirse routers ADSL a los clientes con soporte IPv6 y que comenzara a asignarse direcciones públicas (o rangos de direcciones) IPv6 a estos clientes para aprovisionar sus conexiones. Otro entorno donde puede irrumpir pronto IPv6, es la red LAN de cualquier empresa o cualquier centro universitario que decida en un determinado momento, comenzar a implementar este protocolo. Antes o después, IPv6 acabará desplazando a IPv4, o al menos, esa es la idea.
De hecho, hoy en día, multitud de equipos ya soportan IPv6 para sus comunicaciones. Si vosotros mismos utilizáis un sistema operativo basado en Linux, es posible que ya tengáis una interfaz enviando tráfico IPv6. Y si utilizáis WindowsVista o Windows 7, en ese caso,vuestro equipo ya tiene soporte para IPv6 y estará enviando tráfico IPv6 aunque no lo sepáis.
Teniendo en cuenta los escenarios anteriores, vamos a comenzar con unos conceptos básicos sobre IPv6 que nos ayudarán a entender el resto de las entradas:
-
Direcciones IPv6
Las direcciones IPv6 tienen una longitud de 128 bits. Ejemplo:
1000000000000001:0000110110111000:1010110000010000:1111111000000001:
0000000000000000:0000000000000000:0000000000000000:0000000000000001
Equivalente a: 2001:0DB8:AC10:FE01::1
Uso de Payloads con Unicornscan
Como muchos de vosotros ya sabréis, los escaneos de red de tipo UDP tienen varios inconvenientes.
Debido a las características del propio protocolo UDP, aunque un servicio esté activo y escuchando en una máquina en un determinado puerto, esta máquina no contestará a un mensaje UDP si no tiene el formato esperado por el servicio que está a la escucha. Esto no siempre es así, pero la mayoría de las veces, los servicios no contestarán si no hablas con ellos de la forma esperan.
Por este motivo, puede resultar útil que durante un escaneo UDP, nuestra herramienta nos permita enviar un determinado payload de un servicio que conozcamos.
En este caso, trataremos de descubrir un servicio de Voz IP escuchando en el puerto UDP 5070.
Para ello utilizamos la herramienta Unicornscan.
- Paso 1:
Copiamos un payload de SIP de una captura cualquiera (si no la tenemos podremos recurrir a pcapr).
- Paso 2:
Mediante la herramienta awk podemos modificar el texto obtenido para darle el formato esperado. Por ejemplo, si tenemos en el fichero "payload_sip" el contenido capturado, podemos hacer:
cat payload_sip | awk '{print "\\x"$2"\\x"$3"\\x"$4"\\x"$5"\\x"$6"\\x"$7"\\x"$8"\\x"$9"\\x"$10"\\x"$11"\\x"$12"\\x"$13"\\x"$14"\\x"$15"\\x"$16"\\x"$17}' >> payload_sip2
cat payload_sip2 | awk '{print "\""$1"\""}' > payload_sip
(Seguro que hay métodos más puristas, lo sé J)
- Paso 3:
Añadimos en el fichero de configuración del Unicornscan nuestro payload para el puerto que queramos. Editamos el fichero /etc/unicornscan/payloads.conf y añadimos nuestra información.
La sintaxis utilizada es la siguiente:
/* Comentario */
udp puerto -1 1 {
"payload_a_añadir---"
};
Donde "-1" hace referencia al puerto origen a utilizar al enviar el paquete UDP. Con "-1" le decimos que puede utilizar cualquier puerto origen. El siguiente "1" es el grupo del payload.
Si quisiéramos descubrir un servicio activo de VoIP en un sistema, pero no conocemos el puerto en el que escucha, podríamos modificar el fichero payloads.conf y modificar la sección:
udp -1 -1 1 {
"nuestro_payload"
};
De esta forma, siempre enviará el mismo payload para el rango de puerto que le indiquemos.
- Paso 4:
Probar si funciona:
Antes:
Después:
Pues parece que sí funciona.
La forma de hacerlo con nmap, para la próxima 
Saludos.
EQNTDC[OSPF] Intercambiando rutas entre áreas.
Hace unos días, configurando una red con OSPF me encontré con un pequeño problema al de redistribuir rutas entre diferentes área. Por más que configuraba y revisaba la configuración de los routers no encontraba el motivo del porqué no se intercambiaban correctamente las rutas de OSPF entre diferentes áreas.
Para explicar mejor el problema fijémonos en el siguiente laboratorio, que nos valdrá como ejemplo para este post (Éste ha sido diseñado con Packet Tracert, que solo está disponible a usuarios con cuenta en NetAcad de CISCO, aunque también podéis simularlo utilizando el GNS3).
Figura 1 - Laboratorio OSPF
Aplicando el problema comentado al laboratorio de la Figura 1, nos encontraríamos que Albacete conoce las rutas de las áreas 1 y 2, pero Madrid y Valencia no conocen las rutas de otras áreas que no sea la suya. Podemos ver esto haciendo un show ip route ospf: