Auteur Sujet: Crowdstrike, l'écran tout bleu du 19 juillet écarlate.  (Lu 8725 fois)

0 Membres et 1 Invité sur ce sujet

ericse

  • Abonné Free fibre
  • *
  • Messages: 431
Crowdstrike, l'écran tout bleu du 19 juillet écarlate.
« Réponse #156 le: 27 juillet 2024 à 14:17:03 »
Il faudrait préciser que le rôle du PRA n'a pas pour but de réduire la sévérité du désastre, mais uniquement sa durée, en organisant au mieux le retour à la normale.

C'est le PCA qui doit organiser le mode dégradé de fonctionnement, en reportant les activités qui peuvent l'être, en mettant en oeuvre des moyens ou locaux de remplacement, au besoin en revenant au mode manuel et papier/crayon, et au pire en arrêtant "proprement" tout ou partie de l'activité.

Le PRA lui-même ne démarre que lorsque la situation est stable, bref quand on est au fond du trou, et que l'on envisage de remonter la pente ;)
Et de toute façon, qu'elle ait été "Planifiée" ou non, il y aura toujours une "Reprise d'Activité", même si c'est uniquement de faire et déposer le bilan...

Mais mélanger PRA et PCA c'est s'assurer de mal affecter les ressources.

rooot

  • Abonné RED by SFR fibre FttH
  • *
  • Messages: 2 099
  • 🔵🔵🔵🔵⚪⚪⚪⚪🔴🔴🔴🔴
Crowdstrike, l'écran tout bleu du 19 juillet écarlate.
« Réponse #157 le: 29 juillet 2024 à 13:20:39 »

vivien

  • Administrateur
  • *
  • Messages: 47 698
    • Twitter LaFibre.info
Crowdstrike, l'écran tout bleu du 19 juillet écarlate.
« Réponse #158 le: 08 août 2024 à 09:39:36 »
Crowdstrike a publié mardi 6 août 2024 un rapport détaillé expliquant comment la faille a pu échapper à ses procédures de test.

En résumé, le code fautif faisait appel à « vingt et unième paramètre », en réalité inexistant, qui n’était pas utilisé dans les précédentes mises à jour du logiciel, ni dans les tests conduits par l’entreprise, ce qui explique qu’il est passé inaperçu.

(cliquez sur la miniature ci-dessous - le document est au format PDF)

vivien

  • Administrateur
  • *
  • Messages: 47 698
    • Twitter LaFibre.info
Crowdstrike, l'écran tout bleu du 19 juillet écarlate.
« Réponse #159 le: 08 août 2024 à 09:45:16 »
Traduction rapide des parties les plus importantes du PDF :

Avec la sortie de la version 7.11 du capteur en février 2024, CrowdStrike a introduit un nouveau type de modèle pour permettre la visibilité et la détection de nouvelles techniques d'attaque qui abusent des canaux nommés et d'autres mécanismes de communication interprocessus Windows (« IPC »). Comme indiqué dans le PIR, le nouveau type de modèle IPC a été développé et testé conformément à nos processus de développement de contenu de capteur standard et a été intégré au capteur pour préparer son utilisation sur le terrain. Les instances de modèle IPC sont fournies sous forme de contenu de réponse rapide aux capteurs via un fichier de canal correspondant numéroté 291.

Le nouveau type de modèle IPC définissait 21 champs de paramètres d'entrée, mais le code d'intégration qui appelait l'interpréteur de contenu avec les instances de modèle du fichier de canal 291 ne fournissait que 20 valeurs d'entrée à comparer. Cette incompatibilité du nombre de paramètres a échappé à plusieurs couches de validation et de test de build, car elle n'a pas été découverte pendant le processus de test de la version du capteur, le test de stress du type de modèle (à l'aide d'une instance de modèle de test) ou les premiers déploiements réussis d'instances de modèle IPC sur le terrain. Cela était dû en partie à l'utilisation de critères de correspondance génériques pour la 21e entrée pendant les tests et dans les instances de modèle IPC initiales.

