Vulnérabilité d'abandon Lindell17 [CVE

Cette vulnérabilité permet à un attaquant d'extraire une clé privée complète d'un portefeuille implémentant le protocole Lindell17 2PC, en extrayant un seul bit à chaque tentative de signature (256 au total). Coinbase WaaS, Zengo et d'autres bibliothèques ont été corrigées.

L'équipe de recherche de Fireblocks a découvert une vulnérabilité dans les déploiements réels du protocole Lindell17 seuil-ECDSA. La vulnérabilité a été découverte à l'interface entre le protocole et l'infrastructure de sécurité plus large, et tous les produits de sécurité basés sur Lindell17 sont potentiellement affectés. Nous avons trouvé plusieurs fournisseurs de portefeuilles en tant que service, de portefeuilles de vente au détail et de bibliothèques open source vulnérables à cette attaque à différents degrés d'exploitabilité.

L'exploit provient d'implémentations de Lindell17 s'écartant des spécifications de l'article universitaire et ignorant ou gérant mal les abandons en cas d'échec des signatures. En supposant un accès privilégié de la part de l'attaquant, la vulnérabilité peut être exploitée pour exfiltrer la clé après environ 200 demandes de signature. La vulnérabilité s'est avérée pratique et validée sur les bibliothèques open source populaires et certains systèmes du monde réel.

Les mises en œuvre pratiques du protocole pour les portefeuilles se heurtent souvent à un dilemme difficile : soit arrêter les opérations après un échec de signature, ce qui pourrait potentiellement entraîner le blocage des fonds, soit poursuivre le processus de signature, risquant ainsi d'exposer des bits de clé supplémentaires à chaque signature.

La vulnérabilité a été initialement découverte dans le portefeuille ZenGo, puis vérifiée dans la bibliothèque Coinbase Wallet as a Service (WaaS), avec d'autres fournisseurs de portefeuille et bibliothèques concernés. Il a également été validé avec un POC fonctionnel dans une implémentation open source commune du protocole (lien ci-dessous). Coinbase et ZenGo ont rapidement atténué le problème dans le cadre de notre processus de divulgation responsable et nous ont assuré qu'ils avaient vérifié et qu'aucun portefeuille n'avait été exploité.

La vulnérabilité permet une extraction complète de la clé privée, permettant aux attaquants de voler tous les fonds du portefeuille crypto. Cependant, il s'agit d'une vulnérabilité asymétrique, ce qui signifie que l'attaquant doit corrompre une partie spécifique pour lancer l'attaque (c'est-à-dire que les parties ne sont pas indiscernables en termes d'attaque).

Pour être plus précis, le protocole Lindell17 est généralement utilisé pour les portefeuilles impliquant un fournisseur de portefeuille et un utilisateur final, la clé secrète sous-jacente étant distribuée entre les deux. De plus, il existe deux configurations possibles pour le portefeuille : soit le fournisseur du portefeuille (Service) finalise la signature, soit l'utilisateur final (Client) le fait à la fin du protocole. La partie chargée de finaliser la signature est celle à risque, et un attaquant peut exploiter cette vulnérabilité en compromettant la contrepartie.

Cas 1.Le serveur finalise la signature

Dans ce cas, l'attaquant peut exfiltrer la clé en compromettant le Client et en envoyant des messages malveillants en son nom. Plus précisément, l'attaquant peut lancer deux cents transactions de telle sorte que, dans chaque session de signature, l'attaquant crée un message malveillant différent qui aboutira à une signature valide uniquement si un bit ciblé du partage secret du serveur est égal à zéro.

Ainsi, selon que le Serveur finalise ou non la signature (l'attaquant obtient cette information soit parce que la signature apparaît ou non sur la Blockchain, soit parce que le Serveur lui-même notifie l'attaquant), l'attaquant obtient un peu de la part du Serveur. . Il peut éventuellement récupérer la clé dans son intégralité après 256 signatures.

Il convient de noter que l'attaque ci-dessus pourrait être accélérée si les demandes de signature peuvent être « blitzées » (rapidement lancées les unes après les autres), ce qui est généralement possible car le serveur est généralement automatisé et ne limite pas de manière significative le nombre de signatures.

Cas 2.Le client finalise la signature

Dans le second cas, en compromettant le serveur et en exécutant l'attaque ci-dessus à l'envers, l'attaquant peut extraire la clé de manière analogue.