Linux, Unix : importante faille dans les VPN, avec injection de données et vol de session

Linux, Unix : importante faille dans les VPN, avec injection de données et vol de session

Par Sébastien Gavois

Le 09 Décembre 2019 à 09h04
Logiciel
2 min 56

Linux, Unix : importante faille dans les VPN, avec injection de données et vol de session

Elle porte la référence CVE-2019-14899 et pourrait causer de gros dégâts. Ubuntu 19.10, Fedora, Debian 10.2, Manjaro 18.1.1, Arch 2019.05, FreeBSD, OpenBSD… la liste des distributions touchées est longue.

De manière générale, elle concerne tous les systèmes utilisant la configuration par défaut de systemd sorti après le 28 novembre 2018. En cause, le changement d’un paramètre rp_filter de « strict » à « loose »… avec des conséquences en cascades.

« Cette vulnérabilité affecte la plupart des distributions Linux et des systèmes d'exploitation Unix comme FreeBSD, OpenBSD, macOS, iOS, et Android et permet à un attaquant présent dans le réseau local de déterminer si un autre utilisateur est connecté à un VPN, l'adresse IP virtuelle qui lui a été attribuée par le serveur VPN, et s'il y a ou non une connexion active à un site Web donné », explique le portail de cybersécurité des systèmes de santé qui reprend la publication sur Seclists de William J. Tolley, Beau Kujath et Jedidiah R. Crandall.

Le portail ajoute : « De plus, l’attaquant pourrait déterminer les numéros des séquences et d'acquittements des sessions TCP en comptant les paquets chiffrés et/ou en examinant leur taille. Cela lui permet d'injecter des données dans le flux TCP et de voler ces sessions. Ces vulnérabilités concernent OpenVPN, WireGuard et IKEv2/IPSec, mais potentiellement aussi d'autres technologies VPN ».

Les chercheurs donnent plusieurs pistes permettant de limiter les dégâts, notamment activer le reverse path filtering et mettre en place le filtrage Bogon.

Commentaires (56)


KP2
Le 09/12/2019 à 09h29

OpenBSD est touché aussi ?????

Mais il utilise systemd, lui ???



Je trouve ça chelou…


boogieplayer
Le 09/12/2019 à 09h37

Bon, faut déjà être dans le réseau local…


Triton Abonné
Le 09/12/2019 à 09h53

D’après la publication originale:

Here is a list of the operating systems we have tested which are vulnerable to this attack:





  •  Ubuntu 19.10 (systemd)

  •  Fedora (systemd)

  •  Debian 10.2 (systemd)

  •  Arch 2019.05 (systemd)

  •  Manjaro 18.1.1 (systemd)



     



  •  Devuan (sysV init)

  •  MX Linux 19 (Mepis+antiX)

  •  Void Linux (runit)



     



  • Slackware 14.2 (rc.d)

  • Deepin (rc.d)

  • FreeBSD (rc.d)

  • OpenBSD (rc.d)





      This list isn’t exhaustive, and we are continuing to test other distributions, but made sure to cover a variety of init systems to show this is not limited to systemd.



    Par conséquent, la faille n’est pas dans systemd mais est activée par systemd par défaut depuis la mise à jour en question et d’autres systèmes d’init peuvent l’activer (là aussi depuis plus ou moins longtemps).

    De plus, les distribs utilisant systemd mais qui modifient la conf par défaut peuvent aussi être protégées.

     


fred42 Abonné
Le 09/12/2019 à 10h16

C’est le cas de tous les réseaux Wi-Fi public où, justement, il est de bon ton de se protéger par l’utilisation d’un VPN.


boogieplayer
Le 09/12/2019 à 10h18







fred42 a écrit :



C’est le cas de tous les réseaux Wi-Fi public où, justement, il est de bon ton de se protéger par l’utilisation d’un VPN.







Oui, merci de préciser cela.



dylem29 Abonné
Le 09/12/2019 à 10h24

Si l’admin du Wi-Fi public a bien fait son taf, normalement les&nbsp; utilisateurs sont isolés. <img data-src=" />


