En bref : selon des rapports, CERT-EU conseille de recenser les installations PHP, de les corriger immédiatement et d'isoler les applications accessibles publiquement si elles ne peuvent pas être corrigées rapidement. CERT-Bund et le BSI (office fédéral allemand de la sécurité des technologies de l'information) recommandent dans leur alerte la mise à jour immédiate et, si elle n'est pas possible, de mettre temporairement hors réseau les serveurs web concernés. Les recommandations se rejoignent sur l'essentiel : la mise à jour d'abord, l'isolation comme solution de secours, les mesures transitoires seulement en complément.
Qui alerte, et pour qui ?
Pour PHP2Shell, plusieurs organismes officiels ont réagi en quelques heures. Pour les entreprises en Allemagne, le BSI, avec son équipe de réponse aux urgences informatiques CERT-Bund, est le premier interlocuteur. CERT-EU est le service de cybersécurité des institutions de l'UE ; ses avis s'adressent d'abord à celles-ci, mais sont lus dans toute l'Europe. Selon BleepingComputer, le National Cyber Security Centre britannique a lui aussi lancé une alerte. Dans le secteur privé, Huntress et Cloudflare, entre autres, se sont manifestés.
Pour vous, exploitant, l'origine compte moins que la concordance. Lorsque plusieurs organismes indépendants conseillent la même chose, c'est un signal fort.
CERT-Bund, CERT-EU et les autres : comparaison des alertes PHP
| Organisme | Recommandation principale | Particularité |
|---|---|---|
| BSI / CERT-Bund | mettre à jour immédiatement, sinon mettre temporairement les serveurs web hors réseau | niveau d'alerte 3 / orange |
| CERT-EU | recenser les installations PHP, corriger immédiatement, sinon isoler les applications publiques | jugeait possible, selon des rapports, que les versions à partir de PHP 5 soient concernées |
| UK NCSC | mettre à jour immédiatement ou mettre les systèmes concernés hors réseau jusqu'au correctif | selon BleepingComputer |
| php.net | passer à 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, mesures transitoires seulement comme protection partielle | source primaire pour les versions et les paramètres |
Aucun de ces organismes ne recommande de se fier uniquement à un pare-feu applicatif web ou à des paramètres du fichier php.ini. Tous citent la mise à jour comme la véritable solution. Ce que le BSI conseille en outre en détail figure sur la page Ce que le BSI recommande pour PHP2Shell.
La question des versions : ce que signifie « à partir de PHP 5 »
Selon des rapports, CERT-EU jugeait possible que les versions à partir de PHP 5 soient concernées. L'organisme s'appuyait pour cela, selon des rapports spécialisés, sur des informations qui circulaient avant l'annonce officielle. La presse spécialisée parle de presque toutes les versions jusqu'à PHP 5.4.
Concrètement, la limite exacte change peu de choses. Pour PHP 8.1 et plus ancien, le projet PHP ne fournit plus de mises à jour officielles. Il existe des rétroportages minimaux du code source pour 7.4, 8.0 et 8.1, mais aucune version. Qui exploite encore PHP 5 ou 7 dépend des distributions, de tiers ou d'une migration. Les pages de sécurité propres à votre distribution indiquent si elle a livré une correction, par exemple le Debian Security Tracker, les Ubuntu Security Notices ou les avis de Red Hat. Il existe aussi des offres commerciales de support à long terme pour d'anciennes versions de PHP ; vous devriez vous faire confirmer par écrit par le fournisseur si elles couvrent PHP2Shell. Les détails sur les branches figurent sous Quelles versions de PHP sont concernées ? et PHP 8.1 et plus ancien.
Isoler : comment appliquer la recommandation
« Isoler » semble abstrait. Cela signifie que les requêtes venant d'Internet n'atteignent plus l'application PHP vulnérable. Selon l'application, il existe plusieurs niveaux :
- Mise hors service complète : le site est remplacé par une page d'urgence statique sans PHP. C'est la variante la plus sûre.
- Restreindre l'accès : l'application reste en service, mais n'est plus accessible que par VPN ou pour des adresses IP définies, par exemple pour des portails internes.
- Authentification en amont : une authentification au niveau du serveur web ou du proxy, avant l'application. Attention : avec mod_php, un exploit a été démontré avant que le code de l'application ne s'exécute. L'authentification doit donc intervenir avant PHP, non dans l'application.
- Bloquer l'accès direct à l'origine : qui utilise un service de proxy ou de CDN devrait s'assurer que le serveur n'est pas en plus directement accessible.
Une restriction dans le serveur web peut ressembler à ceci, sous forme de configuration sans danger pour Apache :
# Autoriser l'accès uniquement depuis le réseau interne (adapter la plage donnée en exemple)
<Location "/">
Require ip 192.0.2.0/24
</Location>
Testez l'effet de l'extérieur, par exemple via une connexion mobile. Une isolation vérifiée seulement dans le réseau du bureau n'est pas une isolation vérifiée.
Isoler est un pont provisoire. Dès l'isolation, définissez d'ici quand la mise à jour viendra et qui l'installera. Sinon la solution de secours devient un état permanent.
Ce que les recommandations exigent en commun : un inventaire
Tous les organismes officiels partent du principe que vous savez où PHP tourne. C'est précisément là que de nombreuses entreprises échouent : des microsites issus d'anciennes campagnes, un portail client oublié, un système de test avec adresse publique, une application sur un NAS. CERT-EU cite expressément le recensement des installations PHP comme première étape.
Vous retrouverez le plus facilement les systèmes oubliés par trois voies : les zones DNS de vos domaines, la liste des certificats TLS émis et les contrats avec les agences, hébergeurs et éditeurs de logiciels. Chaque entrée dont personne ne peut dire immédiatement ce qu'il y a derrière doit figurer sur la liste de vérification. Ces systèmes sont précisément dangereux dans une situation comme PHP2Shell, car personne ne les corrige et personne ne les regrette s'ils sont compromis.
Un inventaire utilisable contient pour chaque système : l'adresse, l'usage, l'exploitant, la version de PHP et le mode d'exécution, la source des paquets et l'interlocuteur pour les mises à jour. L'article Inventaire de tous les sites web et serveurs montre comment le constituer et le tenir à jour.
Comment PHP SOS aide-t-il concrètement ?
- Recensement : nous identifions vos systèmes PHP accessibles publiquement et les classons par risque.
- Correctif ou isolation : nous installons les mises à jour ou isolons les applications qui ne peuvent pas être corrigées immédiatement, et vérifions l'effet de l'extérieur.
- Anciennes versions : pour les systèmes sous PHP 8.1 et plus ancien, nous planifions avec vous le chemin vers une version prise en charge.
- Preuve : vous recevez une documentation des recommandations appliquées pour chaque système.
La manière dont nous amenons d'anciennes applications vers des versions prises en charge est décrite dans la prestation Migration PHP pour systèmes hérités.
Conclusion
CERT-EU, CERT-Bund, le BSI et le projet PHP parlent d'une seule voix : mettre à jour, et là où ce n'est pas possible immédiatement, isoler. Les différences tiennent à des détails comme la limite de version. Dans votre pratique, ce qui compte est la première étape que tous présupposent : savoir où PHP tourne partout.
Questions fréquentes
Quelle est la différence entre CERT-Bund et CERT-EU ?
CERT-Bund est l'équipe de réponse aux urgences informatiques rattachée au BSI et alerte en Allemagne sur les vulnérabilités. CERT-EU est le service de cybersécurité des institutions et organes de l'Union européenne. Les deux publient des recommandations utiles aussi aux entreprises.
Qu'est-ce qu'isoler une application PHP ?
L'application n'est alors plus librement accessible depuis Internet. C'est possible par une page d'urgence, par un accès limité à un VPN ou à certaines adresses IP, ou par une mise hors service complète. L'essentiel est que les requêtes venant de l'extérieur n'atteignent plus le processus PHP vulnérable.
Selon CERT-EU, les versions PHP 5 sont-elles aussi concernées ?
Selon des rapports, CERT-EU jugeait possible que les versions à partir de PHP 5 soient concernées, en s'appuyant sur des informations qui circulaient avant l'annonce officielle. La presse spécialisée cite presque toutes les versions jusqu'à PHP 5.4. Il n'existe aucune mise à jour officielle pour des versions aussi anciennes.
Existe-t-il des indicateurs officiels pour reconnaître les attaques ?
Non. Aucun indicateur de compromission (IoC) confirmé n'a été publié jusqu'à présent pour PHP2Shell. La détection repose sur l'analyse du comportement, par exemple des processus du serveur web qui lancent des shells ou de nouveaux fichiers PHP dans les dossiers d'envoi (uploads).