An alternative approach to so-called WebRTC leaks : VPN
jeudi 5 novembre 2015 à 02:35GuiGui's Show - Liens
Ha, tout ce bruit autour de la faille webrtc... Je n'y ai jamais cru (car pas logique techniquement) et vu que mon navigateur n'était pas faillible selon différents checks en ligne, je ne m'étais jamais penché dessus à fond. Sauf qu'hier, j'ai vu un cas d'un VPN OpenVPN avec lequel les checks affichent la vraie IP publique. :o
Souvenez-vous de vos cours SIP (pour ceux/celles qui en ont eu) : les sessions médias (audio/vidéo) ne passent pas par le serveur SIP (signalisation uniquement) pour éviter la charge mais s'établissent en direct. Sauf qu'avec les différents types de NAT et de filtrages baaaah ça marche pas... L'idée d'ICE (http://www.bortzmeyer.org/5245.html) est de ne poser aucune hypothèse et d'essayer plusieurs méthodes de traversée de NAT et se mettre d'accord pour trouver un chemin entre nous et le pair avec qui ont veut causer...
Première étape : lister toutes les interfaces réseaux disponibles. Un « ip link show » quoi. Si vous avez une IP publique c'est-à-dire soit une IPv6 par votre FAI ou par un tunnel broker et/ou une IPv4 publique (université, labo de recherche, certaines entreprises), ne cherchez pas plus loin : votre IP apparaîtra dans les checks en ligne.
Vous ne me croyez pas ? Assignez une IP non RFC1918 mais réservée au benchmark/documentation (198.18.0.X/24 ou 192.0.2.X/24, par exemple) sur une interface, même une interface down : le check va vous la remonter alors que c'est IP ne sont pas routables sur Internet. À ce stade, venir causer de faille du VPN utilisé ou de STUN, c'est ridicule au possible : ils ne sont pas concernés et c'est le but même d'ICE que de découvrir les différents canaux où un échange pourrait avoir lieu.
On notera qu'avant la version 43 de Firefox, la seule manière d'interdire ce listing, c'était de désactiver totalement webrtc en passant « media.peerconnection.enabled » à false. À partir de la version 43, on a de nouveaux paramètres plus fins (voir https://wiki.mozilla.org/Media/WebRTC/Privacy), dont « media.peerconnection.ice.force_interface » qui permet de spécifier la seule interface réseau à utiliser... On met tun0 et hooop, plus de fuite.
Oui, mais tout le monde n'a pas une IP publique sur sa machine alors qu'il y a beaucoup de témoignages positifs sur le web... La vérité est ailleurs.
Deuxième étape : pour chaque IP récoltée, publique ou privée, le navigateur tente de joindre un serveur STUN qui lui retournera l'IP source de laquelle il a reçu le paquet du client. Ça permet de débusquer les NAT (oui, même avec des IP publiques sur sa machine, on peut avoir du NAT en frontal). C'est là que ça devient intéressant.
Le navigateur forge des paquets en mettant chaque IP qu'il a trouvé en IP source puis les envoie. Il est contraint de suivre la table de routage et donc les routes /1 plus spécifiques qu'OpenVPN ajoutent dans la conf' la plus répandue (« redirect-gateway def1 ») l'emportent... et les paquets sont émis sur la tun. Échec, la véritable IP de l'utilisateur sera masquée (parce qu'OpenVPN jettera le paquet grâce à son mécanisme d'iroute (https://wiki.ldn-fai.net/wiki/Tuto_Serveur_OpenVPN#Notion_de_route_interne_.28iroute.29), parce que le presta VPN applique BCP38 (http://www.bortzmeyer.org/usurpation-adresse-ip.html), parce qu'une IP RFC1918 ne sera pas routée au delà du presta VPN,...).
Mais on se dit que ping est capable d'émettre avec une IP/interface bien précise genre ping -I eth0 89.234.141.64. Le paquet bypass le VPN et sort par eth0. Deux conditions pour que ça fonctionne :
* Il faut qu'il y ait une route englobant l'IP du serveur STUN (ou, dans l'exemple ci-dessous, de la mire utilisée par ping) accrochée à l'interface. C'est automatiquement le cas avec « redirect-gateway def1 » : eth0 (ou wlan0 si connexion WiFi) a toujours la route par défaut ;
* Il faut avoir la bonne capabilitie ou être exécuté en root. ping est setuid ;) . Essayez curl --interface eth0 http://lehollandaisvolant.net/tout/ip/ puis la même préfixée par sudo, vous verrez.
Donc tout ça ne peut pas fonctionner sous GNU/Linux. \o/
En revanche, sur winwin, ça fonctionne plus souvent si l'on en croit les témoignages sur le web. Soit n'importe quel soft peut émettre sur n'importe quelle interface réseau sans avoir besoin de droits spécifiques, soit il faut être administrateur et vu la proportion du parc winwin qui tourne en permanence en administrateur, faut pas s'étonner...
Qu'en retenir ? Qu'un navigateur sur un système bien conçu avec un VPN correctement configuré chez un presta bien foutu et un pare-feu qui drop tout ce qui sort sans passer par le VPN, ne fait pas fuiter la véritable IP. Sauf si vous avez des IPs publiques sur votre machine. Tout ce bruit pour un système mal fichu...
Et pour le cas qui m'a amené à me pencher sur tout ça ? IPv4 publique sur eth0 puisque sur un réseau universitaire.
(Permalink)
Ha, tout ce bruit autour de la faille webrtc... Je n'y ai jamais cru (car pas logique techniquement) et vu que mon navigateur n'était pas faillible selon différents checks en ligne, je ne m'étais jamais penché dessus à fond. Sauf qu'hier, j'ai vu un cas d'un VPN OpenVPN avec lequel les checks affichent la vraie IP publique. :o
Souvenez-vous de vos cours SIP (pour ceux/celles qui en ont eu) : les sessions médias (audio/vidéo) ne passent pas par le serveur SIP (signalisation uniquement) pour éviter la charge mais s'établissent en direct. Sauf qu'avec les différents types de NAT et de filtrages baaaah ça marche pas... L'idée d'ICE (http://www.bortzmeyer.org/5245.html) est de ne poser aucune hypothèse et d'essayer plusieurs méthodes de traversée de NAT et se mettre d'accord pour trouver un chemin entre nous et le pair avec qui ont veut causer...
Première étape : lister toutes les interfaces réseaux disponibles. Un « ip link show » quoi. Si vous avez une IP publique c'est-à-dire soit une IPv6 par votre FAI ou par un tunnel broker et/ou une IPv4 publique (université, labo de recherche, certaines entreprises), ne cherchez pas plus loin : votre IP apparaîtra dans les checks en ligne.
Vous ne me croyez pas ? Assignez une IP non RFC1918 mais réservée au benchmark/documentation (198.18.0.X/24 ou 192.0.2.X/24, par exemple) sur une interface, même une interface down : le check va vous la remonter alors que c'est IP ne sont pas routables sur Internet. À ce stade, venir causer de faille du VPN utilisé ou de STUN, c'est ridicule au possible : ils ne sont pas concernés et c'est le but même d'ICE que de découvrir les différents canaux où un échange pourrait avoir lieu.
On notera qu'avant la version 43 de Firefox, la seule manière d'interdire ce listing, c'était de désactiver totalement webrtc en passant « media.peerconnection.enabled » à false. À partir de la version 43, on a de nouveaux paramètres plus fins (voir https://wiki.mozilla.org/Media/WebRTC/Privacy), dont « media.peerconnection.ice.force_interface » qui permet de spécifier la seule interface réseau à utiliser... On met tun0 et hooop, plus de fuite.
Oui, mais tout le monde n'a pas une IP publique sur sa machine alors qu'il y a beaucoup de témoignages positifs sur le web... La vérité est ailleurs.
Deuxième étape : pour chaque IP récoltée, publique ou privée, le navigateur tente de joindre un serveur STUN qui lui retournera l'IP source de laquelle il a reçu le paquet du client. Ça permet de débusquer les NAT (oui, même avec des IP publiques sur sa machine, on peut avoir du NAT en frontal). C'est là que ça devient intéressant.
Le navigateur forge des paquets en mettant chaque IP qu'il a trouvé en IP source puis les envoie. Il est contraint de suivre la table de routage et donc les routes /1 plus spécifiques qu'OpenVPN ajoutent dans la conf' la plus répandue (« redirect-gateway def1 ») l'emportent... et les paquets sont émis sur la tun. Échec, la véritable IP de l'utilisateur sera masquée (parce qu'OpenVPN jettera le paquet grâce à son mécanisme d'iroute (https://wiki.ldn-fai.net/wiki/Tuto_Serveur_OpenVPN#Notion_de_route_interne_.28iroute.29), parce que le presta VPN applique BCP38 (http://www.bortzmeyer.org/usurpation-adresse-ip.html), parce qu'une IP RFC1918 ne sera pas routée au delà du presta VPN,...).
Mais on se dit que ping est capable d'émettre avec une IP/interface bien précise genre ping -I eth0 89.234.141.64. Le paquet bypass le VPN et sort par eth0. Deux conditions pour que ça fonctionne :
* Il faut qu'il y ait une route englobant l'IP du serveur STUN (ou, dans l'exemple ci-dessous, de la mire utilisée par ping) accrochée à l'interface. C'est automatiquement le cas avec « redirect-gateway def1 » : eth0 (ou wlan0 si connexion WiFi) a toujours la route par défaut ;
* Il faut avoir la bonne capabilitie ou être exécuté en root. ping est setuid ;) . Essayez curl --interface eth0 http://lehollandaisvolant.net/tout/ip/ puis la même préfixée par sudo, vous verrez.
Donc tout ça ne peut pas fonctionner sous GNU/Linux. \o/
En revanche, sur winwin, ça fonctionne plus souvent si l'on en croit les témoignages sur le web. Soit n'importe quel soft peut émettre sur n'importe quelle interface réseau sans avoir besoin de droits spécifiques, soit il faut être administrateur et vu la proportion du parc winwin qui tourne en permanence en administrateur, faut pas s'étonner...
Qu'en retenir ? Qu'un navigateur sur un système bien conçu avec un VPN correctement configuré chez un presta bien foutu et un pare-feu qui drop tout ce qui sort sans passer par le VPN, ne fait pas fuiter la véritable IP. Sauf si vous avez des IPs publiques sur votre machine. Tout ce bruit pour un système mal fichu...
Et pour le cas qui m'a amené à me pencher sur tout ça ? IPv4 publique sur eth0 puisque sur un réseau universitaire.
(Permalink)