Malgré les revendications, il n’existe toujours pas de preuve publique d’un exploit générique pour PHP2Shell. Un ingénieur de HubSpot a compilé – avec l’aide de l’IA et sans vérification intégrale, admet-il – une chronologie récapitulative. Elle donne un aperçu de l’enchaînement des annonces… et des rétractations.

Une divulgation pas si coordonnée Avant d’en arriver là, il y eut la procédure de divulgation coordonnée des deux vulnérabilités. Et la mauvaise gestion de l’embargo associé. Chainguard l’a effectivement rompu.

Une dizaine d’heures avant l’échéance convenue, il a publié des versions patchées de sa distro Wolfi. Son patron présente ce choix comme une réaction à des signalements d’exploitation active sur les canaux de coordination. Une décision renforcée, ajoute-t-il, par la « facilité » que l’entreprise avait eue à développer elle-même un PoC.

Une foule de PoC… « de laboratoire » VulnCheck fait partie des entreprises de la cyber qui ont revendiqué un PoC « de laboratoire ». Il l’a d’abord dit fonctionnel contre PHP 8.4.26 (mod_php) sur x86-64 avec ASLR activé et display_errors = off.

Depuis, le rayon s’est étendu à l’essentiel des versions non patchées sur les branches 8.2 à 8.5. Et, pour certaines, à l’architecture ARM. Lire aussi : Dans l'ombre de PHP2Shell, une autre faille mémoire fait parler Trail of Bits y est aussi allé progressivement. Jusqu’à affirmer disposer d’un exploit « de production », en particulier parce que opérationnel en multiworker avec la configuration php.ini de base.

Il en a présenté une démo contre MediaWiki, WordPress, Symfony, phpBB et Laravel. Des annonces de compromissions suivies de rétractations Dans une alerte relative à PHP2Shell, le CERT indien indique que « plusieurs rapports confirment une exploitation à grande échelle ». Il ne les source cependant pas.

Sophos est allé jusqu’à parler de preuve de compromission, mais s’est rétracté quelques heures après. Même situation chez Palo Alto Networks. Son équipe Unit 42 avait rapporté une attaque contre une agence gouvernementale européenne ayant mené au vol de hashs de mots de passe et de secrets MFA « dans les deux heures après exploitation ».

Elle s’est finalement dédite : l’attaque s’est inscrite dans le contexte d’une application PHP vulnérable, mais il n’est pas certain que PHP2Shell ait constitué le vecteur d’accès initial… Chez Perplexity, une preuve limitée d’exploitation « hors labo » La trace la plus crédible d’une exploitation réussie de PHP2Shell « hors laboratoire » provient peut-être du directeur détection et réponse de Perplexity. L'intéressé a observé, sur un réseau de pots de miel, une chaîne d'exploitation en quatre étapes avec exécution de code arbitraire.

Elle reproduit une famille de PoC publics. La première requête épuise la mémoire et laisse le tas dans un état invalide. La deuxième force le renvoi d'un cookie anormalement volumineux qui expose une partie de la mémoire du processus.

L'attaquant peut ainsi cartographier l'agencement et calculer les décalages nécessaires pour contourner l'ASLR. La troisième requête stabilise le tas PHP dans un état prévisible afin que la structure qui sera corrompue lors de la dernière étape se positionne exactement à l'endroit calculé. Le contenu de l'ultime requête est dynamique.

En plus de la commande shell à injecter, il intègre les adresses mémoire recalculées d'après les pointeurs extraits. Le worker détourne son flux d'instructions et engendre un processus enfant qui exécute la charge utile. La corruption mémoire fait crasher le worker avant toute exécution de code applicatif.

L'audit eBPF permet toutefois de journaliser le lancement des processus shell. Logs qu'on peut corréler à la requête via les captures de paquets. Lire aussi : Failles PHP : après l'électrochoc, la crainte du « killer PoC » La configuration des honeypots était favorable aux attaquants, tempère le directeur détection et réponse de Perplexity.

Elle n'était en tout cas pas représentative de déploiements typiques (instances PHP 8.24.6 exécutées via mod_php en mode monoworker, avec memory_limit = 128M). Lundi, la CISA a en tout cas ajouté PHP2Shell dans son catalogue KEV (Known Exploited Vulnerabilities). Illustration générée par IA