Le 19 juillet 2024, deux instances de modèle IPC supplémentaires ont été déployées. L'une d'entre elles a introduit un critère de correspondance non générique pour le 21e paramètre d'entrée. Ces nouvelles instances de modèle ont donné lieu à une nouvelle version du fichier de canal 291 qui obligerait désormais le capteur à inspecter le 21e paramètre d'entrée. Jusqu'à ce que ce fichier de canal soit livré aux capteurs, aucune instance de modèle IPC dans les versions de canal précédentes n'avait utilisé le champ de paramètre d'entrée 21. Le validateur de contenu a évalué les nouvelles instances de modèle, mais a basé son évaluation sur l'attente que le type de modèle IPC soit fourni avec 21 entrées.

Les capteurs qui ont reçu la nouvelle version du fichier de canal 291 contenant le contenu problématique ont été exposés à un problème de lecture hors limites latent dans l'interpréteur de contenu. Lors de la notification IPC suivante du système d'exploitation, les nouvelles instances de modèle IPC ont été évaluées, en spécifiant une comparaison avec la 21e valeur d'entrée. L'interpréteur de contenu n'attendait que 20 valeurs. Par conséquent, la tentative d'accès à la 21e valeur a produit une lecture de mémoire hors limites au-delà de la fin du tableau de données d'entrée et a entraîné un blocage du système.

En résumé, c'est la confluence de ces problèmes qui a entraîné une panne du système : l'inadéquation entre les 21 entrées validées par le validateur de contenu et les 20 entrées fournies à l'interpréteur de contenu, le problème de lecture hors limites latent dans l'interpréteur de contenu et l'absence de test spécifique pour les critères de correspondance non génériques dans le 21e champ. Bien que ce scénario avec le fichier de canal 291 ne puisse plus se reproduire, il informe également sur les améliorations de processus et les mesures d'atténuation que CrowdStrike déploie pour garantir une résilience encore renforcée.




Et pour quoi les tests réalisés n'ont pas détecté le problème ?

Des tests manuels et automatisés ont été effectués lors du développement du type de modèle IPC. Ces tests étaient axés sur la validation fonctionnelle du type de modèle, notamment sur le flux correct des données relatives à la sécurité qui y transitent, et sur l'évaluation de ces données pour générer des alertes de détection appropriées en fonction des critères créés dans les cas de test de développement.

Les tests automatisés ont exploité des outils internes et externes pour créer les données de sécurité requises pour tester le type de modèle IPC sous toutes les versions Windows prises en charge dans un large sous-ensemble des cas d'utilisation opérationnels attendus. Pour les tests automatisés, un ensemble statique de 12 cas de test a été sélectionné pour être représentatif des attentes opérationnelles plus larges et pour valider la création d'alertes de télémétrie et de détection. Une partie de ces tests comprenait la définition d'un fichier de canal à utiliser dans les cas de test. La sélection des données dans le fichier de canal a été effectuée manuellement et comprenait un critère de correspondance générique regex dans le 21e champ pour toutes les instances de modèle, ce qui signifie que l'exécution de ces tests pendant les builds de développement et de publication n'a pas exposé la lecture hors limites latente dans l'interpréteur de contenu lorsqu'il était fourni avec 20 entrées au lieu de 21.

Atténuation : augmenter la couverture des tests pendant le développement du type de modèle. Pour confirmer que nous validons tous les champs de chaque type de modèle, des tests automatisés ont été créés pour tester avec des critères de correspondance non génériques pour chaque champ. Cette étape a été effectuée pour tous les types de modèles existants et est requise pour tous les types de modèles futurs.

De plus, tous les types de modèles futurs incluent des cas de test avec des scénarios supplémentaires qui reflètent mieux l'utilisation en production.




Ce qui a changé dans le déploiment des mises à jour :

