Des pirates s’invitent dans un outil Ledger et affiche, une fois de plus les limites du SBOM dans la protection de la chaine d’approvisionnement.
Le kit Ledger Connect, une solution logicielle développée par Ledger, entreprise spécialisée dans les portefeuilles physiques pour stocker les crypto-monnaies, a été victime d’une attaque informatique sophistiquée ciblant la chaîne d’approvisionnement. Le kit Ledger Connect est une solution logicielle qui permet aux développeurs de connecter leurs applications aux portefeuilles matériels Ledger, via API.
La faille a entrainé la redirection des transactions des utilisateurs vers un portefeuille contrôlé par le pirate. Le malveillant a réussi sont attaque à la suite d’un hameçonnage [phishing] auprès d’un ancien employé (prise de contrôle du compte npm), puis injection de code malveillant dans les versions 1.1.5, 1.1.6 et 1.1.7 du kit de Ledger.
A l’heure actuelle, plus de 700 000 $ ont été volés. Ledger a rapidement publié la version 1.1.8 pour corriger la vulnérabilité.
Pourquoi un SBOM, n’est pas suffisant ?
Le SBOM, ou « Software Bill of Materials », est essentiellement une liste détaillée des composants logiciels dans un produit programme informatique. Imaginez-le comme une liste d’ingrédients pour un code source.
Bien qu’une nomenclature logicielle (SBOM) soit un outil essentiel pour améliorer la transparence et la sécurité des chaînes d’approvisionnement logicielles, son efficacité reste limitée dans certains types d’attaques. Un SBOM répertorie efficacement tous les composants utilisés dans un produit logiciel, « mais il traite principalement des problèmes liés aux vulnérabilités connues de ces composants, et non nécessairement de la sécurité du mécanisme de distribution en lui-même. » confie la société Checkmarx.
Dans le cas de l’attaque du Kit Ledger Connect, le problème principal résidait dans le processus de distribution, qui a été compromis via le piratage du compte NPM. L’attaquant a publié des versions malveillantes du package via un canal légitime, pas nécessairement signalé par le SBOM. Étant donné que ce dernier répertorie les composants, il n’était donc pas en mesure d’identifier le code malveillant introduit dans les versions compromises.
Les SBOM doivent ainsi être complétés par des mécanismes d’analyse rapides et proactifs capables de détecter en temps réel les modifications non autorisées ou les activités malveillantes, au-delà de la simple liste de composants.