Kazer2.0 Abonné
Le 09/12/2019 à 10h44

Tu as encore trop foi dans les compétences des prestataires de solution Wi-Fi public toi <img data-src=" />


dylem29 Abonné
Le 09/12/2019 à 10h47

J’ai travaillé pour une start-up qui délivre ce genre de solutions et y’a bcp de turn-over. <img data-src=" />


Bill2
Le 09/12/2019 à 10h51

/ mode troll activé /

M’en fou, chui sous Windaube :)


democrite
Le 09/12/2019 à 10h53

Ils parlent de vpn en TCP. Cela veut dire que en UDP il n’y a pas ce problème ?


crocodudule
Le 09/12/2019 à 11h00

N’étant pas suffisamment pointu sur le sujet, ça veut dire que les machines sous debian 9 utilisant openvpn&nbsp; en udp sont également touchées ?


spidermoon
Le 09/12/2019 à 11h21

C’est la loose <img data-src=" />


OB
Le 09/12/2019 à 11h43







crocodudule a écrit :



N’étant pas suffisamment pointu sur le sujet, ça veut dire que les machines sous debian 9 utilisant openvpn&nbsp; en udp sont également touchées ?





Pour moi le problème concerne la validation de l’adresse source. Donc là ils jouent un peu le catastrophisme avec wiregard, vpn,…. mais à mon sens toute connection TCP ou UDP peux être touchée.



Le RPF est inclus dans linux depuis … pfffff … longtemps , je sais pas trop pourquoi sur le desktop il est pas activé par défaut.



&nbsp;A lire :https://www.slashroot.in/linux-kernel-rpfilter-settings-reverse-path-filtering

Il y 3 valeurs :

0 : Désactivé

1 : Activé strict ( == drop paquet si il arrive pas par l’interface réseau par laquelle il est censé arriver)

2 : Activé loose ( == drop paquet si il arrive pas par l’interface réseau par laquelle il est censé arriver ni par n’importe quelle autre interface avec une route active)



Chez moi, debian 9 je viens de voir que la valeur est à 0.



&nbsp;Après c’est un réglage important pour les routeurs… mais l’exemple pris avec les VPN implique que dans ce cas précis un desktop aurait 2 interfaces actives en même temps, donc …. devient routeur (partiellement, il manquerais notamment ./ipv4/conf/xxxx/forwarding = 1 )



&nbsp;



Juju251 Abonné
Le 09/12/2019 à 11h47

La vache, l’erreur de config par défaut qui fait mal …



Moi qui voulais justement regarder pour configurer un VPN avec Open VPN pour avoir accès à mon réseau local à distance …



