Audit Least Authority Rabby Wallet (décembre 2024) : Qu’est-ce qu’on a trouvé vraiment ?

En décembre 2024, Least Authority a publié un audit de sécurité complet du portefeuille Rabby Wallet, développé par DeBank. Cet audit représente un exercice de vérification indépendante d’un logiciel critiqué par certains utilisateurs pour son modèle de distribution et loué par d’autres pour sa conception technique. Comprendre ce qu’un audit de cette ampleur révèle réellement exige de dépasser les titres annonçant « aucune vulnérabilité critique » pour examiner les résultats techniques concrets, les corrections appliquées et les implications pour un utilisateur qui gère des actifs numériques sur plusieurs blockchains.

Rabby Wallet, disponible comme extension navigateur pour Chrome, Firefox, Edge et Brave, ainsi que comme application de bureau pour Windows, Mac et Linux, prétend offrir une gestion unifiée de portefeuille avec chiffrement de clés privées sans jamais exposer ces clés en dehors du dispositif de l’utilisateur. L’audit Least Authority était destiné à vérifier si cette promesse technique reposait sur une réalité cryptographique et informatique solide. Les résultats, publiés publiquement, méritent une analyse détaillée plutôt qu’une acceptation superficielle ou un rejet global.

Scope et méthodologie de l’audit Least Authority

Least Authority est un cabinet d’audit de sécurité spécialisé dans l’examen de portefeuilles de cryptomonnaies, de protocoles blockchain et de logiciels critiques pour la garde d’actifs. L’audit de Rabby Wallet couvrait le code source de l’extension navigateur et l’application de bureau, ainsi que les mécanismes de gestion de clés privées, de signature de transactions et d’interaction avec les blockchains. La portée inclure aussi l’analyse des dépendances tierces, des vecteurs d’attaque possibles au niveau du système d’exploitation et des hypothèses de sécurité sous-jacentes au modèle self-custodial du portefeuille.

L’équipe d’audit a examiné comment le portefeuille stocke les clés, chiffre les données sensibles, valide les entrées utilisateur et communique avec les nœuds blockchain. Un aspect critique était la vérification que les clés privées restent bien isolées du processus de signature, c’est-à-dire que même si une partie du code comportait une faille, l’extractabilité directe des clés restait hautement difficile. Least Authority a également testé la robustesse de la génération de nombres aléatoires, la gestion des erreurs lors de la signature et la sécurité du stockage local sur le disque de l’utilisateur.

La méthodologie combinait l’analyse statique (examen du code sans l’exécuter), les tests dynamiques (exécution et analyse du comportement), et la modélisation des menaces. Cela signifie que les auditeurs n’ont pas seulement cherché des bugs évidents, mais ont construit des scénarios hypothétiques : un malware pourrait-il extraire les clés ? Un nœud compromis pourrait-il injecter des transactions malveillantes ? Un attaquant avec accès physique au disque de l’utilisateur pourrait-il casser le chiffrement ? Ces questions définissent la qualité d’un audit crédible.

Résultats techniques : vulnérabilités trouvées et classement

L’audit a identifié un total de 16 problèmes, dont aucun n’a été classé comme critique au sens où il permettrait une compromission immédiate et inévitable des clés privées. Cela ne signifie pas que le portefeuille est « parfait » ou sans risque. Cela signifie que les vulnérabilités découvertes exigeaient généralement des conditions préalables (accès au dispositif de l’utilisateur, exécution de code malveillant spécifique, ou une chaîne d’actions particulière) pour être exploitées.

Parmi les problèmes identifiés figuraient des défaillances de validation d’entrée dans certains champs de formulaires, où des caractères spéciaux n’étaient pas filtrés correctement. Bien que faibles individuellement, ces défaillances pouvaient potentiellement être chaînées dans une attaque plus complexe. Un autre problème concernait la gestion d’erreurs lors de la signature de transactions : dans certains cas rares, le portefeuille ne rejetait pas assez clairement une demande de signature malformée, créant une zone grise où une transaction aurait pu être construite de façon non prévue.

Les problèmes de confidentialité temporelle ont aussi été soulevés. Certain code produisait des bruits de calcul (timing sidechannels) qui, en théorie, pouvaient révéler des informations sur les clés privées à un attaquant capable d’observer le temps exact d’exécution des opérations cryptographiques. Cependant, l’attaque requérait un accès très étroit au dispositif de l’utilisateur et une connaissance préalable du système cryptographique utilisé. Pour un utilisateur ordinaire sans menace adverse spécifique, ce vecteur demeurait hautement théorique.

Corrections appliquées et calendrier de déploiement

DeBank, l’équipe derrière Rabby Wallet, a reçu le rapport d’audit avant sa publication publique et a commencé à appliquer les corrections immédiatement. Le calendrier est important : une vulnérabilité n’est dangereuse que si elle reste exploitable. Le modèle de divulgation responsable utilisé par Least Authority donnait à DeBank le temps de corriger les problèmes avant que les détails techniques ne soient rendus publics, réduisant ainsi la fenêtre pendant laquelle les utilisateurs actifs restaient exposés.

