02-07-2014 01:01 AM
Not sure what this means and how to alleviate it? The firewall is running 4.1.13.
SSL/TLS Protocol Initialization Vector Implementation Information Disclosure Vulnerability
Synopsis : It may be possible to obtain sensitive information from the remote host with SSL/TLS-enabled services. Description : A vulnerability exists in
SSL 3.0 and TLS 1.0 that could allow information disclosure if an attacker intercepts encrypted traffic served from an affected system. TLS 1.1, TLS
1.2, and all cipher suites that do not use CBC mode are not affected. This script tries to establish an SSL/TLS remote connection using an affected
SSL version and cipher suite, and then solicits return data. If returned application data is not fragmented with an empty or one-byte record, it is likely
vulnerable. OpenSSL uses empty fragments as a countermeasure unless the 'SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS' option is specified
when OpenSSL is initialized. Microsoft implemented one-byte fragments as a countermeasure, and the setting can be controlled via the registry key
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\SendExtraRecord. Therefore, if multiple applications use the
same SSL/TLS implementation, some may be vulnerable while others may not, depending on whether or not a countermeasure has been enabled.
Note that this script detects the vulnerability in the SSLv3/TLSv1 protocol implemented in the server. It does not detect the BEAST attack where it exploits
the vulnerability at HTTPS client-side (i.e., Internet browser). The detection at server-side does not necessarily mean your server is vulnerable to the
BEAST attack because the attack exploits the vulnerability at client-side, and both SSL/TLS clients and servers can independently employ the split record
countermeasure. See also : http://www.openssl.org/~bodo/tls-cbc.txt http://vnhacker.blogspot.com/2011/09/beast.html http://technet.microsoft.com/en-us/security/bulletin/ms12-006 http://support.microsoft.com/kb/2643584 http://blogs.msdn.com/b/kaushal/archive/2012/01/21/fixing-the-beast.aspx
Solution :
Configure SSL/TLS servers to only use TLS 1.1 or TLS 1.2 if supported.Configure SSL/TLS servers to only support cipher suites that do not use
block ciphers. Apply patches if available. Note that additional configuration may be required after the installation of the MS12-006 security update in
order to enable the split-record countermeasure. See Microsoft KB2643584 for details. Risk factor : Medium / CVSS Base Score : 4.3 (CVSS2#AV:N/
AC:M/Au:N/C:P/I:N/A:N) CVSS Temporal Score : 3.7 (CVSS2#E:ND/RL:OF/RC:C) Public Exploit Available : true Plugin output : Negotiated cipher suite:
AES256-SHA|TLSv1|Kx=RSA|Au=RSA|Enc=AES-CBC(256)|Mac=SHA1 CVE : CVE-2011-3389 BID : 49778 Other reference : IAVB:2012-B-0006,
MSFT:MS12-006, OSVDB:74829
02-07-2014 11:24 AM
The feature change the cipher suite is available in 6.0. This has been a long standing feature request and only implemented in 6.0. Any product that uses TLS 1.0 (which is pretty much everything right now) is vulnerable to this attack, and we still have to support TLS 1.0 due to its wide spread usage.
The attack exploits an implementation weakness in TLS 1.0 that has been known since 2004, but this latest proof-of-concept makes an attack on the theoretical vulnerability a bit more realistic. However, most security experts are quick to point out that SSL is not "broken wide open". In order to mount a successful attack, the attacker must be able to inject many specially crafted requests from the victim client to the victim website within the SSL session under attack (through an existing cross-site scripting vulnerability, for example; see details below), and then sniff the traffic between the client and the server for some extended period of time. This attack on HTTPS is different from recent attacks on certification authorities (which attacked the authentication scheme of SSL), in that it directly attacks the encryption of SSL and can reveal plaintext to the attacker.
Our threat research team is monitoring the situation, and if proof-of-concept code, toolkits, or any other actionable information emerges, we will act quickly to produce content updates as necessary to mitigate the threat.
Technical Details
The attack against TLS 1.0 is a chosen plaintext attack, and requires the ability to send a long series of tightly controlled request data from the victim client to the victim website. If an attacker wishes to decrypt data within an HTTPS request at a known or predictable location (for example, a session cookie in the HTTP header), the attacker can craft a series of HTTP requests and sniff the encrypted traffic to discover the encrypted data by guessing it 1 byte at a time, which makes guessing encrypted data tractable (i.e. a 1kb session cookie can be decrypted in 10-30 minutes on average).
This is possible because of how TLS 1.0 implements Cipher Block Chaining (CBC). Instead of using a new pseudo random initialization vector (IV) with each message, TLS 1.0 continues the CBC chain across messages and uses the last encrypted block as the IV for the next message, which opens the door for a man-in-the-middle chosen IV attack. This weakness has been known since 2004, but had since been brushed aside as a theoretical weakness. Later versions of TLS (TLS 1.1/1.2) have been available since 2006 and are not vulnerable to this attack. However, there is almost no browser support for these later specifications, and most servers are not configured to support them either. However, this proof-of-concept is likely to speed up server-side and client-side adoption of TLS 1.1+. (Google Chrome is proactively releasing a patch that mitigates the attack. No word yet from other browser vendors.)
However, it is important to note that this attack requires that the attacker be able to send a series of arbitrary requests from the victim client to the victim server within the SSL session under attack. This means that the attacker must be able to inject a malicious script within the victim website through an existing cross-site scripting vulnerability on the website, for example. The researchers also note that the new HTML5 WebSockets protocol can also be used to send malicious requests on behalf of the victim client to the victim server. However, WebSockets is disabled by default or not implemented on most web browsers. Additionally, the WebSockets approach requires that the victim website explicitly enable WebSockets requests from the web server hosting the malicious code.
02-07-2014 11:24 AM
The feature change the cipher suite is available in 6.0. This has been a long standing feature request and only implemented in 6.0. Any product that uses TLS 1.0 (which is pretty much everything right now) is vulnerable to this attack, and we still have to support TLS 1.0 due to its wide spread usage.
The attack exploits an implementation weakness in TLS 1.0 that has been known since 2004, but this latest proof-of-concept makes an attack on the theoretical vulnerability a bit more realistic. However, most security experts are quick to point out that SSL is not "broken wide open". In order to mount a successful attack, the attacker must be able to inject many specially crafted requests from the victim client to the victim website within the SSL session under attack (through an existing cross-site scripting vulnerability, for example; see details below), and then sniff the traffic between the client and the server for some extended period of time. This attack on HTTPS is different from recent attacks on certification authorities (which attacked the authentication scheme of SSL), in that it directly attacks the encryption of SSL and can reveal plaintext to the attacker.
Our threat research team is monitoring the situation, and if proof-of-concept code, toolkits, or any other actionable information emerges, we will act quickly to produce content updates as necessary to mitigate the threat.
Technical Details
The attack against TLS 1.0 is a chosen plaintext attack, and requires the ability to send a long series of tightly controlled request data from the victim client to the victim website. If an attacker wishes to decrypt data within an HTTPS request at a known or predictable location (for example, a session cookie in the HTTP header), the attacker can craft a series of HTTP requests and sniff the encrypted traffic to discover the encrypted data by guessing it 1 byte at a time, which makes guessing encrypted data tractable (i.e. a 1kb session cookie can be decrypted in 10-30 minutes on average).
This is possible because of how TLS 1.0 implements Cipher Block Chaining (CBC). Instead of using a new pseudo random initialization vector (IV) with each message, TLS 1.0 continues the CBC chain across messages and uses the last encrypted block as the IV for the next message, which opens the door for a man-in-the-middle chosen IV attack. This weakness has been known since 2004, but had since been brushed aside as a theoretical weakness. Later versions of TLS (TLS 1.1/1.2) have been available since 2006 and are not vulnerable to this attack. However, there is almost no browser support for these later specifications, and most servers are not configured to support them either. However, this proof-of-concept is likely to speed up server-side and client-side adoption of TLS 1.1+. (Google Chrome is proactively releasing a patch that mitigates the attack. No word yet from other browser vendors.)
However, it is important to note that this attack requires that the attacker be able to send a series of arbitrary requests from the victim client to the victim server within the SSL session under attack. This means that the attacker must be able to inject a malicious script within the victim website through an existing cross-site scripting vulnerability on the website, for example. The researchers also note that the new HTML5 WebSockets protocol can also be used to send malicious requests on behalf of the victim client to the victim server. However, WebSockets is disabled by default or not implemented on most web browsers. Additionally, the WebSockets approach requires that the victim website explicitly enable WebSockets requests from the web server hosting the malicious code.
02-07-2014 08:37 PM
The feature change the cipher suite is available in 6.0
JimS2,
Can you point where can I change the cipher suite in 6.0?
Thanks,
E
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