Ca va sans doute attendre un peu (au moins que j’aie le temps de lire comment réduire le risque. <img data-src=" />

En attendant le tunneling SSH restera mon copain (même si pour le partage de fichiers Windows ça pose d’autres problèmes). <img data-src=" />


Ricard
Le 09/12/2019 à 11h49







crocodudule a écrit :



N’étant pas suffisamment pointu sur le sujet, ça veut dire que les machines sous debian 9 utilisant openvpn  en udp sont également touchées ?







Pareil, je suis pas (du tout) spécialiste du VPN, mais je crois qu’IKEv2 utilise UDP, et qu’OpenVPN, c’est plutôt TCP. Question de vitesse il me semble… A prendre avec des picettes grosses tenailles.



Ricard
Le 09/12/2019 à 11h52







KP2 a écrit :



OpenBSD est touché aussi ?????







Oui.





Mais il utilise systemd, lui ???





Non.



crocodudule
Le 09/12/2019 à 12h03







Ricard a écrit :



Pareil, je suis pas (du tout) spécialiste du VPN, mais je crois qu’IKEv2 utilise UDP, et qu’OpenVPN, c’est plutôt TCP. Question de vitesse il me semble… A prendre avec des picettes grosses tenailles.





Je pense également ça pour openvpn, l’UDP ne servant qu’au moment de la négociation avec le serveur pour la connexion (du moins je l’ai capté comme ça).



democrite
Le 09/12/2019 à 12h07

Openvpn marche en UDP en général. C’est plus rapide que TCP.


democrite
Le 09/12/2019 à 12h21







crocodudule a écrit :



Je pense également ça pour openvpn, l’UDP ne servant qu’au moment de la négociation avec le serveur pour la connexion (du moins je l’ai capté comme ça).





La négociation se fait uniquement en TCP. UDP ne négocie pas



dada55 Abonné
Le 09/12/2019 à 12h26

<img data-src=" />







Juju251 a écrit :



La vache, l’erreur de config par défaut qui fait mal …



On parle d’ES avec son port ouvert aux quatre vents par défaut ?



NicolBolas
Le 09/12/2019 à 12h26

Pas besoin d’être sur le LAN, un MitM BGP permet d’intercepter le flux, c’est bien pour ça que les préconisations concernent le filtrage des routes - d’ailleurs dans URPF, c’est “Forwarding”, pas “Filtering”.


Juju251 Abonné
Le 09/12/2019 à 13h15







dada55 a écrit :



<img data-src=" />

On parle d’ES avec son port ouvert aux quatre vents par défaut ?





ES ?



boogieplayer
Le 09/12/2019 à 13h23







Juju251 a écrit :



Ca va sans doute attendre un peu (au moins que j’aie le temps de lire comment réduire le risque. <img data-src=" />

En attendant le tunneling SSH restera mon copain (même si pour le partage de fichiers Windows ça pose d’autres problèmes). <img data-src=" />







Si ça peut t’aider :https://mobaxterm.mobatek.net/



crocodudule
Le 09/12/2019 à 14h02







democrite a écrit :



La négociation se fait uniquement en TCP. UDP ne négocie pas





Alors je ne dois pas bien comprendre ce qu’est la phase négociation, j’avais dans l’idée que c’était de dire “coucou je suis un client avec tel certificat” “salut moi je suis un serveur avec tel certificat, on se comprend donc on a la même clef publique et la CA nous a validé donc on peut continuer à papoter” et que cela se faisait sur le seul port ouvert sur le serveur (et en UDP par défaut pour openvpn)



GourouLubrik
Le 09/12/2019 à 14h09







democrite a écrit :



Openvpn marche en UDP en général. C’est plus rapide que TCP.





C’est plus rapide, mais ça passe beaucoup moins bien les proxys (d’entreprise ;))

Du coup il y a encore pas mal d’utilisateurs de VPN en tcp…&nbsp;<img data-src=" />



crocodudule
Le 09/12/2019 à 14h20







GourouLubrik a écrit :



C’est plus rapide, mais ça passe beaucoup moins bien les proxys (d’entreprise ;))

Du coup il y a encore pas mal d’utilisateurs de VPN en tcp…&nbsp;<img data-src=" />





Tu peux faire fonctionner openvpn en TCP (pour être honnête j’ai jamais vu la différence)



sohka
Le 09/12/2019 à 14h29

Elasticsearch


Juju251 Abonné
Le 09/12/2019 à 14h39

Merci, je ne connaissais pas. ;)

Du coup, la config par défaut de ce soft à l’air rock’n roll.


dylem29 Abonné
Le 09/12/2019 à 15h28

C’est avant même ça, c’est genre:





  • Coucou j’aimerai établir une connexion avec toi.

  • Coucou je suis d’accord pour établir cette connexion avec toi.

  • Ok, super.


crocodudule
Le 09/12/2019 à 15h31







dylem29 a écrit :



C’est avant même ça, c’est genre:





  • Coucou j’aimerai établir une connexion avec toi.

  • Coucou je suis d’accord pour établir cette connexion avec toi.

  • Ok, super.





    On dirait un mauvais plan tinder <img data-src=" />



dylem29 Abonné
Le 09/12/2019 à 15h37

Un peu. <img data-src=" />



Mais ça permet de “garantir” la connexion, si des paquets sont perdus, ils sont renvoyés.

L’UDP lui s’en font de ça, il t’envoie les données sans rien vérifier et si jamais un paquet et perdu, tant pis, il est utilisé pour le streaming et les jeux en ligne.


