PHP2Shell : 2 failles PHP critiques, attaques en cours
Deux failles PHP critiques viennent de tomber, et pas des petites. Baptisées PHP2Shell, elles permettent ni plus ni moins de prendre le contrôle d’un serveur à distance. Le langage qui fait tourner environ 70 % du web, excusez du peu. Autant dire que la moitié de mes clients vont m’appeler dans les 48 heures. La semaine dernière, un restaurateur du centre-ville m’a déjà sonné pour un site qui « faisait des trucs bizarres ». Je parie que ce n’était que le début. Mine de rien, quand on touche à PHP, on touche à tout : WordPress, Joomla, les vieux CMS maison que personne n’a mis à jour depuis 2015, j’en passe et des meilleurs.
Deux failles PHP critiques découvertes… par des IA
Là où l’histoire devient savoureuse, c’est que ces deux trous de sécurité n’ont pas été débusqués par un chercheur en sécurité en sueur dans son garage. Non. Ce sont les modèles de pointe de Google et d’OpenAI qui les ont sortis. Les mêmes IA qu’on nous vend à toutes les sauces depuis deux ans. Pour être honnête, ça me fait doucement sourire. On passe notre temps à dire que l’IA va remplacer les développeurs, et au final c’est elle qui trouve les bugs que les humains ont laissés traîner pendant dix ans.
Une des deux failles aurait plus de dix ans, paraît-il. Dix ans. J’ai vu des serveurs tourner en production avec des versions de PHP qui datent de l’époque où je montais mes premiers sites en HTML 4. Moi, ce que j’en dis, c’est que si personne n’avait vu le trou avant, c’est surtout parce que personne ne regardait vraiment. On empile les couches, on colle des plugins, et on croise les doigts. Ça marche jusqu’au jour où ça ne marche plus.
- Prise de contrôle du serveur à distance, sans authentification
- Exploitation possible via des requêtes HTTP classiques
- Des attaques déjà observées en conditions réelles, pas juste en labo
- Impact estimé : des centaines de millions de sites web concernés
Attaques en cours : ce que je vois sur le terrain
Les cyberattaques ont déjà commencé. Pas un scénario théorique pour un rapport de conférence. Du concret. Et croyez-moi, quand ce genre de faille tombe, les botnets ne perdent pas de temps à faire des politesses. Ils scannent, ils testent, ils entrent. J’ai un client hébergeur mutualisé qui m’a raconté la semaine dernière avoir vu son trafic anormal grimper en flèche sur des URLs qui n’existent même pas dans son arborescence. Classique. On cherche le point d’entrée, on le trouve rarement tout de suite, et pendant ce temps le serveur fait tourner des scripts que personne n’a écrits.
Autant dire que les administrateurs systèmes qui ne surveillent pas leurs logs vont avoir des surprises. Et pas des bonnes. Mon expérience en atelier me dit toujours la même chose : ce n’est pas la faille qui tue, c’est le délai entre la faille et le patch. Deux jours de retard sur un serveur exposé, c’est déjà trop. Une semaine, c’est un désastre annoncé.
Je ne suis pas certain à 100 % que toutes les attaques observées exploitent réellement ces deux failles précises plutôt qu’une autre vulnérabilité du même type, il faut parfois du recul avant de trancher. Mais d’après ce que je vois circuler chez mes confrères, le timing est trop parfait pour être une coïncidence. Les scanners automatisés trouvent en quelques heures ce qu’un humain mettrait des jours à identifier.
Pourquoi je ne suis pas d’accord avec les experts rassurants
Il y a déjà des voix qui s’élèvent pour dire qu’il suffit d’appliquer la mise à jour et que tout va bien. Faux. Archi-faux. Vous mettez à jour PHP sur un serveur qui héberge un CMS abandonné depuis quatre ans, et vous avez une chance sur deux de casser ledit CMS. J’ai vu ce film des dizaines de fois. Le client applique la MAJ comme on lui dit, le site tombe, et c’est moi qui récupère l’appel à 22 heures un vendredi. Évidemment.
La réalité, c’est que les experts qui conseillent « patchez tout » oublient qu’un serveur web n’est pas une machine isolée. C’est un empilement de dépendances, de plugins, de thèmes, de scripts oubliés par un ancien prestataire. Chaque couche peut casser à la première mise à jour. Alors oui, il faut patcher. Mais il faut tester, sauvegarder, et prévoir le retour arrière. Sinon, on remplace une faille de sécurité par une panne de service. Et une panne, ça se voit tout de suite, alors qu’une faille, ça se voit le jour où il est trop tard.
Ma méthode pour colmater les failles PHP critiques avant qu’il ne soit trop tard
Voilà comment je procède, dans l’ordre, quand un client m’appelle pour ce genre d’alerte. D’abord, je vérifie la version de PHP réellement exécutée sur le serveur. Pas celle affichée dans le panneau d’administration, la vraie. J’ai déjà vu des hébergeurs afficher 8.2 et faire tourner du 7.2 en sous-main, histoire de ne pas casser les vieux scripts. Ensuite, je fais une sauvegarde complète. Fichiers et base de données. Sans ça, aucune mise à jour, point final.
- Identifier la version PHP réelle et les extensions critiques utilisées
- Sauvegarde complète avant toute modification
- Mise à jour en environnement de test quand c’est possible
- Vérification des logs d’accès et des fichiers modifiés récemment
- Surveillance renforcée pendant 72 heures après le patch
Et surtout, je regarde les logs avant et après. Un serveur compromis garde des traces, souvent discrètes, mais des traces quand même. Une requête bizarre sur un fichier qui n’aurait jamais dû être appelé, un processus qui consomme plus que la normale, un fichier PHP modifié à 3 heures du matin. Mine de rien, c’est souvent comme ça qu’on repère une intrusion déjà en cours. Le patch ferme la porte, il ne vide pas la maison.
Du coup, pour mes clients qui ne peuvent pas se permettre une coupure, je propose une approche intermédiaire : mise à jour immédiate si le site est simple, sinon mise en quarantaine de la partie vulnérable et migration planifiée. C’est moins propre qu’un patch dans les règles, je l’admets. Mais un site qui fonctionne avec une protection temporaire reste préférable à un site parfaitement à jour qui affiche une erreur 500 à tous les visiteurs.
Le vrai problème, c’est notre rapport aux mises à jour
Évidemment que la faute ne revient pas qu’à PHP. Elle revient à tout un écosystème qui a laissé des serveurs tourner pendant dix ans sans que personne ne se pose la question. Les hébergeurs qui ne forcent pas les mises à jour, les agences qui livrent un site et disparaissent, les clients qui ne veulent pas payer pour de la maintenance. J’ai un client qui m’a dit un jour : « la maintenance, c’est comme l’assurance, on la paie et on espère ne jamais s’en servir ». Sauf qu’une assurance ne se met pas à jour toute seule.
Alors oui, PHP2Shell fait peur. Deux failles PHP critiques, des attaques en cours, des centaines de millions de sites exposés. Mais la vraie faille, c’est le délai entre la découverte et le patch. Et ça, aucune IA ne le réglera pour nous. Autant dire qu’il va falloir mettre les mains dans le cambouis, et vite. Pour ceux qui veulent les détails techniques de la source, l’article original est disponible chez 01net.com.
Source : article original
