Ouais, c'est difficile de blamer Microsoft quand c'est un vendeur externe qui se positionne dans le kernel et fait une erreur.
Ça serait comme dire qu'il y a une panne de Linux le jour ou un driver nvidia fait n'importe quoi.
Car bon, si Microsoft bloque les drivers encore plus, on va dire qu'ils abusent de leur position dominante, que c'est contre la liberté, etc. Si ils font rien, ce genre de merde arrive.
Alors on peut se demander le rapport avec un driver, mais il faut bien voir que "driver", c'est utiliser dans le sens "module noyau" pour Windows.
Est ce qu'on peut surveiller une machine sans module noyau ? Oui, mais tu vois pas tout. Sous linux, quand tu utilises systemtap, tu compiles un module que tu lances dans le kernel. Tu veux faire de l'EBPF, tu charge le code dans le kernel. Et sinon, tu peux directement faire un module kernel, comme le fait crowdstrike sur RHEL.
Donc bon, on va pas dire que Linux a une architecture différente.
Mais la question est "est ce que ça doit se passer dans le kernel", ce qui implique de savoir ce que "ça" recouvre exactement. De ce que je comprends, Falcon sensor est un outil de monitoring pour la sécurité. Par exemple, tu as un process qui commence à ouvrir des connexions tcp vers tout ton lan sur tout les ports, la plateforme est censé le voir, et c'est signe soit qu'une machine s'est fait pourrir et que les attaquants scannent le lan, soit qu'un salarié faire n'imp. pour faire ça, faut pouvoir intercepter des appels systémes. Y a qu'un endroit pour faire ça, le kernel.
Donc ça tourne niveau kernel. C'est comme les antivirus, si tu veux scanner avant d'ouvrir un fichier, faut le faire dans le kernel.
La ou ça devient intéressant, c'est que comme le fabricant de l'OS (Microsoft, mais ça marche avec n'importe quoi) et le fabricant de la sonde (ici, Crowdstrike) sont 2 boites séparés, le second ne peux pas compter sur le premier pour faire une solution "intégré". Et même une solution integré, ça n'aide pas sur le fait que les clients veulent quelque chose sur le parc existant (ou l'intégration n'existe pas encore), pas le parc futur.
Et donc pourquoi avoir une sonde ? Parce que ça fait parti des obligations grandissantes en matière de sécurité informatiques.
Être capable de voir que quelqu'un est dans ton lan, ça rentre dans ce périmètre, et on peut remercier les différentes lois comme le RGPD, etc, etc pour ça.
Pour commencer j'insiste sur le fait que ce n'est vraiment pas du troll et que j'essaie de comprendre à côté de quoi je passe sachant que je n'ai rien de tout ça sur les serveurs que j'administre.
Mais la question est "est ce que ça doit se passer dans le kernel", ce qui implique de
savoir ce que "ça" recouvre exactement. De ce que je comprends, Falcon sensor est un >outil >de monitoring pour la sécurité. Par exemple, tu as un process qui commence à ouvrir des >connexions tcp vers tout ton lan sur tout les ports, la plateforme est censé le voir, et >c'est signe soit qu'une machine s'est fait pourrir et que les attaquants scannent le lan, >soit qu'un salarié faire n'imp. pour faire ça, faut pouvoir intercepter des appels systémes. >Y a qu'un endroit pour faire ça, le kernel.
Je suis perplexe. J'ai un outil de monitoring qui me remonte en temps réel les users connecté et les commandes exécuté sur la machine par un user connecté. Le tout sur un serveur hors de l'infra. Autre pays, autre DC autre range d'ip. Tout est remonté dans une console de monitoring. J'ai dans la console qui est connecté où et qui fait quoi et bien sur devant cette console il y a 3 personnes et chaque alerte génère la création d'un ticket.
Ici pas besoin d'attaquer le kernel pour faire ça.
J'ai ce même outil qui me remonte à intervalle régulier (1min) la liste des processus qui tourne, les ports et les connexions ouvertes. De la même manière uniquement les processus, les ports et les connexions autorisé ne déclenchent pas d'alerte. Tout ce qui n'est pas explicitement autorisé déclenche une alerte et ça remonte dans la console et ouvre un ticket.
Tout ça sans module kernel.
La seule chose que je vois pour contourner ce système ce serait de remplacer les binaires (ps, ss etc) et donc que la personne soit root sur une machine dont le ssh n'est accessible que via un lan et ou chaque personne et chaque commande lancé est tracé dans un outil externe. Toutes les applications tournent avec un user non root. Mais c'est vrai que ça tourne dans un crio qui lui tourne en root.
Une personne pourrait arriver à injecter du code dans une application web (on ne fait que du web), sortir du serveur d'application, rentrer dans le container, passer root, sortir du container, rester root et remonter sur une des machines du cluster. Sur le papier c'est un chemin qui me semble possible mais vraiment pas simple. Ca fait un paquet de zéro day à exploiter.
Mais pour moi ce genre de chose c'est une attaque ciblée. Et il est bien plus simple de troller un des salariés pour avoir son mdp que de monter un truc aussi complexe.
Donc que pourrait m'apporter ce système ? Sur twitter on m'a dit que ça permettait de découvrir des 0day inconnu et ceci grâce à l'IA. Là j'y vois surtout de la com. Je vois aussi surtout un binaire dont j'ai pas le code, qui se loge dans le kernel, qui est root et qui se connecte à internet. Dans le temps on appelait ça un trojan.
Les "outils" (spywares) style crowdstrike, ou cortex xdr, s'incrustent sur ton systeme via le module kernel. Ainsi, ils décodent aussi bien ssl/tls que ssh, et remontent la collecte de donnée (surement via un hook lors des appels des libs concernées). Ça leur permet également de sniffer pour détecter des échappements typiques tels que DNS utilisé en canal caché.
Pour moi ça introduit des failles techniques (ça devient valable pour un vilain de viser des exploitations de ces modules, surement moins robustes que le kernel), et humaines (qui "analyse" ces données ?)
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
certes, mais comment ce code malicieux arrive juste que sur ma machine. C'est ça que je n'arrive pas à comprendre. C'est si courant que ça d'avoir un remote root exploit dans nginx, ssh, haproxy (c'est tout ce qui écoute sur mes serveurs) ? Je n'en ai vraiment pas l'impression.
Je schématise, bien sûr, c'est un poil plus compliqué que ça (au dessus, c'est du détournement qu'on pratiquait avec MS-DOS).
Je pense que ça détourne syscall (géré via une interruption il me semble) et le linker dynamique. Si le programme à parasiter contient tout le code critique en statique (jamais vu ça, mais potentiellement possible), je ne sais pas comment les XDR s'y prennent.
Il restera de toutes façons syscall dont aucun programme ne peut se passer (ou difficilement en établissant une table de jump , ce qui est difficile vu que les emplacements ne sont pas connus à l'avance. Même MS a abandonné les adresses statiques et tout est relogé, voire mélangé façon jeu de poker pour éviter les points d'entrées évidents).
Donc pour les appels dynamique, c'est réglé avec le module kernel qui fait ce qu'il veut avec tes … threads-euh.
Les XDR de tout crin sont-ils capable de reconnaître un appel SSL statique ,de breaker et d'intercepter ? Là est la question, et déméler la pelote dépasse mes compétences actuelles.
Ça serait intéressant à tester. AMHA, ça va plutôt lever une alerte de leur « module IA » qui va voir passer une bouillie indécodable. Ensuite, coup de fil du siège qui a reçu le rapport tout chaud du CAB (centre d'analyse de Bombay) et mise à pied du petit malin. Parce que la sécurité, c'est pour les gens sérieux, pas pour les rigolos qui n'y connaissent rien et s'amusent sur linuxfr.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
Si tu fais ça via une architecture "naive" a base de cron glorifié (genre un process en userspace qui fait des snapshots, au pif, xymon si je me ne me trompe pas), il y a un risque de race condition voir d'infection plus rapide que l'intervalle des snapshots. La liste des processus qui tourne, un rootkit peut se cacher. Faut pas chercher longtemps pour voir des tutos sur comment faire sur Linux, et pareil sur Windows.
Le kernel offre de quoi surveiller, il y a des sondes via kprobe, il y a auditd, etc. Maintenant, savoir si ça suffit est une question qui requiert sans doute plus de détails sur ce que fait crowdstrike, mais ça prouve bien qu'il faut être au niveau du kernel.
Techniquement, oui, on pourrait faire plus en userspace. Le Hurd existe et le fait. Personne ne l'utilise par contre.
Feu NuFW permettait de faire la gestion de firewall en userspace. Les perfs étaient pourris (et c'est pour ça que le logiciel ne regardait que le paquet syn initial pour décider), et la boite a fait faillite, mais c'était possible de le faire.
Mais au final comme l'espace kernel a la possibilité d'aller faire n'importe quoi sur l'userspace, ça devient assez vite une limite suivant ce que tu veux faire.
Je ne veux pas faire du sensationnalisme, mais je pense qu'un rootkit peut mettre moins d'une minute avant d'etre root. Il y a des exploits qui prennent du temps (ALSR, etc, etc), mais c'est assez indépendant de la partie "infection" en elle même qui peut et est sans doute automatisé dans pas mal de cas. Tu peux regarder ce qui se fait via le concours pwn2own pour voir ce qui est possible en terme de temps.
Une personne pourrait arriver à injecter du code dans une application web
Je pige pas trop ton chemin, car ça serait sans doute "execution dans un process" => "exploit local pour devenir root". Oui, les conteneurs évitent pas mal de souci, faire tourner les choses en pas root aussi. Maintenant, c'est pas 0. En 2016, on a eu dirtycow (CVE-2016-5195). On a eu ssh y a pas longtemps qui permet de devenir root, vu que personne ne filtre ssh sur localhost.
Tu dis que tu as la liste des processes toutes les minutes, mais sur linux (pas sur openbsd), c'est assez trivial de renommer ton process. En fait, si tu as injecté ton code dans apache, c'est un binaire apache qui apparait dans la liste des process.
Ensuite, la question est surtout "est ce que quelqu'un va dépenser de l'argent sur ton infra", et la réponse est sans doute "non". Maintenant, le concept d'OIV existe, et je ne doute pas que les entreprises concernées ont des contraintes sans doute plus fortes qui font que oui, une attaque ciblé rentre dans leur périmètre, ce qui ne serait pas le cas d'une agence web, d'une usine de sac plastique ou d'une bibliothèque.
Comme des gens l'ont fait remarquer sur le web, c'est surtout des entreprises dans des secteurs hautement régulés qui ont été impactés (banque, hopitaux, transport, etc), donc on peut supposer que les contraintes et les risques ne sont pas les nôtres (ni les moyens).
Là j'y vois surtout de la com. Je vois aussi surtout un binaire dont j'ai pas le code, qui se loge dans le kernel, qui est root et qui se connecte à internet. Dans le temps on appelait ça un trojan.
On va pas non plus se mentir, la faille xz montre bien qu'avoir le code n'est pas vraiment non plus la panacée car tout le monde suppose que quelqu'un d'autre va relire (car si la tentative de backdoor a été trouvé quand quelqu'un a constaté un
Mais donc d'après la définition que tu donnes, un driver réseau sous windows est un trojan ?
La ou ça devient intéressant, c'est que comme le fabricant de l'OS (Microsoft, mais ça marche avec n'importe quoi) et le fabricant de la sonde (ici, Crowdstrike) sont 2 boites séparées, le second ne peux pas compter sur le premier pour faire une solution "intégrée".
crowdstrike est apparemment1 l'anti-virus intégré à Microsoft windows par défaut, c'est un choix de Microsoft de s'appuyer sur un prestataire, autant lui octroyer des possibilités d'intégration avancées, non ?
En parlant de bourse, le LSE (bourse de Londres) etait passé sous Linux https://www.itpro.com/615985/why-the-london-stock-exchange-went-for-linux
(bonne vitrine pour nous car ce sont des systèmes haute performance ou chaque part de seconde compte)
et là ils ont pas démarré, ils doivent avoir un mix du coup ?
Comment autant d'entreprises peuvent installer autant d'infrastructures sur la même base technique ?
Tu peux remercier le Gartner pour cela… Google pour "gartner crowdstrike"…
Ça manque de régulation, mais ça, c'est mon côté gauchiste
Au contraire, là où je bosse on est cerné par les régulateurs (NBB, BCE, DBF, …) et si tu ne suis pas les recommendations du Gartner, tu te fais taper sur les doigts.
Posté par Psychofox (Mastodon) .
Évalué à 10.
Dernière modification le 19 juillet 2024 à 13:17.
Crowdstrike c'est un peu le truc qui est apparu dans toutes les grandes entreprises en quelques années. En partie liée aux audits de SOC2 et d'un marketing hyper aggressif. C'était présenté à des managers comme la solution antivirus cloud powered ultime (ajoute les buzzwords que tu veux) pour serveur dans des powerpoints bien baveux qui font tomber les managers comme des mouches.
Et Gartner, c'est ze publication que tous les managers pressés qui ne veulent pas réfléchir lisent et en suivent les recommandations.
Regarde un peu l'imagerie, crowdstrike ça sauve même ton IT des monstres masqués en sweat-shirt polaire à capuche:
Alors qu'en fait c'est un malware et une porte d'entrée additionnelle aux attaques comme la plupart des antivirus.
Ils auraient dû se méfier, on voit bien qu'il s'agit d'une représentation moderne de Zeus (why? À cause du i grec !) qui depuis son nuage foudroie la foule (crowd strike) :-).
Et Gartner, c'est ze publication que tous les managers pressés qui ne veulent pas réfléchir lisent et en suivent les recommandations.
Pourquoi cette popularité en France ? Après tout c'est une boite américaine, ils vont forcément favoriser des solutions non souveraines du point de vue UE.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Surtout que d'emblée, le site ne me semble pas respecter le RGPD : refuser les cookies demande plus d'étapes que de tous les accepter ! Ça devrait les discalifier d'office comme prescripteurs de solution de conformité…
Et avant que les gens s'agitent dans une croisade anti-windows, Crowdstrike est aussi vendu et installé sur une palanquée de serveurs linux de l'industrie. Cette fois-ci ça a touché windows et donc Azure en dommage collatéral, mais ça aurait bien pu faire pécloter des milliers (millions?) de serveurs linux avec un autre bug.
Posté par gUI (Mastodon) .
Évalué à 5.
Dernière modification le 19 juillet 2024 à 13:35.
La question mérite d'être posée…
En gros si j'ai bien tout compris c'est un fichier binaire exécutable de CrowdStrike qui est corrompu (un .SYS). Là sous Windows c'est BSOD, et ça boote plus. Du coup t'es obligé à la main de passer en mode sans echec, et de supprimer ce fichier à la main.
Sur un système Linux, est-ce que ça peut foutre le système complet en carafe ? Il me semble que c'est pas possible (kernel space, user space toussa) mais faudrait voir si CrowdStrike version Linux impacte le kernel (style un module ?). Ou alors par exemple un service systemd qui serait considéré comme vital et qui relancerait en boucle sans fin la machine ?
Par contre au passage vu que c'est systématique, on ne félicitera pas l'envoi d'une mise à jour qui n'a manifestement pas été testée…
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Posté par Psychofox (Mastodon) .
Évalué à 6.
Dernière modification le 19 juillet 2024 à 13:52.
Je n'ai pas analysé l'agent crowdstrike falcon en détail sur nos serveurs linux me je me méfierait. Ces machins veulent avoir accès au ring0 à l'ensemble de la mémoire de ton OS, killer des process. Donc j'imagine qu'ils pourraient sur un autre bug killer un process système de ta distrib sur un faux positif par exemple.
Imagine ton systemd qui est tué par erreur à chaque démarrage de l'agent. Certe tu n'aurais pas forcément un écran bleu de la mort, mais ton OS serait tout aussi inutilisable et tu serais obligé de démarrer en single user pour régler le problème.
Il y a clairement eu un problème dans leur release process. Si la panne est aussi globale que ça en a l'air, ils auraient du pouvoir l'identifier sur un plus petit lot de serveurs de tests.
Si la fiabilité de l'information est aussi bonne que celle de l'encart « valeurs associées », ce serait moins drôle/moral.
Au moment ou je lis (c'est probablement mis à jour dynamiquement), dans l'encart se trouve :
Air France KLM : -100% !!! (probablement une dizaine de Boeing crashé simultanément pour arriver à un tel résultat).
LSE GROUP : à la fois -58.xx et -0,xx% (un état intriqué ???).
Sur le fond, je ne peux m’empêcher de déplorer l'usage de ces outils nuageux et privateurs dans les services publics dans la mesure où des solutions équivalentes (en termes de fonctionnalités réelles), moins dépendantes d'infrastructures géantes, moins onéreuses, moins suspectent du point de vue de la confidentialité, etc, existent.
Ils ont laissé la mise à jour automatique sur leur prod sans qu'elle soit avant validée hors prod ?
Dans ce cas c'est pas tant Microsoft ni CrowdStrike qu'il faut blamer, mais peut-être ceux qui déploient une mise à jour sans qu'elle soit validée hors prod non ? A moins que j'aie raté quelque chose ?
Je pense que la faute est à blâmer à divers échelons. Crowdstrike et les entreprises qui ont des serveurs avec des agents dessus et activent les maj auto. Il faut dire que crowdstrike pousse ses clients à le faire en leur vendant une réactivité accrue en cas d'attaques/virus.
C'est quand même le truc de base à ne pas valider : rien en prod tant que ça n'a pas été testé hors prod, même pour des mises à jour de sécurité. Personne n'a encore réussi à me convaincre du contraire (mais je suis prêt à entendre les arguments contraires - ce qui ne veut pas dire queje les accepterai).
Sur de la prod je désactive les MAJ automatiques, quel que soit l'OS. Et bien souvent, en cas de faille critique, il est bien souvent possible de selectionner la mise à jour à appliquer, et on est rarement pris au point de devoir faire cette mise à jour sans un minimum de précaution (sinon c'est qu'on a un problème bien plus grave dans son SI).
C'est quand même le truc de base à ne pas valider : rien en prod tant que ça n'a pas été testé hors prod
Dans mon entreprise CrowdStrike est installé sur les laptops des employés et personne n'a la main sur l'activation ou la désactivation des MAJ.
Inutile de te dire que ce matin il y avait la queue devant le bureau technique…
Posté par Misc (site web personnel) .
Évalué à 4.
Dernière modification le 19 juillet 2024 à 22:07.
De ce que j'ai compris, c'est des signatures qui ont été mises à jour, et ça ne passe sans doute pas via les mêmes canaux que des mises à jour de code pour la plupart des admins.
Et je pense qu'il y a des bonnes raisons de déployer rapidement des signatures sur un produit de sécurité.
Mais bon, moi, je suis aussi le type qui a des Fedora comme firewall, et des mises à jours auto sur tout les serveurs, ce qui me semble meilleur compromis par rapport au budget humain qu'on a dans mon équipe.
Moi je suis pour les maj autos…mais sur des planning différenciés entre prod et pas prod. Si les environnements de tests pètent et que tu as 2-3 jours pour t'en rendre compte c'est facile de désactiver la maj sur la prod.
Bon ça implique d'héberger sa propre copie des mirroirs pour pouvoir faire des snapshots.
L'exception française, môssieur. On a esquivé le nuage de Tchernobyl, failli éviter le Covid (d'ailleurs on avait bazardé les masques, c'est dire si on était confiants), et là on a eu presque trois fois rien de la queue de l'écume du problème MONDIAL minus nous. La classe américaine à la française, quoi.
C'est comme Pisa : ballec, nous c'est pas pareil…
# Microsoft -> CrowdStrike
Posté par Gellule 💊 . Évalué à 10. Dernière modification le 19 juillet 2024 à 10:46.
C'est plutôt une panne géante de CrowdStrike.
[^] # Re: Microsoft -> CrowdStrike
Posté par Misc (site web personnel) . Évalué à 6.
Ouais, c'est difficile de blamer Microsoft quand c'est un vendeur externe qui se positionne dans le kernel et fait une erreur.
Ça serait comme dire qu'il y a une panne de Linux le jour ou un driver nvidia fait n'importe quoi.
Car bon, si Microsoft bloque les drivers encore plus, on va dire qu'ils abusent de leur position dominante, que c'est contre la liberté, etc. Si ils font rien, ce genre de merde arrive.
[^] # Re: Microsoft -> CrowdStrike
Posté par oau . Évalué à 8.
On pourrait se demander par contre pourquoi il y a besoin de ce genre de logiciel qui n'est pas un driver sur un windows, non ?
[^] # Re: Microsoft -> CrowdStrike
Posté par Misc (site web personnel) . Évalué à 10.
Parce qu'il y a des méchants pirates.
Alors on peut se demander le rapport avec un driver, mais il faut bien voir que "driver", c'est utiliser dans le sens "module noyau" pour Windows.
Est ce qu'on peut surveiller une machine sans module noyau ? Oui, mais tu vois pas tout. Sous linux, quand tu utilises systemtap, tu compiles un module que tu lances dans le kernel. Tu veux faire de l'EBPF, tu charge le code dans le kernel. Et sinon, tu peux directement faire un module kernel, comme le fait crowdstrike sur RHEL.
Donc bon, on va pas dire que Linux a une architecture différente.
Mais la question est "est ce que ça doit se passer dans le kernel", ce qui implique de savoir ce que "ça" recouvre exactement. De ce que je comprends, Falcon sensor est un outil de monitoring pour la sécurité. Par exemple, tu as un process qui commence à ouvrir des connexions tcp vers tout ton lan sur tout les ports, la plateforme est censé le voir, et c'est signe soit qu'une machine s'est fait pourrir et que les attaquants scannent le lan, soit qu'un salarié faire n'imp. pour faire ça, faut pouvoir intercepter des appels systémes. Y a qu'un endroit pour faire ça, le kernel.
Donc ça tourne niveau kernel. C'est comme les antivirus, si tu veux scanner avant d'ouvrir un fichier, faut le faire dans le kernel.
La ou ça devient intéressant, c'est que comme le fabricant de l'OS (Microsoft, mais ça marche avec n'importe quoi) et le fabricant de la sonde (ici, Crowdstrike) sont 2 boites séparés, le second ne peux pas compter sur le premier pour faire une solution "intégré". Et même une solution integré, ça n'aide pas sur le fait que les clients veulent quelque chose sur le parc existant (ou l'intégration n'existe pas encore), pas le parc futur.
Et donc pourquoi avoir une sonde ? Parce que ça fait parti des obligations grandissantes en matière de sécurité informatiques.
Être capable de voir que quelqu'un est dans ton lan, ça rentre dans ce périmètre, et on peut remercier les différentes lois comme le RGPD, etc, etc pour ça.
[^] # Re: Microsoft -> CrowdStrike
Posté par antistress (site web personnel) . Évalué à 7.
En fait cet élément de sécurité est la cause d'une… vulnérabilité ?
[^] # Re: Microsoft -> CrowdStrike
Posté par flan (site web personnel) . Évalué à 2.
Non, pas d’une vulnérabilité : d’un problème.
[^] # Re: Microsoft -> CrowdStrike
Posté par Faya . Évalué à 9.
Ou bien une solution :
[^] # Re: Microsoft -> CrowdStrike
Posté par antistress (site web personnel) . Évalué à 3.
Ton commentaire fait le lien en moi avec cette news NVIDIA, tiens
https://linuxfr.org/users/guillawme/liens/nvidia-transitions-fully-towards-open-source-gpu-kernel-modules#comment-1964164
[^] # Re: Microsoft -> CrowdStrike
Posté par oau . Évalué à 9.
Pour commencer j'insiste sur le fait que ce n'est vraiment pas du troll et que j'essaie de comprendre à côté de quoi je passe sachant que je n'ai rien de tout ça sur les serveurs que j'administre.
Je suis perplexe. J'ai un outil de monitoring qui me remonte en temps réel les users connecté et les commandes exécuté sur la machine par un user connecté. Le tout sur un serveur hors de l'infra. Autre pays, autre DC autre range d'ip. Tout est remonté dans une console de monitoring. J'ai dans la console qui est connecté où et qui fait quoi et bien sur devant cette console il y a 3 personnes et chaque alerte génère la création d'un ticket.
Ici pas besoin d'attaquer le kernel pour faire ça.
J'ai ce même outil qui me remonte à intervalle régulier (1min) la liste des processus qui tourne, les ports et les connexions ouvertes. De la même manière uniquement les processus, les ports et les connexions autorisé ne déclenchent pas d'alerte. Tout ce qui n'est pas explicitement autorisé déclenche une alerte et ça remonte dans la console et ouvre un ticket.
Tout ça sans module kernel.
La seule chose que je vois pour contourner ce système ce serait de remplacer les binaires (ps, ss etc) et donc que la personne soit root sur une machine dont le ssh n'est accessible que via un lan et ou chaque personne et chaque commande lancé est tracé dans un outil externe. Toutes les applications tournent avec un user non root. Mais c'est vrai que ça tourne dans un crio qui lui tourne en root.
Une personne pourrait arriver à injecter du code dans une application web (on ne fait que du web), sortir du serveur d'application, rentrer dans le container, passer root, sortir du container, rester root et remonter sur une des machines du cluster. Sur le papier c'est un chemin qui me semble possible mais vraiment pas simple. Ca fait un paquet de zéro day à exploiter.
Mais pour moi ce genre de chose c'est une attaque ciblée. Et il est bien plus simple de troller un des salariés pour avoir son mdp que de monter un truc aussi complexe.
Donc que pourrait m'apporter ce système ? Sur twitter on m'a dit que ça permettait de découvrir des 0day inconnu et ceci grâce à l'IA. Là j'y vois surtout de la com. Je vois aussi surtout un binaire dont j'ai pas le code, qui se loge dans le kernel, qui est root et qui se connecte à internet. Dans le temps on appelait ça un trojan.
[^] # Re: Microsoft -> CrowdStrike
Posté par jseb . Évalué à 10.
Les "outils" (spywares) style crowdstrike, ou cortex xdr, s'incrustent sur ton systeme via le module kernel. Ainsi, ils décodent aussi bien ssl/tls que ssh, et remontent la collecte de donnée (surement via un hook lors des appels des libs concernées). Ça leur permet également de sniffer pour détecter des échappements typiques tels que DNS utilisé en canal caché.
Pour moi ça introduit des failles techniques (ça devient valable pour un vilain de viser des exploitations de ces modules, surement moins robustes que le kernel), et humaines (qui "analyse" ces données ?)
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Microsoft -> CrowdStrike
Posté par oau . Évalué à 2.
Bonjour,
certes, mais comment ce code malicieux arrive juste que sur ma machine. C'est ça que je n'arrive pas à comprendre. C'est si courant que ça d'avoir un remote root exploit dans nginx, ssh, haproxy (c'est tout ce qui écoute sur mes serveurs) ? Je n'en ai vraiment pas l'impression.
[^] # Re: Microsoft -> CrowdStrike
Posté par jseb . Évalué à 2.
Ce n'est pas de l'exploitation de faille.
C'est de l'interception de fonctions dans les libs utilisées par les logiciels que vous citez.
avant: nginx -> SSL_read()
après: nginx -> SSL_read_hooké() -> slurp() -> SSL_read()
Je schématise, bien sûr, c'est un poil plus compliqué que ça (au dessus, c'est du détournement qu'on pratiquait avec MS-DOS).
Je pense que ça détourne syscall (géré via une interruption il me semble) et le linker dynamique. Si le programme à parasiter contient tout le code critique en statique (jamais vu ça, mais potentiellement possible), je ne sais pas comment les XDR s'y prennent.
Il restera de toutes façons syscall dont aucun programme ne peut se passer (ou difficilement en établissant une table de jump , ce qui est difficile vu que les emplacements ne sont pas connus à l'avance. Même MS a abandonné les adresses statiques et tout est relogé, voire mélangé façon jeu de poker pour éviter les points d'entrées évidents).
Donc pour les appels dynamique, c'est réglé avec le module kernel qui fait ce qu'il veut avec tes … threads-euh.
Les XDR de tout crin sont-ils capable de reconnaître un appel SSL statique ,de breaker et d'intercepter ? Là est la question, et déméler la pelote dépasse mes compétences actuelles.
Ça serait intéressant à tester. AMHA, ça va plutôt lever une alerte de leur « module IA » qui va voir passer une bouillie indécodable. Ensuite, coup de fil du siège qui a reçu le rapport tout chaud du CAB (centre d'analyse de Bombay) et mise à pied du petit malin. Parce que la sécurité, c'est pour les gens sérieux, pas pour les rigolos qui n'y connaissent rien et s'amusent sur linuxfr.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Microsoft -> CrowdStrike
Posté par Misc (site web personnel) . Évalué à 4.
Si tu fais ça via une architecture "naive" a base de cron glorifié (genre un process en userspace qui fait des snapshots, au pif, xymon si je me ne me trompe pas), il y a un risque de race condition voir d'infection plus rapide que l'intervalle des snapshots. La liste des processus qui tourne, un rootkit peut se cacher. Faut pas chercher longtemps pour voir des tutos sur comment faire sur Linux, et pareil sur Windows.
Le kernel offre de quoi surveiller, il y a des sondes via kprobe, il y a auditd, etc. Maintenant, savoir si ça suffit est une question qui requiert sans doute plus de détails sur ce que fait crowdstrike, mais ça prouve bien qu'il faut être au niveau du kernel.
Techniquement, oui, on pourrait faire plus en userspace. Le Hurd existe et le fait. Personne ne l'utilise par contre.
Feu NuFW permettait de faire la gestion de firewall en userspace. Les perfs étaient pourris (et c'est pour ça que le logiciel ne regardait que le paquet syn initial pour décider), et la boite a fait faillite, mais c'était possible de le faire.
Mais au final comme l'espace kernel a la possibilité d'aller faire n'importe quoi sur l'userspace, ça devient assez vite une limite suivant ce que tu veux faire.
Je ne veux pas faire du sensationnalisme, mais je pense qu'un rootkit peut mettre moins d'une minute avant d'etre root. Il y a des exploits qui prennent du temps (ALSR, etc, etc), mais c'est assez indépendant de la partie "infection" en elle même qui peut et est sans doute automatisé dans pas mal de cas. Tu peux regarder ce qui se fait via le concours pwn2own pour voir ce qui est possible en terme de temps.
Je pige pas trop ton chemin, car ça serait sans doute "execution dans un process" => "exploit local pour devenir root". Oui, les conteneurs évitent pas mal de souci, faire tourner les choses en pas root aussi. Maintenant, c'est pas 0. En 2016, on a eu dirtycow (CVE-2016-5195). On a eu ssh y a pas longtemps qui permet de devenir root, vu que personne ne filtre ssh sur localhost.
Tu dis que tu as la liste des processes toutes les minutes, mais sur linux (pas sur openbsd), c'est assez trivial de renommer ton process. En fait, si tu as injecté ton code dans apache, c'est un binaire apache qui apparait dans la liste des process.
Ensuite, la question est surtout "est ce que quelqu'un va dépenser de l'argent sur ton infra", et la réponse est sans doute "non". Maintenant, le concept d'OIV existe, et je ne doute pas que les entreprises concernées ont des contraintes sans doute plus fortes qui font que oui, une attaque ciblé rentre dans leur périmètre, ce qui ne serait pas le cas d'une agence web, d'une usine de sac plastique ou d'une bibliothèque.
Comme des gens l'ont fait remarquer sur le web, c'est surtout des entreprises dans des secteurs hautement régulés qui ont été impactés (banque, hopitaux, transport, etc), donc on peut supposer que les contraintes et les risques ne sont pas les nôtres (ni les moyens).
On va pas non plus se mentir, la faille xz montre bien qu'avoir le code n'est pas vraiment non plus la panacée car tout le monde suppose que quelqu'un d'autre va relire (car si la tentative de backdoor a été trouvé quand quelqu'un a constaté un
Mais donc d'après la définition que tu donnes, un driver réseau sous windows est un trojan ?
[^] # Re: Microsoft -> CrowdStrike
Posté par BAud (site web personnel) . Évalué à 0.
crowdstrike est apparemment1 l'anti-virus intégré à Microsoft windows par défaut, c'est un choix de Microsoft de s'appuyer sur un prestataire, autant lui octroyer des possibilités d'intégration avancées, non ?
https://github.com/CrowdStrike/falcon-scripts/blob/main/powershell/install/README.md ↩
[^] # Re: Microsoft -> CrowdStrike
Posté par Psychofox (Mastodon) . Évalué à 3.
Non ce n'est pas ce qui est dit dans le lien que tu donnes, tu es dans la pure fantaisie, on croirait un commentaire écrit par une LLM.
# j'ai hésité à en faire un journal
Posté par jseb . Évalué à 4.
J'attendais qu'un autre microsoftien se trahisse.
(on apprend également que tu boursicotes entre deux piquets de grève).
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: j'ai hésité à en faire un journal
Posté par antistress (site web personnel) . Évalué à 6. Dernière modification le 19 juillet 2024 à 11:24.
En parlant de bourse, le LSE (bourse de Londres) etait passé sous Linux
https://www.itpro.com/615985/why-the-london-stock-exchange-went-for-linux
(bonne vitrine pour nous car ce sont des systèmes haute performance ou chaque part de seconde compte)
et là ils ont pas démarré, ils doivent avoir un mix du coup ?
[^] # Re: j'ai hésité à en faire un journal
Posté par dj_ (site web personnel) . Évalué à 5.
C'est leur site web d'actu qui ne fonctionne pas (il est resté sous windows)
[^] # Re: j'ai hésité à en faire un journal
Posté par Victor STINNER (site web personnel) . Évalué à 3.
J'ai écrit un journal : https://linuxfr.org/users/vstinner/journaux/une-mise-a-jour-de-l-antivirus-crowdstrike-bloque-des-milliers-de-postes-windows-au-demarrage
[^] # Re: j'ai hésité à en faire un journal
Posté par antistress (site web personnel) . Évalué à 3. Dernière modification le 19 juillet 2024 à 15:45.
Bizarre : tout se passe dans les Liens de nos jours
(je blague, bonidé)
[^] # Re: j'ai hésité à en faire un journal
Posté par antistress (site web personnel) . Évalué à 3.
Tiens, pour toi :
La valeur du jour à Wall Street - CrowdStrike dans la tourmente
https://www.boursorama.com/bourse/actualites/la-valeur-du-jour-a-wall-street-crowdstrike-dans-la-tourmente-c38040947613cd8d2a8a1e250f7d8543
# Monoculture
Posté par Glandos . Évalué à 10.
On peut blâmer les vendeurs de solutions (ici Microsoft et Crowdstrike), mais moi, ce que je vois surtout, c'est un grave problème de monoculture.
Comment autant d'entreprises peuvent installer autant d'infrastructures sur la même base technique ? Le moindre pépin, et tout est foutu.
Ma logique serait la même si tout le monde avait une Debian avec ClamAV et Crowdsec d'ailleurs.
Ça manque de régulation, mais ça, c'est mon côté gauchiste ;) En tout cas, il manque au moins une sorte d'index, ou d'indicateur de « monoculture ».
[^] # Re: Monoculture
Posté par Flyounet (site web personnel) . Évalué à 5.
Tu peux remercier le Gartner pour cela… Google pour "gartner crowdstrike"…
Au contraire, là où je bosse on est cerné par les régulateurs (NBB, BCE, DBF, …) et si tu ne suis pas les recommendations du Gartner, tu te fais taper sur les doigts.
[^] # Re: Monoculture
Posté par antistress (site web personnel) . Évalué à 3.
Peux-tu préciser ?
[^] # Re: Monoculture
Posté par Psychofox (Mastodon) . Évalué à 10. Dernière modification le 19 juillet 2024 à 13:17.
Crowdstrike c'est un peu le truc qui est apparu dans toutes les grandes entreprises en quelques années. En partie liée aux audits de SOC2 et d'un marketing hyper aggressif. C'était présenté à des managers comme la solution antivirus cloud powered ultime (ajoute les buzzwords que tu veux) pour serveur dans des powerpoints bien baveux qui font tomber les managers comme des mouches.
Et Gartner, c'est ze publication que tous les managers pressés qui ne veulent pas réfléchir lisent et en suivent les recommandations.
Regarde un peu l'imagerie, crowdstrike ça sauve même ton IT des monstres masqués en sweat-shirt polaire à capuche:
Alors qu'en fait c'est un malware et une porte d'entrée additionnelle aux attaques comme la plupart des antivirus.
[^] # Re: Monoculture
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
Ils auraient dû se méfier, on voit bien qu'il s'agit d'une représentation moderne de Zeus (why? À cause du i grec !) qui depuis son nuage foudroie la foule (crowd strike) :-).
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Monoculture
Posté par Psychofox (Mastodon) . Évalué à 5.
le Y, c'est la goutte de morve que je vois couler sous son nez?
[^] # Re: Monoculture
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
C'est ça. Avec ce temps orageux, forcément…
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Monoculture
Posté par antistress (site web personnel) . Évalué à 3.
Awé l'illustration enlève tout sérieux à la boite, manmère
[^] # Re: Monoculture
Posté par antistress (site web personnel) . Évalué à 4. Dernière modification le 19 juillet 2024 à 17:53.
En plus c'est les couleurs du quartier chaud d'Amsterdam 🤔
Y'a un tit côté site de rencontres mélangé de vilains hackers.
Qui a pondu cette horreur ?
[^] # Re: Monoculture
Posté par antistress (site web personnel) . Évalué à 3.
[^] # Re: Monoculture
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Pourquoi cette popularité en France ? Après tout c'est une boite américaine, ils vont forcément favoriser des solutions non souveraines du point de vue UE.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Monoculture
Posté par aiolos . Évalué à 6.
Surtout que d'emblée, le site ne me semble pas respecter le RGPD : refuser les cookies demande plus d'étapes que de tous les accepter ! Ça devrait les discalifier d'office comme prescripteurs de solution de conformité…
[^] # Re: Monoculture
Posté par Psychofox (Mastodon) . Évalué à 10.
Et avant que les gens s'agitent dans une croisade anti-windows, Crowdstrike est aussi vendu et installé sur une palanquée de serveurs linux de l'industrie. Cette fois-ci ça a touché windows et donc Azure en dommage collatéral, mais ça aurait bien pu faire pécloter des milliers (millions?) de serveurs linux avec un autre bug.
[^] # Re: Monoculture
Posté par gUI (Mastodon) . Évalué à 5. Dernière modification le 19 juillet 2024 à 13:35.
La question mérite d'être posée…
En gros si j'ai bien tout compris c'est un fichier binaire exécutable de CrowdStrike qui est corrompu (un
.SYS). Là sous Windows c'est BSOD, et ça boote plus. Du coup t'es obligé à la main de passer en mode sans echec, et de supprimer ce fichier à la main.Sur un système Linux, est-ce que ça peut foutre le système complet en carafe ? Il me semble que c'est pas possible (kernel space, user space toussa) mais faudrait voir si CrowdStrike version Linux impacte le kernel (style un module ?). Ou alors par exemple un service
systemdqui serait considéré comme vital et qui relancerait en boucle sans fin la machine ?Par contre au passage vu que c'est systématique, on ne félicitera pas l'envoi d'une mise à jour qui n'a manifestement pas été testée…
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Monoculture
Posté par Psychofox (Mastodon) . Évalué à 6. Dernière modification le 19 juillet 2024 à 13:52.
Je n'ai pas analysé l'agent crowdstrike falcon en détail sur nos serveurs linux me je me méfierait. Ces machins veulent avoir accès au ring0 à l'ensemble de la mémoire de ton OS, killer des process. Donc j'imagine qu'ils pourraient sur un autre bug killer un process système de ta distrib sur un faux positif par exemple.
Imagine ton systemd qui est tué par erreur à chaque démarrage de l'agent. Certe tu n'aurais pas forcément un écran bleu de la mort, mais ton OS serait tout aussi inutilisable et tu serais obligé de démarrer en single user pour régler le problème.
Il y a clairement eu un problème dans leur release process. Si la panne est aussi globale que ça en a l'air, ils auraient du pouvoir l'identifier sur un plus petit lot de serveurs de tests.
[^] # Re: Monoculture
Posté par Misc (site web personnel) . Évalué à 6.
En fait, c'est déjà arrivé:
https://www.reddit.com/r/linux/comments/1e72ovd/comment/ldxc3ma/
https://access.redhat.com/solutions/7068083
# Valeurs associées
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 7. Dernière modification le 19 juillet 2024 à 11:13.
Si la fiabilité de l'information est aussi bonne que celle de l'encart « valeurs associées », ce serait moins drôle/moral.
Au moment ou je lis (c'est probablement mis à jour dynamiquement), dans l'encart se trouve :
Sur le fond, je ne peux m’empêcher de déplorer l'usage de ces outils nuageux et privateurs dans les services publics dans la mesure où des solutions équivalentes (en termes de fonctionnalités réelles), moins dépendantes d'infrastructures géantes, moins onéreuses, moins suspectent du point de vue de la confidentialité, etc, existent.
Allez, je retourne à mon LaTeX sous emacs.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# SNCF et RATP pas concernés
Posté par antistress (site web personnel) . Évalué à 4.
https://www.boursorama.com/bourse/actualites/panne-chez-microsoft-les-systemes-informatiques-d-adp-epargnes-les-operations-de-compagnies-aeriennes-perturbees-c69db9a382192e650e9150e0082a9b72
J'en deduis qu'ils doivent avoir un autre système, bonne nouvelle que tous les transports flanchent pas en même temps
[^] # Re: SNCF et RATP pas concernés
Posté par goeb . Évalué à 8.
Ou un système qui n'a pas été mis à jour récemment.
[^] # Re: SNCF et RATP pas concernés
Posté par Psychofox (Mastodon) . Évalué à 10.
Ça tourne peut-être sur win98.
[^] # Re: SNCF et RATP pas concernés
Posté par wilk . Évalué à 10.
Mon vélo n'a pas été impacté non plus.
[^] # Re: SNCF et RATP pas concernés
Posté par Anthony Jaguenaud . Évalué à 4.
Ouf !
[^] # Re: SNCF et RATP pas concernés
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4.
J'ai eu peur un moment. C'est bon d'être rassurée.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: SNCF et RATP pas concernés
Posté par antistress (site web personnel) . Évalué à 3.
Je prends !
[^] # Re: SNCF et RATP pas concernés
Posté par Psychofox (Mastodon) . Évalué à 7.
J'ai une chambre à air qui a percé sans utiliser le vélo. Tu crois que c'est lié?
[^] # Re: SNCF et RATP pas concernés
Posté par wilk . Évalué à 5.
Tu as bien vissé ton firevalve ?
# Mais pourquoi cette panne atteint-elle des serveurs de prod?
Posté par totof2000 . Évalué à 6.
Ils ont laissé la mise à jour automatique sur leur prod sans qu'elle soit avant validée hors prod ?
Dans ce cas c'est pas tant Microsoft ni CrowdStrike qu'il faut blamer, mais peut-être ceux qui déploient une mise à jour sans qu'elle soit validée hors prod non ? A moins que j'aie raté quelque chose ?
[^] # Re: Mais pourquoi cette panne atteint-elle des serveurs de prod?
Posté par Psychofox (Mastodon) . Évalué à 8.
Je pense que la faute est à blâmer à divers échelons. Crowdstrike et les entreprises qui ont des serveurs avec des agents dessus et activent les maj auto. Il faut dire que crowdstrike pousse ses clients à le faire en leur vendant une réactivité accrue en cas d'attaques/virus.
[^] # Re: Mais pourquoi cette panne atteint-elle des serveurs de prod?
Posté par antistress (site web personnel) . Évalué à 3.
Le mot bérézina te conviendrait ?
[^] # Re: Mais pourquoi cette panne atteint-elle des serveurs de prod?
Posté par totof2000 . Évalué à 3.
C'est quand même le truc de base à ne pas valider : rien en prod tant que ça n'a pas été testé hors prod, même pour des mises à jour de sécurité. Personne n'a encore réussi à me convaincre du contraire (mais je suis prêt à entendre les arguments contraires - ce qui ne veut pas dire queje les accepterai).
Sur de la prod je désactive les MAJ automatiques, quel que soit l'OS. Et bien souvent, en cas de faille critique, il est bien souvent possible de selectionner la mise à jour à appliquer, et on est rarement pris au point de devoir faire cette mise à jour sans un minimum de précaution (sinon c'est qu'on a un problème bien plus grave dans son SI).
[^] # Re: Mais pourquoi cette panne atteint-elle des serveurs de prod?
Posté par patrick_g (site web personnel) . Évalué à 10. Dernière modification le 19 juillet 2024 à 16:53.
Dans mon entreprise CrowdStrike est installé sur les laptops des employés et personne n'a la main sur l'activation ou la désactivation des MAJ.
Inutile de te dire que ce matin il y avait la queue devant le bureau technique…
[^] # Re: Mais pourquoi cette panne atteint-elle des serveurs de prod?
Posté par antistress (site web personnel) . Évalué à 3.
What's its name ? xD
[^] # Re: Mais pourquoi cette panne atteint-elle des serveurs de prod?
Posté par patrick_g (site web personnel) . Évalué à 3.
Motus et bouche cousue :-)
[^] # Re: Mais pourquoi cette panne atteint-elle des serveurs de prod?
Posté par antistress (site web personnel) . Évalué à 3.
On dirait le nom d'un jeu télé !
[^] # Re: Mais pourquoi cette panne atteint-elle des serveurs de prod?
Posté par mousquetaire G2 . Évalué à 3.
Et tout le monde a pioché une boule noire.
[^] # Re: Mais pourquoi cette panne atteint-elle des serveurs de prod?
Posté par Misc (site web personnel) . Évalué à 4. Dernière modification le 19 juillet 2024 à 22:07.
De ce que j'ai compris, c'est des signatures qui ont été mises à jour, et ça ne passe sans doute pas via les mêmes canaux que des mises à jour de code pour la plupart des admins.
Et je pense qu'il y a des bonnes raisons de déployer rapidement des signatures sur un produit de sécurité.
Mais bon, moi, je suis aussi le type qui a des Fedora comme firewall, et des mises à jours auto sur tout les serveurs, ce qui me semble meilleur compromis par rapport au budget humain qu'on a dans mon équipe.
[^] # Re: Mais pourquoi cette panne atteint-elle des serveurs de prod?
Posté par Psychofox (Mastodon) . Évalué à 5.
Moi je suis pour les maj autos…mais sur des planning différenciés entre prod et pas prod. Si les environnements de tests pètent et que tu as 2-3 jours pour t'en rendre compte c'est facile de désactiver la maj sur la prod.
Bon ça implique d'héberger sa propre copie des mirroirs pour pouvoir faire des snapshots.
# BFM
Posté par Faya . Évalué à 4.
Je ne sais pas si c'est une plaisanterie, mais BFM affirme que si la France a été moins touchée c'est «Notamment grâce à une culture du "logiciel libre" différente des autres pays européens et du monde.»
[^] # Re: BFM
Posté par antistress (site web personnel) . Évalué à 10. Dernière modification le 19 juillet 2024 à 21:50.
L'exception française, môssieur. On a esquivé le nuage de Tchernobyl, failli éviter le Covid (d'ailleurs on avait bazardé les masques, c'est dire si on était confiants), et là on a eu presque trois fois rien de la queue de l'écume du problème MONDIAL minus nous. La classe américaine à la française, quoi.
C'est comme Pisa : ballec, nous c'est pas pareil…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.