[LAC-TF] [lacnog] Articulo: How to avoid security issues with VPN leaks on dual-stack networks

[Fernando Gont]

Hola, Eduardo,

Gracias por tus comentarios! -- Mis respuestas van entre lineas...


On 01/27/2013 01:36 AM, Eduardo Trápani wrote:
> Lo leí y me quedaron un par de dudas:
> 
>> The simplest option (though not necessarily the most desirable) is to
> disable IPv6 support in all network interface cards when a VPN
> connection is meant to be employed.
> 
> ¿Qué debería entender por "network interface *cards*"?  No me queda
> claro si incluye pseudo interfaces (tipo "tun/tap", que puede ser usado
> por OpenVPN, y que no manejan NICs).

tun/tap viene a ser una interfaz e red virtual, asi que ahí tambien.

Otra respuesta seria "el advice aplica a cuanto elemento/interfaz te sea
reportado por ifconfig/ipconfig"... :-)


>> An attacker could simply pose as the local recursive DNS server by
> sending forged Router Advertisement messages that include the
> corresponding RDNSS option
> 
> ¿Es así de fácil?  Es decir, ¿eso alcanza en algún sistema con una
> instalación "por defecto" para que el sistema olvide su resolv.conf y
> pase a usar el nuevo servidor?  En Linux por lo menos, creo que tenés
> que instalar *y* configurar el demonio rdnssd.

Estoy en un bus en este momento (offline, y con pocos recursos). Pero me
atreveria a decir que los OSes que no habilitan el rocesamiento de RDNSS
"por defecto" lo haran en el corto plazo. -- sin ir mas lejos, SLAAC sin
RDNSS es, salvo para casos puntuales, inutil.

Mas alla de eso, hay otro vector similar para el atacante: enviar RAs
con el bit "M" ("Managed") seteado, de modo que los hosts envien luego
DHCPv6 requests. -- Y luego instalas el "recursive DNS server" via
DHCPv6 (en vez de via SLAAC).



>> If an application at the host attempts to communicate with a
> dual-stacked system, it typically queries both A and AAAA DNS resource
> records <http://whatis.techtarget.com/definition/AAAA-resource-record>.
> If the host supports both IPv4 and IPv6 connectivity but prefers an IPv6
> destination address, even though the other system has both A and AAAA
> DNS resource records, the host will employ IPv6 to communicate with the
> aforementioned system.
> 
> Como todo parece empezar por la preferencia de IPv6 sobre IPv4,

"Si" y "No" al mismo tiempo: si vos podes forgear respuestas DNS (o bien
oficiar de "recursive DNS server"), entonces simplemente podes enviar
registros AAAA (y ningun A), y entonces ya no importa el tema de la
preferencia.

Es mas, en un ataque real, no encuentro mucho argumento para publicar
ambos, si al fin y al cabo lo que vos querés es que la victima use los
AAAA y *no* los A.

Para lo que *si* affecta la preferencia de v6 vs v4 s cuando el VPN-leak
ocurre de manera casual, y no como fruto de actividad maliciosa por
aprte de un atacante (ver debajo).



> ¿podría
> ser una alternativa más (en Linux) el configurar gai.conf (la
> configuración de getaddrinfo) para que se prefiera IPv4[1]? 

Esto es una alternativa para mitigar leaks que ocurren de forma casual,
al visitar destinos dual-stack.

Sin embargo, personalmente no recomendaria esta estrategia: Por ej., si
visitaras un destino v6-only, el leak ocurriria igual.


>  Al menos
> eso funcionaría para los hosts de destino que no sean IPv6-only y para
> las aplicaciones que usen esa biblioteca (me parece que todas las
> ipv6-aware).  Al día de hoy creo que eso puede ayudar a mitigar bastante
> el problema del tráfico ipv6 por afuera de la VPN.  Siempre y cuando lo
> del RDNSS que mencionabas no sea así de fácil, porque ahí podés hacer
> que cualquier host se vea como IPv6-only.

En cuanto llegue a casa voy a ver de hacer algunas pruebas con distintos
OSes -- windows en particular.

Para quien quiera adelantarse :-), esto puede ensayarse con la
herramienta ra6 del IPv6 toolkit: <http://www.si6networks.com/ipv6toolkit>.

Un abrazo, y gracias!
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492