Une erreur d'un seul caractère qui a envoyé un logiciel malveillant
Tout a commencé par une faute de frappe. Quelque part, dans la ruée des publications et des fusions de relations publiques, quelqu'un a tapé @utils_core au lieu de @utils-core into the package.jsonCe glissement de caractère unique n'a pas généré d'erreur. Au lieu de cela, il a discrètement généré un package malveillant similaire au cours de la prochaine CI/CD exécuter, en tirant parti de la confiance dans les versions épinglées et l'automatisation. Bienvenue dans le monde du typosquatting en open source.
Typosquatting : le vecteur d'attaque qui prospère grâce à l'erreur humaine
Le typosquatting est exactement ce que son nom indique : des acteurs malveillants enregistrent des paquets portant des noms quasiment identiques à ceux de paquets légitimes. Dans les environnements dynamiques, cela fonctionne car les développeurs ont confiance en leurs package.json et package-lock.json Refléter leurs attentes. Un personnage en moins ? Il pourrait tout aussi bien être invisible dans un diff PR.
NPM a été exploité par le biais du typosquatting. Des packages comme crossenv au lieu de environnement croisé or flux d'événements Les portes dérobées ont déjà démontré l'efficacité de ces sosies. Ces faux packages passent souvent les tests simplement parce qu'ils semblent corrects et ne génèrent pas d'erreurs d'exécution immédiates.
Les pièges courants incluent :
- Trait d'union vs trait de soulignement : lnoyau odash vs lodash_core
- Pluriels : demandez vs demandes
- Caractères substitués : exprimer au lieu de express
Où package-lock.json devient un angle mort
Le développeur corrige sa faute de frappe. Du moins, c'est ce qu'il croit. Mais maintenant, package-lock.json a déjà verrouillé le paquet de l'attaquant. Et c'est là que réside le véritable risque.
Contrairement à package.json, qui est édité manuellement et fait l'objet d'un examen plus approfondi, package-lock.json est généré automatiquement par NPM. En conséquence, elle est souvent traitée comme une formalité, ignorée ou seulement survolée. pull request Avis. Il n'est pas rare que les équipes le considèrent comme « trop bruyant » ou lui accordent une confiance implicite sans un examen approfondi.
Les attaquants le savent. Ils s'y fient. Une fois qu'un paquet malveillant est référencé, grâce à une faute de frappe dans package.json, package-lock.json Enregistre la version résolue. Même si l'erreur est corrigée ultérieurement, l'entrée malveillante peut persister, sauf si le fichier de verrouillage est explicitement régénéré.
Pire encore, l'épinglage de version, censé garantir la cohérence, peut se retourner contre eux. Les attaquants peuvent ainsi créer une version identique de leur faux paquet à celle du paquet légitime. CI/CD le système fait confiance aveuglément aux versions épinglées, il ne détectera pas qu'il installe un package avec un numéro de version connu comme étant bon mais provenant d'une source différente et malveillante.
Cette persistance silencieuse est ce qui fait package-lock.json C'est tellement dangereux. Cela garantit des builds déterministes, certes, mais aussi la persistance d'un mauvais paquet, à moins qu'il ne soit détecté et nettoyé manuellement.
CI/CD:Où les logiciels malveillants frappent – package.json
Dans un typique CI/CD pipelineLe package malveillant n'a pas besoin d'attendre l'exécution. Il est résolu et déclenché bien plus tôt dans le processus :
Résolution de dépendance
Le pipeline extrait les versions de dépendance exactes de package-lock.json, qui comprend désormais le package typosquatté en raison d'une faute de frappe dans paquet.json.
Phase d'installation
Lors de l'exécution de npm ci, toutes les dépendances sont installées, y compris la dépendance malveillante. Aucun avertissement, aucune invite : une installation silencieuse.
Exécution du script post-installation
Le package similaire inclut un script de post-installation qui s'exécute automatiquement une fois l'installation terminée. C'est là que le problème se pose.
Exemple de pseudocode :
if (installation_phase_active) {
runHiddenPayload()
}Description du pseudocode :
Pendant la phase d'installation, si le hook de cycle de vie post-installation est présent, le faux paquet déclenche sa logique cachée, souvent avant même l'exécution des builds ou des tests. Cela peut impliquer des requêtes externes, l'injection de portes dérobées ou d'autres actions non autorisées.
⚠️ Avertissement : ce pseudo-code est uniquement à des fins de démonstration et ne doit pas être utilisé dans des environnements réels.
Aucune alerte n'est déclenchée. Rien ne tombe en panne. L'environnement est déjà compromis, avant même que vous ne le sachiez. pipeline atteint même le stade des tests.
Repérer la différence avant qu'il ne soit trop tard
Une erreur courante : supposer package.json raconte toute l'histoire. Ce n'est pas le cas. Le véritable pouvoir réside dans la combinaison de paquet.json + paquet-lock.json.
Voici ce qu'il faut rechercher :
- Est-ce que package-lock.json inclure des packages inattendus ?
- Certaines dépendances proviennent-elles de registres inconnus ou ont-elles des portées étranges ?
- Les numéros de version sont-ils trop spécifiques ou mal alignés ?
Utilisez des outils CLI tels que :
- audit npm pour signaler les problèmes connus
- npm ls pour afficher l'arbre de dépendances complet
- diff pour comparer les versions entre package.json et package-lock.json
Renforcez votre Pipeline: Des défenses qui fonctionnent
Pour se défendre contre le typosquatting :
- Appliquer les restrictions de portée dans paquet.json.
- Ajouter une pré-fusion hooks pour analyser et valider les dépendances.
- Utilisez le npm ci pour éviter toute dérive de version involontaire.
- Scannez régulièrement package-lock.json pour les anomalies.
Et surtout : traitez les entrées non vérifiées dans package-lock.json comme des risques potentiels. Chaque commit devrait être traité comme un point de contrôle de la chaîne d’approvisionnement.
Détection automatisée : comment des outils comme Xygeni peuvent aider
Bien qu’il ne s’agisse pas d’une solution miracle, des outils automatisés comme Xygéni Jouez un rôle essentiel dans la réduction du facteur d'erreur humaine, source de typosquattage. Xygeni s'intègre directement à votre workflow DevOps, ajoutant une couche de protection en temps réel contre le détournement de dépendances avant même son exécution.
Voici comment Xygeni aide :
- Détection de nom de colis suspect :
Utilise des heuristiques intelligentes pour détecter les modèles de typosquatting dans package.json, à la recherche de variations mineures dans les noms de packages bien connus (comme des traits de soulignement ajoutés, des transpositions ou des échanges de lettres). - Vérification du hachage inconnu :
Compare le hachage de chaque dépendance dans package-lock.json par rapport à une base de données d'artefacts reconnus comme fiables provenant de registres de confiance. Même si le nom et la version d'un paquet semblent corrects, une incompatibilité de hachage déclenche un signal d'alarme. - Blocage avant la construction :
Intercepte et bloque l'installation de tout package non vérifié ou suspect avant qu'il n'atteigne les phases d'installation ou de post-installation dans le CI/CD pipeline. - Analyse du graphique de dépendance :
Inspecte en permanence l'arbre de dépendances complet pour détecter les tentatives de typosquattage indirectes ou les dépendances transitives malveillantes. - Alertes et rapports :
Fournit des alertes détaillées et exploitables, indiquant ce qui a été signalé, pourquoi et d'où cela vient dans la chaîne de dépendance.
À mesure que les écosystèmes de packages se complexifient, des outils comme Xygeni deviennent essentiels. La revue manuelle ne s'adapte pas à la prolifération des dépendances ni aux itérations rapides. Xygeni intervient pour automatiser les vérifications critiques modernes. pipelines besoin, combler le fossé entre la confiance et la vérification.
Un personnage. De réelles conséquences.
Ce n'était pas exotique zero-dayC'était une faute de frappe. Un caractère mal placé dans package.json, silencieusement renforcé par package-lock.json, et des logiciels malveillants ont été expédiés, automatiquement, au cours d'une routine CI/CD fonctionner.
C'est là le véritable danger du typosquatting : il n'a pas besoin de complexité. Il exploite la vitesse, la confiance et l'automatisation. Ce compromis aurait pu être évité avec les bons contrôles en place :
- Numérisation automatisée pour détecter les noms et versions de paquets suspects avant l'installation.
- Audit des fichiers verrouillés pour détecter les entrées non examinées ou inattendues dans package-lock.json.
- Heuristique de vérification de nom pour signaler les correspondances proches des packages de confiance.
Un seul personnage a suffi. Des vérifications appropriées auraient pu l'arrêter avant qu'il ne vous touche. pipelineLa confiance ne suffit pas. Dans le DevSecOps moderne, on vérifie tout, ou on risque tout.
