Lancez la commande d'installation d'un nouveau projet web et comptez le nombre de paquets téléchargés : ce chiffre dépasse souvent le millier. Combien d'entre eux avez-vous lus ?
Les trois types d'attaques les plus courants
- Prise de contrôle du compte de l'auteur — l'attaquant s'empare des droits de publication puis diffuse une version contenant un code malveillant ; l'utilisateur effectue la mise à jour comme d'habitude et est infecté
- Nom de paquet trompeur — enregistrement d’un nom très similaire à celui d’un paquet populaire, en attendant que l’utilisateur se trompe en le saisissant
- Fidélisation de longue date suivie d’une trahison — l’attaquant contribue activement pendant plusieurs mois pour obtenir les droits de maintenance, puis installe une porte dérobée sophistiquée
Le troisième type est le plus dangereux, car le code malveillant y est introduit progressivement, dissimulé dans des fichiers de compilation ou des données de test, et non dans le code source lisible.
Défense en fonction de l'effort fourni
C'est simple et à faire sans tarder : verrouillez la version exacte à l'aide du fichier « lock » et ajoutez-la au dépôt ; activez la détection automatique des failles ; empêchez le script d'installation du paquet de s'exécuter de manière arbitraire.
En moyenne : conserver un cache interne plutôt que de télécharger directement depuis Internet ; prévoir un délai de quelques jours avant de recevoir la nouvelle version, car la plupart des paquets malveillants sont détectés dans les 48 premières heures.
C'est cher, mais cela en vaut la peine pour les systèmes critiques : possibilité de recompiler à partir du code source, de comparer et de vérifier les signatures, et réduction significative du nombre de dépendances.
Une question utile à se poser lorsqu'on ajoute une bibliothèque : si l'auteur de ce paquet devenait hostile demain, qu'est-ce que mon système perdrait ?
Thảo luận