Les correctifs de sécurité PHP publiés le 21 octobre demeurent la seule solution contre PHP2Shell, une paire de vulnérabilités permettant à un attaquant non authentifié de prendre le contrôle d'un serveur vulnérable. Les correctifs ne protègent un serveur qu'une fois installés par son propriétaire et après redémarrage de PHP.

Le PDG de Cloudflare, Matthew Prince, a indiqué que les tentatives d'exploitation sur le réseau de l'entreprise étaient passées de milliers à des millions. L'agence fédérale allemande de cybersécurité, le BSI, et le gouvernement japonais ont déclaré n'avoir confirmé aucune intrusion réussie. La PHP Foundation, qui finance le développement de PHP lui-même, a indiqué avoir identifié dès 2024 les premiers signes de l'une des failles et a décrit le retard dans sa résolution comme « un échec structurel ».

Ces développements sont survenus un jour après que les deux failles PHP ont poussé des gouvernements et des organisations à mettre leurs sites web hors ligne. La question immédiate pour les internautes est de savoir s'il est sûr de naviguer normalement. La réponse courte : Internet ne s'est pas effondré, et la plupart des utilisateurs sont exposés au risque via les sites qu'ils visitent plutôt que via leurs propres téléphones ou ordinateurs. Cependant, de nombreux serveurs restent à corriger.

PHP, un langage open source côté serveur, est utilisé en coulisses par environ 70 % des sites web dont le langage de programmation côté serveur est connu. Cette portée explique pourquoi une faille dans PHP lui-même devient un événement de correction à l'échelle du web plutôt qu'un problème d'une seule entreprise. Les deux vulnérabilités, surnommées collectivement PHP2Shell, peuvent permettre à un inconnu de prendre le contrôle d'un serveur vulnérable sans s'authentifier.

PHP2Shell est-il corrigé ?

PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 le 21 octobre, selon ses notes de version. L'annonce précise : « Il n'existe aucune atténuation complète, la mise à jour est le seul choix sûr. » Au 22 octobre, PHP n'avait publié aucun correctif complémentaire.

La disponibilité d'un correctif ne signifie pas que chaque site web concerné est protégé. PHP ne se met pas à jour tout seul : les hébergeurs, les services informatiques et les propriétaires de sites individuels doivent installer la version appropriée sur leurs propres serveurs et redémarrer le logiciel pour que le changement prenne effet. En pratique, la protection se diffuse au rythme de la maintenance des serveurs plutôt qu'au moment de la publication ; le nombre de serveurs encore exposés dépendra donc de la rapidité avec laquelle les opérateurs déploieront ces mises à jour.

PHP 8.1 et les versions antérieures ne reçoivent plus de versions officielles, ce qui fait des serveurs anciens un point faible particulier. L'équipe de sécurité de PHP a toutefois publié des correctifs sommaires pour les versions 7.4, 8.0 et 8.1 destination des utilisateurs qui compilent le logiciel eux-mêmes.

Des serveurs ont-ils été compromis ?

Les attaquants ont rapidement commencé à sonder les systèmes vulnérables. Prince a déclaré que Cloudflare avait observé des milliers de tentatives d'exploitation au cours des 10 heures précédant l'annonce publique, des dizaines de milliers dans les 45 minutes suivantes, des centaines de milliers en deux heures, puis des millions ensuite.

https://x.com/eastdakota/status/2113079352682570051?ref_src=twsrc%5Etfw

Amazon a indiqué que ses serveurs leurres avaient enregistré une tentative le 17 octobre, quatre jours avant la divulgation publique des vulnérabilités. Le DSI d'Amazon, CJ Moses, a écrit qu'« il reste difficile de savoir comment l'acteur a obtenu les informations d'exploitation avant la divulgation », et a précisé que PHP2Shell était « désormais largement exploité in the wild ».

Dans un article de blog sur la sécurité, Amazon a indiqué que l'activité avait été observée avant la divulgation publique.

Les gouvernements, en revanche, n'avaient pas signalé d'intrusions réussies confirmées à ce stade. Thomas Caspers, vice-président de l'agence fédérale allemande de cybersécurité BSI, a déclaré que l'agence avait observé des attaques mais aucune exploitation réussie des failles, ajoutant : « Il semble un peu plus compliqué que prévu de les exploiter. » Le secrétaire général du cabinet japonais, Minoru Kihara, a également indiqué qu'aucune attaque exploitant ces vulnérabilités n'avait été confirmée.

Une tentative d'exploitation et une intrusion réussie sont deux événements distincts. Des millions de tentatives peuvent survenir sans qu'aucune intrusion confirmée n'ait encore été identifiée, et les intrusions réussies sont souvent découvertes après coup plutôt qu'en temps réel. Pour les lecteurs qui suivent ce dossier, cela signifie que les informations sur d'éventuelles intrusions confirmées arriveront via des enquêtes ultérieures et des divulgations officielles plutôt que par des annonces en temps réel.

Pourquoi le problème n'a-t-il pas été corrigé plus tôt ?

