Une semaine après le correctif d’urgence pour PHP2Shell, aucun incident majeur n’a été signalé. Selon Fox-IT, il est trop tôt pour affirmer que le danger est totalement écarté.
Rarement une faille logicielle aura autant fait la une que celle de PHP. Le 21 octobre, la PHP Foundation a publié un correctif d’urgence pour deux vulnérabilités critiques du langage de programmation. Elles étaient déjà exploitées avant même que le correctif ne soit disponible. En Belgique, DPG Media, la VUB et plusieurs hôpitaux, entre autres, ont mis leurs sites hors ligne par précaution.
Les vulnérabilités étaient sans doute déjà exploitées avant cela. La société de sécurité néerlandaise Fox-IT avait déjà observé des signalements d’exploitation possible à partir du 17 octobre, soit quatre jours avant la publication du correctif. Frank van Oeveren, interim Director Cyber Intelligence & Response chez Fox-IT, dresse un petit bilan une semaine plus tard. Dans la mesure du possible, car les conséquences éventuelles de la faille sont loin d’être connues, selon lui.
Des intrusions pas encore visibles
L’absence d’incidents majeurs signalés une semaine plus tard ne rassure pas Van Oeveren. « Il est trop tôt pour le dire. On ne voit pas toujours clairement si une intrusion a réellement eu lieu quelque part. De plus, des systèmes désormais corrigés ont pu être piratés auparavant. »
« L’exploitation était peut-être trop compliquée », dit Van Oeveren. « Mais des incidents peuvent survenir pendant des mois, voire des années. Beaucoup de serveurs ne sont pas encore corrigés, ce qui signifie que de nombreux systèmes restent vulnérables. » Il renvoie à Log4Shell, la faille de la bibliothèque Java Log4j apparue fin 2021. À l’époque aussi, des systèmes ont été piratés longtemps après sa divulgation.
Selon Van Oeveren, il existe des moyens de retrouver les traces d’une intrusion. « On peut voir si des tentatives d’accès ont déjà eu lieu. Le plus difficile, c’est qu’on ne le voit pas tout de suite. » Les organisations dotées d’un système de monitoring ont de bonnes chances de repérer un attaquant lorsqu’il tente de se déplacer plus loin dans le réseau ou effectue des tentatives de connexion suspectes. « Cela n’arrive qu’après l’attaque initiale. À ce moment-là, on est en fait déjà piraté. »
Son conseil : rester vigilant dans les semaines à venir. « Continuez à surveiller votre réseau, vos applications et tout ce qui est connecté au réseau. Il faut que cela soit bien en ordre, afin de savoir si des tentatives ont eu lieu. » Amazon recommande de remonter au moins jusqu’au 17 octobre.
De bonnes mesures de précaution
Partout dans le monde, des sites sont passés hors ligne par précaution. Même le Centre pour la Cybersécurité Belgique (CCB) a mis son propre site en mode maintenance et a conseillé aux organisations belges d’en faire autant. Un appel qui a été entendu. Van Oeveren juge ce choix justifié a posteriori.
« Better safe than sorry. On peut plaider pour ne pas le faire, mais le risque n’en vaut pas la peine. Pour les détaillants, l’arbitrage était plus difficile, car une boutique en ligne hors service coûte immédiatement du chiffre d’affaires. Même là, ils ont préféré mettre le site hors ligne un moment et ont accepté le manque à gagner. »
On ne voit généralement l’exploitation qu’à l’attaque initiale. À ce moment-là, on est en fait déjà piraté.
Frank van Oeveren, interim Director Cyber Intelligence & Response Fox-IT
Une divulgation désordonnée
On a déjà beaucoup dit et écrit sur la manière dont la vulnérabilité est parvenue au grand public. Des messages alarmistes sur la faille ont circulé massivement et la société de sécurité Chainguard a publié des images corrigées plus de six heures avant la publication officielle. La PHP Foundation ne s’en est pas montrée satisfaite par la suite.
« Les vulnérabilités sont tombées dans le domaine public, tout le monde pouvait les voir », dit Van Oeveren.. « L’information a vite été supprimée, mais tout le monde avait déjà fait des captures d’écran. » Selon lui, l’emballement médiatique a aussi eu un bon côté. « Sans attention des médias, ce genre de faille passe parfois inaperçu. Là, tout le monde a agi immédiatement. »
La pression a aussi contraint PHP à déployer le correctif plus vite que prévu. « En fait, cela devrait être possible sans que les médias s’en mêlent d’abord, mais cela a réveillé tout le monde. Au final, les choses se sont bien passées ainsi. » Selon Van Oeveren, les risques de la divulgation précoce ont donc pesé moins lourd.
Une faille connue de longue date
La PHP Foundation a reconnu par la suite que les premiers signes de l’une des vulnérabilités étaient connus depuis 2024. Comme aucune voie d’attaque n’était connue à l’époque, d’autres problèmes ont été traités en priorité. Selon Van Oeveren, cela n’a rien d’exceptionnel. « Parfois, une vulnérabilité est connue, mais il n’existe aucun chemin logique pour l’exploiter. Il faut alors une seconde vulnérabilité pour atteindre la première. Ici, l’IA les a reliées. »
La gravité et l’urgence d’une vulnérabilité doivent à chaque fois faire l’objet d’un arbitrage. « Pour évaluer la gravité, on regarde d’abord le score CVSS », explique Van Oeveren. « Il indique quel accès la faille offre, ici un accès administrateur complet pour PHP2Shell. Il faut aussi tenir compte de l’existence d’une preuve de concept et du fait que la faille soit exploitée dans la nature. »
« Si elle dépasse un certain seuil, il faut prendre une décision et la mettre en balance avec le risque : corriger immédiatement, retirer le système ou poursuivre l’analyse. » En tant que fournisseur de sécurité, Fox-IT conçoit des règles de détection pour ses clients et recherche lui-même des traces d’exploitation. « Beaucoup d’engrenages se mettent aussitôt en marche », poursuit Van Oeveren.
L’IA accélère
Les modèles d’IA auraient joué un rôle important dans la découverte de la vulnérabilité. C’est peu à peu la nouvelle norme en matière de sécurité logicielle. Lorsqu’une vulnérabilité est connue, on ne parle plus de mois, mais de jours, voire d’heures avant qu’elle puisse être exploitée. Par défaut, un fournisseur dispose de quatre-vingt-dix jours pour combler une faille avant qu’elle ne soit rendue publique.
Van Oeveren juge exagéré d’affirmer que l’IA a soudain totalement changé les règles du jeu. « Le déploiement des correctifs ne se passe finalement pas très différemment d’avant, mais beaucoup plus vite. L’IA accélère beaucoup de choses, surtout en sécurité logicielle. Les vulnérabilités sont découvertes plus vite et doivent donc aussi être corrigées plus vite. »
Attaquants et défenseurs disposent des mêmes possibilités, et un humain reste nécessaire pour vérifier, estime Van Oeveren. « Les fournisseurs utilisent eux-mêmes des LLM pour détecter les vulnérabilités, mais les criminels le font aussi. Quand une telle faille devient publique, on ne sait pas toujours. Cela arrivait déjà avant, mais à bien plus petite échelle et à un rythme plus lent qu’aujourd’hui. »
La responsabilité de tous
Ces derniers jours, on a beaucoup cherché à désigner des responsables. La PHP Foundation a appelé les utilisateurs du langage de programmation à contribuer davantage à la sécurité. Douter maintenant de la sécurité du code open source serait un mauvais réflexe, selon Van Oeveren. « Avec un logiciel propriétaire, le fournisseur peut garder une vulnérabilité secrète. C’est impossible avec l’open source.
Il voit surtout dans l’ouverture du code une force. « Tout le monde peut accéder au code, et c’est une bonne chose. Une entreprise peut garder une vulnérabilité secrète. L’open source, nous pouvons tous le tester, et les gens le font. Ils considèrent le logiciel comme le leur et le traitent comme tel. » Cette responsabilité est partagée. « Les entreprises qui intègrent du code open source dans leur offre à leurs clients ont aussi intérêt à y affecter des personnes », ajoute-t-il.
Même maintenant que l’IA est utilisée en sécurité logicielle, l’open source a ses avantages. « Pour tester des vulnérabilités avec des LLM, il faut le code source. On ne peut pas tester ainsi un logiciel dont le code n’est pas public. L’open source en sort donc finalement plus sûr. »
Savoir ce que l’on a en place
La vigilance reste de mise, selon Van Oeveren. Le code PHP est partout : environ 70 pour cent d’internet en dépend. Les organisations doivent donc bien savoir ce qu’elles ont en place. « La plupart des organisations en ont une bonne vision. Cela va de pair avec la maturité. Certaines n’ont aucune vue d’ensemble de leur propre environnement. »
La réglementation y aide un peu. NIS2 impose cette vue d’ensemble, y compris aux PME. « Avant, cela se faisait trop souvent en best effort. Aujourd’hui, ce genre de choses est imposé. Les entreprises dépendent davantage les unes des autres et ont donc aussi plus d’obligations les unes envers les autres. En tant que consommateur ou utilisateur de services, on doit pouvoir s’y fier. »
Sa principale leçon pour les CISO et les IT-managers est bien connue. « C’est ce que nous répétons depuis cinq à dix ans : sachez ce que vous avez en place, ce qui est exposé à internet, et ayez une gestion des correctifs en ordre. Tout commence par ces conseils de base, ensuite on va plus loin. Cela implique aussi que, si vous êtes piraté, et cela peut toujours arriver, vous sachiez quand quelqu’un est entré. »
Van Oeveren n’ose pas prédire l’ampleur des dégâts que PHP2Shell finira par causer, ni combien de temps on en parlera encore. « Nous ne savons pas ce qui va encore sortir, ni en quelle quantité. » Reste à savoir si la faille PHP se révélera une tempête dans un verre d’eau ou un tsunami dévastateur : nous ne le saurons sans doute que dans quelques années.