Cybersécurité

Un serveur PHP appâté avec 2 000 dollars en bitcoin a cédé à PHP2Shell en 19 heures

Adrian Kessler
Ajoutez-nous sur Google

Un serveur utilisant une version non corrigée de PHP, laissé en ligne avec une clé de portefeuille bitcoin en guise d’appât, n’a pas tenu une journée. Un chercheur utilisant le pseudonyme KillaBoi s’y est introduit grâce à PHP2Shell, un duo de failles critiques dans le langage qui alimente une grande partie du Web, et en a extrait la clé. Le même week-end, un leurre informatique géré par un responsable de la sécurité chez Perplexity a enregistré une attaque similaire contre un véritable serveur, mettant fin à l’idée rassurante que ces failles étaient trop difficiles à exploiter.

Cela concerne tous ceux qui gèrent un site web, ainsi que tous ceux dont les données y sont hébergées. PHP est au cœur de WordPress, Drupal, Joomla et de la plupart des offres d’hébergement mutualisé. Ces failles peuvent permettre à une personne sans compte d’exécuter des commandes sur le serveur. Depuis la publication des correctifs, le principal argument en faveur de l’attente était que les tentatives d’attaque rendues publiques échouaient systématiquement. Ces deux résultats le balayent.

Le défi, baptisé Steal My Bitcoin, a été mis en ligne sur son propre site et annoncé dans un message publié sur un forum. Son créateur, qui publie sous le nom de cloudlandsdev, a écrit : « J’ai créé ça parce que je me demande si quelqu’un a réussi à trouver comment exploiter concrètement cette RCE PHP. Nous avons paniqué ces derniers jours. Amusez-vous bien ! » La cagnotte, qui s’élevait au départ à environ 502 dollars, a grossi grâce aux dons pour atteindre 0,02511679 BTC, soit 2 021,22 dollars au moment où elle a été réclamée, quelque 19 heures après le lancement, selon Tom’s Hardware. Le serveur a plié sous l’afflux de personnes qui tentaient leur chance et, faute d’espace de stockage, n’a pas pu conserver tous ses journaux.

KillaBoi a ensuite publié une preuve de concept sur GitHub. Mark Maunder, fondateur de l’entreprise de sécurité WordPress Wordfence, a qualifié cette publication de « meilleure explication que vous pourrez trouver de la difficulté à exploiter #php2shell », en soulignant la précision du travail nécessaire à l’attaque. Difficile, comme on l’a découvert, ne veut pas dire lent.

Le résultat le plus inquiétant est venu de l’extérieur du défi. Adel Karimi, responsable de la détection et de la réponse aux incidents chez Perplexity, a déclaré que ses leurres avaient détecté une exécution de code à distance confirmée sur un serveur Apache utilisant PHP 8.4.26. « Il s’agit désormais d’une RCE confirmée, avec une divulgation de mémoire exploitable, et pas simplement d’un plantage suivi d’un processus suspect », a-t-il écrit, selon BleepingComputer. Marcus Hutchins, chercheur en cybermenaces chez Expel, qui suivait les déclarations d’attaques réussies, a estimé qu’il s’agissait « de loin de la confirmation la plus solide d’une exploitation de php2shell en conditions réelles que j’aie vue jusqu’ici ». Jusque-là, Cloudflare, watchTowr, Patchstack et d’autres sociétés de sécurité n’avaient enregistré que des tentatives infructueuses, tandis que l’équipe de renseignement sur les menaces d’Amazon avait repéré le début d’opérations de balayage quatre jours avant la publication des correctifs.

Aucun de ces résultats ne signifie que tous les serveurs non corrigés tomberont demain. La clé récupérée par KillaBoi ne correspondait pas à l’adresse du portefeuille affichée sur le site ; l’organisateur a parlé d’une erreur de configuration et indiqué que les fonds seraient transférés, selon Cointelegraph. Le site de sécurité Cyberpress souligne par ailleurs que les éléments rendus publics montrent qu’une clé a été récupérée, et non que le prix a été dérobé. L’exploit publié est également adapté à une version précise de PHP et échoue sur d’autres builds de la même version : ce n’est donc pas un outil utilisable d’un simple clic. Ce qui a disparu, c’est l’argument selon lequel personne n’était parvenu à le faire fonctionner.

Le problème est mondial. Des agences gouvernementales aux Pays-Bas, en Australie, au Japon et en Finlande ont mis hors ligne des sites web critiques pendant la préparation des correctifs, rapporte Cointelegraph. Un décompte de Shodan réalisé par la société de sécurité Mallory a recensé environ 884 000 hôtes accessibles depuis Internet qui annoncent une version de PHP ne bénéficiant plus de correctifs officiels, soit 59 % des quelque 1,5 million qui en indiquent une, selon Notebookcheck. Il s’agit de versions déclarées dans les bannières, et non de victimes confirmées, car les distributions Linux corrigent souvent d’anciens paquets sans modifier leur numéro de version.

Pour les propriétaires de sites, la marche à suivre n’a pas changé. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ; elles ont été publiées le 21 octobre pour les vulnérabilités CVE-2026-109618 et CVE-2026-109619, toutes deux notées 9,2 sur 10. Avec un hébergement mutualisé, la mise à jour relève de l’hébergeur, et non d’une mise à jour de WordPress ou d’une extension. La bonne question à poser à votre fournisseur est donc de savoir quelle version de PHP fait tourner votre site et quand elle a été corrigée. L’agence américaine de cybersécurité CISA a demandé aux organisations qui ne peuvent pas effectuer la mise à jour, ou qui utilisent encore PHP 8.1 ou une version antérieure, de mettre ces systèmes hors ligne jusqu’à ce qu’elles le puissent.

Le prochain problème est déjà là. Vendredi, l’équipe PHP a publié une solution de contournement pour une troisième faille d’exécution de code à distance, CVE-2026-115560, qui n’a pas encore de correctif et ne concerne que les systèmes « présentant une combinaison inhabituelle de configuration et de code applicatif ». En attendant la publication d’un correctif, les développeurs de PHP recommandent de désactiver le paramètre session.upload_progress, comme ils l’avaient déjà conseillé avant les correctifs de PHP2Shell. La prise en charge de sécurité de PHP 8.2 prendra fin le 31 décembre 2026, et les serveurs encore sous 8.1 ont déjà dépassé leur échéance.

Étiquettes: , , , , ,

Ajoutez-nous sur Google

Discussion

Il y a 0 commentaire.