cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4987
Views
0
Helpful
2
Replies

Detected vulnerabilities in ESA

John
Level 1
Level 1

SSL/TLS Compression Algorithm Information Leakage Vulnerability
SSL/TLS use of weak RC4 cipher

SSL/TLS Server supports TLSv1.0

SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Server Side Vulnerability (BEAST)

SSL/TLS Compression Algorithm Information Leakage Vulnerability

SSL/TLS use of weak RC4 cipher

What version we need to upgrade to our ESA?

2 Accepted Solutions

Accepted Solutions

Libin Varghese
Cisco Employee
Cisco Employee

Hi John,

Below is some information I found on the mentioned vulnerabilities.

***************************************************************************************************************


# Qualys Scan: SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Server Side Vulnerability (BEAST) .

CVE-2011-3389

Solution:
This attack was identified in 2004 and later revisions of TLS protocol which contain a fix for this. If possible, upgrade to TLSv1.1 or TLSv1.2. If upgrading to TLSv1.1 or TLSv1.2 is not possible, then disabling CBC mode ciphers will remove the vulnerability.

Setting your SSL server to prioritize RC4 ciphers mitigates this vulnerability. Microsoft has posted information including workarounds for IIS at <a href="http://technet.microsoft.com/en-us/security/advisory/2588513" target="_blank" rel="nofollow">KB2588513</a>.

Using the following SSL configuration in Apache mitigates this vulnerability:

SSLHonorCipherOrder On

SSLCipherSuite RC4-SHA:HIGH:!ADH

***************************************************************************************************************

# Qualys Scan: SSL/TLS use of weak RC4 cipher

CVE-2013-2566,CVE-2015-2808

Solution:
RC4 should not be used where possible. One reason that RC4 was still being used was BEAST and Lucky13 attacks against CBC mode ciphers in SSL and TLS. However, TLSv 1.2 or later address these issues.

***************************************************************************************************************

# SSL/TLS Compression Algorithm Information Leakage Vulnerability

[ESA] CRIME Vulnerability (CVE-2012-4929)

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCum72269

Workaround:
The CRIME vulnerability can only be exploited if both the server and web browser both support TLS compression.

All version of Internet Explorer, Safari, Opera are not vulnerable because TLS compression is not supported on any version. All versions of Chrome and Firefox released after 2012 have been patched for this exploit.

All major updated web browsers disable compression for TLS connections. To avoid any potential exposure to this vulnerability, please ensure that your browser does not support TLS compression.

I just looked more into this and this defect is not being worked on because the development evaluation states that this does not affect ESA because we're not using TLS compression or SPDY/HTTP2 protocols.

So if this a concern for the customer please have them open a TAC Support cases and have them provide the corresponding information from the scanning system.

***************************************************************************************************************

# SSL/TLS Server supports TLSv1.0

If there is a certain vulnerability with ciphers used by TLS 1.0 then you could disable usage of that cipher as explained in the below article.

http://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118518-technote-esa-00.html

However do note, I expect you will see a significant drop off in TLS connectivity as not everything supports TLS 1.2 only. Lots of MTA on the peer side may only speak TLS1.0 or even lower cipher suites. This will cause TLS handshake failure.

If the TLS negotiation has started and then failed due to cipher, then the SMTP transaction does not fall back to clear text.

Preferred - When this option is chosen, TLS can negotiate from the remote MTA to the ESA. However, if the remote MTA does not negotiate (prior to the reception of a 220 response), the SMTP transaction continues in the clear (not encrypted). If an error occurs after the 220 response is received, then the SMTP transaction does not fall back to clear text.

As you are looking to prevent usage of TLS v1.0 disabling SSLv3 ciphers used by TLS 1.0 should be enough, TLS v1.2 has its own set of ciphers which would then be used.

SSLv3 ciphers can be removed by adding -SSLv3 or !SSLv3 to the existing cipher string.

Also with TLSv1 and TLSv1.2 both active the device would always try TLSv1.2 first. TLSv1 is not listed separately and disabled completely as it is still in use globally

***************************************************************************************************************

TLS v1.2 is available in Async OS 9.5 and higher.

TLS v1.1 was recently introduced as a configurable option in Async OS 10.0.1 (Maintenance Deployment)

Please review all release notes below:

http://www.cisco.com/c/en/us/support/security/email-security-appliance/products-release-notes-list.html

I would certainly recommend upgrade to 9.5 or above.

Thanks!

Libin Varghese

View solution in original post

John,

After you upgrade you'll want to go look at the SSL/TLS cipher settings to make sure you don't still have weak ciphers enabled.  Upgrades don't always change the cipher strings.  

I'd go all the way to 10.0.1.-087, now you can enable/disable each TLS version separately, but at least to 9.6...

In newer builds, the config is under System Administration/SSL configuration... I don't remember where it is in older builds, but even there you can set your string to turn off weak stuff, and close some holes.

