quand une personne malveillante arrive à capter le mot de passe d'une autre personne bienveillante, malveillante peut commettre des exactions au nom de bienveillante ; et malheureusement on a eu beaucoup de cas qui font que ce scénario n'est plus de faible probabilité mais avéré
[Référence nécessaire]
On a des cas de contributeurs à PyPI ou à NPM dont les mots de passe ont été captés par des acteurs malveillants qui les ont ensuite utilisé pour publier du code malveillant au nom de ces contributeurs ?
La dépêche fait référence (sans lien d’ailleurs, ce qui est dommage) à une étude de l’Open Source Security Foundation qui a trouvé « plus de 200 paquets Javascript et Python malveillant ». Il s’agit de ce projet, dont le résumé dit clairement
The vast majority of the malicious packages we detected are dependency confusion and typosquatting attacks.
(L’emphase est de moi.) Les attaques par « confusion de dépendances1 » et « typosquattage » ne nécessitent aucunement de capturer les identifiants et mots de passe de qui que ce soit. L’attaquant publie les paquets malveillants avec un compte qu’il a créé lui-même et donc qu’il contrôle déjà entièrement. C’est justement un des intérêts de ces attaques que de ne pas nécessiter un quelconque acte de « piraterie » pour être mis en œuvre.
L’authentification à deux, trois, ou douze facteurs n’a strictement aucun effet sur ce genre d’attaques.
L’étude ne mentionne explicitement aucun cas de code malveillant publié avec le compte d’un contributeur légitime qui se serait fait pirater son compte. Je pense que s’ils avaient détecté un tel cas, ç’aurait été suffisamment notable pour mériter une mention.
Donc non, il n’y a pas de rapport entre « tout le monde peut publier sur NPM ou PyPI, du coup il y a des paquets malveillants » et « désormais les projets critiques doivent utiliser l’authentification à deux facteurs ». Le second n’est pas une solution au premier, c’est une solution à un tout autre problème,2 et jusqu’à preuve du contraire un problème beaucoup moins répandu que le premier.
1 En gros, l’attaquant apprend, d’une manière ou une autre, que la cible utilise des paquets PyPI ou NPM privés (hébergés sur un dépôt interne), et du coup publie un paquet avec le même nom sur PyPI ou NPM, ce qui « masque » les paquets hébergés sur le dépôt privé et conduit la victime à télécharcher le paquet fabriqué par l’attaquant plutôt que le paquet hébergé en interne.
2 Non pas que ce soit une mauvaise solution (perso j’accueille favorablement toute initiative en faveur de la généralisation de l’authentification à deux facteurs, que j‘utilise moi-même partout où elle est disponible, y compris sur PyPI).
[^] # Re: Je vois pas le rapport!
Posté par gouttegd . En réponse à la dépêche PyPI déploie le système 2FA pour les projets critiques écrits en Python. Évalué à 6.
[Référence nécessaire]
On a des cas de contributeurs à PyPI ou à NPM dont les mots de passe ont été captés par des acteurs malveillants qui les ont ensuite utilisé pour publier du code malveillant au nom de ces contributeurs ?
La dépêche fait référence (sans lien d’ailleurs, ce qui est dommage) à une étude de l’Open Source Security Foundation qui a trouvé « plus de 200 paquets Javascript et Python malveillant ». Il s’agit de ce projet, dont le résumé dit clairement
(L’emphase est de moi.) Les attaques par « confusion de dépendances1 » et « typosquattage » ne nécessitent aucunement de capturer les identifiants et mots de passe de qui que ce soit. L’attaquant publie les paquets malveillants avec un compte qu’il a créé lui-même et donc qu’il contrôle déjà entièrement. C’est justement un des intérêts de ces attaques que de ne pas nécessiter un quelconque acte de « piraterie » pour être mis en œuvre.
L’authentification à deux, trois, ou douze facteurs n’a strictement aucun effet sur ce genre d’attaques.
L’étude ne mentionne explicitement aucun cas de code malveillant publié avec le compte d’un contributeur légitime qui se serait fait pirater son compte. Je pense que s’ils avaient détecté un tel cas, ç’aurait été suffisamment notable pour mériter une mention.
Donc non, il n’y a pas de rapport entre « tout le monde peut publier sur NPM ou PyPI, du coup il y a des paquets malveillants » et « désormais les projets critiques doivent utiliser l’authentification à deux facteurs ». Le second n’est pas une solution au premier, c’est une solution à un tout autre problème,2 et jusqu’à preuve du contraire un problème beaucoup moins répandu que le premier.
1 En gros, l’attaquant apprend, d’une manière ou une autre, que la cible utilise des paquets PyPI ou NPM privés (hébergés sur un dépôt interne), et du coup publie un paquet avec le même nom sur PyPI ou NPM, ce qui « masque » les paquets hébergés sur le dépôt privé et conduit la victime à télécharcher le paquet fabriqué par l’attaquant plutôt que le paquet hébergé en interne.
2 Non pas que ce soit une mauvaise solution (perso j’accueille favorablement toute initiative en faveur de la généralisation de l’authentification à deux facteurs, que j‘utilise moi-même partout où elle est disponible, y compris sur PyPI).