Respirez. Ça fait environ une semaine que les équipes de sécurité et de développement du monde entier traversent une période difficile. Vous n'êtes pas seuls.
Ces révélations ont fait l’effet d’une bombe, mais elles n’ont pas surgi de nulle part. En août, Jason Clinton, responsable adjoint de la sécurité des systèmes d’information chez Anthropic, avait annoncé qu’un « tsunami » de vulnérabilités allait déferler d’ici quelques mois. Et voilà qu’en octobre, nous avons eu droit à PHP2Shell, deux failles critiques d’exécution de code à distance dans PHP, et à HTTP2Shell, une faille dans la bibliothèque de compression Brotli (Broccoli2Shell ?!). Les prévisions se sont avérées exactes.
On parle désormais d’« Octobre noir », un nom qui semble exagérer l’ampleur des dégâts constatés jusqu’à présent, aucune compromission massive n’ayant encore été signalée. Mais Clinton affirme désormais que la situation va encore s’aggraver considérablement avant de s’améliorer, et qu’il faudra tenir bon pendant environ 18 mois (quoi que cela puisse signifier).
Attachez vos ceintures.
CloudflareMatthew Prince, PDG de [nom de l'entreprise], partage ce point de vue. Il estime que « nous allons traverser quelques années où, chaque semaine, nous aurons l’impression que le ciel nous tombe sur la tête ». Ce n’est pas vraiment ce qu’on appelle une bonne nouvelle pour les professionnels de la sécurité, mais nous pensons qu’il faut faire preuve de plus d’optimisme et que, à long terme, les défenseurs finiront par l’emporter, comme nous allons le voir.
Pourquoi la situation empire avant de s'améliorer
Clinton avait prévenu qu’il n’y aurait pas assez de temps pour corriger les failles des infrastructures critiques. Il conseillait de s’adresser à son conseil d’administration pour obtenir de l’aide sur les fondamentaux, ce qui, selon lui, n’avait rien à voir avec l’IA. Ces fondamentaux, comme nous l’avons décrit dans notre article consacré au « Mythos », un autre courant alarmiste tout aussi exagéré, consistent en réalité à savoir ce que l’on exploite et à être capable de déployer rapidement un correctif.
Pour comprendre pourquoi la situation s'aggrave entre-temps, il suffit de se pencher sur le cas de PHP2Shell. Le bug de mémoire insuffisante à l'origine de cette faille avait été détecté lors d'un audit en 2024, mais n'avait pas été corrigé, car personne n'avait démontré qu'il pouvait être exploité. L'année dernière, des chercheurs l'ont prouvé.
« Il y a un monde entre dire “Je constate un comportement étrange et inattendu, qui provoque peut-être un plantage momentané d’un worker” et ce qui s’est finalement produit, à savoir l’exécution de code à distance sans authentification », explique Mackenzie Jackson, directeur technique sur le terrain chez Aikido.
« Le rôle joué par l’IA a consisté à transformer cette idée rudimentaire en une véritable démonstration de faisabilité pour l’exécution de code à distance. »
Ce type de comportement inexpliqué est présent dans les langages, les environnements d'exécution et les bibliothèques sur lesquels reposent la plupart des logiciels, notamment PHP et Brotli. Jusqu’à présent, personne n’avait eu le temps de les étudier. L’IA permet désormais de réduire l’effort nécessaire pour y parvenir, en déterminant lesquels de ces comportements peuvent déboucher sur une véritable faille exploitable. C’est la combinaison de la rapidité, de la persévérance et de la capacité à enchaîner les failles qui rend l’IA si utile aux attaquants.
Pourquoi les défenseurs s'en sortent mieux
Depuis que Mythos est devenu un enjeu majeur en matière de sécurité, les équipes de sécurité ont pour consigne d’accélérer sans cesse la mise en œuvre des mesures correctives et des interventions, tout en les automatisant davantage. Réagir rapidement est l’un des meilleurs moyens de se protéger. Mais ce n’est qu’une partie de l’équation.
Cette semaine, Anton Chuvakin, ancien conseiller en sécurité chez Google, a fait valoir que les défenseurs devraient refuser la course à la vitesse et se concentrer sur les invariants : ces règles que le système applique quoi qu’il arrive. Phil Venables, expert en cybersécurité, a répondu:
« Je suis tout à fait d'accord : si votre seule réponse face à des attaquants rapides se résume à une défense réactive rapide, vous êtes fichu. Les invariants (c'est-à-dire une architecture de sécurité défensive solide appliquée de manière cohérente) sont essentiels. Mais la réactivité rapide a également sa place. »
Les deux ont raison. Une architecture de qualité limite les dégâts lorsqu’une faille est exploitée, mais elle ne peut pas éliminer la faille elle-même. Les failles découvertes la semaine dernière concernaient PHP et Brotli ; ainsi, même une équipe disposant d’une architecture irréprochable les avait tout de même dans sa pile. C’est là qu’une réaction plus rapide pour corriger ces failles revêt une importance cruciale.
Mais c’est en alliant architecture et réactivité que les équipes de sécurité prendront une longueur d’avance. Tout le monde parle de « défenseurs utilisant les mêmes modèles que les attaquants » pour y parvenir, et cela fait partie de la solution. Mais c’est la manière dont on intègre l’IA dans le cycle de vie du développement logiciel qui fait toute la différence.
Dans la pratique, le travail commence par la visibilité. On ne peut corriger que ce que l'on voit, et PHP s'est avéré présent dans des endroits où les équipes ne s'y attendaient pas, comme les images de base des conteneurs, les images d'intégration continue (CI), les panneaux d'hébergement et les logiciels de fournisseurs. C'est en sachant ce que vous exécutez, y compris ce que vous n'avez pas installé, que vous pouvez déterminer rapidement si une faille de sécurité vous concerne.
À partir de là, l’objectif est d’intégrer la sécurité dès le début et d’accélérer les corrections. Cela implique de vérifier le code au fur et à mesure de son écriture, de soumettre votre application et votre réseau externe à des tests d’intrusion à l’aide de l’IA avant la mise en production, puis à chaque modification, et de transformer chaque constat en correction pouvant être validée par un humain. Lorsqu’aucune mise à jour n’est encore disponible, ou qu’une mise à jour risquerait de causer des dysfonctionnements, conservez la version que vous utilisez et intégrez-y la correction. Les équipes qui procèdent ainsi ont moins de corrections à apporter lorsque la prochaine faille est révélée, et celles qu’elles doivent corriger sont déployées plus rapidement.
Les défenseurs disposent également d'un atout dont les attaquants sont dépourvus : la connaissance des mesures de sécurité qu'ils ont mises en place.
« On dit toujours que le défenseur doit avoir raison à chaque fois, tandis que l’attaquant n’a besoin d’avoir raison qu’une seule fois. C’est ce qui rend le rôle de défenseur si difficile. Ce n’est pas tout à fait vrai. En réalité, les attaquants ne connaissent pas toujours vos multiples niveaux de défense ni la manière dont vous mettez en œuvre votre défense en profondeur », a déclaré Willem Delbare, PDG d’ Aikido, à propos de ces vulnérabilités la semaine dernière.
« Je pense que les défenseurs ont encore l'avantage pour l'instant. Il faut bien sûr y mettre du sien », a-t-il poursuivi.
Après-demain
« Nous sommes tout à fait capables de surmonter cette épreuve. Tout dépendra de notre capacité à tirer les leçons de nos erreurs. » - Jack Hall, Le Jour d’après.
La situation risque d'être difficile à court terme, mais nous pensons que les « défenseurs » finiront quand même par s'en sortir. Des correctifs ont été publiés pour les versions de PHP prises en charge, bon nombre des sites qui devaient être mis hors ligne l'ont fait, et aucune compromission massive n'a été confirmée (pour l'instant). Chaque équipe doit identifier ses points faibles et ses lacunes, et celles qui y remédieront sortiront gagnantes.
