Hello again and welcome back. Today I want to talk about a Sunday I
spent reversing the Cisco Firepower Management Console virtual
appliance that resulted in multiple CVEs being issued. The tricks I
will show have worked on four or five other virtual appliances from
other vendors. Results from those are either pending disclosure or
have already been reported by other researchers. Either way, this
should be something you can easily recreate to find vulnerabilities.

Before I start, normally I am just barely satisfied or outright
discouraged by the vendor's response. I want to commend the Cisco team
for their rapid response and great communication. They didn't drag
their feet nor attempt to prevaricate or downplay the findings (as the
below issues all require some level of authenticated access to
leverage). Cisco has issued three CVEs for the vulnerabilities we
disclosed:

Everything is virtualized nowadays, including appliances. What is
great is that most companies who develop appliances will allow trial
copies of them to be released. Just Google 'Virtual appliance trial
download' and you'll find plenty of targets. I did just that and came
across a trial download for the Cisco Firepower Management Console.

Now I will go through the file content of each Linux partition until I
come across something interesting. Note that fdisk's output is in
512-byte blocks, but the loop offsets below are in bytes, i.e. blocks
* 512.

The useradd binary from the appliance has the flag -g which allows you
to specify which group to place a newly created user into. It also
supports specifying the new user's password hash on the command line.

Usage: useradd [options] LOGIN
Options:
-b, --base-dir BASE_DIR base directory for the home directory of the
new account
-c, --comment COMMENT GECOS field of the new account
-d, --home-dir HOME_DIR home directory of the new account
-D, --defaults print or change default useradd configuration
-e, --expiredate EXPIRE_DATE expiration date of the new account
-f, --inactive INACTIVE password inactivity period of the new account
-g, --gid GROUP name or ID of the primary group of the new
account
[snip]
-p, --password PASSWORD encrypted password of the new account
[snip]

Therefore, if I could get the www user to run a specific command I
could get root. Here is the command:

The management web application maintains ten separate security roles.
Only two of those roles can update IDS signature rules. The two roles
are: Administrator, and Intrusion Administrator. With the exception of
the Administrator user, none of these groups afford the user shell
access.

Oddly enough, the target appliance uses a shell script to do the IDS
rule update. I tried the following:

This listener is not externally exposed, but still using a static
password of 'admin' is not a great idea.

This was issued CVE-2016-6434.

We also found a denial-of-service for the web application management
interface. That's not as exciting though, I won't go into details on
it here but information regarding it can be found on our advisory
page.