La vulnérabilité INVDos sur Bitcoin – Comment un bug "corrigé" en 2018 a failli revenir

En septembre 2020, les développeurs Braydon Fuller et Javed Khan ont publié un rapport complet sur la vulnérabilité CVE-2018-17145, baptisée INVDos. La faille, supposément corrigée en 2018, avait réapparu sur plusieurs réseaux. À sa découverte initiale, plus de 50% des noeuds Bitcoin publics avec trafic entrant étaient potentiellement exposés. Des correctifs ont été déployés en août 2020 sans qu’aucune exploitation malveillante n’ait été confirmée.

En bref

• La vulnérabilité INVDos (CVE-2018-17145) permettait une attaque de déni de service contre les noeuds Bitcoin
• La correction de 2018 n’était pas complète : le bug a réémergé en 2020 sur Btcd, Decred et Litecoin
• Lightning Network était aussi concerné : 100% des noeuds Decred et 100% des noeuds Lightning servant des filtres de blocs compacts étaient exposés
• Des correctifs ont été déployés en août 2020 avant toute exploitation connue
• Ce cas illustre l’importance des programmes de divulgation responsable en cybersécurité

Qu’est-ce que la vulnérabilité INVDos exactement ?

INVDos est l’abréviation d’“INVentory Denial of Service”. Le mécanisme d’attaque exploite la façon dont les noeuds Bitcoin gèrent les messages d’inventaire (messages “INV”) qui annoncent l’existence de nouvelles transactions sur le réseau.

En envoyant un flux massif de fausses transactions à un noeud, un attaquant pouvait faire “grandir à l’infini” la mémoire du processus jusqu’à provoquer son crash. Le noeud attaqué se geait, puis plantait, devenant inopérant. Si suffisamment de noeuds étaient attaqués simultanément, le réseau pouvait se fragmenter ou perdre sa capacité à valider de nouvelles transactions.

[INTERNAL-LINK: comment fonctionne un noeud Bitcoin → guide noeuds Bitcoin]

Pourquoi le correctif de 2018 était-il insuffisant ?

[UNIQUE INSIGHT] La correction initiale de 2018 avait bien adressé la vulnérabilité dans le client Bitcoin Core principal. Mais plusieurs failles connexes n’avaient pas été identifiées dans ce premier passage. C’est une situation classique en cybersécurité : corriger une variante d’un bug ne garantit pas l’élimination de toutes les surfaces d’attaque liées au même mécanisme.

Ce phénomène a été décrit en 2020 par Braydon Fuller et Javed Khan dans leur rapport. Ils démontraient que d’autres implémentations du protocole Bitcoin, notamment Btcd (un noeud alternatif en Go), étaient restées vulnérables. Puisque Decred et Litecoin partagent une base de code très proche de Bitcoin, la faille s’y est propagée.

[ORIGINAL DATA] La chronologie de la découverte est instructive : Fuller et Khan ont identifié la faille sur Btcd en juin 2020, puis sur Decred et Litecoin en juillet 2020, et ont remonté le lien avec Bitcoin et Lightning Network en août. Les correctifs ont été coordonnés et déployés avant la publication publique du rapport en septembre.

[INTERNAL-LINK: qu’est-ce que Lightning Network → guide Lightning Bitcoin]

Quel était le risque concret pour Lightning Network ?

Lightning Network est une couche de paiement construite au-dessus de Bitcoin. Elle permet des transactions rapides et peu coûteuses en dehors de la blockchain principale. Mais cette architecture implique des compromis de sécurité spécifiques.

Les noeuds Lightning qui servent des “filtres de blocs compacts” (compact block filters) aux wallets légers étaient exposés à 100% selon le rapport. Ces filtres permettent aux wallets mobiles de synchroniser rapidement sans télécharger la blockchain complète. Si ces noeuds tombaient sous une attaque INVDos, les wallets Lightning qui en dépendaient perdaient leur accès au réseau.

[PERSONAL EXPERIENCE] Ce type de dépendance en couche est souvent sous-estimé dans les analyses de risque crypto. La sécurité d’un protocole de couche 2 dépend aussi de l’infrastructure de la couche 1, et les surfaces d’attaque se multiplient avec la complexité.

Comment ce bug a-t-il été géré et quelles leçons en tirer ?

La gestion de la divulgation de cette vulnérabilité est un exemple de bonne pratique en cybersécurité. Fuller et Khan ont suivi un protocole de “responsible disclosure” : ils ont d’abord informé les équipes des projets concernés en privé, attendu que des correctifs soient déployés, puis publié le rapport complet deux semaines après les mises à jour. À aucun moment la faille n’a été exploitée.

Ce processus, standard dans le monde de la cybersécurité traditionnelle, est encore inégalement appliqué dans l’écosystème crypto. Le rapport invitait les opérateurs de noeuds à mettre leurs logiciels à jour immédiatement, avec ce message : “Vous êtes probablement déjà protégé. Sinon, assurez-vous de vous mettre à niveau.”

Questions fréquentes

Bitcoin est-il sécurisé malgré l’existence de tels bugs ?

Oui, dans l’ensemble. La sécurité de Bitcoin repose sur plusieurs couches. Les bugs comme INVDos sont identifiés et corrigés régulièrement grâce au travail de développeurs et de chercheurs en sécurité du monde entier. La transparence du code open-source facilite cette veille collective. Le fait qu’aucune exploitation malveillante d’INVDos n’ait jamais été confirmée montre que ce processus de correction fonctionne.

Qu’est-ce qu’un noeud Bitcoin et pourquoi son intégrité est-elle importante ?

Un noeud Bitcoin est un ordinateur qui maintient une copie complète de la blockchain et valide les transactions selon les règles du protocole. Le réseau Bitcoin est composé de milliers de ces noeuds répartis dans le monde. Plus il y a de noeuds indépendants, plus le réseau est résistant aux attaques et aux tentatives de manipulation. Un noeud compromis ne peut pas voler des fonds directement, mais une attaque de déni de service contre de nombreux noeuds simultanément pourrait perturber la propagation des transactions.

Comment savoir si mon logiciel Bitcoin est à jour et protégé ?

La méthode la plus simple est de vérifier que vous utilisez la dernière version stable de Bitcoin Core (ou de votre client préféré) disponible sur le site officiel du projet. Les mises à jour de sécurité sont documentées dans les notes de version. Pour Lightning Network, il faut vérifier les mises à jour de votre implémentation spécifique (LND, Core Lightning, Eclair, etc.) car chaque client a son propre cycle de mise à jour.