Les corrections ont inclus un renforcement de la validation des entrées, une amélioration de la gestion des erreurs lors de la signature, et l’ajout de protections contre les attaques par canal auxiliaire (constant-time cryptography). DeBank a également mis à jour les dépendances tierces identifiées comme potentiellement vulnérables, bien que cette catégorie soit plus délicate : mettre à jour une dépendance peut résoudre une vulnérabilité mais introduire accidentellement une régression. Les corrections ont été intégrées progressivement dans les versions ultérieures du portefeuille, avec chaque mise à jour déployée automatiquement aux utilisateurs disposant de rabby wallet windows mac linux via les mécanismes de mise à jour du navigateur ou de l’application de bureau.

Un point crucial : même après l’audit et les corrections, Rabby Wallet reste un logiciel. Les logiciels évoluent, les code bases se modifient, et de nouveaux problèmes peuvent émerger. L’audit de décembre 2024 représente une photographie sécuritaire à un instant T, non une garantie perpétuelle. Les utilisateurs doivent continuer à mettre à jour le portefeuille et à suivre les annonces de sécurité de DeBank.

Gestion des clés privées : ce que l’audit a confirmé

Un résultat clé était que Least Authority a confirmé que les clés privées ne quittent jamais le dispositif de l’utilisateur. Cela signifie que même si DeBank voulait y accéder, ou si un serveur DeBank était compromis, les clés résideraient toujours sous le contrôle exclusif de l’utilisateur sur sa machine locale. C’est la promesse fondamentale d’un portefeuille self-custodial, et c’est celle qui méritait vérification.

Le processus de signature des transactions a aussi été audité en détail. Lorsqu’un utilisateur approuve une transaction dans Rabby Wallet, le portefeuille construit la structure de la transaction, la présente à l’utilisateur pour confirmation, puis demande au module de signature local de signer à l’aide de la clé privée. Aucun intermédiaire externe n’intervient dans cette étape. Least Authority a vérifié que cette architecture empêchait des attaques où un serveur intermédiaire aurait pu intercepter la transaction avant signature ou injecter des modifications.

L’isolation de la clé privée repose sur l’hypothèse que le système d’exploitation et le navigateur de l’utilisateur ne sont pas compromis au niveau du kernel. Si un malware installé sur l’ordinateur disposait d’accès administrateur, il pourrait potentiellement lire la mémoire de l’application Rabby Wallet ou le stockage local, et extraire les clés chiffrées. C’est une limite fondamentale de tout portefeuille logiciel : il ne peut pas surpasser la sécurité du système d’exploitation sous-jacent. C’est pourquoi les portefeuilles matériels (hardware wallets) restent préférables pour les fonds très importants, car ils isoles la signature cryptographique sur un circuit dédié inaccessible au système d’exploitation principal.

Simulation de transactions et prévention d’escroqueries

Rabby Wallet incluait une fonctionnalité de simulation de transactions, censée alerter les utilisateurs avant d’approuver des transactions malveillantes ou désavantageuses. L’audit a examiné comment cette simulation fonctionnait techniquement. La simulation appelle un nœud blockchain pour estimer le résultat d’une transaction avant qu’elle ne soit diffusée, permettant d’identifier les cas où un contrat intelligent aurait pu voler des fonds ou produire un résultat inattendu.

Least Authority a confirmé que le mécanisme de simulation existait et fonctionnait généralement comme prévu, mais a aussi identifié ses limites. Une simulation ne peut protéger que contre les attaques que le nœud peut détecter. Si un attaquant construisait une transaction qui paraît inoffensive lors de la simulation mais change de comportement au moment de l’exécution (une attaque appelée MEV ou Miner Extractable Value), la simulation ne la révélerait pas. De plus, la simulation dépend de l’intégrité du nœud blockchain utilisé. Si l’utilisateur se connectait à un nœud compromis, la simulation pourrait être manipulée pour paraître positive alors qu’elle ne l’était pas.

Cet élément de l’audit illustre un principe fondamental : aucun portefeuille ne peut surpasser les limites de la blockchain sous-jacente. La simulation est un outil utile pour les utilisateurs, pas une arme magique contre tous les pièges. Elle réduit les erreurs stupides (envoyer des fonds à un contrat que vous ne comprenez pas), mais ne protège pas contre les escrocs sophistiqués qui dissimulent les véritables termes d’une transaction.

Gestion des tokens et positions DeFi : portée et implications

Rabby Wallet agrégait les positions DeFi (prêts, échanges, pools de liquidité) en une seule interface. L’audit couvrait la façon dont le portefeuille interrogeait les contrats intelligents pour récupérer ces informations. Un risque identifié était que si le portefeuille appelait un nœud compromis ou attaqué, les données de position auraient pu être falsifiées, trompant l’utilisateur sur ses soldes réels.

