Speaker #0Ce jour-là a lieu l'un des plus gros incidents informatiques de l'histoire. Un bug majeur impliquant Falcon, l'EDR de Counter-Strike. A l'instar des œuvres faussement chaotiques de Pollock, ce bug a provoqué, ce qu'on appelle dans le jargon, un sacré bordel. Des centaines de milliers de services et d'entreprises ont été affectés par cet incident, qui a entraîné une paralysie de nombreux systèmes. Ce dysfonctionnement a impacté la disponibilité des réseaux, compromettant la sécurité et la continuité des opérations de plusieurs grandes structures. Cet événement a mis en lumière les risques et les vulnérabilités inhérents aux solutions de cybersécurité en cas de dysfonctionnement. Il a aussi rappelé à quel point notre dépendance aux technologies modernes peut avoir des conséquences majeures lorsque survient un problème à grande échelle. Ce qui a aussi été fascinant, c'est la quantité de réactions suite à ce problème. Certains ont parlé de cyberattaque, d'autres ont argumenté le fait que ce genre de problème ne pouvait pas arriver avec des solutions souveraines. Enfin bref, tout et n'importe quoi a été dit sur cette affaire. Mais avant de plonger dans les méandres de ce chaos, j'aimerais passer un instant et vous expliquer le contexte. Et avant toute chose, vous expliquer ce qu'est le produit Falcon de Cronstrike. Un EDR ou Endpoint Detection and Response est une solution de cybersécurité conçue pour protéger des terminaux d'une organisation. c'est-à-dire des ordinateurs, les serveurs et même les appareils mobiles. Contrairement aux antivirus classiques, qui se concentrent sur la détection de menaces connues, un EDR analyse en continu l'activité des terminaux pour repérer des comportements inhabituels ou suspects. En pratique, cela signifie que l'EDR surveille tout ce qui se passe sur la machine. Il identifie les activités potentiellement dangereuses et permet aux équipes de sécurité d'intervenir rapidement en cas d'incident. En cas de détection d'une anomalie, l'EDR permet une réponse immédiate en isolant la menace et en limitant son impact sur le reste du système. Cela aide non seulement à protéger les données, mais aussi à maintenir la continuité des activités d'une organisation face à des cyberattaques en constante évolution. L'EDR agit en surveillant en temps réel tous les processus et activités d'une machine afin de détecter des comportements malveillants ou suspects. C'est ce qui le différencie des antivirus classiques. En utilisant le mode kernel, l'EDR opère en interaction directe avec le noyau du système d'exploitation. la partie fondamentale qui gère les ressources matérielles de l'ordinateur, comme la mémoire et le processeur. Ce mode lui permet de surveiller des processus critiques sans dépendre des mêmes permissions ou des excès limités qu'un logiciel normal. C'est ainsi qu'il parvient à déceler des menaces avancées qui tenteraient de se dissimuler au sein de processus habituels, ou même d'interférer avec la sécurité de la machine. Si l'EDR ne fonctionnait pas à ce niveau, les cyberattaquants pourraient plus facilement dissimuler leur présence en imitant des processus normaux. Dans le cas de Falcon de CrowdStrike, l'EDR est chargé lors du démarrage avec un Boot Start Driver, ce qui signifie qu'il est intégré lors du lancement de la machine, dès que l'ordinateur s'allume. L'EDR prend le contrôle pour assurer la surveillance immédiate des processus du système. Cette inclusion dans la séquence de démarrage rend l'EDR essentiel pour le bon fonctionnement de la machine. Mais cela implique aussi que si l'EDR rencontre un problème critique, comme un bug ou un échec de démarrage, ce dysfonctionnement peut provoquer le plantage complet de l'appareil, car il est considéré comme un composant fondamental du système d'exploitation. Ce type de configuration représente donc un revers de la médaille. Lors du bug du 19 juillet 2024, une défaillance de l'EDR a provoqué une panne généralisée sur des centaines de milliers de systèmes. Des entreprises se sont retrouvées avec des machines inutilisables avec le fameux écran bleu de la mort, très significatif d'un problème de bas niveau. Beaucoup ont vu en ce problème une cyberattaque utilisant la stratégie de l'attaque de l'abreuvoir, qu'on nomme en anglais le Watering All Attacks. C'est une attaque où les cybercriminels ciblent des sites web ou des plateformes fréquemment utilisées par un groupe précis d'utilisateurs, souvent employés d'une même entreprise ou d'un même secteur d'activité. Plutôt que de cibler directement les systèmes de l'entreprise ou les appareils individuels, l'attaquant compromet un site ou un service de confiance pour que, lorsqu'un utilisateur se connecte, son appareil soit infecté. Et pour certains, le problème de Crownstrike était une attaque de ce genre. L'argument est d'autant plus intéressant car, comme nous l'avons évoqué plus haut, l'EDR tourne avec des droits plus forts que les droits administrateurs des machines. Cette situation est donc très attrayante pour un assaillant qui pourrait prendre virtuellement possession d'un nombre gigantesque de machines sans déployer beaucoup d'efforts. Cette hypothèse semble donc séduisante, mais elle ne correspond pas à la réalité des faits, et ce pour plusieurs raisons. Tout d'abord, un piratage de CrowdStrike aurait été nécessaire. CrowdStrike est une entreprise de cybersécurité réputée. avec des protections très sophistiquées et des protocoles stricts pour prévenir ce type de compromission. Un accès non autorisé à leurs systèmes, particulièrement à un niveau qui permet de manipuler leur EDR, représenterait un défi technique considérable, même pour un attaquant expérimenté. D'autre part, Microsoft applique également des contrôles de qualité rigoureux sur ses systèmes pour garantir leur stabilité. En effet, afin de maintenir un certain niveau de fiabilité, Microsoft exige des fournisseurs qui utilisent le kernel driver, comme CrossFrag avec son EDR, de passer un processus de certification. Cette certification, appelée WHQL pour Windows Hardware Quality Labs, est conçue pour tester et valider les drivers de manière indépendante. Le processus WHQL vise à minimiser les risques de défaillance en soumettant des drivers à une série de tests approfondis. Cela permet de s'assurer, dans la mesure du possible, que ces drivers ne causent pas de crash ou d'instabilité dans les systèmes Windows. En d'autres termes, la certification WHQL aide à détecter et à corriger d'éventuels problèmes avant qu'ils n'affectent les utilisateurs finaux. Admettons cependant qu'un acteur malveillant ait effectivement réussi à pénétrer les systèmes de Crown Strike. Il est très peu probable qu'il choisisse de provoquer un plantage massif des machines protégées par leur EDR. Au contraire, une cyberattaque sophistiquée visant ce type de système aurait plutôt privilégié la discrétion pour obtenir un accès prolongé et sans interruption de service. Le but serait de passer inaperçu pour collecter des données sensibles ou d'installer des backdoors, des portes dérobées, permettant un contrôle futur sans attirer l'attention par des pannes flagrantes. Par conséquent, si un bug a entraîné un dysfonctionnement de masse, il est plus probable qu'il soit lié à un problème interne, qu'à une mise à jour défectueuse ou une incompatibilité imprévue. plutôt qu'à une intrusion malveillante visant à perturber intentionnellement les services de Crownstrike. Mais quel a été ce bug ? Et comment et pourquoi l'EDR a fait planter tant de machines ? Il faut d'abord comprendre que la certification WHQL n'est pas un gilet pare-balles. Même si ces tests réduisent considérablement les risques de panne, ils ne garantissent pas une fiabilité absolue, car des incompatibilités ou des bugs imprévus peuvent toujours survenir. C'est en partie ce qui a causé le problème rencontré avec Crownstrike. Le cœur du système de Cronstrike est bel et bien certifié WHQL, mais cette certification ne s'applique pas aux fichiers de données qui l'accompagnent. Il est important de comprendre que, dans la majorité des cas, le cœur du système de détection est stable. En revanche, les fichiers de données utilisés pour modéliser les attaques et les comportements à détecter sont mis à jour très fréquemment, parfois plusieurs fois par jour, afin de rester en phase avec les nouvelles menaces. CronStrike, comme d'autres solutions de cybersécurité, suit cette dynamique de mise à jour fréquente. Dans ce cas particulier, c'est l'un de ces fichiers, essentiels pour la modélisation des comportements suspects, qui semble être à l'origine du problème. Ce fichier... qui n'a pas suivi le même processus de certification que le noyau de l'EDR, a introduit une instabilité imprévue, illustrant ainsi les limites de la certification WHQL face aux mises à jour dynamiques nécessaires pour contrer les cyber-menaces modernes. En réalité, c'est une petite modification sur un fichier, plus précisément le champ 21 du fichier Channel 291. C'est lui qui a déclenché ce cataclysme. Le cœur de l'EDR n'était programmé que pour traiter 20 champs. et ne s'attendait donc pas à en trouver un de plus. Pendant plusieurs mois, ce champ supplémentaire n'avait pas d'impact, car il contenait seulement un caractère générique ou wildcard, ce qui signifiait concrètement que le cœur de l'EDR n'avait pas à le prendre en compte. En fait, le bug existait depuis février 2024, mais n'avait encore jamais causé de problème. Cependant, le 19 juillet 2024, ce fichier a été mis à jour et le champ 21 a reçu une valeur autre que la wildcard. Et à ce moment-là, le cœur de l'EDR a tenté de traiter cette nouvelle information et a cherché à accéder à une zone mémoire incohérente, entraînant ainsi le crash de la machine. Ce changement dans la structure des données a donc révélé un défaut caché dans la structure du programme, qui, en essayant de traiter ce champ inattendu, a provoqué des pannes massives et imprévisibles des systèmes. Plusieurs millions de machines par terre à cause d'une mise à jour. C'est la triste et simple réalité du bug du 19 juillet. Mais comment se prémunir de ce type de catastrophe ? D'une part, de plus en plus de produits offrent la possibilité d'effectuer des mises à jour programmées, c'est-à-dire à des moments bien définis. Cela permet d'organiser les modifications de manière plus structurée et de détecter d'éventuels problèmes avant qu'ils ne se généralisent. Cette approche facilite également le déploiement en canary, ou déploiement par étape. Le terme canary vient de la pratique des mineurs d'autrefois. qui amenait avec eux un canary dans les mines pour détecter le grisou, un gaz explosif et toxique. Le canary chantait constamment. Si le gaz toxique était présent, l'oiseau s'arrêtait de chanter, voire mourait, signalant ainsi aux mineurs qu'il devait évacuer de toute urgence. Cette méthode, bien que cruelle, était extrêmement efficace pour leur sécurité. Il en va de même pour les déploiements de logiciels. En précédant par étapes, et en installant les mises à jour d'abord sur un petit nombre de machines, Il est possible d'observer tout effet indésirable au sein d'un groupe restreint. Cela permet de détecter et de corriger les problèmes potentiels bien en amont, avant que l'impact ne se propage à l'ensemble du système. Ce type de déploiement réduit donc les risques de bannes majeures en testant d'abord des nouvelles versions sur un environnement limité et contrôlé. Malheureusement, cette méthodologie de déploiement par étapes peut sembler contre-intuitive lorsqu'il s'agit de logiciels de sécurité. En effet, les outils de sécurité nécessitent souvent des mises à jour rapides et massives pour garantir une couverture optimale contre les attaques émergentes. Chaque minute où un EDR n'est pas à jour représente une potentielle vulnérabilité. Pour améliorer la qualité et la fiabilité de ces logiciels, il existe cependant d'autres méthodes, comme les tests approfondis de code et la vérification de sa cohérence. Ces principes sont explorés dans l'épisode intitulé Tractacus Logico-Philosophicus. qui abordent des stratégies rigoureuses pour renforcer la solidité des logiciels. Une autre voie d'amélioration consiste à permettre aux EDR de fonctionner sans avoir recours au mode kernel pour leurs opérations principales. Cela réduirait les risques de crash critique tout en maintenant une surveillance active du système. Cependant, cette fonctionnalité n'est pas encore disponible sous les systèmes Windows. En revanche, elle a été intégrée dans macOS depuis un certain temps, permettant une gestion plus souple des outils de sécurité, sans compromettre la stabilité du noyau. Si vous voulez en savoir plus, vous trouverez le lien du rapport Cronstrike en description de cet épisode. Le cas de Cronstrike est un peu comme le tableau de Pollock. Il semble aléatoire, complètement chaotique, mais en fait, il n'en est rien. Alors comme ça, vous habitez l'immeuble ? Oui, ce sont des voisins, ils habitent au-dessus.
Speaker #0Oh non, pas Mickey, on est des peintres. La méthode de Jackson Pollock pour peindre l'avant-darmiste est en réalité très structurée et réfléchie. Pollock a développé une technique qu'il appelait le drip painting ou peinture par égouttement, où il appliquait la peinture en faisant couler, éclabousser ou projeter des couleurs sur une grande toile posée au sol. Ce procédé, bien que paraissant aléatoire, était exécuté avec une précision remarquable. Dans Lavender Mist, Pollock applique plusieurs couches de peinture en mouvements calculés, utilisant des variations de vitesse, de densité et de direction pour créer un effet de profondeur et de texture. Il alterne entre des mouvements rapides et contrôlés pour déposer des gouttes fines et des gestes plus larges pour que des traînées apparaissent. Chaque ligne Éclaboussures ou tourbillons de peinture semblent suivre un rythme presque musical. Et Pollock avait une compréhension intuitive de l'espace sur la toile, lui permettant de créer un équilibre visuel malgré l'apparence du désordre. Les chercheurs ont constaté que les lignes, les éclaboussures et les gouttes de peinture présentent une structure fractale. Lorsqu'on analyse ces œuvres de près, on peut voir que les motifs de gouttes et les lignes semblent se répéter à différentes échelles. Cette répétition de formes similaires bien que de tailles variées, créent une cohésion dans l'apparente complexité. Pollock atteignait ces motifs fractales grâce à des mouvements répétitifs mais variés, en superposant des couches de peinture et en variant la densité et la largeur des traits. Les chercheurs ont même réussi à calculer les niveaux de fractalité de ces peintures, montrant qu'ils modifiaient la densité des motifs fractales au fil des années, devenant plus complexes dans ses œuvres tardives. Nous sommes focalisés sur le cas de Crown Strike, Mais il en est de même pour beaucoup d'autres pannes bien connues, comme celle de McAfee en 2010, ou Microsoft et même Google. Comme souvent en informatique, et encore plus en cybersécurité, ce qui semble chaotique en fait pour origine un enchaînement bien structuré d'événements. Imaginer qu'une solution est invulnérable, c'est comme croire que la peinture de Pollock est désordonnée et aléatoire. C'est méconnaître la réalité de ce qui se passe en profondeur. En cybersécurité, chaque incident, chaque brèche... est souvent le résultat d'une suite logique de failles, d'actions et de réponses. Cela peut donner l'impression d'un chaos imprévisible, mais ce n'est qu'en surface. Derrière chaque problème de cybersécurité, on retrouve une série de décisions et de configurations techniques, des vulnérabilités exploitées et des réactions en chaîne qui, ensemble, créent cette apparente instabilité. De la même manière, les œuvres de Pollock peuvent sembler désorganisées, mais elles sont en réalité le produit d'un processus précis où chaque geste chaque couche de peinture est intentionnelle. Penser qu'un système d'information est invulnérable revient à nier les interconnexions complexes qui existent entre les différents composants d'un système. Tout comme voir un tableau de Pollock comme un simple amas de peinture revient à ne pas comprendre les motifs fractales et la structure sous-jacente de son travail. Dans les deux cas, une analyse en profondeur révèle un ordre caché sous le désordre apparent. Encore un grand merci d'avoir écouté cet épisode de la cybersécurité expliquée à ma grand-mère. N'hésitez pas à le liker, à le partager avec d'autres et à en parler autour de vous. Si vous êtes sur Spotify, vous pouvez aussi donner votre avis et proposer des sujets qui vous semblent pertinents. Mais surtout n'oubliez pas, pour certains, la cybersécurité est un danger de vie ou de mort. C'est bien plus sérieux que ça.
