Premiers détails sur la cause du crash de CrowdStrike CSAgent.sys
(twitter.com/patrickwardle)- Les crashs Windows à l’échelle mondiale ont d’abord été analysés comme un flux où CSAgent.sys de CrowdStrike référençait une adresse mémoire incorrecte
- L’instruction en cause était
mov r9d, [r8], etR8contenait une adresse non mappée extraite comme index depuis un tableau de pointeurs - Les fichiers
C-00000291-...xxx.sysne semblaient pas être des pilotes kernel, mais des données obfusquées lues par CSAgent.sys, que CrowdStrike a confirmées comme étant des fichiers de configuration Channel Files - CrowdStrike a indiqué que
C-00000291-avait provoqué une erreur logique menant au crash de l’OS, et a nié que la cause soit un octet nul dans le Channel File - Ce déploiement a été traité non comme une mise à jour de version mais comme une mise à jour de contenu, ce qui a dans certains cas contourné les contrôles de staging de certains clients, et le crash report a constitué un indice clé pour l’analyse de la cause
Flux du crash de CSAgent.sys
- L’analyse initiale reposait sur du reverse engineering de CSAgent.sys de CrowdStrike et sur une analyse statique à partir d’un seul crash dump
- Les éléments étaient partagés sans système Windows ni VM, avec une demande d’enquête complémentaire
- CSAgent.sys a été analysé à partir d’un fichier publié sur VirusTotal : Échantillon VirusTotal
- Le point de crash était l’instruction
mov r9d, [r8]R8était une adresse non mappée- Cette valeur provenait d’une adresse récupérée dans un tableau de pointeurs présent dans
RAX, à l’indexRDX(0x14 * 0x8)
- D’autres fichiers
.syscommeC-00000291-...32.syssemblaient être non pas de vrais pilotes mais des données obfusquées- Il y avait des indices montrant que CSAgent.sys référençait ou lisait ces fichiers
- Comme la suppression du fichier faisait disparaître le crash, l’hypothèse a été avancée que son contenu influençait le crash de CSAgent.sys
- Il était également précisé qu’un débogage permettrait de le confirmer plus facilement
- Le
.zippartagé contenait plusieurs versions de CSAgent.sys, des IDB et plusieurs fichiersC-....sys- L’un des fichiers les plus récents semblait inclure quelque chose désigné comme “fix”
- Lien partagé : Google Drive zip
Channel Files et éléments confirmés par CrowdStrike
- Kevin Beaumont a écrit que les fichiers
.sysà l’origine du problème étaient des channel update files, et qu’un format invalide avait fait planter le pilote CS de niveau supérieur- Lien : Post de Kevin Beaumont
- L’explication technique de CrowdStrike a confirmé la même direction que l’analyse initiale
- Les fichiers
C-...sysne sont pas des pilotes kernel mais des fichiers de configuration appelés Channel Files C-00000291-a déclenché une erreur logique, provoquant ensuite un crash de l’OS via CSAgent.sys- Lien : Explication technique de CrowdStrike
- Les fichiers
- Certains ont supposé qu’un Channel File vide
0x0était en cause, mais CrowdStrike a nié tout lien entre le problème et un octet nul dans le Channel File- Malware Utkonos a signalé une vérification selon laquelle le fichier devrait commencer par
0xaaaaaaaa: Post associé
- Malware Utkonos a signalé une vérification selon laquelle le fichier devrait commencer par
- Il a été confirmé que la channel update avait été déployée en contournant les contrôles de staging de certains clients
- Certains responsables IT avaient configuré les politiques CrowdStrike pour ignorer les versions les plus récentes, mais cette mise à jour l’a contourné parce qu’il ne s’agissait pas d’une mise à jour de version mais d’une mise à jour de contenu
- Post associé : Fil ResetEra
- L’expression channel files apparaît également à plusieurs reprises dans des brevets CrowdStrike
- US11822515B2 et US11645397B2 sont cités comme exemples
- La requête de recherche est
channel file assignee:(Crowdstrike, Inc.)
crash report et indices sur les System Extensions de macOS
- Le crash report a servi à comprendre le crash CrowdStrike et a aussi été utilisé pour révéler un autre 0day sur macOS
- Le titre de la présentation Black Hat associée est “The Hidden Treasure of Crash Reports?”
- Lien : Page de la présentation Black Hat
- Le fait qu’Apple ait abandonné les kext tiers au profit de System Extensions en mode utilisateur est jugé positivement
- Il est toutefois indiqué que cette transition a entraîné des kernel panic, des élévations de privilèges et des problèmes de déchargement d’outils de sécurité
- Dans macOS, le code kernel prenant en charge les System Extensions en mode utilisateur comportait de nombreux bugs, et il y a eu des cas où des outils de sécurité déplacés en mode utilisateur ont provoqué des kernel panic généralisés dans des kext cœur d’Apple
- Un problème d’élévation de privilèges dans le framework central des System Extensions de macOS est mentionné sous la référence CVE-2019-8805
- Présentation associée : Endpoint Security and Insecurity
- En raison de défauts dans le traitement des System Extensions, du code non privilégié ou des malwares peuvent provoquer le déchargement d’outils de sécurité
- Il est indiqué, à titre d’exemple, qu’il est possible d’arrêter LuLu, un pare-feu fonctionnant comme une System Extension de confiance, même sur les versions récentes de macOS
- Ce bug ne concerne pas uniquement LuLu
1 commentaires
Avis sur Hacker News
Dès que j’ai vu « c’est une mise à jour de contenu qui provoque un BSOD, et le supprimer règle le problème », je me suis dit que je pourrais parier 100 £ que c’était une combinaison de données binaires corrompues et d’un parseur mal écrit
Je fais de l’informatique assez sérieusement depuis une dizaine d’années, sans avoir du tout fait de cybersécurité, mais j’ai l’impression que presque tous les CVE, crashs, bugs, baisses de performance et autres douleurs viennent du processus qui consiste à désérialiser des données binaires pour les transformer en structures de données relisibles par la machine
Parce que les programmeurs humains oublient les cas limites, et que les langages impératifs le permettent. Cela inclut les algorithmes de décompression, les lecteurs de contours de polices, les parseurs d’images, de vidéo et d’audio, les parseurs de données de jeux, les parseurs XML/HTML, les parseurs de certificats, signatures et clés d’OpenSSL, jusqu’au parseur de contenu de l’EDR CrowdStrike cette fois-ci
Je pourrais même ajouter 50 £ de plus en considérant une deuxième hypothèse
Le fichier corrompu a soit passé les tests internes, soit il n’y avait pas de tests internes, et les réglages individuels concernant le moment d’application des mises à jour semblent aussi avoir été ignorés. En plus, le déploiement a été fait simultanément dans le monde entier, sans limiter les dégâts, et on ne sait toujours pas pourquoi le fichier a été corrompu au départ
La désérialisation de données non fiables (CWE-502) était 15e, tandis que la 1re place était occupée par l’écriture hors limites (CWE-787) et la 4e par l’utilisation après libération (CWE-416). Les faiblesses présentes dans la liste à chaque édition depuis 2019 sont récapitulées ici : https://cwe.mitre.org/top25/archive/2023/2023_stubborn_weaknesses.html
Pour référence, je travaille dans la sécurité de l’information depuis plus de 30 ans
À l’inverse, une variante de Scheme que j’utilisais il y a 20 ans était fonctionnelle, mais ne vérifiait pas que tous les cas étaient couverts, et ghc de Haskell n’activait pas non plus cette vérification par défaut il y a quelques années. Je ne sais pas si cela a changé depuis
Plusieurs responsables IT ont confirmé qu’ils avaient configuré la politique CS pour ignorer la dernière version, mais que cela avait été contourné parce qu’il ne s’agissait pas d’une « mise à jour de version » mais d’une « mise à jour de contenu ». Si une mise à jour de contenu peut casser le client, elle ne doit pas pouvoir contourner les contrôles ou politiques de staging
Indépendamment de la question de savoir si des logiciels de surveillance d’endpoints basés sur des rootkits comme CS sont vraiment nécessaires, des alternatives open source pourraient être un levier puissant pour faire évoluer ce domaine vers des standards plus éthiques
Si l’outil central est open source, ce qu’il fait exactement est transparent, et le public peut l’auditer pour vérifier l’absence de portes dérobées ou de bugs graves. En parallèle, le fait que les équipes de sécurité fournissent des signatures de malwares peut toujours constituer un modèle économique
En tant qu’utilisateur, je ne peux pas me rassurer en me disant qu’un rootkit de surveillance open source serait mieux testé, mieux développé ou qu’il prendrait mes intérêts en compte. Le problème, c’est toute la catégorie des logiciels de surveillance. Ils ne devraient pas exister. Les entreprises qui utilisent ce genre de choses ne comprennent pas la sécurité, ne font pas confiance à leurs employés et ne sont pas de bons endroits où travailler
Il est installé sur tous les appareils clients de Google
Ces outils fournissent une protection indispensable contre les menaces sophistiquées, et ils les détectent réellement. Si un test inclut des machines Windows, mon travail devient 90 % plus facile quand il n’y a pas d’EDR
Il existe des EDR open source comme OpenEDR, mais ils sont vieillissants et la qualité de leur télémétrie est mauvaise : https://github.com/ComodoSecurity/openedr. Assembler divers proof of concept trouvés sur GitHub pour en faire un EDR de production est irréaliste et dangereux
Le capteur EDR lui-même devient une cible. Du point de vue d’un attaquant, l’EDR est souvent le seul obstacle ; l’ouvrir en open source augmente donc le risque de contributions malveillantes destinées à ralentir le développement ou à introduire des vulnérabilités. Le développement de capteurs de sécurité se fait dans un environnement extrêmement hostile, où l’on ne peut pas être sûr de l’identité de l’adversaire
En réalité, c’est presque l’inverse. Il existe des règles heuristiques open source pour les malwares, comme les règles de détection d’Elastic Security : https://github.com/elastic/detection-rules. Elastic propose aussi un EDR incluant un pilote noyau, et d’après mon expérience il est plutôt plus difficile à contourner. Si l’on crée un EDR sans pilote sous Windows, mon travail devient plus facile
Les capteurs EDR sont déjà « audités » par les chercheurs en sécurité et les attaquants. Ils font en permanence l’objet de rétro-ingénierie et de débogage pour trouver leurs faiblesses. Si je découvrais un problème du niveau d’un EDR qui accepte et exécute tel quel du shellcode en mode noyau, je le publierais évidemment
C’est beaucoup plus complexe qu’un simple programme de recherche de hash
Difficile de comprendre pourquoi cela n’a pas été détecté lors du déploiement de test. Je me demande quelle était la différence qui a fait que le problème n’est apparu qu’une fois déployé dans le monde extérieur.
Il est difficile de croire que cela n’a pas été testé avant le déploiement, et les entreprises devraient aussi disposer d’un environnement de test avant de déployer des composants tiers. Pendant le développement, il est courant qu’un package échoue à l’installation ou provoque des problèmes, mais personne ne pense qu’il soit souhaitable de le mettre directement en production sans test. Je ne vois pas pourquoi ce cas serait différent.
Dans le pipeline 1, les mises à jour du code logiciel auraient été considérées comme des changements importants, avec passage par des environnements hors production et des tests canary avant le déploiement mondial d’une nouvelle « version ».
Dans le pipeline 2, les mises à jour de contenu/de canal ont peut-être été traitées différemment. Par cette voie, on ne déploie que des choses comme de nouvelles signatures de malware ; on a donc pu supposer que les nouveaux fichiers étaient des fichiers de données au format standard, simplement lus et non « exécutés ».
Ce pipeline lui-même a sans doute été testé au départ et jugé satisfaisant, mais il n’y avait probablement pas d’étape de test pour vérifier l’intégrité des fichiers de données générés, ni surtout pour s’assurer qu’ils fonctionnaient sans erreur une fois déployés sur la version logicielle la plus récente en usage.
Le logiciel agent qui lit chaque jour les fichiers de canal a sans doute été testé « en profondeur » dans le pipeline 1 avec toutes les tailles possibles de fichiers de données et du contenu simulé. Même si, bien sûr, un fichier de données invalide aurait dû être rejeté avec une erreur.
Le scénario exact ici pourrait être qu’un pipeline cassé sur la deuxième voie a produit un fichier de données invalide d’une forme inhabituelle, et que ce cas précis n’avait pas été imaginé ni testé dans le pipeline de développement, de test et de déploiement de la version logicielle.
Si c’est bien cela, la leçon est claire. Même pour un déploiement réservé aux « données », et même si le pipeline est très standardisé et stable, les tests avant un déploiement à grande échelle sont indispensables. Cela augmente les coûts et les délais, mais il faut l’accepter. C’est un peu comme le fait que les gens paient pour un logiciel de « sécurité » au départ.
Les clients entreprises devraient eux aussi tester les nouveaux livrables dans des zones hors production de leur environnement IT, ou prévoir un déploiement canary avant de les autoriser sur toute la flotte de production.
Quand l’entreprise a essayé d’entrer sur le marché de la sécurité des endpoints et de la détection d’anomalies réseau, plusieurs clients potentiels exigeaient un SLA de 4 heures pour divers types et niveaux de gravité de CVE. Cela signifiait des ingénieurs sécurité d’astreinte 24/7 et la création puis le déploiement de définitions en moins de 4 heures, avec la possibilité de les déployer sur 100 % des cibles dans ce délai.
Rédiger et déployer en 4 heures une définition de qualité pour un zero-day est déjà difficile ; la faire passer par un pipeline de test l’est encore plus, sans parler d’écrire de nouveaux tests qui la couvrent réellement. Dans ce domaine, c’était considéré comme « normal », et nous avons vite abandonné. Cela ne me surprendrait pas que CS ait fonctionné de manière similaire ici.
Cela reste lamentable, mais s’ils ont vraiment publié sans aucun test, ce serait un niveau de négligence vraiment sidérant.
Ce que je ne comprends pas est beaucoup moins technique, mais plus important : pourquoi le rayon d’impact a-t-il été aussi vaste ?
J’ai déjà vu des services beaucoup moins critiques être déployés beaucoup plus lentement, avec supervision automatique et rollback. On déployait d’abord sur une bêta sans trafic client ; si aucun problème n’apparaissait, on passait à une petite fraction de la flotte, puis on augmentait lentement la proportion d’hôtes recevant la mise à jour.
Avec cette méthode, le problème aurait été stoppé immédiatement ; je pensais que c’était une pratique courante.
Quand on prend connaissance d’un nouveau virus, il circule déjà dans la nature, donc chaque minute compte. On ne veut pas retarder d’une journée pour découvrir ensuite que son serveur a été compromis 20 heures plus tôt.
L’idée devait être que, même si l’on ne veut pas de changements potentiellement cassants, on veut quand même les dernières règles de détection de virus. Le cas limite manqué est celui où une configuration non testée casse le code existant.
Source : pure spéculation, donc ne pas citer dans un article.
Il y avait beaucoup de façons d’éviter ce problème, ou au moins d’en réduire le risque, mais comme toujours, le profit est passé avant les gens.
Il est surprenant que le rôle de Microsoft soit si peu discuté dans cette affaire. Microsoft n’est pas responsable du bug qui a directement provoqué le crash, mais elle a créé un environnement où il manque les incitations — c’est-à-dire les bénéfices et la concurrence — pour rendre Windows résilient face à ce type de situation
Microsoft est en position de quasi-monopole dans l’informatique de poste de travail et, comme Windows relève désormais presque de l’infrastructure, l’entreprise a un devoir de diligence pour garantir la sécurité, la fiabilité et les fonctionnalités du produit
Faute de concurrence, Microsoft a cessé d’innover sur Windows, et certaines de ces innovations auraient peut-être pu éviter cette panne. Par exemple, CrowdStrike s’exécute en espace utilisateur sur macOS et Linux ; Windows ne pourrait-il pas fournir les fonctionnalités nécessaires pour que CrowdStrike s’exécute en espace utilisateur ?
Des innovations dans le sandboxing des applications n’auraient-elles pas pu réduire le besoin du niveau de contrôle exigé par CrowdStrike ?
Microsoft détient de fait les clés de l’infrastructure informatique mondiale, quasiment sans concurrence et avec très peu de supervision. Windows représentait autrefois plus de 80 % du chiffre d’affaires de Microsoft, mais ce chiffre est désormais tombé à environ 10 %
Il n’y a pas de problème à ce qu’une entreprise privée cherche le profit, mais si son produit est essentiel au fonctionnement des hôpitaux, des compagnies aériennes et des infrastructures critiques, elle ne peut pas se contenter de courir après les assistants IA et la publicité pour améliorer sa rentabilité
À mon avis, Microsoft a manqué à son devoir de diligence envers les consommateurs, et CrowdStrike en est un symptôme. Les pouvoirs publics devraient soit encourager sérieusement la concurrence sur le marché des espaces de travail desktop, soit réglementer les produits Microsoft Windows
L’un des avantages de la baisse de la part de Windows dans le chiffre d’affaires est que Microsoft cessera peut-être de le traiter comme un sanctuaire intouchable
Je n’utilise pas CrowdStrike directement et, à ma connaissance, je ne l’ai jamais installé sur mon système. Il me semble que quelque chose de similaire tournait sur mon dernier ordinateur d’entreprise ; qu’on me corrige si je me trompe
Le pilote CS est d’abord installé et ne peut pas être supprimé ; il est probablement détecté par un moniteur distant, et comme c’est un pilote signé, ils semblent avoir fait beaucoup d’efforts pour le rendre difficile à modifier
Mais ce pilote charge donc des fichiers de données non signés que l’utilisateur final peut supprimer à sa guise ? Est-ce que l’utilisateur final pourrait aussi ajouter librement de tels fichiers pour faire en sorte que le pilote se comporte d’une manière qu’il ne devrait pas ?
Je me demande ce qui empêcherait un acteur malveillant d’utiliser un fichier de données malveillant pour provoquer une autre panne massive, ou pire, obtenir des privilèges noyau
Il faut monter le système de fichiers depuis un autre système d’exploitation pour y parvenir, ce que BitLocker empêche généralement
Les clients de CrowdStrike ont-ils leur mot à dire sur le déploiement de ce type de mise à jour, ou acceptent-ils simplement que CrowdStrike dispose d’une exécution de code à distance complète sur toutes les machines de leur entreprise ?
J’espère au moins que les autorités de certification et les spécialistes de la cryptographie peuvent exclure ce genre de chose de leurs systèmes
Le fait que CrowdStrike automatise cette partie est justement le cœur du produit
Peut-être que nous ne le verrons même pas. Parce que nous pourrions faire partie de ces millions
Je me demande si quelqu’un sait si ce « fichier de canal » est signé et vérifié par le pilote CS. Sinon, cela ressemble à une énorme brèche menant à un rootkit ring 0
Il faut des privilèges pour installer un fichier de canal, mais une fois que c’est possible, on peut se cacher bien plus profondément dans le système. Si un fichier de canal peut provoquer une erreur de segmentation, il peut probablement faire bien plus
Toutes les entrées traitées à un niveau de privilège aussi élevé devraient au minimum faire l’objet d’un contrôle d’intégrité. C’est la base. Le simple fait qu’on puisse supprimer un fichier de canal suggère qu’il n’existe même pas de mécanisme anti-altération