Disabling Cipher Block Chaining (CBC) encryption on Firepower Management Centre 2000 v6.1.0.3?

dam0c0nr0y · ‎06-29-2018

A security audit has flagged the fact that the SSH services on our Firepower Management Centre 2000 appliance (running v6.1.0.3) is configured to support Cipher Block Chaining (CBC) encryption.

The security audit has advised disabling CBC mode cipher encryption, and enabling CTR or GCM cipher mode encryption.

How can this be done on a Firepower Management Centre 2000 appliance running v6.1.0.3 software?

Marvin Rhoads · ‎06-29-2018

That vulnerability should have been patched with 6.1.0.2.

There are two BugIDs which indicate as much:

I'd double check the scan and if it's indeed correct, open a TAC case to check why it might not be fixed for you.

dam0c0nr0y · ‎06-29-2018

Thanks Marvin

I have just checked bug CSCuu97541 and the fixed released are listed as:

6.2.2

6.2.0.4

6.1.0.5

5.4.1.9

5.4.0.10

with 6.1.0 listed as an affected release.

We are running 6.1.0.3 on our FMC 2000, so it looks to me like we would need to upgrade to 6.1.0.5 to get the fix.

Would you agree with this assessment?

Marvin Rhoads · ‎06-29-2018

It was a bit ambiguous as I thought the second bug was specific to the CBC ciphers.

In any case, upgrading is certainly a good idea. The latest 6.2.x is a good release but you may need to look at your sensors as well before jumping on that. For now, you could move to the latest 6.1.0.x (currently 6.1.0.6).

Note the downloads page advises "If you are running Versions 6.1.0.x, 6.2.0.x, or 6.2.2.x, we strongly recommend upgrading to Version 6.2.3.2 to take advantage of new features and resolved vulnerabilities."

https://software.cisco.com/download/home/286290710/type/286271056/release/6.1.0.6?i=!pp

dam0c0nr0y · ‎07-04-2018

Thanks Martin for this additional info.

We are considering upgrading our FMC 2000 appliances from 6.1.0.3 to 6.2.3.2

Our FMC 2000 appliances currently manage Firepower SFR software modules in ASA 5500-X series where the Firepower SFR software modules are also currently running 6.1.0.3

I see from the "Firepower Management Center and Managed Device Version Compatibility" guidelines document (link below) that having devices running v6.1.0.x software managed by Firepower Management Centre appliance running 6.2.3.2 is a compatible configuration.

Question: Can you shed light on whether or not it is Cisco best practice to have the FMC appliance and the SFR modules it manages both running the same version of software? i.e. should be plan on also upgrading the Firepower SFR modules in addition to upgrading our FMC 2000 appliances?

https://www.cisco.com/c/en/us/td/docs/security/firepower/upgrade/fpmc-upgrade-guide/compatibility.html#id_59217

Marvin Rhoads · ‎07-04-2018

As noted earlier, 6.2.3.2 is the current recommended release. That applies to all the Firepower platforms - FMC, Firepower service module on ASA, FTD appliances or classic 3D series Firepower devices.

I haven't seen any incompatibilities between FMC and sensors running a slightly earlier release (as long as it's within the release notes requirements) but it is generally a best practice recommendation to keep them in sync. Of course there are operational issues to take into account that often makes the upgrade process stagger across several maintenance periods in a production environment.

dam0c0nr0y · ‎07-05-2018

Thanks again Martin

I have been taking another look at bug CSCuu97541 ("Turn off older SSL/TLS versions and ciphers")

The description of the bug reads as below:

"This is a modification on the Cisco FireSIGHT System Software to adopt new secure code best practices to enhance the security posture and resiliency of the product.
The web server should be secure by default. Known broken/risky/weak cryptographic and hashing algorithms should not be used.

This is an enhancement request to allow the administrator via the web user interface to disable older Secure Socket Layer (SSL) and Transport Layer Security (TLS) versions and ciphers. The user wants to disable SSLv2, SSLv3 TLS version prior to 1.2 and the Cipher block chaining (CBC) and Rivest Cipher 4 (RC4) ciphers."

The bug details also includes a "PSIRT Evaluation" section which reads:

"The Cisco PSIRT has evaluated this issue and does not meet the criteria for PSIRT ownership or involvement. This issue will be addressed via normal resolution channels. If you believe that there is new information that would cause a change in the severity of this issue, please contact psirt@cisco.com for another evaluation."

So, my follow-on question is when the bug details confirms the existence of Known Fixed Releases (including for example release 6.2.2) do you know how the original problem with turning off older SSL/TLS versions and ciphers has actually been implemented in these released which contain the Cisco fix to bug CSCuu97541? i.e. in 6.2.2 for example is there now an additional capability available to administrators of the FMC appliance via the GUI to selectively turn off older insecure SSL/TLS versions and ciphers? or is the situation that Cisco have turned off these currently known insecure elements by default in the fixed releases?

Marvin Rhoads · ‎07-05-2018

I appears that the default settings for FMC itself continue to support CBC as seen on the following scan of my FMC 6.2.3 lab server:

Starting Nmap 7.70 ( https://nmap.org ) at 2018-07-06 10:39 Malay Peninsula Standard Time
Nmap scan report for fmc.ccielab.mrneteng.com (172.31.1.10)
Host is up (0.00s latency).

PORT    STATE SERVICE  VERSION
443/tcp open  ssl/http Apache httpd
|_http-server-header: Apache
| ssl-enum-ciphers: 
|   TLSv1.2: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|     compressors: 
|       NULL
|     cipher preference: server
|_  least strength: A

I don't see any place in the GUI (or a configuration guide reference) to change that.

You can however change the settings for managed sensors under Devices > Platform Settings > SSL.

Here is the output of my FTDv with SSL VPN enabled. Interestingly it still shows some CBC parameters despite their not being chosen in the platform settings:

Starting Nmap 7.70 ( https://nmap.org ) at 2018-07-06 10:51 Malay Peninsula Standard Time
Nmap scan report for ftdv.ccielab.mrneteng.com (192.168.0.204)
Host is up (0.0029s latency).

PORT    STATE SERVICE  VERSION
443/tcp open  ssl/http Cisco ASA SSL VPN
|_http-trane-info: Problem with XML parsing of /evox/about
| ssl-enum-ciphers: 
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 768) - B
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 768) - B
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Key exchange (dh 768) of lower strength than certificate key
|_  least strength: B

You may be best served by opening a TAC case to inquire about further about the status of the BugID.

jaime.pedraza · ‎11-25-2022

Hi @Marvin Rhoads,

It's an old post and many things have changed but, have you tried to do the hardening to a Firepower 41XX? Is the FXOS hardening inherited to the instances?

Many thanks in advance