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.