• # Microsoft -> CrowdStrike

    Posté par  . Évalué à 10 (+13/-1). Dernière modification le 19 juillet 2024 à 10:46.

    C'est plutôt une panne géante de CrowdStrike.

    • [^] # Re: Microsoft -> CrowdStrike

      Posté par  (site web personnel) . Évalué à 6 (+5/-2).

      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  . Évalué à 8 (+7/-0).

        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  (site web personnel) . Évalué à 10 (+7/-0).

          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  (site web personnel) . Évalué à 7 (+4/-0).

            En fait cet élément de sécurité est la cause d'une… vulnérabilité ?

          • [^] # Re: Microsoft -> CrowdStrike

            Posté par  (site web personnel) . Évalué à 3 (+0/-0).

          • [^] # Re: Microsoft -> CrowdStrike

            Posté par  . Évalué à 9 (+8/-0).

            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.

            • [^] # Re: Microsoft -> CrowdStrike

              Posté par  . Évalué à 10 (+8/-0).

              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 freenode / #gamedev-fr

              • [^] # Re: Microsoft -> CrowdStrike

                Posté par  . Évalué à 2 (+1/-0).

                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  . Évalué à 2 (+2/-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 freenode / #gamedev-fr

            • [^] # Re: Microsoft -> CrowdStrike

              Posté par  (site web personnel) . Évalué à 4 (+2/-1).

              Tout ça sans module kernel.

              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 ?

          • [^] # Re: Microsoft -> CrowdStrike

            Posté par  (site web personnel) . Évalué à 0 (+0/-2).

            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 ?

  • # j'ai hésité à en faire un journal

    Posté par  . Évalué à 4 (+3/-1).

    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 freenode / #gamedev-fr

  • # Monoculture

    Posté par  . Évalué à 10 (+15/-0).

    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  (site web personnel) . Évalué à 5 (+4/-0).

      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.

      • [^] # Re: Monoculture

        Posté par  (site web personnel) . Évalué à 3 (+0/-0).

        Peux-tu préciser ?

        • [^] # Re: Monoculture

          Posté par  (Mastodon) . Évalué à 10 (+9/-0). 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:
          crowdstrike ooouh danger

          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  (Mastodon) . Évalué à 10 (+7/-0).

      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  (Mastodon) . Évalué à 5 (+2/-0). 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.

        • [^] # Re: Monoculture

          Posté par  (Mastodon) . Évalué à 6 (+3/-0). 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  (site web personnel) . Évalué à 6 (+3/-0).

  • # Valeurs associées

    Posté par  (site web personnel) . Évalué à 7 (+5/-0). 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 :

    • 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.

    Allez, je retourne à mon LaTeX sous emacs.

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

  • # SNCF et RATP pas concernés

    Posté par  (site web personnel) . Évalué à 4 (+1/-0).

  • # Mais pourquoi cette panne atteint-elle des serveurs de prod?

    Posté par  . Évalué à 6 (+5/-1).

    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 ?

  • # BFM

    Posté par  . Évalué à 4 (+2/-0).

    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  (site web personnel) . Évalué à 10 (+8/-1). 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…

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.