1/ chaque instance de modèle sont maintenant déployée progressivement, lors d'un déploiement par étapes

2/ La plateforme Falcon a été mise à jour pour offrir aux clients un contrôle accru sur la diffusion du contenu Rapid Response. Les clients peuvent choisir où et quand les mises à jour du contenu Rapid Response sont déployées. Nous continuons d'améliorer cette capacité pour offrir un contrôle plus précis sur les déploiements du contenu Rapid Response ainsi que les détails des mises à jour du contenu via des notes de version, auxquelles les clients peuvent s'abonner.




Enfin, l'avenir est à faire fonctionner les produits de sécurité en espace utilisateur :

La présence dans le noyau offre une riche visibilité sur les activités liées à la sécurité à l'échelle du système, telles que la création de processus et de threads, ou les fichiers en cours d'écriture, de suppression et de modification sur le disque. Les interfaces exposées par le noyau permettent aux pilotes de CrowdStrike d'appliquer des contrôles critiques pour un produit de sécurité, tels que la prévention en ligne des processus malveillants ou le blocage des fichiers malveillants en cours d'écriture sur le disque.

Le pilote du noyau de CrowdStrike est chargé dès les premières phases de démarrage du système pour permettre au capteur d'observer et de se défendre contre les logiciels malveillants qui se lancent avant le démarrage des processus en mode utilisateur.


[...]

CrowdStrike certifie chaque nouvelle version de capteur Windows via le programme Windows Hardware Quality Labs (WHQL), qui comprend des tests approfondis via tous les tests requis dans le kit Windows Hardware Lab (HLK) et le kit de certification matérielle Windows de Microsoft (HCK). Le processus de certification WHQL marque la fin d'un ensemble complet de tests internes comprenant des tests fonctionnels, des tests de longévité, des tests de contrainte avec injection de fautes, des tests de fuzzing et de performances. Lors des tests requis pour le programme WHQL, les capteurs utilisent les dernières versions des fichiers de canaux au moment de la certification.

À mesure que les nouvelles versions de Windows introduisent la prise en charge de l'exécution d'un plus grand nombre de ces fonctions de sécurité dans l'espace utilisateur, CrowdStrike met à jour son agent pour utiliser cette prise en charge. Un travail important reste à faire pour l'écosystème Windows pour prendre en charge un produit de sécurité robuste qui ne repose pas sur un pilote du noyau pour au moins certaines de ses fonctionnalités. Nous nous engageons à travailler directement avec Microsoft de manière continue, à mesure que Windows continue d'ajouter davantage de prise en charge pour les besoins en produits de sécurité dans l'espace utilisateur.

Steph

  • Abonné K-Net
  • *
  • Messages: 7 896
  • La Balme de Sillingy 74
    • Uptime K-net
Crowdstrike, l'écran tout bleu du 19 juillet écarlate.
« Réponse #160 le: 08 août 2024 à 09:53:04 »
En gros, t'as un tableau de 10 cases numérotées de 0 à 9 et tu vas taper dans la numéro 10.

Vieux comme le C...

pju91

  • Abonné Free fibre
  • *
  • Messages: 918
  • 91
Crowdstrike, l'écran tout bleu du 19 juillet écarlate.
« Réponse #161 le: 08 août 2024 à 12:30:14 »
En gros, t'as un tableau de 10 cases numérotées de 0 à 9 et tu vas taper dans la numéro 10.

Vieux comme le C...
Mouais, un peu plus subtil quand même ici.
A une époque (très ancienne) je m'amusais à faire des trucs fun, du genre provoquer une boucle infinie dans un programme C en cassant la "pile" en écrivant à une adresse hors du tableau ...

Mais si je comprends bien l'article, un "bug" existait quand même depuis février 2024. 12 pages pour nous expliquer qu'ils ont me...dé.


Cochonou

  • Abonné Bbox fibre
  • *
  • Messages: 1 383
  • FTTH 2 Gb/s sur Saint-Maur-des-Fossés (94)
