Un package « nodejs » assez populaire balance les variables d'environnement des imprudents utilisateurs vers son serveur. Bien sur, ces variables contiennent souvent des mots de passes, des tokens API et autres informations spécifiques.
Plus de détail sur https://medium.com/@ceejbot/crossenv-malware-on-the-npm-registry-45c7dc29f6f5 le 3ème point va vous faire halluciner !
Il y a vraiment des gens qui utilisent ça sur des serveurs de production ? Je veux dire dans un mode de vrais professionnels.
L'une des parades seraient un firewall applicatif. Ca existe sous Linux ?
# "assez populaire"?
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 04 août 2017 à 11:30.
As-tu lu le lien que tu mets?
("50 real installations" je n'appelle pas ça populaire mais typo-squatting, comme ceux qui écrivent sur le lien que tu as mis)
Ou je n'ai pas compris, peux-tu expliciter?
Pas compris, peux-tu citer?
[^] # Re: "assez populaire"?
Posté par ckiller . Évalué à -2.
Tu n'as pas lu l'article car sinon, tu aurais vu qu'il y a un paragraphe "Exposure" qui se termine par :
[^] # Re: "assez populaire"?
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 04 août 2017 à 11:43.
Je l'ai lu, et vu ce que tu as copié.
Donc que du typo-squatting ou name-squatting, peu de downloads, qu'est-ce qui fait halluciner?
Toujours pas compris ce qui est hallucinant ou populaire dans ce que tu as copié.
[^] # Re: "assez populaire"?
Posté par freem . Évalué à 2.
Je suppose que c'est ça:
mais je ne vois pas pourquoi.
[^] # Re: "assez populaire"?
Posté par Zenitram (site web personnel) . Évalué à 3.
679 n'est pas "populaire" pour moi (ou alors mes logiciels sont "ultra-populaire"), et j'ai lu :
"From this you can see that the real danger came from the crossenv package, which had nearly 700 downloads, with some secondary exposure from the jquery typosquats. But even in that case, most of the downloads come from mirrors requesting copies of the 16 versions of crossenv published. Our estimate is that there were at most 50 real installations of crossenv, probably fewer."
D'où mon "50" dans ma première réponse (ben oui, j'avais lu que 679 n'était pas à prendre comme tel).
Je cherche donc toujours le côté populaire et hallucinant, si l'auteur de ces mots veut bien expliquer à la place de troller…
Perso, je vois que du squatting classique, rien de populaire (les logiciels sont des contrefaçons) ni d'hallucinant (aucun nombre gros, c'est du squatting peu rentable et viré, sujet clos, rien qui fasse bondir), ou j'ai loupé un épisode (que l'auteur éclaire ma lanterne).
[^] # Re: "assez populaire"?
Posté par ckiller . Évalué à 0.
Jette un œil à https://www.blogdumoderateur.com/types-clickbaits/ Le 7ème paragraphe va t'étonner. C'est une figure de style à vocation humoristique.
Ben non, pour moi, le sujet n'est pas clos. Oui, ce cas est résolu, mais les problèmes de sécurité de ce genre de dépôt reste entier.
Pour moi, la solution passe par un parefeu applicatif qui vérifierait et autoriserait ou pas le trafic de ce genre d'outil.
C'est l'objet de ce journal. L'auteur a-t-il suffisamment éclairé ta lanterne ?
[^] # Re: "assez populaire"?
Posté par Thomas Debesse (site web personnel) . Évalué à 3. Dernière modification le 04 août 2017 à 20:12.
la chute est énorme !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: "assez populaire"?
Posté par kursus_hc . Évalué à 3.
Si la seule conséquence d'une attaque de ce genre (détectable en quelques minutes dans des conditions normales de développement au passage, je suis prêt à parier que le type qui à découvert ça a été le premier à rentrer des informations sensibles) c'est 50 types -ne sachant pas taper 5 caractères- sur qui ça tombe et la création de la parade, je vois pas ce qu'on peut avoir de mieux. Quand à un "parefeu applicatif", hum… On va plutôt recommander la prudence hein.
# mod_security
Posté par eggus . Évalué à 1.
Il y a ce module Apache qui sert à appliquer des règles sur le trafic HTTP : modsecurity
Utilisable si le package en question était pour une application web (je connais pas trop node.js mais en général c'est pour faire du backend sur des appli web).
Un pare-feu classique (iptables ou autre) aurait tout aussi bien pu arrêter cette fuite de données si seul le trafic vers des connexions déjà établies ou clairement identifiées avait été autorisé.
[^] # Re: mod_security
Posté par ckiller . Évalué à 2.
il faudrait que tu m'expliques en quoi modsecurity aurait eu un intérêt dans ce cas.
Je ne comprends pas
[^] # Re: mod_security
Posté par eggus . Évalué à 1.
Modsecurity est un pare-feu applicatif après je l'avoue je ne m'étais pas vraiment penché sur ce qu'était en fait crossenv. J'avais fait un raccourci rapide nodejs => package utilisé dans le dev d'une application web. On est d'accord, dans ce cas ça n'a aucun interêt.
[^] # Re: mod_security
Posté par ckiller . Évalué à 2.
Oui, ca bloque, mais ca n'aurait pas permis de détecter la faille.
Un parefeu applicatif aurait dit : « npm cherche à accéder à un nouveau site : http://malware.com, souhaitez-vous autoriser le traffic ? [No/yes/always]»
Je trouve que c'est un outil qui manque (à ma connaissance) dans les distributions linux et qui marche parfaitement sous les OS Microsoft.
[^] # Re: mod_security
Posté par claudex . Évalué à 4.
Tu parlais de contexte professionnel dans ton journal. Dans ce cas, tu as un proxy avec une whitelist. Et le problème ne se pose pas.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: mod_security
Posté par eggus . Évalué à 3. Dernière modification le 04 août 2017 à 15:07.
OK je pense que nous n'avons pas la même définition de ce qu'est un pare-feu applicatif.
Sur Windows, il s'agit juste d'un pare-feu stateful mais qui permet d'avoir des règles sur l'application source plutôt que seulement les IP et ports. Tu peux faire quelque chose d'équivalent avec iptables, plus précisemment avec l'option --cmd-owner de l'extension owner match.
L'interêt d'un pare-feu qui demande si on souhaite autoriser un trafic est assez limité à mon avis sur un serveur de production :
- C'est de la prod, tu est censé connaître tous les trafic réseau entrants et sortants de ton serveur et donc capable de les autoriser à priori et de bloquer tout le reste.
- Car l'événement déclencheur (l'activation du malware) n'a pas forcement lieu lorsqu'on a une session ouverte dessus.
Dans un contexte de serveurs de production, on devrait normalement avoir une console de supervision qui s'allume comme un sapin de noël si un pare-feu détecte des flux sortants non autorisés. Car il s'agit soit d'un malware, soit d'une application mal configurée donc potentiellement qui ne peut pas rendre le service. Donc un firewall classique aurait dans ce cas mis en lumière cette faille.
[^] # Re: mod_security
Posté par ckiller . Évalué à 1.
Oui, c'est exact pour la production. La responsabilité et l'élaboration d'une whitelists devrait revenir aux dèvs. L'ajout d'une dépendance est une décision qui vient du dev du projet ou de l'un des devs d'une des dépendances, ou d'une dépendance de dépendance.
Tout cela étant ensuite poussé sur les serveurs de devs, et parfois de façon automatique.
Au final, il n'y a pas de maitrise, ni des versions utilisés, ni des dépendances, (et je ne parle pas du respect des licences libres) et c'est ce que je reproche à cet écosystème.
Ce que je trouve regrettable, c'est que ces outils n'intègrent pas mieux ces sécurités élémentaires dans leur mode de développement. Que la facilité l'emporte sur la sécurité.
Si vous avez des bonnes pratiques pour sécuriser les postes de devs, c'est le moment de partager ;)
C'est surement le cas dans les grosses infra, mais ce n'est quand même pas si courant que ça.
[^] # Re: mod_security
Posté par BAud (site web personnel) . Évalué à 3.
sur Mageia tu as drakguard qui gère des white-list :
http://doc.mageia.org/mcc/6/fr/content/drakguard.html
bon, c'est présenté sous l'angle « contrôle parental » mais cela sert à établir interactivement des listes blanches, noires, ce que tu veux… et générer les règles appropriées.
Tu peux aussi t'appuyer sur mandi le « pare-feu interactif » :
http://madb.mageia.org/package/show/application/0/release/cauldron/name/mandi
http://madb.mageia.org/package/show/application/0/release/cauldron/name/mandi-ifw
[^] # Re: mod_security
Posté par Anonyme . Évalué à -1.
euh dans un monde professionnel tu fait des règles awk ou grep pour voir ce qui se passe. Si tu as un budget un serveur snort. pas besoin de popoup avec la terrachier de log de dispo sous linux
Sous windows vu le niveau général je comprend qu'il faille des popup partout, avec une version pro a 12$ par mois qui s'affiche.
[^] # Re: mod_security
Posté par Marotte ⛧ . Évalué à 5.
À moins de vivre les yeux rivés sur une console, ou de lire tous les matins la sortie de ton filtre à base de awk, grep et colle Cléopâtre, tu n’auras pas exactement le même service qu’un snort qui va te déranger seulement quand c’est nécessaire : ça s’appelle une notification. Tu compte développer un système de parsing de log en shell, lancé par cron et qui va envoyer un mail ? C’est une approche, de dinosaure j’ose le dire… mais pourquoi pas. Je dis que pour fonctionner comme ça tu as intérêt à avoir de la ressource en personnel très qualifié, des gens pour lesquels ce genre de solution est vivable, voire KISS.
Avoir des logs à foison c’est pas forcément un signe de qualité, il n’y a qu’à voir les messages d’erreur de Java. Sur Windows aussi il y a de quoi lire… c’est plus dur à trouver et tu n’as pas tout à fait le même type de communauté pour te permettre de te former. Là par contre je trouve qu’il y a clairement une différence entre les LL et les autres logiciels, sur la bonne manière de se former pour l’un ou l’autre.
Hein ?! Un budget pour quoi ?
Le temps que tu passes à développer/maintenir tes scripts shell et celui que tu passerais à configurer/administrer snort doivent être kif-kif, non ? Je parie même que plus le temps passe et plus la solution snort (ou du même type, intégrée quoi…) devient avantageuse.
Va falloir arrêter avec le winadmin bashing… OK tu précises bien "général"… mais d’une, des incompétents sous Linux on en rencontre de plus en plus, et de deux, ça reste insultant pour les admin windows qui bossent bien… Qu’on le veuille ou non, qu’on le regrette ou pas, il en faut ! Puisque je préfère moi (et j’exige plus ou moins de) travailler avec du LL :)
Ce que tu remets en cause n’a rien à voir avec Windows. Ça s’appelle effectuer un apprentissage initial sur un logiciel, ça se fait couramment pour le filtrage du spam, la dictée vocale ou la reconnaissance d’écriture manuscrite. Et oui, ça peut se concevoir pour "éduquer" un firewall (surtout applicatif).
Personnellement je n’utilise pas un clickodrome à 12$ sous Windows pour configurer mes firewalls mais je fonctionne exactement de la même manière : je regarde ce que le firewall bloque et j’ajoute la règle en fonction (à l’unique condition de comprendre à quoi elle sert). C’est beaucoup plus simple, pas besoin de se rappeler toutes les configurations de filtrage des différents outils ou de devoir ressortir la doc à chaque fois…
Si j’avais beaucoup de firewalls à gérer, une appli qui me notifierait que la machine bidule essaye de parler à la machine machin en utilisant le protocole truc : voulez-vous autoriser ? oui/non ça me ferait gagner du temps. Pour tous les cas simples.
Si je sais que l’équipe machin vient de commissionner ce serveur pour faire tel truc et que ça correspond au paquets rejetés bah je valide d’un clic, et je peux faire autre chose. Je ne mets le awk dans les logs que pour les cas qui le nécessitent vraiment…
[^] # Re: mod_security
Posté par freem . Évalué à 3.
Loin de moi l'envie de défendre Windows, son terminal à 2 balles (et je suis gentil) et son «power» shell, mais il semblerait qu'ils aient fini par se doter d'outils un peu moins foireux que l'émulateur MSDOS pour contrôler le système.
Bon, si tu me demandes, je te dirais juste que le powershell est trop verbeux à mon goût, mais qu'au moins il intègre, à priori systématiquement, des exemples d'utilisations dans ses pages de doc (ça, ça serait super pour nos pages de man… elles sont bien trop rares celles qui intègrent un exemple réellement exploitable).
Quand j'étais encore enfermé dans le monde de la fenêtre, il y avait un firewall… enfin, non, un outil de sécurité (open source, mais je ne me rappelle plus le nom dudit soft) qui permettait de contrôler et définir facilement les accès des applications au réseau et même aux APIs Windows.
Ben je t'avoue que j'aimais bien cet outil, c'était genre 1000 fois plus léger qu'un antivirus, et vu que je l'avais mis en mode liste blanche (comme il se doit) j'étais juste emmerdé quand j'installais une application volontairement.
Et sinon c'était pas des popup qui informaient d'un problème, mais une notification. La différence, c'est qu'une popup, ça fait chier, une notif, c'est discret.
[^] # Re: mod_security
Posté par pralines . Évalué à 1. Dernière modification le 07 août 2017 à 17:11.
Zone Alarm ?non, pas open source, ça doit être autre chose, commentaire inutile à ignorer/supprimer, désolé
Envoyé depuis mon Archlinux
[^] # Re: mod_security
Posté par pasBill pasGates . Évalué à 3. Dernière modification le 08 août 2017 à 00:49.
Non ca c'est les amateurs qui font. Dans le monde professionel tu as un outillage légèrement plus solide et rapide que awk et grep
Ben visiblement le niveau est bien plus élevé que chez toi.
https://technet.microsoft.com/en-us/library/jj554908(v=wps.630).aspx
# npm
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 04 août 2017 à 11:35.
Note: il fallait faire une typo dans sa liste des packages pour être « infecté » par le mauvais package.
Le problème c'est pas tant nodejs que la façon dont est géré la sécurité dans tous les systèmes de packaging de librairies/modules. On tape volontier sur nodejs/npm mais c'est la même chose pour cpan, les rubygems, pip, les pléthores de librairies java, .net ou autre que tu peux utiliser pour développer ton application.
Est-ce que les projets pip, rubygems, packages.debian.org ou epel font de l'analyse systématique de tout code qui va dans leurs dépôt pour vérifier que ce genre de backdoor n'apparaisse pas ? Pas à ma connaissance. On se base essentiellement sur la confiance que l'on a envers les mainteneurs des packages.
[^] # Re: npm
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 04 août 2017 à 11:38.
Tu mélanges 2 types de repos:
- Les repos où il te faut un "sponsor", et ça prend des mois/années avant d'y être, et les typos sont vues en amont, pendant tout le process, et le "sponsor" a une bonne raison de proposer le logiciel.
- Les repos où n'importe qui peut uploader avec un nom avec des typos, les typos sont vu à postériori.
Les 2 cas ont des problèmes de sécurité très différents.
Et pour le premier cas, le "sponsor" est connu, et s'engage, donc beaucoup moins de risque de typo-squatting (je crois même que ce n'est jamais arrivé).
[^] # Re: npm
Posté par Marotte ⛧ . Évalué à 1.
Et toi tu oublis tout l’éventail de type de repos qui existent entre ces deux extrêmes.
[^] # Re: npm
Posté par freem . Évalué à 7.
Analyse systématique? Non, pas à ma connaissance.
Mais pour publier un paquet sur Debian, il faut passer quand même pas mal de barrières, si le paquet est malveillant il vaudrait mieux que ça soit bien dissimulé pour ne pas être repéré pendant assez longtemps pour finir stable.
Ce serait beaucoup plus simple de mettre un faux site officiel pour faire ajouter aux utilisateur un dépôt dans leurs sources.list, amha.
[^] # Re: npm
Posté par Adrien . Évalué à 5.
Pour Debian, il y a désormais des tests Lintian sur les problèmes de vie privée, par exemple :
https://lintian.debian.org/tags/privacy-breach-generic.html
Ça n'empêche pas forcément le paquet d'être dans Debian, mais au moins c'est transparent pour l'utilisateur.
Tout comme pour les failles de sécurité, au moins on sait à quoi s'attendre :
https://security-tracker.debian.org/tracker/status/release/stable
Pour les systèmes type rubygems, pip, etc. je ne sais pas si le même genre de mécanisme existe.
[^] # Re: npm
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Dans le monde java, maven propose des éléments de sécurité (signature, clefs…) et il est conseillé d'utiliser son propre repository privé plutôt qu'un public.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.