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

Fernando Gont fgont at si6networks.com
Tue Jan 29 15:21:22 BRST 2013


On 01/29/2013 01:38 PM, Eduardo Trápani wrote:
>>>> 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).
>>
>> Otra respuesta seria "el advice aplica a cuanto elemento/interfaz te sea
>> reportado por ifconfig/ipconfig"... :-)
> 
> ¿Y eso no equivaldría a deshabilitar completamente IPv6?  ¿Para qué
> enumerar?
> 
> Algo como (Linux):
> 
> ipv6.disable=1 como comando de arranque.

Completanebte de acuerdo. La aclaración de "deshabilitar IPv6 en todas
las interfaces" es porque alguno se podría ver tentado a deshabilitar v6
solo en una interfaz, y no en otras.



>> 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.
> 
> Inútil...  Pero, en la red donde estoy ahora es justamente así.  Todos
> tenemos IPv6, con SLAAC y el RA no anuncia nada más que el prefijo.

Eso de "implementacion de RDNSS no mandatoria para slaac" es, en mi
opinion, productos de debates religioos estupidos en la IETF.


> El resolv.conf en cada equipo ya tiene los valores.  

Asumo que "aprendidos via IPv4"?



>> 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).
> 
> Pero tengo que tener instalado el cliente de DHCPv6.  Sin ese cliente y
> sin el demonio rdnss no se puede.  Digamos que tengo que exponerme a
> propósito.

Yo veo en mi red requests v6 por defecto... IIRC, producto de Windows
7/Vista...  (si, en caso de Linux, te requiere instalar un paquete
aparte.... pero, nuevamente, esto es una tonteria... ya que el paquete
deberia venir instalado por defecto, porque si te conectas a una red
v6-only que usa DHCPv6.. que haces?)



> En Ubuntu el NetworkManager puede procesar el RDNSS por defecto (pero se
> puede apagar), así que depende también del entorno.
> 
> Algo más para agregar a las pautas de seguridad, una vez que procesar el
> RDNSS se vuelva la norma, asegurarse, en los entornos donde esto sea
> válido, que no te cambien el DNS si es estático, por ejemplo dentro de
> una empresa.  Capaz que eso merece un artículo aparte...

Buen punto.



>>> Como todo parece empezar por la preferencia de IPv6 sobre IPv4,
>>
>> 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.
> 
> Sí, está bien.  Yo lo que quiero es que la víctima saque el tráfico para
> afuera.  Pero puede servirme también dar una dirección A, depende de qué
> servicios tenés en la VPN.
> 
> Si tu VPN te da acceso NAT hacia la internet, un A te puede robar
> tráfico igual.
> 
> Si tu VPN no te da acceso a internet, solo a una intranet (como la VPN
> en la que estoy conectado ahora) entonces la ruta por defecto que
> instala la VPN solamente abarca ese espacio de direcciones.  Ahí un A
> modificado te puede sacar a otro lado, evitando esa ruta y robándote
> tráfico.

Asi es.



>>>  Al menos
>>> eso funcionaría para los hosts de destino que no sean IPv6-only y para
> 
> Eso mismo te decía :). Pero, yo entendí en el artículo que el host era
> dual-stack y la VPN solamente manejaba IPv4.

El tema es que esa es la situación de la mayoria de los clientes de vpn
(dicho por el propio director del vpnc.org :-) ).


> En ese caso ni siquiera sé si considerarlo un leak ;),

Lo de leak viene, principalmente, porque uno asume "todo mi trafico var
por la VPN"... pero resulta que como en Internet el trafico puede ser v4
o v6, si tu vpn maneja solo v4, por ejemplo, esa expectativa puede no
cumplirse.



> ese tráfico nunca hubiera podido pasar por
> la VPN.  Aunque te entiendo, la respuesta deseada si tu VPN tiene que
> ser un embudo sería 'host not found'.

Ese es el punto.

Ejemplo tonto: Usualente cuando viajo apra conferencias, tuneleo todo
(con OpenVPN) a través de una VPN con algun equipo conectado "en casa"
(mia, de algun familiar, etc.)... Eso hace que aquel trafico "no seguro"
pueda salir al menos seguro de la conferencia.

AHora bien, si esos destinos pasan a ser dual-stacked, de golpe todo ese
trafico aparece "in the clear".



> Entiendo que hay dos leaks que proponés, el casual, que se mitiga con
> las preferencia de protocolo y el deliberado, que surge de un ataque.
> Para ese segundo caso estaría bueno buscar más maneras para evitar que
> te cambien el DNS.  Deshabilitar IPv6 es una, no tener instalados rndss
> y dhcpv6 puede ser otra y ...
> 
> Y ... llegué a tu misma conclusión, lo más simple es deshabilitar IPv6 :).

Yo hasta hablé con desarrolladores de openvpn, y la respuesta
basicamente fue "evitar esos ataques es un quilombo". :-) Por ende lo
que terminé haciendo fue deshabilitar v6 cuando sabia que iba a ir a una
conferencia... Y lo cierto es que lo termine dejando así (es decir,
terminé no usando v6 en mi maquina).

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







More information about the LACTF mailing list