La PHP Foundation a déclaré que ses travaux de sécurité en 2024 « avaient trouvé les premiers signes du problème d'OOM derrière CVE-2026-109618 », en référence au bug de saturation mémoire au cœur de l'une des deux vulnérabilités.

Selon le récit de la fondation sur la version de sécurité, l'équipe a développé « plusieurs approches concurrentes » mais « a eu du mal à choisir entre elles et craignait les répercussions d'un mauvais choix ». La fondation a précisé que son financement avait permis à plusieurs personnes de travailler à temps plein sur ce problème.

« Nous ne ferons pas semblant du contraire : le retard était un échec structurel, causé à la fois par le processus de décision de l'équipe de sécurité et par son manque de ressources », a écrit la fondation. Elle a indiqué que l'équipe de sécurité, qui exigeait auparavant un consensus, prendrait désormais ses décisions à la majorité.

La fondation a également indiqué que les travaux de sécurité sur le logiciel qui fait tourner une grande partie du web « dépendent toujours d'un petit groupe de développeurs financés par la fondation et d'une aide bénévole limitée ».

Pourquoi certains sites web sont-ils restés hors ligne ?

Les correctifs prennent du temps, et les organisations qui ne pouvaient pas appliquer immédiatement le correctif ont été invitées à mettre leurs systèmes hors ligne. Le National Cyber Security Centre britannique a demandé aux organisations d'envisager de « mettre le système hors ligne jusqu'à ce qu'il puisse être entièrement atténué », selon ses recommandations.

Selon TechRadar, les sites et services touchés le 21 octobre comprenaient les services Wikimedia, les sites et applications d'Orange dans des dizaines de pays, 32 services gouvernementaux britanniques, hôpitaux néerlandais et le prestataire informatique fédéral allemand, ITZBund.

L'Office for Budget Responsibility britannique et le site du conseil municipal d'Édimbourg étaient de retour en ligne au 22 octobre. D'autres services, dont le site néerlandais de signalement anonyme de crimes Meld Misdaad Anoniem, étaient toujours hors ligne jeudi matin, selon DutchNews.

Les utilisateurs doivent-ils changer leurs mots de passe ?

Pas uniquement à cause de PHP2Shell, du moins selon les informations disponibles. Aucune fuite de données confirmée n'avait été liée aux vulnérabilités, et changer tous les mots de passe ne protégerait pas un site dont le serveur n'est pas encore corrigé.

Les mesures de sécurité standard restent utiles : utiliser un mot de passe unique pour chaque compte, activer l'authentification à deux facteurs et prêter attention aux notifications des entreprises concernant d'éventuelles fuites dans les semaines à venir. Si une entreprise confirme une fuite, les utilisateurs doivent changer le mot de passe concerné ainsi que tout autre mot de passe réutilisé.

Les propriétaires de sites web ont davantage de travail, car l'application d'un correctif ferme la vulnérabilité mais ne révèle pas si un attaquant a accédé au serveur au préalable. La société de sécurité Tag1 conseille de rechercher des fichiers PHP non téléversés par ses soins, de nouvelles tâches planifiées et de nouveaux comptes créés, et de renouveler les mots de passe de base de données et les clés API de tout serveur exposé à Internet ayant exécuté une version vulnérable. Les recommandations de Tag1 sont disponibles ici.

Que signifie PHP2Shell pour les utilisateurs de crypto ?

Le fondateur de Binance, Changpeng Zhao, a averti les utilisateurs sur X : « Appelez-moi paranoïaque, mais soyez particulièrement prudent en visitant N'IMPORTE QUEL site web ces prochains jours. »

https://x.com/cz_binance/status/2113029289155178716

Un serveur web compromis peut afficher une version falsifiée d'un site légitime. Dans le secteur des crypto-monnaies, une telle page pourrait demander à un utilisateur de connecter son portefeuille et d'approuver une transaction qui le vide. Un réseau blockchain peut rester intact alors que les sites qui y donnent accès sont compromis.

Les utilisateurs doivent vérifier attentivement ce qu'ils signent, mettre en favori les sites qu'ils utilisent plutôt que de suivre des liens, et utiliser un portefeuille matériel s'ils en possèdent un. Aucun échange de crypto-monnaies n'avait publiquement signalé de fuite liée à PHP2Shell au 22 octobre.

Est-il sûr de naviguer ?

Naviguer sur le web restait globalement aussi sûr que la semaine précédente, même si aucune activité sur Internet n'est exempte de risque. La principale exposition concernait les serveurs non corrigés. La société de sécurité Mallory a recensé environ 884 000 serveurs accessibles sur Internet exécutant des versions de PHP qui ne reçoivent plus de correctif officiel.

Amazon a exhorté les défenseurs à ne pas présumer que la date de divulgation publique correspondait à la première date d'exploitation. « Les défenseurs ne doivent pas supposer que la date de divulgation publique est la date la plus ancienne d'exploitation », a déclaré l'entreprise. Tout serveur ayant exécuté une version vulnérable de PHP depuis au moins le 17 octobre devrait être examiné, et pas simplement corrigé.

Source originale : Decrypt