{"id":53634,"date":"2019-12-06T00:00:00","date_gmt":"2019-12-05T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/uyazvimost-pozvolyayushhaya-vklinivatsya-v-tcp-soedineniya-osushhestvlyaemye-cherez-vpn-tunneli"},"modified":"2020-02-18T14:01:34","modified_gmt":"2020-02-18T11:01:34","slug":"uyazvimost-pozvolyayushhaya-vklinivatsya-v-tcp-soedineniya-osushhestvlyaemye-cherez-vpn-tunneli","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/uyazvimost-pozvolyayushhaya-vklinivatsya-v-tcp-soedineniya-osushhestvlyaemye-cherez-vpn-tunneli","title":{"rendered":"Vuln\u00e9rabilit\u00e9 permettant de s'immiscer dans les connexions TCP \u00e9tablies via des tunnels VPN","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Publi\u00e9e<\/a><\/noindex> Technique d'attaque (CVE-2019-14899) permettant de substituer, modifier ou ins\u00e9rer des paquets dans des connexions TCP traversant des tunnels VPN. Ce probl\u00e8me touche Linux, FreeBSD, OpenBSD, Android, macOS, iOS et d'autres syst\u00e8mes de type Unix. Linux prend en charge le m\u00e9canisme rp_filter (filtrage de chemin inverse) pour IPv4, dont l'activation en mode \u00ab Strict \u00bb neutralise ce probl\u00e8me. <\/p>\n

Cette m\u00e9thode permet de substituer des paquets au niveau des connexions TCP \u00e0 l'int\u00e9rieur d'un tunnel chiffr\u00e9, mais ne permet pas de s'immiscer dans des connexions utilisant des couches de chiffrement suppl\u00e9mentaires (par exemple, TLS, HTTPS, SSH). Les algorithmes de chiffrement utilis\u00e9s dans les VPN n'ont pas d'importance, car les paquets falsifi\u00e9s proviennent de l'interface externe et sont trait\u00e9s par le noyau comme des paquets de l'interface VPN. La cible la plus probable de l'attaque est l'interf\u00e9rence avec les connexions HTTP non chiffr\u00e9es, mais il ne faut pas exclure<\/a><\/noindex> l'utilisation de l'attaque pour manipuler les r\u00e9ponses DNS. <\/p>\n

Une substitution de paquets r\u00e9ussie a \u00e9t\u00e9 d\u00e9montr\u00e9e pour les tunnels cr\u00e9\u00e9s \u00e0 l'aide de OpenVPN, WireGuard et IKEv2\/IPSec. Tor n'est pas concern\u00e9 par ce probl\u00e8me, car il utilise SOCKS pour le passage du trafic et se lie \u00e0 l'interface loopback. Pour IPv4, l'attaque est possible si rp_filter est r\u00e9gl\u00e9 en mode \u00ab Loose \u00bb (sysctl net.ipv4.conf.all.rp_filter = 2). Au d\u00e9part, la plupart des syst\u00e8mes utilisaient le mode \u00ab Strict \u00bb, mais depuis systemd 240<\/a><\/noindex>, qui a \u00e9t\u00e9 publi\u00e9 en d\u00e9cembre de l'ann\u00e9e derni\u00e8re, le mode par d\u00e9faut a \u00e9t\u00e9 remplac\u00e9 par \u00ab Loose \u00bb, et ce changement est refl\u00e9t\u00e9 dans les r\u00e9glages par d\u00e9faut de nombreuses distributions Linux.<\/p>\n

Le m\u00e9canisme rp_filter utilisons<\/a><\/noindex> pour une v\u00e9rification suppl\u00e9mentaire des chemins de passage des paquets afin de pr\u00e9venir le spoofing de l'adresse source. Lorsque r\u00e9gl\u00e9 \u00e0 0, aucune v\u00e9rification de l'adresse source n'est effectu\u00e9e et tout paquet peut \u00eatre redirig\u00e9 sans restrictions entre les interfaces r\u00e9seau. Le mode 1 \u00ab Strict \u00bb implique une v\u00e9rification de chaque paquet entrant de l'ext\u00e9rieur par rapport \u00e0 la table de routage, et si l'interface r\u00e9seau par laquelle le paquet a \u00e9t\u00e9 re\u00e7u n'est pas li\u00e9e au chemin optimal de livraison de la r\u00e9ponse, le paquet est rejet\u00e9. Le mode 2 \u00ab Loose \u00bb assouplit la v\u00e9rification pour permettre le fonctionnement avec des \u00e9quilibreurs de charge ou une routage asym\u00e9trique, dans lequel
\nla route de r\u00e9ponse peut passer par une interface r\u00e9seau diff\u00e9rente de celle par laquelle le paquet entrant est arriv\u00e9.<\/p>\n

En mode \u00ab Loose \u00bb, un paquet entrant est v\u00e9rifi\u00e9 par rapport \u00e0 la table de routage, mais est consid\u00e9r\u00e9 comme valide si l'adresse source est atteignable par n'importe quelle interface r\u00e9seau existante. L'attaque propos\u00e9e repose sur le fait que l'attaquant peut envoyer un paquet avec une adresse source falsifi\u00e9e correspondant \u00e0 l'interface VPN, et malgr\u00e9 le fait que ce paquet entre dans le syst\u00e8me par une interface r\u00e9seau externe et non par le VPN, en mode rp_filter \u00ab Loose \u00bb, ce paquet ne sera pas rejet\u00e9. <\/p>\n

Pour mener \u00e0 bien l'attaque, l'attaquant doit contr\u00f4ler la passerelle par laquelle l'utilisateur acc\u00e8de au r\u00e9seau (par exemple, via une organisation MITM, lorsque la victime se connecte \u00e0 un point d'acc\u00e8s Wi-Fi contr\u00f4l\u00e9 par l'attaquant ou \u00e0 travers le piratage du routeur<\/a><\/noindex>). En contr\u00f4lant la passerelle \u00e0 laquelle l'utilisateur est connect\u00e9 au r\u00e9seau, l'attaquant peut envoyer des paquets factices, qui seront per\u00e7us dans le contexte de l'interface r\u00e9seau VPN, mais les r\u00e9ponses seront envoy\u00e9es via le tunnel.<\/p>\n

En g\u00e9n\u00e9rant un flux de paquets factices, dans lequel l'adresse IP de l'interface VPN est ins\u00e9r\u00e9e, des tentatives sont faites pour influencer la connexion \u00e9tablie par le client, mais l'observation de l'impact de ces paquets ne peut se faire que par une analyse passive du flux de trafic chiffr\u00e9 associ\u00e9 au fonctionnement du tunnel. Pour mener l'attaque, il est n\u00e9cessaire de conna\u00eetre l'adresse IP du tunnel attribu\u00e9e par le serveur VPN, ainsi que de d\u00e9terminer qu'\u00e0 ce moment, une connexion active \u00e0 un certain h\u00f4te passe par le tunnel. <\/p>\n

Pour d\u00e9terminer l'adresse IP de l'interface r\u00e9seau virtuelle VPN, des paquets SYN-ACK sont envoy\u00e9s au syst\u00e8me victime, en it\u00e9rant progressivement sur toute la plage d'adresses virtuelles (en priorit\u00e9, les adresses utilis\u00e9es par d\u00e9faut dans le VPN, par exemple, dans OpenVPN, le sous-r\u00e9seau 10.8.0.0\/24 est utilis\u00e9). L'existence d'une adresse peut \u00eatre jug\u00e9e sur la base de la r\u00e9ception d'une r\u00e9ponse avec le drapeau RST.<\/p>\n

De la m\u00eame mani\u00e8re, la pr\u00e9sence d'une connexion avec un site sp\u00e9cifique et le num\u00e9ro de port du c\u00f4t\u00e9 client est d\u00e9termin\u00e9e en parcourant les num\u00e9ros de port du c\u00f4t\u00e9 utilisateur en envoyant un paquet SYN, avec l'adresse IP du site en tant qu'adresse source et l'adresse IP virtuelle VPN comme adresse de destination. Le port serveur peut \u00eatre pr\u00e9dit (80 pour HTTP), tandis que le num\u00e9ro de port du c\u00f4t\u00e9 client peut \u00eatre calcul\u00e9 par essai et erreur, en analysant pour diff\u00e9rents num\u00e9ros le changement d'intensit\u00e9 des r\u00e9ponses ACK en combinaison avec l'absence de paquet avec le drapeau RST.<\/p>\n

\u00c0 ce stade, l'attaquant conna\u00eet les quatre \u00e9l\u00e9ments de la connexion (adresses\/port IP source et adresse\/port IP destination), mais pour g\u00e9n\u00e9rer un paquet fictif, que le syst\u00e8me de la victime interpr\u00e9tera, l'attaquant doit d\u00e9terminer les num\u00e9ros de s\u00e9quence et d'accus\u00e9 de r\u00e9ception (seq et ack) de la connexion TCP. Pour d\u00e9finir ces param\u00e8tres, l'attaquant envoie continuellement de faux paquets RST, en essayant diff\u00e9rents num\u00e9ros de s\u00e9quence, jusqu'\u00e0 ce qu'il capture un paquet ACK de r\u00e9ponse, dont la r\u00e9ception indique que le num\u00e9ro se trouve dans la fen\u00eatre TCP. <\/p>\n

Ensuite, l'attaquant v\u00e9rifie la pr\u00e9cision de son identification en envoyant des paquets avec le m\u00eame num\u00e9ro et en observant les ACK- r\u00e9ponses re\u00e7ues, apr\u00e8s quoi il ajuste le num\u00e9ro de la s\u00e9quence actuelle. La t\u00e2che est compliqu\u00e9e par le fait que les r\u00e9ponses sont envoy\u00e9es \u00e0 l'int\u00e9rieur d'un tunnel chiffr\u00e9 et qu'il n'est possible de les analyser dans le flux de trafic intercept\u00e9 que par des m\u00e9thodes indirectes. La r\u00e9alit\u00e9 de l'envoi d'un paquet ACK \u00e0 destination du serveur VPN par le client est d\u00e9termin\u00e9e sur la base de la taille et du d\u00e9lai des r\u00e9ponses chiffr\u00e9es, corr\u00e9l\u00e9es \u00e0 l'envoi de paquets falsifi\u00e9s. Par exemple, pour OpenVPN, un paquet chiffr\u00e9 de taille 79 permet de conclure avec certitude qu'il contient une confirmation ACK.<\/p>\n

Avant que la protection contre l'attaque ne soit ajout\u00e9e au noyau du syst\u00e8me d'exploitation, comme m\u00e9thode temporaire pour bloquer le probl\u00e8me il est recommand\u00e9<\/a><\/noindex> \u00e0 l'aide d'un filtre de paquets dans la cha\u00eene \u00ab preroute \u00bb pour bloquer le passage des paquets dont l'adresse de destination est l'adresse IP virtuelle du tunnel.<\/p>\n

iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! --src-type LOCAL -j DROP<\/p>\n

ou pour nftables<\/p>\n

nft add table ip raw
\n nft add chain ip raw prerouting '{ type filter hook prerouting priority 0; }'
\n nft add rule ip raw prerouting 'iifname != \u00abwg0\u00bb ip daddr 10.182.12.8 fib saddr type != local drop'<\/p>\n

Pour la protection lors de l'utilisation de tunnels avec des adresses IPv4, il suffit de mettre le rp_filter en mode \u00ab Strict \u00bb (en utilisant 'sysctl net.ipv4.conf.all.rp_filter = 1'). Du c\u00f4t\u00e9 VPN, la m\u00e9thode de d\u00e9termination du num\u00e9ro de s\u00e9quence peut \u00eatre bloqu\u00e9e en ajoutant un remplissage suppl\u00e9mentaire aux paquets chiffr\u00e9s, rendant ainsi la taille de tous les paquets identique. <\/p>\n

<\/a><\/noindex><\/p>\n

Source : opennet.ru<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041e\u043f\u0443\u0431\u043b\u0438\u043a\u043e\u0432\u0430\u043d\u0430 \u0442\u0435\u0445\u043d\u0438\u043a\u0430 \u0430\u0442\u0430\u043a\u0438 (CVE-2019-14899), \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0430\u044f \u043f\u043e\u0434\u043c\u0435\u043d\u0438\u0442\u044c, \u0438\u0437\u043c\u0435\u043d\u0438\u0442\u044c \u0438\u043b\u0438 \u043f\u043e\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u043f\u0430\u043a\u0435\u0442\u044b \u0432 TCP-\u0441\u043e\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u044f, \u043f\u0440\u043e\u0431\u0440\u0430\u0441\u044b\u0432\u0430\u0435\u043c\u044b\u0435 \u0447\u0435\u0440\u0435\u0437 VPN-\u0442\u0443\u043d\u043d\u0435\u043b\u0438. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0437\u0430\u0442\u0440\u0430\u0433\u0438\u0432\u0430\u0435\u0442 Linux, FreeBSD, OpenBSD, Android, macOS, iOS \u0438 \u0434\u0440\u0443\u0433\u0438\u0435 Unix-\u043f\u043e\u0434\u043e\u0431\u043d\u044b\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b. Linux \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442 \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c rp_filter (reverse path filtering) \u0434\u043b\u044f IPv4, \u0432\u043a\u043b\u044e\u0447\u0435\u043d\u0438\u0435 \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u0432 \u0440\u0435\u0436\u0438\u043c «Strict» \u043d\u0435\u0439\u0442\u0440\u0430\u043b\u0438\u0437\u0443\u0435\u0442 \u0434\u0430\u043d\u043d\u0443\u044e \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443. \u041c\u0435\u0442\u043e\u0434 \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u0435\u0442 \u043e\u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0438\u0442\u044c \u043f\u043e\u0434\u0441\u0442\u0430\u043d\u043e\u0432\u043a\u0443 \u043f\u0430\u043a\u0435\u0442\u043e\u0432 \u043d\u0430 \u0443\u0440\u043e\u0432\u043d\u0435 TCP-\u0441\u043e\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u0439, \u043f\u0440\u043e\u0445\u043e\u0434\u044f\u0449\u0438\u0445 \u0432\u043d\u0443\u0442\u0440\u0438 \u0448\u0438\u0444\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0433\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-53634","post","type-post","status-publish","format-standard","hentry","category-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47 Vuln\u00e9rabilit\u00e9 permettant de s'immiscer dans les connexions TCP effectu\u00e9es via des tunnels VPN | ProHoster","description":"Une technique d'attaque (CVE-2019-14899) a \u00e9t\u00e9 publi\u00e9e, permettant de falsifier, modifier ou intercaler des paquets.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/news\/uyazvimost-pozvolyayushhaya-vklinivatsya-v-tcp-soedineniya-osushhestvlyaemye-cherez-vpn-tunneli","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0423\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c, \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0430\u044f \u0432\u043a\u043b\u0438\u043d\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0432 TCP-\u0441\u043e\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u044f, \u043e\u0441\u0443\u0449\u0435\u0441\u0442\u0432\u043b\u044f\u0435\u043c\u044b\u0435 \u0447\u0435\u0440\u0435\u0437 VPN-\u0442\u0443\u043d\u043d\u0435\u043b\u0438 | ProHoster","og:description":"\u041e\u043f\u0443\u0431\u043b\u0438\u043a\u043e\u0432\u0430\u043d\u0430 \u0442\u0435\u0445\u043d\u0438\u043a\u0430 \u0430\u0442\u0430\u043a\u0438 (CVE-2019-14899), \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0430\u044f \u043f\u043e\u0434\u043c\u0435\u043d\u0438\u0442\u044c, \u0438\u0437\u043c\u0435\u043d\u0438\u0442\u044c \u0438\u043b\u0438 \u043f\u043e\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u043f\u0430\u043a\u0435\u0442\u044b \u0432.","og:url":"https:\/\/prohoster.info\/fr\/blog\/news\/uyazvimost-pozvolyayushhaya-vklinivatsya-v-tcp-soedineniya-osushhestvlyaemye-cherez-vpn-tunneli","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-12-05T21:00:00+00:00","article:modified_time":"2020-02-18T11:01:34+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"53634","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 08:12:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:21:20","updated":"2026-01-24 08:12:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/53634","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=53634"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/53634\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=53634"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=53634"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=53634"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}