Here's what I'm currently using:
MEDIUM:HIGH:!RC4:!aNULL:!MD5:!DSS:!EXPORT:@STRENGTH

based on this document: http://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/117855-technote-esa-00.html

Ken

View solution in original post

2 Replies 2

Libin Varghese
Cisco Employee
Cisco Employee

Hi John,

Below is some information I found on the mentioned vulnerabilities.

***************************************************************************************************************


# Qualys Scan: SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Server Side Vulnerability (BEAST) .

CVE-2011-3389

Solution:
This attack was identified in 2004 and later revisions of TLS protocol which contain a fix for this. If possible, upgrade to TLSv1.1 or TLSv1.2. If upgrading to TLSv1.1 or TLSv1.2 is not possible, then disabling CBC mode ciphers will remove the vulnerability.

Setting your SSL server to prioritize RC4 ciphers mitigates this vulnerability. Microsoft has posted information including workarounds for IIS at <a href="http://technet.microsoft.com/en-us/security/advisory/2588513" target="_blank" rel="nofollow">KB2588513</a>.

Using the following SSL configuration in Apache mitigates this vulnerability:

SSLHonorCipherOrder On

SSLCipherSuite RC4-SHA:HIGH:!ADH

***************************************************************************************************************

# Qualys Scan: SSL/TLS use of weak RC4 cipher

CVE-2013-2566,CVE-2015-2808

Solution:
RC4 should not be used where possible. One reason that RC4 was still being used was BEAST and Lucky13 attacks against CBC mode ciphers in SSL and TLS. However, TLSv 1.2 or later address these issues.

***************************************************************************************************************

# SSL/TLS Compression Algorithm Information Leakage Vulnerability

[ESA] CRIME Vulnerability (CVE-2012-4929)

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCum72269

Workaround:
The CRIME vulnerability can only be exploited if both the server and web browser both support TLS compression.

All version of Internet Explorer, Safari, Opera are not vulnerable because TLS compression is not supported on any version. All versions of Chrome and Firefox released after 2012 have been patched for this exploit.

All major updated web browsers disable compression for TLS connections. To avoid any potential exposure to this vulnerability, please ensure that your browser does not support TLS compression.

I just looked more into this and this defect is not being worked on because the development evaluation states that this does not affect ESA because we're not using TLS compression or SPDY/HTTP2 protocols.

So if this a concern for the customer please have them open a TAC Support cases and have them provide the corresponding information from the scanning system.

***************************************************************************************************************

# SSL/TLS Server supports TLSv1.0

If there is a certain vulnerability with ciphers used by TLS 1.0 then you could disable usage of that cipher as explained in the below article.

http://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118518-technote-esa-00.html

However do note, I expect you will see a significant drop off in TLS connectivity as not everything supports TLS 1.2 only. Lots of MTA on the peer side may only speak TLS1.0 or even lower cipher suites. This will cause TLS handshake failure.

If the TLS negotiation has started and then failed due to cipher, then the SMTP transaction does not fall back to clear text.

Preferred - When this option is chosen, TLS can negotiate from the remote MTA to the ESA. However, if the remote MTA does not negotiate (prior to the reception of a 220 response), the SMTP transaction continues in the clear (not encrypted). If an error occurs after the 220 response is received, then the SMTP transaction does not fall back to clear text.

As you are looking to prevent usage of TLS v1.0 disabling SSLv3 ciphers used by TLS 1.0 should be enough, TLS v1.2 has its own set of ciphers which would then be used.

SSLv3 ciphers can be removed by adding -SSLv3 or !SSLv3 to the existing cipher string.

Also with TLSv1 and TLSv1.2 both active the device would always try TLSv1.2 first. TLSv1 is not listed separately and disabled completely as it is still in use globally

***************************************************************************************************************

TLS v1.2 is available in Async OS 9.5 and higher.

TLS v1.1 was recently introduced as a configurable option in Async OS 10.0.1 (Maintenance Deployment)

Please review all release notes below:

http://www.cisco.com/c/en/us/support/security/email-security-appliance/products-release-notes-list.html

I would certainly recommend upgrade to 9.5 or above.

Thanks!

Libin Varghese

John,

After you upgrade you'll want to go look at the SSL/TLS cipher settings to make sure you don't still have weak ciphers enabled.  Upgrades don't always change the cipher strings.  

I'd go all the way to 10.0.1.-087, now you can enable/disable each TLS version separately, but at least to 9.6...

In newer builds, the config is under System Administration/SSL configuration... I don't remember where it is in older builds, but even there you can set your string to turn off weak stuff, and close some holes.

Here's what I'm currently using:
MEDIUM:HIGH:!RC4:!aNULL:!MD5:!DSS:!EXPORT:@STRENGTH

based on this document: http://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/117855-technote-esa-00.html

Ken