LavaMoat et l'attaque de la chaîne d'approvisionnement logicielle de Ledger

Que s'est-il passé ?

Le 14 décembre, l'une des bibliothèques logicielles de Ledger, Ledger Connect Kit, a été la cible d'une attaque sur la chaîne d'approvisionnement logicielle.

La compromission aurait pour origine un ancien employé qui, disposant toujours d'un accès de publication, a été victime d'une attaque de phishing. Cette attaque a compromis ses identifiants npm. npm, ou Node Package Manager, est un outil permettant d'importer des bibliothèques logicielles open source, largement utilisé dans le secteur du développement web ainsi que dans le web3.

Cette attaque a permis la publication d'une version malveillante de la bibliothèque en question. Cette bibliothèque est intégrée de manière dynamique via un réseau de diffusion de contenu (CDN) dans de nombreuses applications web de l'écosystème Ethereum. Cela a entraîné l'injection de code malveillant dans ces applications web.

Comment prévenir cela ? LavaMoat.

LavaMoat est un ensemble d'outils conçus spécifiquement pour aider à résoudre les problèmes de sécurité de la chaîne d'approvisionnement logicielle auxquels font face les développeurs d'applications web.

LavaMoat offre des protections contre les attaques sur la chaîne d'approvisionnement à trois moments distincts du cycle de développement logiciel : au moment de l'installation des dépendances (lorsque vous importez toutes ces bibliothèques), lors de la compilation (lorsque l'application est préparée pour être servie sur Internet), et à l'exécution (lorsque l'application compilée est en cours d'exécution).

LavaMoat se distingue par ses protections à l'exécution. D'autres outils peuvent être utilisés pendant le développement, comme snyk.io, qui ne fournit que des avertissements sur les vulnérabilités connues, ou socket.dev, qui propose une analyse de code plus complète et n'attend pas que des experts signalent leurs découvertes à une base de données centrale. Ces outils d'analyse jouent un rôle inestimable, et nous vous recommandons d'utiliser l'intégration GitHub de socket.dev.

Cependant, ils sont incapables de fournir des garanties à l'exécution. Pour cette raison, nous estimons qu'il est insuffisant de s'appuyer uniquement sur eux.

Les protections de sécurité de LavaMoat reposent sur le principe de délégation exclusive de capacités spécifiées aux dépendances de votre application.

Qu'est-ce que cela signifie ? Lisez la suite et consultez notre conférence Devcon 6 pour mieux comprendre le fonctionnement de LavaMoat et son utilisation.

Introduction au modèle de capacités objet

Vous pouvez concevoir un système comme possédant des capacités : des actions qu'il peut effectuer, comme afficher des informations, lire des données stockées localement, ou envoyer des requêtes à d'autres systèmes tels que des requêtes web vers des serveurs ou des demandes de transactions vers des portefeuilles, ainsi que la capacité de déléguer ces capacités à d'autres.

Lors de la délégation d'une capacité, vous pouvez en fournir une version limitée ou restreinte. C'est ce qu'on appelle l'atténuation.

Ces trois composantes constituent la base du modèle de sécurité par capacités objet. En utilisant ce modèle, vous pouvez comprendre qui a la capacité de faire quoi.

Sécurité des applications web

Les navigateurs font un travail correct pour isoler les applications dans des environnements sandbox, c'est-à-dire les maintenir séparées et les empêcher d'interférer avec votre ordinateur ou d'autres sites web.

Cependant, ils ne fournissent pas de blocs de construction robustes permettant aux développeurs d'applications web d'isoler davantage des portions spécifiques de leur application, ce qui pourrait empêcher certains composants de compromettre l'ensemble de l'application.

Pour cette raison, lorsque vous importez une bibliothèque dans votre application, vous déléguez effectivement toutes les capacités à cette bibliothèque. Cela est encore compliqué par le fait que la plupart des bibliothèques JavaScript n'apportent pas seulement leur propre code, mais un ensemble de bibliothèques écrites par divers auteurs.

Détails de l'attaque Ledger

La bibliothèque @ledger/connect-kit-loader est la méthode recommandée par Ledger pour s'intégrer à leurs produits. Ce package est une fine couche d'encapsulation qui charge la dernière version de leur bibliothèque depuis un CDN.

Bien que cela signifie que votre application disposera toujours de la dernière version de la bibliothèque, cela implique également que vous déléguez effectivement le contrôle de votre application web à la bibliothèque de chargement Ledger, qui à son tour le délègue au code hébergé sur le CDN.

Vous pouvez modéliser la chaîne de délégation ainsi :

Application web → **@ledger/connect-kit-loader** → jsDelivr CDN → npm → Ledger → ex-employé Ledger → attaquant

Même ceci est une simplification. En zoomant sur un composant, comme le CDN jsDelivr, on peut découvrir une complexité impressionnante de services supplémentaires qui font également partie de la chaîne d'approvisionnement et constituent des points d'entrée potentiels pour lancer une attaque.

Sécuriser les applications avec la sécurité par capacités objet

Bien que les navigateurs eux-mêmes ne fournissent pas beaucoup d'outils, comme mentionné, pour limiter les capacités des sous-composants d'une application, le langage JavaScript est en réalité bien adapté à cette tâche.

JavaScript, avec un effort minutieux, vous permet de construire des Compartiments, qui limitent ce à quoi le code est autorisé à accéder. Consultez l'initiative Hardened Javascript d'Agoric pour une implémentation des Compartiments.

Le système de sécurité de la chaîne d'approvisionnement LavaMoat de MetaMask et le système de plugins MetaMask Snaps s'appuient tous deux sur les Compartiments pour assurer le confinement.

LavaMoat aurait-il empêché l'attaque sur la chaîne d'approvisionnement de Ledger ?

Se demander si LavaMoat l'aurait empêchée, c'est un peu comme demander si la fonction d'arrêt au contact d'une scie circulaire vous aiderait si vous teniez la scie en sautant d'une falaise — oui, vos doigts resteraient probablement attachés à votre main après le saut.

En principe, le fonctionnement de @ledgerhq/connect-kit-loader oblige le développeur d'application à renoncer à de nombreuses bonnes pratiques de sécurité établies. Mais tout n'est pas perdu.

La meilleure façon de laisser LavaMoat (et d'autres outils de sécurité de la chaîne d'approvisionnement) vous aider serait d'utiliser @ledgerhq/connect-kit directement, sans confier tout le contrôle au loader.

LavaMoat a été conçu pour atténuer des attaques comme le piratage du portefeuille Copay, également connu sous le nom d'« incident event-stream », et s'en protège efficacement. Alors, comment LavaMoat se comporte-t-il face à cette attaque différente ?

La réponse est, malheureusement, le sempiternel « ça dépend ». LavaMoat est un outil destiné aux développeurs d'applications, et non aux développeurs de bibliothèques, en raison de la façon dont il s'intègre dans le runtime de l'application. Cela signifie que si certaines applications web auraient pu se protéger avec LavaMoat, les applications sans LavaMoat resteraient vulnérables.

De plus, LavaMoat n'applique qu'une politique spécifiée par les développeurs. Si vous définissez une politique non sécurisée, LavaMoat ne pourra pas vous protéger.

Voyons comment une application utilisant LavaMoat aurait pu être protégée de cette attaque.

LavaMoat utilise un fichier de politique pour déterminer quelles capacités, sous forme d'API de plateforme globales, une dépendance devrait recevoir. Pour faciliter cela, vous pouvez demander à LavaMoat d'analyser un package et de déterminer automatiquement ce dont il semble avoir besoin pour fonctionner. C'est ce qu'on appelle l'analyse statique.

Bien que l'analyse statique soit un moyen imparfait de comprendre ce que du code tente de faire, LavaMoat n'utilise l'analyse statique qu'à titre pratique pour vous aider à générer un fichier de politique. Il n'utilise pas l'analyse statique pour appliquer ses politiques à l'exécution. Les politiques générées sont ensuite examinées, ajustées et approuvées par le développeur.

Pour répondre à la question initiale : Oui, LavaMoat peut protéger votre application et vos utilisateurs contre les attaques sur la chaîne d'approvisionnement, en empêchant les packages d'avoir la capacité de charger du nouveau code à l'exécution. Il peut vous protéger si vous l'avez correctement configuré et si vous utilisez des dépendances qui n'exigent pas des capacités excessivement puissantes.

Une autre réponse est : Non. Si vous aviez configuré LavaMoat pour permettre à **@ledgerhq/connect-kit-loader** de fonctionner normalement et d'injecter une balise script exécutant n'importe quel code en dehors du runtime LavaMoat, l'attaque aurait quand même réussi. Cela fait partie du compromis de LavaMoat entre la compatibilité ascendante et un système plus sûr. LavaMoat est très flexible afin d'être le plus compatible possible, vous permettant de l'intégrer dans votre application sans la réécrire de zéro. La responsabilité incombe toujours au développeur d'application de définir des politiques sensées et de choisir des dépendances appropriées. LavaMoat vous permet de fournir sélectivement des API de navigateur globales, mais certaines API globales contiennent tout simplement trop de puissance pour être confiées en toute sécurité à un package tiers. Nous explorons plusieurs moyens de limiter davantage ces pouvoirs, mais créer quelque chose qui fonctionne simplement pour des packages ne faisant aucun effort pour limiter leur contrôle est un défi.

L'une des fonctionnalités de LavaMoat, appelée Scuttling, interférerait à la fois avec le package malveillant et le package original chargé par @ledgerhq/connect-kit-loader. Le Scuttling supprime l'accès aux capacités pour le code s'exécutant en dehors du sandbox LavaMoat. Cela vous empêcherait d'utiliser l'@ledgerhq/connect-kit-loader non sécurisé dès le départ, et vous pousserait à utiliser directement et donc à maîtriser le processus de mise à jour d'@ledgerhq/connect-kit, vous assurant de garder un contrôle total sur le code exécuté dans votre application.

Bien que LavaMoat ne soit pas une solution miracle, il vous donne contrôle et visibilité là où vous n'en auriez autrement aucun. LavaMoat ne devrait être qu'un outil parmi d'autres dans votre stratégie de sécurité.

Voici ce que vous pouvez faire dès maintenant pour vous défendre contre une attaque demain :

• Ajoutez le moniteur de dépendances Socket.dev gratuit (2 min).

• Ajoutez une CSP avec un contrôle strict des ressources (30 min).

• Ajoutez LavaMoat à votre système de compilation et à votre bundle d'application (1 h).