Hacking IPv6 III – IPv6 Spoofing in 6in4 tunnels
In this post we will show a real risk that happens today in Intenet related with IPv6 tunnels. We have detected that some of the main 6in4 tunnel providers don't control correctly the IPv6 source filtering in the client access they provide to their clients. This situation leverages a risk that make easy the execution of some attacks that require source IP spoofing.
To help the reader understand the risks that involves IP spoofing in the Internet, below are shown a brief list of attacks that take advantage of this risk:
SYN flooding desde direcciones IP falseadas.
Connection hijacking averiguando el número de secuencia TCP
Bypass firewall
IDLE scan
Smurf attack
DNS Cache Poisoning
...
This assessment is only focused on one type of tunnel, the 6in4 type. These tunnels provide IPv6 access to Internet from a regular IPv4 access. They are usually are free and some of them even allow anonym accesses.
In our oppinion, these tunnels may happen to be a headache form a security point of view in some points of Internet.
Iniqua people have done a brief assessment of the three main IPv6 tunnel provider. The main result of this study was that in no case was the source IPv6 filtering correctly controlled, so they allow users to inject packets with a fake IPv6 source addres.
The following images show some of the results obtained in the study. A regular ICMPv6 "Echo Request" packet is sent first, and later, another one is sent, but this time with a fake source IPv6 address. All these packets are sent to an equipment controlled by the testing team.
- IP Spoofing sent from an access from provider A:
Regular IPv6 source address: 2a01:d0:ffff:141::2
Fake IPv6 source address: 2001:2222:3333:4444:5555:6666:7777:8888 (made up address)

- IP Spoofing sent from an access from provider B:
Regular IPv6 source address: 2001:470:1f08:1812::55
Fake IPv6 source address: 2a00:1450:4001:c01::67 (ipv6.google.com address)
In this case the reader can see an ICMPv6 "Destination Unreachable" packet. This is because of an ICMPv6 Echo Reply unespected packet received.

- IP Spoofing sent from an access from provider C:
Regular IPv6 source address: 2001:5c:0:1400:a:8000:0:580:3aa
Fake IPv6 source address: 2a00:1450:4001:c01::93 (ipv6.google.com address)
In this case, an ICMPv6 "Destination Unreachable" can be observed too.

With this publication we just only wanted to show a real risk related with the incoming of IPv6 to Internet in a practical way. It's not a new vulnerability nor nothing new connected to IPv6 protocol definition. However, we find interesting to notice that IPv6 implies some technological changes that should be considered form a security point of view.
Prior to publish this post, Iniqua team has been in contact with the people form the three providers under study to notice them about this situation. In some cases, the provider was aware of it but the correct filtering wasn't applied because of temporal technical issues.
If any other provider would be interested in knowing about this type of filtering in its networks, Iniqua team would be willing to do the proper testing and help anyone to assess the security of any IPv6 access to Internet.
Conlusion:
The introduction of IPv6 implies some security topics that must be considered as soon as possible to plan and act the better as possible..

------------------------------------------------------------------------
# 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.
Install BackTrack 5 in your hard drive from Windows
Maybe the title is weird. But yes, a operating system can be installed in a real hard disk (Backtrack in this case) within another and asily.
¿Cómo?
Utilizando un sistema de virtualización, como VirtualBox o VMWare, crearemos una máquina virtual que use nuestro disco duro físico real e instalaremos en él el sistema que queramos, como si fuese uno virtualizado, pero lo que instalemos permanecerá en nuestro disco duro real.
How?
Reasons to install BackTrack (or another OS) from a virtual machine:
- No need to burn a CD or copy into a USB.
- No need to reboot the PC.
- You can continue working with your PC while you install/update it.
- Drivers virtualized for VirtualBox or BackTrack are recognised for all OS. This give us the possibility to install drivers after OS are installed (for video cards drivers, for example).
- And... is fun!
What do I need?
- VirtualBox (we will use this for example) ro VMWare.
- Backtrack ISO.
Steps
1 - Create the virtual machine
We create the virtual machine as usual linux. When it ask for hard disk we omit the step:
