PHP2Shell persistera dans les environnements d’entreprise pendant des années

Deux vulnérabilités critiques ont été annoncées la semaine dernière dans PHP, le moteur d’exécution d’applications Web le plus utilisé sur Internet, et elles étaient accompagnées de l’avertissement familier de corriger immédiatement. Mais les RSSI devront faire face à la longue traîne de ces failles pendant des années en raison de l’intégration généralisée de PHP dans des produits tiers avec des cycles de correctifs que les clients ne contrôlent pas.

Les appareils NAS, les pare-feu, les passerelles VPN, les imprimantes, les panneaux de gestion de bâtiments, les appareils IoT industriels et les interfaces homme-machine (IHM) au sein des réseaux de technologie opérationnelle (OT) disposent de panneaux Web alimentés par des environnements d’exécution PHP qui ne peuvent pas être corrigés directement. Et bon nombre de ces environnements d’exécution ont des versions non prises en charge pour lesquelles les correctifs en amont ne sont pas disponibles.

Les vulnérabilités des technologies largement utilisées peuvent persister pendant des années, et certains déploiements ne sont jamais corrigés car ils se trouvent dans des produits qui ne sont plus pris en charge mais sont toujours en service. Un an après la divulgation de Log4Shell en décembre 2021, près des trois quarts des organisations disposaient toujours d’actifs vulnérables à la faille critique de l’omniprésente bibliothèque Java Log4j, qui est restée l’un des principaux vecteurs d’attaque dans les attaques du monde réel tout au long de l’année 2023.

PHP2Shell (CVE-2026-109618 et CVE-2026-109619) pourrait être encore pire que Log4Shell pour les entreprises qui ne peuvent pas identifier et corriger tous leurs actifs – et des attaques sont déjà en cours. Lundi, CISA a ajouté les deux vulnérabilités à son catalogue de vulnérabilités exploitées connues, confirmant ainsi leur exploitation active. Les chercheurs avaient déjà signalé une analyse généralisée et des tentatives d’exploitation, mais aucune compromission confirmée des systèmes de production.

Lorsque les correctifs pour les appareils et produits logiciels tiers peuvent mettre des semaines à arriver de la part des fournisseurs, les équipes de sécurité doivent réduire l’exposition par d’autres moyens, à la fois à la périphérie d’Internet et à l’intérieur des réseaux internes. Et ce n’est qu’après avoir dressé un inventaire des actifs concernés, ce qui n’est pas simple pour ces failles.

Les défis des correctifs

Le projet PHP a publié PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 en tant que versions corrigées officielles, mais se fier uniquement aux numéros de version n’est pas suffisant en raison de la manière dont PHP est distribué. La plupart des serveurs exécutent des distributions Linux qui fournissent des mises à jour d’applications via leurs propres gestionnaires de packages, y compris les distributions de support à long terme (LTS) qui regroupent les anciennes versions de PHP. Dans de nombreux cas, les correctifs devront être rétroportés manuellement par les responsables des packages pour ces distributions spécifiques.

Par exemple, PHP 7.4, 8.0 et 8.1 sont officiellement en fin de vie, même s’ils sont encore largement utilisés. Les développeurs PHP ont publié des rétroportages minimaux des sources pour ces versions afin d’aider les responsables des packages, mais PHP 7.3 et versions antérieures n’étaient pas du tout couverts. La société de renseignement sur les vulnérabilités VulnCheck a découvert que 42 % des 2,6 millions d’hôtes PHP connectés à Internet qu’elle a analysés exécutaient des branches en fin de vie, dont 27 % sur PHP 3.x à 7.3 et 15 % sur 7.4, 8.0 ou 8.1.

L’obtention du correctif sur les distributions LTS nécessite différentes approches en fonction de la version PHP fournie. Sur Ubuntu 22.04, il arrive sous forme de mise à jour gratuite de PHP 8.1 ; sur Ubuntu 20.04, le correctif PHP 7.4 nécessite un abonnement Pro ; sur Debian 11, le correctif pour PHP 7.4 fourni se trouve derrière un contrat de support étendu Freexian ; et sur AlmaLinux 8, il arrive en tant que rétroportage pour les PHP 7.2, 7.3 et 8.0 retirés. Red Hat Enterprise Linux, SUSE, Alpine et Amazon Linux établissent chacun leurs propres limites de support et celles-ci déterminent si un correctif existe pour les différentes versions de distribution.

Les numéros de version des correctifs rétroportés peuvent également être incohérents avec les versions en amont, ce qui ajoute aux défis d’inventaire. Par exemple, le patch php-8.3.33-1.el10_2.alma.1 d’AlmaLinux se trouve en dessous du numéro de version fixe en amont pour cette branche : 8.3.36. Par conséquent, un scanner qui lit une bannière de version PHP pourrait signaler un hôte comme vulnérable même lorsque la distribution a appliqué le correctif.

En plus de tout cela, il existe des images de conteneurs, de machines virtuelles et de micrologiciels prédéfinis pour toutes sortes de produits d’entreprise tiers qui disposent de leurs propres environnements d’exécution intégrés et qui sont beaucoup plus difficiles à inspecter à l’aide de scanners automatisés.

« L’équipe PHP a fait du bon travail dans une situation horrible », a déclaré Eylam Milner, co-fondateur et CTO de la société de sécurité de la chaîne d’approvisionnement logicielle Echo. « Le problème pour la plupart des entreprises est qu’elles ne savent pas où elles exécutent PHP. C’est dans les images de base et dans les composants qui regroupent leur propre runtime, et une grande partie se trouve sur des versions antérieures à 8.2 qui sont en fin de vie. « 

Il n’existe aucune estimation publique du nombre d’appliances d’entreprise ou d’appareils IoT et OT susceptibles d’exécuter des versions vulnérables de PHP, mais elles existent et certaines sont accessibles depuis Internet. La société de sécurité Flare a utilisé des analyses Internet provenant de plusieurs sources couvrant 2 220 231 enregistrements de service provenant d’hôtes PHP dans 224 pays. Dans un échantillon régional couvrant un seul État américain, ils ont identifié des périphériques NAS, des passerelles VPN, des portails d’accès à distance, des systèmes d’automatisation de bâtiment et des contrôleurs d’accès physique.

« Les organisations considèrent toujours PHP comme une dépendance d’application de base, mais il est souvent intégré profondément dans les appareils, les plates-formes d’hébergement et les images de conteneurs en amont, où l’application de correctifs dès le premier jour n’est tout simplement pas une option », a déclaré Tom Kellermann, vice-président de la sécurité de l’IA et de la recherche sur les menaces chez TrendAI. « La vraie bataille n’est pas seulement la vulnérabilité ; c’est la visibilité. »

PHP se retrouve également dans les appareils industriels qui peuvent être utilisés pendant une décennie ou plus et pour lesquels les correctifs de micrologiciel prennent du temps à développer et à déployer. Certains de ces appareils doivent être isolés jusqu’à l’arrivée des correctifs.

La société de gestion des vulnérabilités Cogent Security a analysé des dizaines d’environnements clients Fortune 500 le jour de la divulgation de PHP2Shell et a trouvé en moyenne 2 266 actifs affectés par entreprise, dont 926 exécutaient activement le service PHP et 122 étaient exposés à Internet.

L’évaluation de l’entreprise s’est concentrée sur les serveurs et les machines virtuelles, et non sur les appareils matériels et les appareils OT. Cela montre que le problème des entreprises ne sera pas l’indisponibilité des scanners, mais leur manque de visibilité sur tous les types d’actifs. En tant que telles, les organisations auront besoin d’une combinaison de stratégies pour découvrir toutes les installations PHP dans leurs environnements : depuis les versions signalées par les gestionnaires de packages basés sur l’hôte jusqu’aux scanners de réseau et aux nomenclatures de logiciels lorsqu’elles sont disponibles.

Réduire l’exposition en attendant les correctifs

Avoir un inventaire à jour est important, mais une carte complète des installations PHP ne résout pas le problème des environnements d’exécution regroupés dans des produits tiers, chacun avec son propre calendrier de correctifs et ses propres instructions d’atténuation pouvant aller de la désactivation de l’interface de gestion Web à l’isolement complet du périphérique sur le réseau.

Pour ne donner que quelques exemples, Palo Alto Networks a programmé des mises à jour pour certains de ses appareils PAN-OS cette semaine et Siemens a conseillé aux clients de ses appareils RUGGEDCOM APE1808 pour les réseaux industriels également alimentés par PAN-OS de suivre l’avis de Palo Alto. Delta Controls a mis à jour sa plate-forme de gestion de bâtiments d’entreprise enteliWEB, mais les contrôleurs de CVC et de salle concernés attendent toujours des correctifs pour le micrologiciel. Certains NetModule IIoT et routeurs industriels de Belden sont confirmés vulnérables, mais des correctifs sont toujours en cours de développement.

Jusqu’à ce que les correctifs soient disponibles, ce qui peut prendre des semaines dans certains cas, les organisations devront surveiller les avis relatifs aux produits tiers qu’elles utilisent et suivre les instructions d’atténuation temporaires pour chacun d’entre eux. Il est également probable que certains produits arriveront en fin de vie et ne recevront jamais de correctif, en particulier ceux qui prennent en charge les applications existantes dont les organisations ont encore besoin pour rester opérationnelles.

Pour un système qui ne peut pas être mis à jour, les mesures se répartissent en trois groupes :

• Supprimez l’application Web vulnérable des segments de réseau non sécurisés
• Placez les contrôles du pare-feu devant
• Évaluer si un compromis a déjà eu lieu

Dans certains cas, la gestion via HTTP ou HTTPS peut ne pas être nécessaire et les mêmes fonctionnalités peuvent être obtenues via SSH ou d’autres protocoles. Par exemple, Belden et Delta conseillent aux clients de désactiver le serveur HTTP intégré jusqu’à ce que les correctifs soient disponibles. NetScaler conseille aux clients de garder l’interface graphique et l’API de gestion accessibles uniquement à partir de réseaux administratifs approuvés.

En ce qui concerne les règles de détection du pare-feu, il existe certaines limites. Au niveau de l’application, les pare-feu d’application Web (WAF) peuvent aider, mais ils ne peuvent pas bloquer tous les exploits PHP2Shell qui abusent des téléchargements de données en plusieurs parties, car ils n’inspectent généralement pas le corps complet d’une requête Web, contrairement au moteur PHP.

Un WAF peut rechercher des modèles d’attaque connus, mais il n’analyse pas la structure interne de ces téléchargements de formulaires de manière suffisamment approfondie pour détecter toutes les variations possibles, de sorte que les attaquants peuvent modifier le formatage de la requête pour potentiellement contourner les règles. Par exemple, si un WAF examine uniquement les premiers kilo-octets d’une requête, un attaquant peut simplement compléter le début de sa charge utile avec des données indésirables pour pousser le code d’exploitation malveillant au-delà de la limite d’inspection.

De plus, si un attaquant parvient à trouver l’adresse IP directe d’un système backend, il pourrait complètement contourner les contrôles WAF. Cela ne veut pas dire que les règles WAF sont inutiles, mais elles ne constituent pas une solution miracle contre les exploits. Du côté du cloud, AWS, Cloudflare et Microsoft Azure proposent déjà des règles de protection WAF pour PHP2Shell et de nombreux WAF d’entreprise locaux ont également ajouté la détection.

L’autre type de protection par pare-feu se situe au niveau de la couche réseau via des systèmes de prévention d’intrusion (IPS). Le problème avec ces pare-feu est qu’ils pourraient être contournés s’ils ne sont pas configurés pour déchiffrer le trafic HTTPS. Les fournisseurs d’IPS ont déjà créé des détections : Palo Alto a l’ID de menace 543004 ; Check Point dispose d’une protection IPS CPAI-2026-15172 ; Cisco Talos a les règles Snort 67359 et 67360 et les règles Suricata 3000650 à 3000652 sont également disponibles.

Mais le déploiement de correctifs et d’atténuations alternatives n’aide pas les systèmes déjà compromis. Et plus la mise en œuvre de ces mesures prend du temps, plus il est probable que des attaquants aient compromis un serveur.

« Les failles PHP2Shell sont passées du bruit d’analyse à la confirmation de l’exécution de code à distance sur un pot de miel quelques jours après les correctifs du 21 octobre, et c’est dans cette lacune que se produisent la plupart des dégâts réels », a déclaré Steve Povolny, vice-président de la stratégie d’IA et de la recherche sur la sécurité chez Exabeam. « De nombreux sites n’ont pas été corrigés dès le premier jour. Certains de ces serveurs ont probablement été exploités avant que quiconque ne s’en aperçoive, et l’installation du correctif ne fait plus rien contre un intrus qui est entré la semaine dernière. L’application de correctifs ferme la porte. Elle ne vous dit pas qui est déjà à l’intérieur. »

Tout effort de détection et de prévention doit être accompagné d’une enquête sur les journaux existants, notamment les journaux d’accès et d’erreurs du serveur Web, les journaux PHP-FPM, les journaux WAF et de proxy inverse, les journaux CDN, la télémétrie EDR et de processus, les journaux DNS et de sortie, les journaux d’authentification, la surveillance de l’intégrité des fichiers et les journaux d’audit du cloud.

Comment savoir si vous avez déjà été piraté

Les éléments à rechercher dans ces journaux sont PHP_SESSION_UPLOAD_PROGRESS et un cookie PHPSESSID, les données multiparts/formulaires envoyées aux points de terminaison qui n’acceptent pas les téléchargements, les corps multiparts inhabituellement volumineux ou mal formés, les noms de champs profondément imbriqués, les POST répétés d’une seule source et les pics d’erreurs HTTP 500.

Les administrateurs doivent également rechercher les processus de travail PHP-FPM, Apache ou httpd générant sh, bash, curl, wget, base64 ou divers interpréteurs de code, les processus enfants inattendus sous le compte de service Web, les shells inversés, les connexions sortantes des travailleurs Web, ainsi que les fichiers .php nouveaux ou modifiés dans les répertoires racine Web, les répertoires de téléchargement et les répertoires de plugins. Selon les chercheurs de la société de sécurité Xint.io, une longueur anormale ou une corruption des cookies PHPSESSID, des fichiers de session inhabituellement volumineux et des redémarrages inexpliqués des travailleurs ou des erreurs de segmentation pourraient également être des signes d’exploitation.