Crowdstrike, l'écran tout bleu du 19 juillet écarlate.
« Réponse #162 le: 09 août 2024 à 13:45:20 »
Ce n'est pas comme si ce genre de problèmes arrivait en permanence dans les développements en C/C++, même avec des développeurs expérimentés. Ce qui est plus surprenant pour moi c'est ça :
Citer
For automated testing, a static set of 12 test cases was selected to be representative of broader operational expectations and to validate the creation of telemetry and detection alerts.
Vu le nombre de cas qui peuvent être rencontrés pour cette fonction et le nombre de machines sur lesquelles le soft est déployé, ça me semble ridiculement bas.
On fait beaucoup plus de tests sur dans des contextes moins ouverts et avec des logiciels tournant sur un plus petit nombre de machines...
Mais il y a probablement un nombre de tests de non-régression gigantesque quand on considère toutes les fonctions du logiciel.

Free_me

  • Abonné Free fibre
  • *
  • Messages: 3 279
  • Marseille
Crowdstrike, l'écran tout bleu du 19 juillet écarlate.
« Réponse #163 le: 09 août 2024 à 16:15:22 »
Ben il n'y avait pas de test pour quand le fichier de definitions est foireux, rien de plus
De mon experience, les tests ne marchent jamais. Enfin c'est la perception, malheureusement, tu payes plus cher en dev pour te dire que le truc est blindé, et a la fin quand on tombe sur un bug insupportable en prod, haben ouais, y avait pas de test pour ce cas-la....
Enfin mon cas n'est surement pas une generalité j'imagine.

testing5555

  • Abonné Bbox fibre
  • *
  • Messages: 586
  • Lyon 3 (69)
Crowdstrike, l'écran tout bleu du 19 juillet écarlate.
« Réponse #164 le: 09 août 2024 à 16:32:24 »
Ben il n'y avait pas de test pour quand le fichier de definitions est foireux, rien de plus
De mon experience, les tests ne marchent jamais. Enfin c'est la perception, malheureusement, tu payes plus cher en dev pour te dire que le truc est blindé, et a la fin quand on tombe sur un bug insupportable en prod, haben ouais, y avait pas de test pour ce cas-la....
Enfin mon cas n'est surement pas une generalité j'imagine.
Problème de perception : le problème qui arrive en prod et qui n’est pas une erreur d’utilisation peut toujours être vu comme un test manquant.
Mais ça cache tous les problèmes détectés avant la mise en prod quand les tests sont bien faits (et forcément on ne communique pas sur les bugs corrigés avant que le soft sorte, ça n’est pas bon niveau marketing…). Encore faut-il qu’ils soient bien fait et idéalement par des gens dédiés et non les devs (qui effectivement ont du mal à tester les cas qu’ils n’ont pas imaginé et donc traiteé lors du dev)

C’est un peu le même système que les attentats : tu as beau en stopper 99% avant qu’ils arrivent le grand public ne va garder à l’esprit que le cas qui aura déjoué la surveillance…

trekker92

  • Abonné Free adsl
  • *
  • Messages: 1 337
Crowdstrike, l'écran tout bleu du 19 juillet écarlate.
« Réponse #165 le: 18 août 2024 à 01:07:09 »
tu as beau en stopper 99% avant qu’ils arrivent le grand public ne va garder à l’esprit que le cas qui aura déjoué la surveillance…
ca fonctionne magistralement pour tout, et c'est très esprit de société et de vie d'aujourd'hui, que de pointer ce qui ne fonctionne pas : c'est anormal.
quand ca marche, c'est normal, c'est l'inverse qui est scandaleux, et il ne manquerait plus qu'un "merci" en surplus de ce qui est déjà "remercié" par le tarif.


sinon, c'est sur que si crowdstrike avait été utilisé dans des situations critiques, bonsoir les dégats: