Crowdstrike lève petit à petit le voile sur les causes de la mise à jour défectueuse du capteur de son agent Falcon (Falcon Sensor). Le fournisseur de cybersécurité a ainsi pointé plusieurs lacunes ayant entraîné depuis vendredi 19 juillet le plantage de millions d'ordinateurs Windows. Ces manquements concernent deux procédures : celle de mise à jour de signature d'exploit (Rapid Response Content) et celle de test d'intégrité de ses fichiers de canaux (Content Validator). Dans son analyse préliminaire de l'incident, Crowdstrike a confirmé que le plantage des ordinateurs de ses clients était dû à une faille dans le fichier Channel 291, qui fait partie d'une mise à jour de la configuration de ses capteurs diffusée sur les systèmes Windows à 04:09 UTC le 19 juillet. Dans son rapport, le fournisseur a fourni une première explication sur la manière dont cette faille a été déployée et a indiqué les changements qu'elle apporte à ses processus pour éviter que cela ne se reproduise. Crowdstrike n'est pas la seule entreprise à envisager des changements à la suite de l'incident : de nombreux DSI reconsidèrent également leur dépendance à l'égard des logiciels cloud comme ceux de Crowdstrike.

La revue de Crowdstrike décrit le processus de test rigoureux qu'elle applique aux nouvelles versions de son agent logiciel et aux fichiers de données par défaut qui les accompagnent - ce qu'elle appelle Sensor Content - mais indique que la faille se trouvait dans un type de mise à jour de signature d'exploit qu'elle appelle Rapid Response Content, qui fait l'objet de vérifications moins rigoureuses. Les clients ont la possibilité d'utiliser la dernière version de Sensor Content ou l'une des deux versions précédentes s'ils préfèrent privilégier la fiabilité plutôt que la couverture des attaques les plus récentes. Le contenu de réponse rapide est toutefois déployé automatiquement sur les versions de capteurs compatibles. Le contenu de réponse rapide est stocké dans un fichier binaire propriétaire qui contient des données de configuration plutôt que du code. Les fichiers sont livrés sous forme de mises à jour de la configuration du capteur Falcon, ce qui permet à la plateforme de mieux détecter les caractéristiques d'une activité malveillante en se basant sur la reconnaissance des comportements. Crowdstrike utilise son système de configuration du contenu pour créer des instances de modèles décrivant le comportement à détecter, en les stockant dans des fichiers de canaux qu'il teste ensuite à l'aide d'un outil appelé Content Validator.

Un compte à rebours vers la catastrophe

Falcon Sensor 7.11 a été mis à la disposition des clients le 28 février, introduisant un nouveau type de modèle pour détecter les nouvelles techniques d'attaque sur les communications interprocessus (IPC) qui abusent de ce que l'on appelle les Named Pipes. Le premier Channel File 291 a été mis en production le 5 mars après un test de résistance réussi. Les instances du modèle qui s'appuient sur le fichier de canal 291 ont été diffusées sans problème le 5 mars, le 8 avril et le 24 avril. Une catastrophe s'est produite lorsque deux autres instances de modèles ont été déployées le 19 juillet. « En raison d'un bogue dans Content Validator, l'une des deux instances de modèle a passé la validation bien qu'elle contienne des données de contenu problématiques », a déclaré Crowdstrike dans son rapport.

Ce qui semblait être une mise à jour mineure de la configuration d'un composant qui avait été testé et était déjà en production a en fait déclenché une vague de pannes. Néanmoins, le fournisseur a affirmé avoir agi de manière responsable avant ce qui s'est avéré être un désastre. « Sur la base des tests effectués avant le déploiement initial du type de modèle (le 5 mars 2024), de la confiance dans les vérifications effectuées par Content Validator et des précédents déploiements réussis de l'instance de modèle IPC, ces instances ont été déployées en production », a expliqué Crowdstrike. « Lorsqu'il a été reçu par le capteur et chargé dans l'interpréteur de contenu, le contenu problématique du fichier de canal 291 a entraîné une lecture de la mémoire hors limites, 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) », a ajouté l'organisation.

Une amélioration des tests à venir

Dorénavant, les mises à jour de Crowdstrike seront testées localement avant d'être envoyées aux clients. Des tests de mise à jour du contenu et de retour en arrière seront effectués, ainsi que des tests supplémentaires de stabilité et d'interface du contenu. Les procédures existantes de traitement des erreurs dans l'interprète de contenu seront améliorées de sorte que, par exemple, les bogues ne fassent que planter le programme au lieu de déclencher une panne du système d'exploitation. Crowdstrike introduira également une stratégie de déploiement échelonné pour le contenu de réponse rapide à l'origine de l'incident du 19 juillet. Dans un premier temps, le nouveau contenu fera l'objet d'un « déploiement canari » afin de détecter les problèmes critiques, avant d'être diffusé auprès d'une part de plus en plus importante de sa base de clients. Elle permettra également aux clients de refuser les toutes dernières versions du contenu, en offrant « une sélection granulaire du moment et du lieu où ces mises à jour sont déployées ».

Les premières réactions à l'analyse de Crowdstrike et au plan de remédiation des experts en sécurité, tels que Kevin Beaumont, ont été positives. La réponse de Crowdstrike a été très bonne après l'erreur », a déclaré M. Beaumont dans un fil de discussion sur Twitter/X. “Ils réalisent clairement qu'ils doivent désormais donner la priorité à la sécurité”. « Ils ont clairement compris qu'ils devaient désormais donner la priorité à la sécurité.