Least Authority a recommandé des améliorations dans la validation des données retournées par les nœuds, y compris la vérification des valeurs aberrantes et la comparaison des données entre plusieurs sources. DeBank a incorporé ces recommandations dans les mises à jour post-audit. Cependant, un élément demeure inévitable : une interface unifiée de plusieurs blockchains dépend de sources de données externes. Rabby Wallet ne peut jamais être plus sûr que les nœuds auprès desquels il demande des informations, sauf si l’utilisateur configure un nœud privé personnel.

Architecture open-source et implications pour la confiance

Rabby Wallet est open-source, ce qui signifie que n’importe qui peut examiner le code avant de l’utiliser. C’est un point majeur pour la confiance en sécurité. Cependant, l’open-source ne résout pas le problème de la distribution binaire. Un utilisateur qui télécharge l’extension navigateur depuis le Chrome Web Store ou l’application de bureau depuis le site officiel fait confiance à plusieurs couches : que le code distribué correspond au code source publié, que les dépendances compilées ont été construites fidèlement, et que les serveurs de distribution n’ont pas été compromis.

L’audit Least Authority a inclus une vérification que le code source auditée correspondait aux binaires déployés, dans la limite de ce qui est possible. Cependant, les utilisateurs techniques qui veulent une confiance maximale pourraient compiler eux-mêmes le portefeuille à partir du code source. C’est un processus avancé et peu d’utilisateurs le font, mais le potentiel existe, ce qui représente un avantage de l’open-source qu’un portefeuille fermé ne peut pas offrir.

L’open-source crée aussi un bénéfice secondaire : si une nouvelle vulnérabilité était découverte, n’importe quel chercheur en sécurité indépendant pourrait l’identifier et la signaler, plutôt que d’être confiné à un processus interne de l’entreprise. Cette forme de contrôle décentralisé améliore la probabilité que les bugs graves soient détectés, même après la publication initiale de l’audit.

Implications pratiques pour les utilisateurs : risque résiduel et bonnes pratiques

Un audit favorable ne signifie pas que Rabby Wallet est exempt de risque. Cela signifie que les risques identifiés sont contrôlés à un niveau technique raisonnablement bon, compte tenu des contraintes inhérentes au logiciel. Le risque résiduel provient de plusieurs sources. Premièrement, un utilisateur qui installe un malware sur son ordinateur s’expose à tous les portefeuilles logiciels. Deuxièmement, la perte ou l’exposition de la graine de récupération (seed phrase) reste la vulnérabilité la plus probable. Troisièmement, approuver par erreur une transaction malveillante reste possible, même si la simulation de Rabby aide à réduire ce risque.

Les bonnes pratiques demeurent incontournables. Les utilisateurs doivent conserver leur seed phrase hors ligne, ne jamais la partager, maintenir le système d’exploitation à jour, utiliser un antivirus à jour, et ne pas installer d’extensions navigateur suspectes aux côtés de Rabby Wallet. Pour les fonds considérables, l’option de connecter un portefeuille matériel (Ledger, Trezor) à Rabby Wallet offre une couche d’isolation supplémentaire : les clés privées résident sur le périphérique matériel, tandis que Rabby Wallet ne gère que la construction et la signature des transactions.

La simulation de transactions doit être utilisée comme un filet de sécurité supplémentaire, pas comme une garantie. Si une transaction paraît suspecte, l’approuver n’est jamais obligatoire. La patience face à une transaction proposée par un service peu connu ou mal compris réduit le risque accidentel bien plus que toute fonctionnalité automatisée ne peut.

Évolutions post-audit et transparence continue

Depuis la publication de l’audit en décembre 2024, DeBank a continué à communiquer sur les mises à jour de sécurité. La transparence publique du rapport complet (plutôt que simplement un résumé marketing) renforce la crédibilité. Un auditeur réputé qui publie ses résultats s’expose à des critiques si les découvertes s’avéraient superficielles, ce qui crée une incitation à la rigueur.

Cependant, un audit unique, aussi bon soit-il, ne suffit pas. DeBank devrait envisager des audits réguliers ou continus, en particulier après les modifications majeures du code. La sécurité du logiciel n’est pas une destination, mais un processus. Les utilisateurs qui dépendent fortement de Rabby Wallet pour gérer des actifs importants sur plusieurs blockchains feraient bien de suivre les annonces de sécurité de DeBank et d’examiner les notes de mise à jour pour les corrections de vulnérabilités.

L’existence d’un audit crédible comme celui de Least Authority élève également la barre concurrentielle pour d’autres portefeuilles. Si un concurrent refuse de se soumettre à un audit indépendant ou reste flou sur les résultats, c’est un signal d’alerte utile. Rabby Wallet, par son audit public, offre un repère auquel comparer d’autres solutions.