npm a déployé une nouvelle protection cette semaine pour ses comptes les plus sollicités. Lorsque npm détecte une action sensible sur un compte à fort impact, comme un changement d'adresse e-mail ou l'utilisation d'un code de récupération 2FA, il place ce compte dans un état de lecture seule de 72 heures et envoie une alerte à l'adresse e-mail précédente. Les installations et téléchargements de paquets continuent de fonctionner normalement pendant cette période, et le gel est levé automatiquement à la fin de la période d'attente.
Cette mise à jour empêche les actions qui affectent le registre ou la sécurité du compte, telles que la publication, la gestion des jetons, les modifications de la visibilité des paquets et les modifications de l'adhésion à l'organisation. Il s'agit d'un contrôle au niveau du registre pour détecter rapidement lorsqu'un compte commence à échapper au contrôle de son propriétaire.
C'est excellent, et ce n'est que la dernière d'une série d'améliorations de sécurité de la part de npm. Ils nous ont donné la publication par étapes en mai et bloqueront les scripts post-installation par défaut dans la v12 en juillet. Les paramètres par défaut tendent lentement vers la prévention plutôt que la réaction. Microsoft a récemment travaillé sur des correctifs de sécurité, probablement inspiré par une série d'attaques de malwares se produisant sur ses plateformes (et contre ses plateformes).
npm n'a pas redéfini de seuil pour cette fonctionnalité, mais il a déjà utilisé le terme. Sa politique d'application de la 2FA définit un compte à fort impact comme un compte gérant des paquets avec plus d'un million de téléchargements hebdomadaires ou 500 dépendances, et la période de gel utilise probablement les mêmes critères.
L'impulsion derrière ce changement
La récente compromission d'axios en mars et l'attaque Mastra l'autre semaine sont les exemples les plus clairs de mémoire récente expliquant pourquoi cela est nécessaire. Ces attaques ont utilisé des campagnes d'ingénierie sociale contre les comptes ciblés pour obtenir un accès. Dans le cas d'axios, l'attaquant s'est fait passer pour un fondateur d'entreprise et a attiré un responsable de maintenance principal dans un appel vidéo. Le lien de l'appel contenait une invite « votre système est obsolète » qui a installé un cheval de Troie d'accès à distance (RAT), donnant à l'attaquant le contrôle de la machine de la victime et d'une session npm active. Ils ont changé l'e-mail du compte, puis ont publié directement deux versions malveillantes d'axios, contournant l'ensemble du système CI. axios représente environ 100 millions de téléchargements par semaine.
Ce type d'attaque est principalement invisible pour le registre, comme les étapes sur Slack et la machine compromise. Le changement d'e-mail est la seule étape de la séquence sur laquelle npm a une visibilité. Les attaquants changent les e-mails car cela coupe le chemin de récupération du véritable propriétaire et redirige les alertes de sécurité loin d'eux.
Comment cela s'intègre avec les autres changements de sécurité de npm
La période de gel est encore plus utile si l'on considère les deux correctifs que npm a déployés au cours de la dernière année environ.
La publication de confiance supprime les jetons de longue durée. La publication s'authentifie via des identifiants OIDC de courte durée définis pour un workflow CI, de sorte qu'aucun jeton persistant ne reste sur une machine qu'un RAT pourrait voler. Cependant, cela ne sert à rien lorsqu'un attaquant détient une session active et publie directement.
La publication par étapes, que nous avons obtenue le mois dernier, ajoute une étape d'approbation humaine. Un paquet étagé depuis le CI ne devient pas public tant qu'un mainteneur ne l'approuve pas avec la 2FA, de sorte qu'un workflow automatisé seul ne peut pas publier une version. Un attaquant qui contrôle le compte peut contourner cela en approuvant son propre paquet étagé, si le paquet l'a activé.
Ensemble, la publication de confiance gère les identifiants volés, la publication par étapes gère les versions automatisées non révisées, et la période de gel gère la prise de contrôle de compte que les deux autres contournent. Bien sûr, cela ne résout pas tout, mais si vous avez une publication de confiance uniquement par étapes et des jetons désactivés, vous empêchez une bonne partie des chemins côté publication que les attaquants utilisent.
Que faire maintenant
Si vous maintenez un paquet populaire, vérifiez que l'e-mail de votre compte npm est un e-mail que vous contrôlez et surveillez réellement (sinon, vous manquerez leur alerte par e-mail). Passez à FIDO2 là où vous le pouvez. Traitez un avis de changement d'e-mail inattendu comme un incident de sécurité plutôt que comme un spam ou un bug. Si vous publiez depuis le CI, configurez la publication de confiance comme étant uniquement par étapes et désactivez les jetons, de sorte que chaque version passe par une approbation humaine, et qu'il n'y ait aucun identifiant de longue durée à voler. Si vous recevez effectivement un e-mail inattendu concernant un changement de compte, contactez le support npm.
Si vous consommez des paquets plutôt que de les publier, félicitations ! Vous en bénéficiez sans rien faire. Cependant, certains paquets n'auront pas toutes leurs mesures de sécurité activées (beaucoup n'ont toujours pas ces paramètres de sécurité activés). Safe Chain par Aikido est un wrapper gratuit et open-source pour npm, npx et yarn qui vérifie chaque paquet à la recherche de malwares avant l'installation et impose une période d'attente sur les nouvelles versions, ce qui détecte une bonne partie des versions compromises avant qu'elles n'atteignent votre machine.
C'est formidable de pouvoir écrire sur les changements positifs apportés aux registres de paquets récemment.
