Sonatype a désactivé la possibilité de télécharger les dépendances Java à partir de Maven Central sur HTTP non chiffré, ce qui permet de sécuriser la chaîne logistique logicielle contre les attaques par injection. Le changement comprend également la vérification du certificat de Maven pour se prémunir contre les attaques de l'homme du milieu (Men In The Middle MITM).
De nombreux systèmes de création de logiciels dans l'écosystème Java, notamment Maven, Gradle et SBT, s'appuient sur Maven Central pour localiser et télécharger les dépendances logicielles. Le passage à l'exigence HTTPS a été annoncé par le chef de produit Sonatype Terry Yanko et l'ingénieur Gradle Jonathan Leitschuh.
Le travail effectué par Jonathan Leitschuh s'appuie sur un travail commencé en 2014, lorsque Sonatype a activé l'accès SSL au référentiel Maven. À cette époque, Max Veytsman avait créé une note et un outil expliquant comment détourner des fichiers JAR provenant de Maven lors de leur passage sur un réseau. À la suite de cette attaque, les systèmes fonctionneraient sans le savoir avec l'artefact qu'ils avaient téléchargé. Les artefacts de code, cependant, pourraient être modifiés lors du transfert via un processus simple qui ne fonctionne plus en raison du changement de Sonatype.
- Un serveur proxy personnalisé capturerait les éléments provenant de Maven Central.
- Le proxy analyserait l'artefact entrant comme un ZipInputStream .
- Comme il a détecté le binaire d'un ZipEntry, le proxy transmettrait l'entrée à une bibliothèque de bytecode Java, comme ASM.
- L'ASM ClassVisitor personnalisé ajouterait ou modifierait des méthodes de classe spécifiques, telles que la méthode d'initialisation statique, <clinit>()V, pour ajouter du bytecode personnalisé qui pourrait par exemple exécuter une commande système.
- Le proxy ré-compresserait tout le contenu dans un ZipOutputStream qui était transmis au client.
- Le système de build et/ou tout système qui a chargé ou exécuté les classes back-doored exécuterait le payload qui a été mise en place par le serveur proxy.
Le risque nécessitait une attaque MITM et n'était pas une vulnérabilité dans Maven ou Java lui-même. Des exemples d'exploitation ont été réalisés dans des environnements de laboratoire et il n'y a aucune attaque connue sur l'écosystème Java/Maven qui a exploité cette attaque par injection de bytecode. Les attaques à grande échelle sur le routage du réseau nécessitent des efforts importants de la part des organisations disposant de compétences, d'un financement et d'un accès importants. Au cours de la même période, l'analyse annuelle de vulnérabilité de Trend Micro en 2014 a cité des améliorations positives de la sécurité Java, "Quelques bonnes nouvelles - il n'y avait pas de faille zero-days concernant Java en 2014! "
"Heureusement, la sécurité des applications est passée d'une activité unique avant la publication à un processus de qualité holistique appliqué tout au long du cycle de développement. L'amélioration de la sécurité de la chaîne d'approvisionnement commence par chacun de nous améliorant la sécurité de nos propres produits", explique Milton Smith, directeur d'AppSec Alchemy. En 2014, Milton Smith était chef de produit au sein du Java Platform Group d'Oracle.
Pour les utilisateurs qui nécessitent un accès HTTP non chiffré, Sonatype a créé une solution de contournement qui permet aux systèmes de continuer à fonctionner. Les systèmes plus anciens qui ne peuvent pas être mis à jour vers les versions récentes de Maven peuvent simplement basculer leurs URL de téléchargement de repo.maven.org ou repo1.maven.org vers insecure.repo1.maven.org. Sonatype a placé le mot non sécurisé (insecure) dans le nom d'hôte comme moyen de communiquer clairement que cette modification est sans ambiguïté un problème de sécurité. Les organisations disposant de contrôles de sécurité peuvent également choisir de bloquer ou de signaler les hôtes qui accèdent à cette URL pour équilibrer entre le fonctionnement de builds et le blocage des téléchargements potentiellement non sécurisés.