Ledger et Trezor ont appelé à la normalisation de la divulgation des vulnérabilités

Ledger et Trezor ont appelé à la normalisation de la divulgation des vulnérabilités

Le 7 septembre, Charles Guillemot, directeur technique de Ledger, a publié une lettre ouverte proposant que la divulgation coordonnée des vulnérabilités devienne une norme de l'industrie. L'initiative a été soutenue par Trezor, Foundation, AnchorWatch, SEAL et d'autres acteurs du marché.

« L'IA a rendu la recherche de vulnérabilités peu coûteuse, mais elle n'a pas rendu facultative la divulgation responsable », indique le message.

Guillem a décrit un processus de divulgation coordonné standard en quatre étapes : un chercheur signale confidentiellement une vulnérabilité à une entreprise, l'équipe reproduit le problème, le confirme et convient avec l'auteur d'un calendrier de résolution.

    Le CTO de Ledger a suggéré une période de référence de 90 jours, bien que la période puisse varier en fonction de la gravité du bug et de la complexité du correctif. Cependant, pendant la période de correction, les deux parties ne publient pas de détails techniques. Une fois la mise à jour publiée, les informations sont entièrement divulguées et le chercheur reçoit généralement une récompense.

    Selon Guillem, l’essor de l’IA rend cet ordre particulièrement important. Le faible seuil d'entrée permet à des personnes sans expérience en matière de sécurité de l'information de détecter de véritables erreurs, mais certaines d'entre elles publient immédiatement leurs découvertes sur les réseaux sociaux.

    « La sécurité est toujours un jeu du chat et de la souris, mais avec beaucoup plus de chats impliqués, et l'utilisateur en souffre« , —a-t-il souligné.

    Guilmet a identifié trois scénarios problématiques :

    • reproduire une erreur déjà corrigée et la présenter comme une attaque active ;
    • divulgation complète de la vulnérabilité avant la publication du correctif ;
    • publier des teasers comme « une vulnérabilité critique a été trouvée » avec divulgation progressive des détails dans un souci de couverture.

    « Appelez-le par son nom : la recherche de l'attention au détriment du risque d'autrui », écrit le spécialiste.

    Il a qualifié cette pratique de particulièrement dangereuse pour le secteur des cryptomonnaies, où une transaction erronée est généralement irréversible.

    Trois appels aux utilisateurs et aux chercheurs

    Guilmet a adressé son premier appel aux utilisateurs, leur recommandant d'installer les mises à jour du firmware et des applications en temps opportun. Selon lui, les modèles de langage ont réduit l'écart entre la publication d'un correctif et l'apparition d'outils permettant d'exploiter un ancien bug, ce qui rend plus risqué le report des mises à niveau.

    Le deuxième appel s’adresse à de nouveaux chercheurs utilisant l’intelligence artificielle pour trouver des vulnérabilités. Guillem a suggéré que les résultats confirmés soient transmis via des programmes formels de divulgation des fournisseurs. Dans des publications ultérieures, il a demandé que la gravité du problème, les versions du produit concernées et la disponibilité d'un correctif soient immédiatement indiquées.

    « Ce n'est pas de la bureaucratie. « C'est la différence entre rendre l'écosystème plus sécurisé et mettre les utilisateurs en danger pour quelques likes », a déclaré le CTO de Ledger.

    Le troisième appel s'adresse aux entreprises elles-mêmes et aux professionnels de la sécurité. Guillem a suggéré de soutenir publiquement la divulgation coordonnée, de récompenser les chercheurs qui suivent ses règles et de ne pas distribuer de publications qui privilégient la portée plutôt que la sécurité des utilisateurs.

    Réaction de Trezor

    Dans un commentaire à ForkLog, le responsable de la sécurité de Trezor, Jan Komárek, a souligné que la découverte de nouveaux problèmes ne signifie pas en soi un échec de la protection.

    « La sécurité n'est pas un état qui peut être atteint et maintenu une seule fois. C'est un cycle constant : les chercheurs découvrent des problèmes, les fabricants les résolvent, les utilisateurs mettent à jour les logiciels et le système devient plus fiable », a-t-il expliqué.

    Selon Komarek, ce processus échoue lorsque des détails techniques sont publiés avant qu'un correctif ne soit disponible, ou lorsqu'un bug déjà corrigé est présenté comme étant en direct.

    Dans le secteur des cryptomonnaies, les conséquences peuvent s’étendre au-delà de la vulnérabilité elle-même. Les fraudeurs peuvent utiliser la panique qui en résulte à des fins de phishing et se faire passer pour un service d'assistance, demandant aux utilisateurs de « transférer les fonds vers un endroit sûr ».

    « Les dommages secondaires sont régulièrement plus importants que ce que l'erreur elle-même aurait pu causer », a déclaré Komárek.

    Il a également soutenu l'objectif de 90 jours, qualifiant ce délai d'engagement non seulement pour le chercheur, mais aussi pour le fabricant. Selon le spécialiste, si l'entreprise ne résout pas le problème dans les délais convenus, le chercheur devrait avoir le droit de publier les détails techniques.

    Komarek a lié séparément la discussion à un incident sur le réseau liquide sidechain Bitcoin. Le 6 septembre, des inconnus se faisant appeler hackers au chapeau blanc ont retiré environ 4 000 BTC, d'une valeur d'environ 320 millions de dollars, du portefeuille de la Fédération Liquid.

    Selon l'équipe SideSwap, le service a reçu 4 000 L-BTC. Les jetons ont été détruits dans le cadre de la procédure de retrait standard, après quoi la fédération a payé 3996 BTC.

    SideSwap affirme qu'au cours de l'enquête ultérieure, les spécialistes de Blockstream ont découvert un bug dans le logiciel Elements, qui permettait la création de L-BTC sans la garantie Bitcoin correspondante.

    Les participants à l'incident ont déclaré qu'ils restitueraient la plupart des fonds après avoir corrigé l'erreur et mis à jour les nœuds du réseau. Blockstream leur a ensuite envoyé un message signé indiquant que la mise à niveau était terminée et qu'ils étaient prêts à accepter la restitution des actifs.

    « Cela viole les principes de divulgation responsable », a commenté Komárek.

    Polémique sur la divulgation de bogues

    Fin août, la question de la divulgation coordonnée était déjà devenue un point de discorde autour de Ledger. Le 22 août, la société de sécurité IA TestMachine a décrit publiquement la vulnérabilité de l'application Ethereum Ledger.

    Le lendemain, Guillemy a déclaré que l'équipe de Ledger Donjon avait découvert le problème par elle-même et l'avait résolu avant la publication de TestMachine. Selon lui, les chercheurs se sont tournés vers le programme de bug bounty après la publication du correctif et ne se sont pas mis d'accord sur une divulgation publique avec Ledger.

    Le 27 août, l’équipe OneKey Anzen a reproduit l’attaque en laboratoire sur l’application Ledger Ethereum version 1.22.1. En raison d'une condition de concurrence critique, l'appareil pourrait, sous certaines conditions, afficher une transaction et en signer une autre.

    Selon la newsletter Ledger, la version 1.22.2 de l'application Ethereum avec un correctif a été publiée le 13 août. Le 21 août, la société a également éliminé la possibilité d’une telle attaque au niveau du Ledger Secure SDK.

    Rappelons qu'en août, les fabricants de portefeuilles cryptographiques matériels Trezor et Foundation ont averti les utilisateurs des attaques de phishing dans le contexte de l'incident de Coldcard.

    Abonnez-vous à ForkLog sur les réseaux sociaux

    Vous avez trouvé une erreur dans le texte ? Sélectionnez-le et appuyez sur CTRL+ENTRÉE



Voir l’article original en russe

Audible
🎧 Découvrez le plaisir de l’écoute avec Audible d’Amazon ! Cliquez maintenant et obtenez votre premier livre audio GRATUIT. Ne manquez pas cette chance de transformer vos trajets en aventures épiques ! 📚