nickstadb/pocDépôt d'exploits de preuve de concept et d'outils.
Dépôt pour les exploits et outils de preuve de concept.
Exploit d'exécution de commandes à distance non authentifiée pour l'agent RSCD de BMC Server Automation. L'exploit fonctionne contre les serveurs affectés par CVE-2016-1542 (détecté par Nessus).
Il s'agit désormais d'un module Metasploit, voir exploits/multi/misc/bmc_server_automation_rscd_nsh_rce
L'exploit a été créé en faisant scanner par Nessus un script Python qui enregistrait les paquets et leur renvoyait des données/junk. Une fois les paquets capturés, le format des données était trivial à « inverser » pour créer un exploit semi-fonctionnel. J'ai ensuite eu accès au logiciel de l'agent affecté et j'ai pu utiliser un débogueur et du fuzzing pour régler les détails et transformer cela en un exploit RCE solide.
Consultez mes articles de blog sur la façon dont j'ai construit l'exploit pour plus de détails :
Exploit d'exécution de code à distance non authentifiée pour HP Device Manager versions 5.0.0 à 5.0.3 (CVE-2020-6926, CVE-2020-6927).
L'exploit tire parti d'un service Java RMI non authentifié qui présente une vulnérabilité d'injection Hibernate Query Language. L'injection ORM est utilisée pour faire passer en fraude une charge utile d'injection SQL Postgres afin de remplacer le fichier pg_hba.conf sur le serveur HP Device Manager, permettant ainsi un accès à distance à la base de données Postgres fournie avec HPDM. Une fois activé, un compte superutilisateur backdoor est utilisé pour s'authentifier auprès de la base de données Postgres et exécuter des commandes arbitraires sur le système d'exploitation.
Consultez mon article de blog sur la façon dont j'ai découvert ces vulnérabilités pour plus de détails :
Bien que cet exploit ne fonctionne que contre HPDM 5.x, le service Java RMI non authentifié est présent dans toutes les versions de HPDM antérieures à 5.0.4 et 4.7 service pack 13. L'impact de l'exploitation de ce service peut être moindre, mais il existe toujours une vulnérabilité HQLi/SQLi, ainsi que la possibilité d'extraire la configuration (potentiellement y compris les mots de passe d'autres services), et tous les noms d'utilisateur des comptes HPDM ainsi que les hash MD5 des mots de passe correspondants.
Exploit d'exécution de code à distance non authentifiée pour les points de terminaison de service Java JNBridge configurés de manière non sécurisée. Basé sur les travaux de Moritz Bechler (CVE-2019-7839).
Le protocole réseau implémenté par JNBridge est conçu uniquement pour faciliter l'exécution de code à distance pour l'interopérabilité entre les applications Java et .NET. Ainsi, ce n'est pas techniquement un exploit, mais simplement un petit script Python pratique pour exécuter des commandes arbitraires contre un point de terminaison Java JNBridge.
Consultez mon article de blog pour une présentation pas à pas de mon parcours, de l'avis de sécurité à la production d'un exploit complet :
Cet exploit cible la fonctionnalité de mise à jour automatique non sécurisée de WordPress pour déposer un shell PHP sur le serveur sous-jacent. L'exploit a été testé avec succès jusqu'à WordPress 4.9.8, qui est la dernière version à la date de publication.
Lorsque WordPress vérifie les mises à jour, il tente d'établir une connexion HTTPS sécurisée vers api.wordpress.org. Si cette connexion échoue, par exemple parce qu'un certificat non fiable est présenté, WordPress revient alors à une connexion HTTP non sécurisée.
Le deuxième problème est que WordPress fait confiance aux mises à jour de traductions. Il ne met pas automatiquement à jour les plugins, les thèmes ou les versions majeures du noyau, probablement en raison des risques liés à l'installation de nouveaux codes sur le serveur. En revanche, il met automatiquement à jour les traductions. Malheureusement, WordPress ne valide pas correctement les archives de traduction : tant que le fichier ZIP de traduction contient au moins un fichier avec l'extension .po et un fichier avec l'extension .mo, WordPress extraira le contenu sur le serveur sous-jacent (y compris le shell inséré par le MitM).
J'ai découvert ces problèmes par accident, mais lorsque je les ai signalés (novembre 2017), l'équipe WordPress a essentiellement répondu WONTFIX pour des raisons de compatibilité ascendante. Si quelqu'un exécute WordPress sur un serveur qui ne peut pas établir de connexion SSL/TLS sortante, il devrait toujours pouvoir mettre à jour WordPress automatiquement pour des raisons de sécurité, disent-ils.
¯\_(ツ)_/¯
Consultez mon article de blog pour plus de détails :
Quelques extraits JS à utiliser pour exploiter les vulnérabilités XSS de WordPress.