crocodudule
Le 09/12/2019 à 15h39







dylem29 a écrit :



Un peu. <img data-src=" />



Mais ça permet de “garantir” la connexion, si des paquets sont perdus, ils sont renvoyés.

L’UDP lui s’en font de ça, il t’envoie les données sans rien vérifier et si jamais un paquet et perdu, tant pis, il est utilisé pour le streaming et les jeux en ligne.





Merci de ces précisions :)



dylem29 Abonné
Le 09/12/2019 à 15h40

Pas de souci, mais ne prend pas ça comptant, c’est des souvenirs de cours. <img data-src=" />


Winderly Abonné
Le 09/12/2019 à 15h50

”…un attaquant présent dans le réseau local…”

Ouf, j’ai failli avoir peur.


Idiogène
Le 09/12/2019 à 15h56







dylem29 a écrit :



Pas de souci, mais ne prend pas ça comptant, c’est des souvenirs de cours. <img data-src=" />







Le wifi c’est un peu comme UDP. A la différence que le routeur fait un monologue même quand il n’y a personne :




  • “Coucou, moi c’est …SSID…”

  • “Coucou, moi c’est …SSID…”

  • “Coucou, moi c’est …SSID…”

  • “Coucou, moi c’est …SSID…”

  • “Coucou, moi c’est …SSID…”

  • “Coucou, moi c’est …SSID…”

  • “Coucou, moi c’est …SSID…”

    (…)



    -“Non je ne veux pas parler avec toi”

  • “Coucou, moi c’est …SSID…”

  • “Coucou, moi c’est …SSID…”

  • “Coucou, moi c’est …SSID…”

  • “Coucou, moi c’est …SSID…”

  • “Coucou, moi c’est …SSID…”

  • “Coucou, moi c’est …SSID…”



    Bref. <img data-src=" />



dylem29 Abonné
Le 09/12/2019 à 15h58

C’est un peu le harceleur de rue. haha


Idiogène
Le 09/12/2019 à 16h03

Pire : il y a en a maintenant dans les foyers ! <img data-src=" />



Sinon il y a le même problème avec https… au moins la partie quel site visité. D’où le ESNI proposé par cloudflare… c’est la période parano. <img data-src=" />


crocodudule
Le 09/12/2019 à 16h05

C’est le weinstein des réseaux ! Surtout s’ils ont des NAT !


democrite
Le 09/12/2019 à 17h37

Ça c’est du TCP


crocodudule
Le 09/12/2019 à 17h44







democrite a écrit :



Ça c’est du TCP





Mais du coup comment fait le client openvpn pour négocier en TCP avec le serveur openvpn dont seul un port en UDP est accessible depuis l’extérieur ?



dylem29 Abonné
Le 09/12/2019 à 18h08

Bah oui, je le dis que c’est du TCP.



L’UDP il n’y a pas de session.


domFreedom
Le 09/12/2019 à 19h32







Bill2 a écrit :



/ mode troll activé /

M’en fou, chui sous Windaube :)







Windaube, c’est aussi sous SystemV. <img data-src=" />

Enfin, le V, c’est pour les 5 minutes de temps d’accès au bureau après le démarrage… En entreprise, derrière un AD… <img data-src=" /> <img data-src=" />



Quiproquo Abonné
Le 09/12/2019 à 20h20







OB a écrit :



Le RPF est inclus dans linux depuis … pfffff … longtemps , je sais pas trop pourquoi sur le desktop il est pas activé par défaut.







Comme tu le dis plus bas, il n’y a théoriquement aucune raison de l’activer sur le desktop, ce genre de traitement est sensé se faire sur le routeur.



Les auteurs du rapport disent d’ailleurs que c’est probablement une mauvaise piste pour résoudre la faille.



Possible Mitigations:





  1. Turning reverse path filtering on



    Potential problem: Asynchronous routing not reliable on mobile devices,

    etc. Also, it isn’t clear that this is actually a solution since it

    appears to work in other OSes with different networking stacks. Also,

    even with reverse path filtering on strict mode, the first two parts of

    the attack can be completed, allowing the AP to make inferences about

    active connections, and we believe it may be possible to carry out the

    entire attack, but haven’t accomplished this yet.



