Ceci est l'analyse préliminaire après incident (PIR) de CrowdStrike. Nous détaillerons notre enquête complète dans l'analyse des causes fondamentales qui sera rendue publique. Tout au long de ce PIR, nous avons utilisé une terminologie généralisée pour décrire la plateforme Falcon afin d'améliorer la lisibilité. La terminologie utilisée dans d'autres documents peut être plus spécifique et technique.
Que s'est-il passé ?
Le vendredi 19 juillet 2024 à 04:09 UTC, dans le cadre des opérations régulières, CrowdStrike a publié une mise à jour de la configuration du contenu pour le capteur Windows afin de recueillir des données télémétriques sur d'éventuelles nouvelles techniques de menace.
Ces mises à jour font partie intégrante des mécanismes de protection dynamique de la plateforme Falcon. La mise à jour problématique de la configuration de Rapid Response Content a entraîné un crash du système Windows.
Les systèmes concernés sont les hôtes Windows utilisant la version 7.11 et supérieure du capteur qui étaient en ligne entre le vendredi 19 juillet 2024 04:09 UTC et le vendredi 19 juillet 2024 05:27 UTC et qui ont reçu la mise à jour. Les hôtes Mac et Linux n'ont pas été touchés.
Le défaut dans la mise à jour du contenu a été annulé le vendredi 19 juillet 2024 à 05:27 UTC. Les systèmes mis en ligne après cette heure, ou qui ne se sont pas connectés pendant la fenêtre, n'ont pas été affectés.
Qu'est-ce qui n'a pas fonctionné et pourquoi ?
CrowdStrike fournit des mises à jour de configuration du contenu de sécurité à ses capteurs de deux manières : Sensor Content qui est livré directement avec nos capteurs, et Rapid Response Content qui est conçu pour répondre à l'évolution du paysage des menaces à la vitesse opérationnelle.
Le problème survenu vendredi concernait une mise à jour Rapid Response Content avec une erreur non détectée.
Sensor Content
Sensor Content fournit un large éventail de capacités pour aider à la réponse de l'adversaire. Il fait toujours partie de la publication d'un capteur et n'est pas mis à jour de manière dynamique à partir du cloud. Sensor Content comprend des modèles d'IA et d'apprentissage automatique sur le capteur, et comprend du code écrit expressément pour fournir des capacités réutilisables à plus long terme pour les ingénieurs de CrowdStrike chargés de la détection des menaces.
Ces capacités comprennent des Template Types (types de modèle), qui comportent des champs prédéfinis que les ingénieurs de détection des menaces peuvent exploiter dans le Rapid Response Content Les Template Types sont exprimés en code. Tous les Sensor Content, y compris les Template Types, sont soumis à un processus d'assurance qualité approfondi, qui comprend des tests automatisés, des tests manuels, des étapes de validation et de déploiement.
Le processus de mise à disposition des capteurs commence par des tests automatisés, avant et après l'intégration dans notre base de code. Cela comprend des tests unitaires, des tests d'intégration, des tests de performance et des tests de stress. Cela aboutit à un processus de déploiement du capteur par étapes, qui commence par un test interne chez CrowdStrike, suivi par les utilisateurs précoces. Le capteur est ensuite mis à la disposition des clients. Les clients ont alors la possibilité de sélectionner les parties de leur flotte qui doivent installer la dernière version du capteur (« N »), ou une version plus ancienne (« N-1 ») ou deux versions plus anciennes (« N-2 ») par le biais des politiques de mise à jour des capteurs.
L'événement du vendredi 19 juillet 2024 n'a pas été déclenché par Sensor Content, qui n'est livré qu'avec la sortie d'une mise à jour du capteur Falcon. Les clients ont un contrôle total sur le déploiement du capteur - qui comprend le Sensor Content et les Template Types.
Rapid Response Content
Rapid Response Content est utilisé pour effectuer une variété d'opérations de mise en correspondance de modèles comportementaux sur le capteur à l'aide d'un moteur hautement optimisé. Le Rapid Response Content est une représentation des champs et des valeurs, avec le filtrage associé. Ce Rapid Response Content est stocké dans un fichier binaire propriétaire qui contient des données de configuration. Il ne s'agit pas d'un code ou d'un pilote de noyau.
Le Rapid Response Content est fourni sous la forme de Template Instances (instances de modèles), qui sont des instanciations d'un Template Type donné. Chaque Template Instance correspond à des comportements spécifiques que le capteur doit observer, détecter ou prévenir. Les Template Instances disposent d'un ensemble de champs qui peuvent être configurés pour correspondre au comportement désiré.
En d'autres termes, les Template Types représentent une capacité de capteur qui permet de nouvelles télémétries et détections, et leur comportement en cours d'exécution est configuré dynamiquement par un Template Instance (c'est-à-dire un Rapid Response Content).
Rapid Response Content fournit une visibilité et des détections sur le capteur sans qu'il soit nécessaire de modifier le code du capteur. Cette capacité est utilisée par les ingénieurs chargés de la détection des menaces pour recueillir des données télémétriques, identifier les indicateurs du comportement de l'adversaire et effectuer des détections et des préventions. Rapid Response Content est une heuristique comportementale, séparée et distincte des capacités de prévention et de détection de l'IA sur le capteur de CrowdStrike.
Test et déploiement du Rapid Response Content
Le Rapid Response Content est fourni sous forme de mises à jour de la configuration du contenu au capteur Falcon. Il existe trois systèmes principaux : le Content Configuration System (système de configuration du contenu), le Content Interpreter (interpréteur de contenu) et le Sensor Detection Engine (moteur de détection du capteur).
Le Content Configuration System fait partie de la plateforme Falcon dans le cloud, tandis que le Content Interpreter et le Sensor Detection Engine sont des composants du capteur Falcon. Le Content Configuration System est utilisé pour créer des instances de modèles, qui sont validées et déployées sur le capteur par le biais d'un mécanisme appelé « Channel Files ». Le capteur stocke et met à jour ses données de configuration de contenu par le biais de fichiers de canaux, qui sont écrits sur le disque de l'hôte.
Le Content Interpreter du capteur lit le fichier de canal et interprète le Rapid Response Content, ce qui permet au moteur de détection du capteur d'observer, de détecter ou de prévenir les activités malveillantes, en fonction de la configuration de la politique du client. L'interprète de contenu est conçu pour gérer de manière élégante les exceptions liées à un contenu potentiellement problématique.
Les Template Types nouvellement publiés sont soumis à des tests de résistance sur de nombreux aspects, tels que l'utilisation des ressources, l'impact sur les performances du système et le volume d'événements. Pour chaque Template Types, une Template Instance spécifique est utilisée pour tester le Template Types en le comparant à toutes les valeurs possibles des champs de données associés afin d'identifier les interactions négatives du système.
Les Template Instances sont créées et configurées à l'aide du Content Configuration System, qui comprend le Content Validator qui effectue des contrôles de validation sur le contenu avant qu'il ne soit publié.
Chronologie des événements : Essais et déploiement du Template Type InterProcessCommunication (IPC)
Publication de Sensor Content : Le 28 février 2024, le capteur 7.11 a été mis à la disposition générale des clients, introduisant un nouveau Template Type IPC pour détecter les nouvelles techniques d'attaque qui abusent des Named Pipes. Cette version a suivi toutes les procédures de test du Sensor Content décrites ci-dessus dans la section Sensor Content.
Test de stress du Template Type : Le 05 mars 2024, un test de stress du Template Type IPC a été exécuté dans notre environnement de préparation, qui se compose d'une variété de systèmes d'exploitation et de charges de travail. Le Template Type IPC a réussi le test de stress et a été validé pour l'utilisation.
Publication du Template Instance via le Channel File 291 : Le 5 mars 2024, après la réussite du test de stress, une Template Instance IPC a été mise en production dans le cadre d'une mise à jour de la configuration du contenu. Par la suite, trois autres Template Instances IPC ont été déployées entre le 8 avril 2024 et le 24 avril 2024. Ces Template Instances ont fonctionné comme prévu en production.
Que s'est-il passé le 19 juillet 2024 ?
Le 19 juillet 2024, deux Template Instances IPC supplémentaires ont été déployées. En raison d'un bogue dans le Content Validator, l'une des deux Template Instances a passé la validation bien qu'elle contienne des données de contenu problématiques.
Sur la base des tests effectués avant le déploiement initial du Template Type (le 05 mars 2024), de la confiance dans les vérifications effectuées dans le Content Validator et des précédents déploiements réussis des Template Instances IPC, ces instances ont été déployées en production.
Lorsqu'il a été reçu par le capteur et chargé dans le Content Interpreter, le contenu problématique du Channel File 291 a entraîné une lecture hors limites de la mémoire, ce qui a déclenché une exception. Cette exception inattendue n'a pas pu être gérée de manière élégante, ce qui a entraîné un plantage du système d'exploitation Windows (BSOD).
Comment éviter que cela ne se reproduise ?
Résilience des logiciels et tests
- Améliorer les tests Rapid Response Content en utilisant des types de tests tels que :
- Tests auprès des développeurs locaux
- Mise à jour du contenu et rollback des tests
- Tests de stress, fuzzing et injection de fautes
- Tests de stabilité
- Tests d'interface de contenu
- Ajout de contrôles de validation supplémentaires au Content Validator pour le Rapid Response Content. Un nouveau contrôle est en cours pour éviter que ce type de contenu problématique ne soit déployé à l'avenir.
- Améliorer la gestion des erreurs dans le Content Interpreter.
Déploiement du Rapid Response Content
- Mettre en œuvre une stratégie de déploiement échelonné pour le Rapid Response Content dans laquelle les mises à jour sont progressivement déployées sur des parties plus importantes de la base de capteurs, en commençant par un déploiement Canary.
- Améliorer la surveillance des performances des capteurs et du système, en recueillant des feedbacks pendant le déploiement de Rapid Response Content afin d'orienter un déploiement progressif.
- Offrir aux clients un plus grand contrôle sur la diffusion des mises à jour de Rapid Response Content en permettant une sélection granulaire du moment et de l'endroit où ces mises à jour sont déployées.
- Fournir des détails sur les mises à jour de contenu par le biais de notes de mise à jour, auxquelles les clients peuvent s'abonner.
En plus de cette analyse préliminaire après incident, CrowdStrike s'engage à rendre publique l'analyse complète des causes profondes une fois l'enquête terminée.
État de la classification du dossier
Le fichier de canal responsable des pannes du système le vendredi 19 juillet 2024 à partir de 04:09 UTC a été identifié et déprécié sur les systèmes opérationnels. Lorsqu'il y a dépréciation, un nouveau fichier est déployé, mais l'ancien fichier peut rester dans le répertoire du capteur.
Par excès de prudence, et pour éviter que les systèmes Windows ne subissent d'autres perturbations, la version impactée du fichier de canal a été ajoutée à la liste des erreurs connues de Falcon dans le Cloud de CrowdStrike.
Aucune mise à jour de capteur, aucun nouveau fichier de canal ni aucun code n'a été déployé à partir du Cloud CrowdStrike.
Pour les machines opérationnelles, il s'agit d'une mesure d'hygiène. Pour les systèmes impactés disposant d'une forte connectivité réseau, cette action pourrait également entraîner la récupération automatique des systèmes en boucle de démarrage.
Ceci a été configuré en US-1, US-2, et EU le 23 juillet, 2024 UTC. Les clients de Gov-1 et Gov-2 peuvent demander la classification known-bad du fichier 291 de channel en contactant le support de CrowdStrike.
Partager