Imaginez perdre tout votre Portefeuille Rabby pas à un lien de phishing, pas à une fausse application, pas même à un moment d'inattention, mais simplement en jouant à un jeu par navigateur pendant dix minutes pendant que votre extension se verrouille silencieusement.
C’est véritablement ce que les chercheurs en sécurité ont découvert enfoui dans l’un des noms les plus fiables dans les extensions de navigateur d’auto-garde.
Aucun clic suspect. Aucun avertissement visible ignoré. Juste un portefeuille, un compte à rebours et une demande de signature que personne n'a jamais vue.
Le bug qui s'est caché à la vue de tous
Le chercheur en sécurité v12sec a présenté la découverte en détail, la décrivant comme une extraction silencieuse de signature conduisant à une fuite complète du portefeuille.
La configuration était d’une simplicité désarmante. Une page malveillante se connecte au portefeuille d'un utilisateur, puis présente quelque chose de complètement banal, en l'occurrence, un jeu par navigateur calqué sur Temple Run. Au démarrage du jeu, la page met silencieusement en file d'attente une demande de signature permettant de vider le portefeuille connecté. C'est ici que cela devient vraiment sournois : un bug contextuel dans Chrome masque entièrement la boîte de dialogue de confirmation, de sorte que l'utilisateur ne voit jamais de demande en attente d'approbation. Après dix minutes, le portefeuille se verrouille automatiquement avec cette demande toujours en attente et, surtout, le verrouillage automatique ne l'annule pas.
Comment la saisie de votre mot de passe est devenue l'approbation
Je pense que c’est la partie de l’exploit qui est vraiment difficile à comprendre. Lorsque l'utilisateur revient finalement et saisit son mot de passe pour simplement déverrouiller son portefeuille, cette entrée de mot de passe elle-même est utilisée comme approbation de la demande en attente. La signature est signée et renvoyée automatiquement à la page malveillante, sans que l'utilisateur ne voie ou ne confirme quoi que ce soit sur lequel il était réellement d'accord.
La cause technique remonte à la manière dont Rabby gère les demandes en attente. Le portefeuille conserve exactement une approbation en vol à la fois, stockée dans un singleton d'arrière-plan appelé notificationService.currentApproval. Lorsque la minuterie de verrouillage automatique se déclenche, la fonction gérant ce verrouillage, setLocked()efface le mot de passe et supprime les trousseaux de clés du portefeuille, mais il ne touche jamais la file d'attente d'approbation située à côté. Il n'y a qu'un seul abonné à l'écoute de cet événement de verrouillage n'importe où dans la base de code, et sa seule tâche consiste à effacer un intervalle d'analyse sans rapport. L'approbation en attente, qui maintient toujours un rappel en direct dans le processus de signature proprement dit, survit simplement au verrouillage intact.
Pourquoi le contrôle de sécurité du portefeuille ne l'a pas détecté
Voici ce que je trouve le plus frappant dans toute cette affaire : Rabby avait en fait construit une garde spécifiquement pour empêcher exactement ce genre de décalage. L'enregistrement correspondant resolveApproval se lit clairement : si un ID d'approbation existe et ne correspond pas à l'ID d'approbation actuel, la fonction renvoie sans rien résoudre. C'est précisément le genre de protection que vous souhaiteriez ici. Le problème est que la vérification ne se déclenche que si un identifiant d'approbation est effectivement transmis en premier lieu, et il s'avère que presque tous les écrans d'approbation de la base de code de Rabby transmettent cet identifiant, sauf un.
L'écran de déverrouillage est le seul écran d'approbation qui appelle resolveApproval() sans pièce d'identité du tout, bien qu'il soit spécifiquement sur liste blanche pour coexister avec d'autres approbations en attente dans la file d'attente. La résolution sans argument donne au processus de signature un résultat indéfini, et parce que les chemins de signature réels ne lisent qu'un fichier spécifique extra propriété de ce résultat, undefined est toléré plutôt que rejeté. Le porte-clés signe quand même. Cela affecte personal_sign et tous les quatre eth_signTypedData variantes, y compris la v4, produisant une signature cryptographiquement valide renvoyée directement au site qui l'a demandé, l'utilisateur n'ayant jamais rien vu ni confirmé.
Un deuxième déclencheur encore plus sournois
Ce qui rend ce cas vraiment préoccupant plutôt qu'un simple cas restreint, c'est qu'il existe une deuxième façon de déclencher exactement la même faille, une qui ne nécessite aucune interaction avec la fenêtre de notification. La fonction de déverrouillage de Rabby est également résolue via un bus d'événements interne via un UNLOCK_WALLET auditeur et appelant wallet.unlock() diffuse cet événement sur chaque surface de l’interface utilisateur simultanément.
Cela signifie déverrouiller Rabby via la fenêtre contextuelle de la barre d'outils, une action normale complètement distincte que la plupart des utilisateurs effectuent des dizaines de fois, invoque handleUnlockSuccess() à l'intérieur d'une fenêtre de notification, l'utilisateur n'a peut-être jamais ouvert ou même connu l'existence, résolvant silencieusement toute demande en attente se trouvant dans cette file d'attente. La fenêtre qui a réellement produit la signature n’est jamais visualisée. Je pense que ce détail est ce qui fait passer cela d'un exploit intelligent à un défaut de conception véritablement grave : le problème central est que le consentement et la demande spécifique à laquelle il est censé s'appliquer n'ont jamais été liés ensemble nulle part dans le système. Un singleton d’arrière-plan détient une approbation. Un verrou détruit les clés de session mais laisse cette approbation là. Un déverrouillage résout tout ce qui se trouve dans la file d'attente sans vérifier quel écran l'a déclenché ou si un utilisateur a réellement confirmé quelque chose. La seule saisie d’un mot de passe correct suffisait pour produire une signature valide.
La réponse de Rabby et la rapidité avec laquelle elle a réellement évolué
Au véritable honneur de Rabby, la réponse a été rapide. v12sec a confirmé que la découverte avait été divulguée le 3 août et que l'équipe de Rabby avait reconnu et corrigé le bug en moins de 24 heures, les chercheurs eux-mêmes examinant ensuite le correctif et confirmant qu'il était efficace.
Le propre compte officiel de Rabby a directement confirmé le correctif, indiquant que la vulnérabilité a été résolue lors de sa découverte et qu'une mise à jour la corrigeant a été publiée le 11 août.
L'équipe a spécifiquement exhorté les utilisateurs à s'assurer que leur extension Rabby est entièrement mise à jour et a confirmé que l'application mobile n'a jamais été affectée par ce problème, puisque l'exploit reposait spécifiquement sur le comportement de l'extension du navigateur.
À quel point devriez-vous réellement vous inquiéter
Je pense qu'il vaut la peine de terminer sur la partie véritablement rassurante de cette histoire, car les conditions requises pour déclencher cet exploit étaient assez étroites. Deux choses devaient être vraies simultanément : le portefeuille devait d'abord être connecté à un site Web malveillant, et l'utilisateur devait avoir modifié manuellement sa minuterie de verrouillage automatique à dix minutes spécifiquement, car aucun autre paramètre de minuterie n'était totalement affecté par cette faille. Rabby et les chercheurs qui l'ont découvert ont confirmé qu'aucun exploit n'avait jamais été détecté dans la nature avant la livraison du correctif.
C’est vraiment une bonne nouvelle, mais je ne pense pas que cela devrait inciter quiconque à se montrer complaisant quant à ce que cette affaire révèle réellement. Un portefeuille entièrement corrigé, construit par une équipe sérieuse, avec un contrôle de sécurité existant spécialement conçu pour empêcher ce scénario précis, avait encore une lacune dans son code aussi longtemps qu'il existait avant que quelqu'un ne le trouve. Si vous utilisez Rabby, la mise à jour de votre extension n'est pas facultative à ce stade, c'est la seule chose qui vous sépare d'un exploit qui ne nécessite rien de plus de la part d'un attaquant que de vous convaincre de jouer à un jeu pendant que l'horloge de votre portefeuille s'épuise tranquillement.
Divulgation : Il ne s’agit pas de conseils en matière de trading ou d’investissement. Faites toujours vos recherches avant d’acheter une crypto-monnaie ou d’investir dans un service. Suivez-nous sur X @nulltxnews