
PoC RCE CVE-2024-4577
En implémentant PHP, l'équipe n'a pas remarqué la fonctionnalité Best-Fit de la conversion d'encodage dans le système d'exploitation Windows. Cette négligence permet à des attaquants non authentifiés de contourner la protection précédente de CVE-2012-1823 par des séquences de caractères spécifiques. Du code arbitraire peut être exécuté sur des serveurs PHP distants via l'attaque par injection d'arguments.
Ce PoC est uniquement à des fins d'apprentissage et de recherche. Ne l'utilisez pas pour des activités illégales ; vous êtes seul responsable de toute conséquence juridique.
Cette vulnérabilité a été découverte par Orange Tsai (@orange_8361) de DEVCORE (@d3vc0r3). Assurez-vous de suivre ses recherches remarquables, notre rôle était seulement de recréer et développer l'exploit pour ce problème.
Pourquoi est-il nécessaire de réécrire le script d'exploit alors qu'il existe déjà de nombreux PoCs publiés en ligne ?
Étant donné que de nombreux PoCs disponibles publiquement sont basés sur le même exploit original, de nombreux vendeurs ont utilisé ces PoCs comme références et ont bloqué certains mots-clés pour empêcher leur exploitation. Cependant, ils négligent souvent de bloquer tous les vecteurs d'exploitation potentiels. Pour y remédier, le script inclut un mécanisme simple pour générer des paramètres aléatoires, ainsi que différentes méthodes d'exploitation LFI vers RCE, pour améliorer le taux de réussite de l'injection CGI PHP menant à RCE.
Lors d'un test où j'essayais de reproduire une vulnérabilité environnementale, j'ai découvert que mon PoC déclenchait constamment une erreur HTTP 500, quels que soient les ajustements. Comme je travaillais dans un environnement vulnérable, j'ai commencé à enquêter sur la cause de l'erreur. Puis, je me suis souvenu d'un article de Devcore mentionnant que, dans certains scénarios d'exploitation, le serveur renvoyait une erreur HTTP 500, même si l'exploit RCE avait réussi. Avec cela à l'esprit, j'ai décidé de tester si je pouvais lancer calc.exe localement, et à ma surprise, cela a fonctionné — c'était un RCE aveugle !
Cependant, lorsque j'ai consulté le journal d'erreurs Apache, j'ai trouvé une erreur faisant référence à allow_url_include, malgré le fait que l'attaque avait été exécutée avec succès (et je ne comprends toujours pas entièrement la cause racine ; si vous avez des idées, veuillez me contacter). Cela m'a conduit à créer un exploit qui inclut une option pour tester également le RCE aveugle😊.
Si votre cible est une version du système d'exploitation antérieure à Windows 7, vous pouvez toujours passer à un RCE visible ou à un reverse shell par d'autres méthodes. Cependant, ces techniques sortent du cadre de cet article, nous n'entrerons donc pas dans les détails. En tant que testeur de pénétration ou spécialiste red team, vous devriez être capable de trouver des solutions alternatives assez rapidement, ce qui peut être un processus intéressant😉.
Mis à jour le 15 novembre 2024
En raison des exigences professionnelles, j'ai continué à améliorer le script pour le rendre aussi compatible que possible avec tous les environnements et maximiser les chances d'obtenir un RCE. Cet effort était motivé par le fait que certaines cibles ne pouvaient pas exécuter PHP avec succès en utilisant de nombreux PoCs publics. Finalement, j'ai résolu ce problème de manière inattendue, parvenant à surmonter presque tous les cas où l'erreur 500 se produisait et affichant avec succès les résultats d'exécution de PHP. En conséquence, le RCE aveugle ne semblait plus aussi critique. 😧
Conditions d'exploitation
Vous devez installer les dépendances :
$ python3 -m pip install requests Exécutez le script directement pour obtenir les instructions d'utilisation. Vous pouvez exécuter la commande ci-dessous pour vérifier si la cible est vulnérable.
$ python3 CVE-2024-4577.py <target> <php shell>

Si l'exploit existe sur la cible, vous pouvez enregistrer les résultats d'exécution PHP localement, ce qui est utile pour ceux qui ont besoin de voir phpinfo.
$ python3 CVE-2024-4577.py <target> "phpinfo()" --save info.html

Lorsque la cible est vulnérable au RCE aveugle, le script tentera d'écouter sur un port local et déclenchera l'exécution de PHP sur le serveur cible, en envoyant une requête pour vérifier l'existence de l'exploit. Lorsque la requête est reçue, cela indique que le serveur cible a exécuté la commande avec succès.
