• [^] # Re: Microsoft -> CrowdStrike

    Posté par (site web personnel) . En réponse au lien Une panne géante de Microsoft paralyse de nombreuses entreprises dans le monde. Évalué à 4.

    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 ?