democrite
Le 10/12/2019 à 00h00







crocodudule a écrit :



Mais du coup comment fait le client openvpn pour négocier en TCP avec le serveur openvpn dont seul un port en UDP est accessible depuis l’extérieur ?





D’abord ils discutent en TCP pour effectuer la connexion et en suite ils établissent un tunnel en UDP et tout se passe dedans .



democrite
Le 10/12/2019 à 05h28

Le serveur Openvpn écoute sur un port TCP , comme tous les serveurs. L’autorisation se passe en TCP,ensuite un tunnel UDP est créé et tout se passe a l’intérieur par la suite. On peut créé un tunnel en TCP mais c’est considérablement plus lent.


Tandhruil
Le 10/12/2019 à 09h11

Ca me rappelle Baldur’s Gate <img data-src=" />



Hé c’est moi Imoen

Hé c’est moi Imoen

Hé c’est moi Imoen

…


ElMarcassin Abonné
Le 10/12/2019 à 09h17

“pour le groupe !”


crocodudule
Le 10/12/2019 à 10h52







democrite a écrit :



D’abord ils discutent en TCP pour effectuer la connexion et en suite ils établissent un tunnel en UDP et tout se passe dedans .





J’ai du mal à suivre, ils peuvent discuter alors que le port est fermé en TCP ? <img data-src=" />



alain_du_lac Abonné
Le 10/12/2019 à 11h50

On m’aurait caché des choses sur la sureté de LINUX ? <img data-src=" />

Comme quoi Windows 10 n’est pas si mauvais en matière de sécurité …


fred42 Abonné
Le 10/12/2019 à 12h32

Il y a beaucoup de routeurs qui tournent sous Windows 10 ?


democrite
Le 11/12/2019 à 06h52







crocodudule a écrit :



J’ai du mal à suivre, ils peuvent discuter alors que le port est fermé en TCP ? <img data-src=" />





Le port est toujours ouvert en TCP.Ils discutent, se reconnaissent et font un tunnel en protocol UDP









Winderly a écrit :



“…un attaquant présent dans le réseau local…”

Ouf, j’ai failli avoir peur.





C’est vrai que les hébergeurs n’ont pas de réseau local. Ton serveur chez eux ne court aucun risque.



Winderly Abonné
Le 11/12/2019 à 15h42

Je n’ai aucun serveur. <img data-src=" />


fred42 Abonné
Le 11/12/2019 à 17h02

Qu’est-ce que tu fous ici alors? <img data-src=" />


Winderly Abonné
Le 11/12/2019 à 17h26

Je viens de relire avec attention la brève à 2 reprises.

Il est bien mentionné “le serveur VPN”.

Mais je trouve que la brève laisse penser que tout le monde peut être victime.



Bref j’ai sans doute mal (ou pas) compris que c’est réservé aux gens ayant au moins un serveur.


fred42 Abonné
Le 11/12/2019 à 18h17

Ma blague est tombée à plat.



Pas grave, tu m’as poussé à aller lire la description complète sur seclists.org, ce que j’avais eu la flemme de faire, la brève étant trop brève pour tout décrire.



Oui, toute machine sous un Linux (ou autre système cité) étant connecté par un VPN (ou autre WireGuard, ou IKEv2/IPSec) peut être vulnérable, pas uniquement un serveur.



Par contre, il est décrit qu’il faut contrôler un AP (point d’accès) pour attaquer alors que la brève dit qu’il faut être dans le même réseau local. Les 2 sont peut-être bien vrais suivant les cas, l’AP étant plus facile puisqu’il voit passer tous les paquets par design mais je pense qu’en étant en écoute de tout ce qui passe dans un réseau Wi-Fi, ça doit être pareil. Par contre, dans un réseau filaire, sur un switch réseau, tu ne peux pas écouter les autres connexions et contrôler le routeur est bien le plus simple (sinon, il faut faire du arp poisoning pour détourner vers le trafic vers ta machine sur le même réseau local).



Fermer