Hacking IPv6 II – Interceptación de tráfico mediante envenenamiento de caché (MITM) – (1ª parte)
Ésta es la segunda entrada de una serie de artículos que tratan de ser un estudio práctico sobre ataques de Hacking en entornos LAN sobre el protocolo IPv6.
------------------------------------------------------------------------ # 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 ------------------------------------------------------------------------En el primer artículo de la serie estuvimos viendo algunos conceptos básicos sobre el protocolo IPv6, necesarios para entender el resto de entregas.
Recordemos que estos artículos no pretenden ser un estudio en profundidad sobre ataques en entornos IPv6. Simplemente intentan ser un primer acercamiento a este nuevo protocolo que todavía resulta ser un gran desconocido para mucha gente. El enfoque de estos artículos es principalmente didáctico para ayudar a entender y aclarar algunos conceptos sobre IPv6.
En este artículo entraremos de lleno sobre el primero de los ataques que veremos a lo largo de las distintas entregas. Este ataque consiste en un ataque de envenenamiento de caché mediante mensajes ICMPv6.
IPv6 es un protocolo de capa 3 del modelo OSI que llegó hace algún tiempo y se presenta como la alternativa a IPv4. En entornos IPv4, cualquier dispositivo que se conecte una red Ethernet, y que desee comunicarse con otro dispositivo de la red, necesita conocer al menos, su dirección de capa de enlace (o dirección MAC).
Los ataques de envenenamiento de caché, consisten en hacer creer a una víctima que la dirección de capa de enlace de un determinado dispositivo de la red, es otra distinta de la que realmente es. El ataque más conocido es el ataque MITM, que conlleva que un atacante pueda interceptar las comunicaciones entre dos dispositivos.
En IPv4, los ataques MITM se realizan mediante mensajes ARP especialmente manipulados. En IPv6, estos ataques se realizan empleando mensajes ICMPv6.
Veamos cómo utilizar ICMPv6 para la ejecución de estos ataques. En condiciones normales, cuando un dispositivo A desea comunicarse con otro dispositivo B, lo primero que debe hacer A es enviar a la red (a una determinada dirección multicast), un mensaje ICMPv6 de tipo "Neighbor Solicitation" preguntando por dirección MAC de B. Acto seguido, B contestará con un mensaje "Neighbor Advertisment" incluyendo en su contenido su dirección MAC de capa de enlace. El dispositivo A guardará en su propia caché esta información durante un tiempo, y la utilizará para construir en adelante los paquetes en Capa 2 que vayan dirigidos a B.
Los ataques de tipo MITM en entornos IPv6, se basan en enviar cada cierto tiempo mensajes de tipo "Nieghbor Advertisment" con información especialmente manipulada hacia las víctimas. El fin último del envío de estos mensajes, es introducir información maliciosa en la caché de las víctimas. De esta forma, las víctimas enviarán sin saberlo el tráfico hacia el atacante.
Después de esta breve introducción teórica sobre los ataques de envenenamiento de caché, pasemos a la parte práctica.
- El entorno sobre el que realizaremos el ataque es el siguiente.
TLS Renegotiation Indication Extension
Marsh Ray y Steve Dispensa han hecho pública la versión 1.1 del documento donde presentan un ataque MiTM basado en la renegociación TLS. En el comienzo del documento podemos leer:
There are three general attacks against HTTPS discussed here, each with slightly
different characteristics, all of which yield the same result: the attacker is able to
execute an HTTP transaction of his choice, authenticated by a legitimate user (the
victim of the MITM attack)
Esta versión del documento se ha traducido en un borrador de IETF:
Internet draft "Transport Layer Security (TLS) Renegotiation Indication Extension"
TLS [RFC5246] allows either the client or the server to initiate renegotiation--a new handshake which establishes new cryptographic parameters. Unfortunately, although the new handshake is carried out over the protected channel established by the original handshake, there is no cryptographic connection between the two. This creates the opportunity for an attack in which the attacker who can intercept a client's transport layer connection can inject traffic of his own as a prefix to the client's interaction with the server. [...] This attack can be prevented by cryptographically binding renegotiation handshakes to the enclosing TLS channel, thus allowing the server to differentiate renegotiation from initial negotiation, as well as preventing renegotiations from being spliced in between connections. An attempt by an attacker to inject himself as described above will result in a mismatch of the extension and can
UPDATE:
Actualización para OpenSSL
Nov 5 17:20:01 2009 openssl-0.9.8l.tar.gz (MD5) (SHA1) (PGP sign) [LATEST]
OpenSSL CHANGES
_______________Changes between 0.9.8k and 0.9.8l [5 Nov 2009]
*) Disable renegotiation completely - this fixes a severe security
problem (CVE-2009-3555) at the cost of breaking all
renegotiation. Renegotiation can be re-enabled by setting
SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION in s3->flags at
run-time. This is really not recommended unless you know what
you're doing.
[Ben Laurie]
Más información en los siguientes enlaces
http://extendedsubset.com/?p=8
http://www.links.org/?p=780
http://sunbeltblog.blogspot.com/2009/11/man-in-middle-attack-uses-ssl.html
http://www.hispasec.com/unaaldia/4030
http://www2.packetstormsecurity.org/cgi-bin/search/search.cgi?searchvalue=renegotiating+tls
Prueba de concepto del ataque: http://packetstormsecurity.org/0911-exploits/ssl-mitm.c