Plusieurs bibliothèques publiques et populaires abandonnées mais toujours utilisées dans les applications Java et Android se sont révélées sensibles à une nouvelle méthode d’attaque de la chaîne d’approvisionnement logicielle appelée MavenGate.
« L’accès aux projets peut être détourné via l’achat de noms de domaine et comme la plupart des configurations de build par défaut sont vulnérables, il serait difficile, voire impossible, de savoir si une attaque a été menée », dit dans une analyse publiée la semaine dernière.
Une exploitation réussie de ces lacunes pourrait permettre à des acteurs malveillants de détourner des artefacts dans les dépendances et d’injecter du code malveillant dans l’application, et pire encore, de compromettre le processus de construction via un plugin malveillant.
La société de sécurité mobile a ajouté que toutes les technologies basées sur Maven, y compris Gradle, sont vulnérables à l’attaque et qu’elle a envoyé des rapports à plus de 200 entreprises, dont Google, Facebook, Signal, Amazon et d’autres.
Apache Maven est principalement utilisé pour créer et gérer des projets basés sur Java, permettant aux utilisateurs de télécharger et de gérer les dépendances (qui sont identifiées de manière unique par leurs identifiants de groupe), de créer de la documentation et de gérer les versions.
Bien que les référentiels hébergeant de telles dépendances puissent être privé ou publiqueun attaquant pourrait cibler ces derniers pour mener des attaques d’empoisonnement de la chaîne d’approvisionnement en exploitant les bibliothèques abandonnées ajoutées aux référentiels connus.
Plus précisément, il s’agit d’acheter le produit périmé domaine inversé contrôlé par le propriétaire de la dépendance et obtenant l’accès au groupId.
« Un attaquant peut accéder à un groupId vulnérable en faisant valoir ses droits via un enregistrement DNS TXT dans un référentiel où aucun compte gérant le groupId vulnérable n’existe », a déclaré la société.
« Si un groupId est déjà enregistré dans le référentiel, un attaquant peut tenter d’accéder à ce groupId en contactant l’équipe d’assistance du référentiel. »
Pour tester le scénario d’attaque, Oversecured a téléchargé sa propre bibliothèque de test Android (groupId : « com.oversecured »), qui affiche le message toast « Hello World ! » sur Maven Central (version 1.0), tout en téléchargeant également deux versions sur JitPack. , où la version 1.0 est une réplique de la même bibliothèque publiée sur Maven Central.
Mais la version 1.1 est une copie éditée « non fiable » qui a également le même groupId, mais qui pointe vers un référentiel GitHub sous leur contrôle et est revendiquée en ajoutant un enregistrement DNS TXT pour référencer le nom d’utilisateur GitHub afin de établir une preuve de propriété.
L’attaque fonctionne ensuite en ajoutant Maven Central et JitPack à la liste des référentiels de dépendances dans le script de build Gradle. Il convient de noter à ce stade que ordre de déclaration détermine comment Gradle vérifiera les dépendances au moment de l’exécution.
« Lorsque nous avons déplacé le référentiel JitPack au-dessus de mavenCentral, la version 1.0 a été téléchargée depuis JitPack », ont indiqué les chercheurs. « Le changement de la version de la bibliothèque en 1.1 a entraîné l’utilisation de la version JitPack quelle que soit la position de JitPack dans la liste des référentiels. »
En conséquence, un adversaire cherchant à corrompre la chaîne d’approvisionnement logicielle peut soit cibler les versions existantes d’une bibliothèque en publiant une version supérieure, soit s’attaquer aux nouvelles versions en proposant une version inférieure à celle de son homologue légitime.
Il s’agit d’une autre forme d’attaque par confusion de dépendances dans laquelle un attaquant publie un package malveillant dans un référentiel de packages public portant le même nom qu’un package dans le référentiel privé prévu.
« La plupart des applications ne vérifient pas la signature numérique des dépendances, et de nombreuses bibliothèques ne la publient même pas », ajoutent les chercheurs. « Si l’attaquant souhaite rester indétectable le plus longtemps possible, il est logique de publier une nouvelle version de la bibliothèque avec le code malveillant intégré et d’attendre que le développeur la mette à niveau. »
Sur les 33 938 domaines analysés, 6 170 (18,18 %) se sont révélés vulnérables à MavenGate, permettant aux acteurs malveillants de détourner les dépendances et d’injecter leur propre code.
Sonatype, propriétaire de Maven Central, dit la stratégie d’attaque décrite « n’est pas réalisable en raison de l’automatisation en place », mais a noté qu’elle a « désactivé tous les comptes associés aux domaines expirés et aux projets GitHub » par mesure de sécurité.
Il a en outre déclaré avoir résolu une « régression dans le processus de validation de la clé publique » qui permettait de télécharger des artefacts dans le référentiel avec une clé non partagée publiquement. Il a également annoncé son intention de collaborer avec SigStore pour signer numériquement les composants.
« Le développeur final est responsable de la sécurité non seulement des dépendances directes, mais également des dépendances transitives », a déclaré Oversecured.
« Les développeurs de bibliothèques doivent être responsables des dépendances qu’ils déclarent et également écrire des hachages de clé publique pour leurs dépendances, tandis que le développeur final ne doit être responsable que de ses dépendances directes. »