SSLv 3.0 and TLS v1.0 protocols are used to provide integrity, authenticity and privacy to other protocols such as HTTP and LDAP. They provide these services by using encryption for privacy, x509 certificates for authenticity and one-way hash functions for integrity. To encrypt data SSL and TLS can use block ciphers, which are encryption algorithms that can encrypt only a fixed block of original data to an encrypted block of the same size. Note that these ciphers will always obtain the same resulting block for the same original block of data. To achieve difference in the output the output of encryption is XORed with yet another block of the same size referred to as initialization vectors (IV). A special mode of operation for block ciphers known as CBC (cipher block chaining) uses one IV for the initial block and the result of the previous block for each subsequent block to obtain difference in the output of block cipher encryption. In SSLv3.0 and TLSv1.0 implementation the choice CBC mode usage was poor because the entire traffic shares one CBC session with single set of initial IVs. The rest of the IV are as mentioned above results of the encryption of the previous blocks. The subsequent IV are available to the eavesdroppers. This allows an attacker with the capability to inject arbitrary traffic into the plain-text stream (to be encrypted by the client) to verify their guess of the plain-text preceding the injected block. If the attackers guess is correct then the output of the encryption will be the same for two blocks. For low entropy data it is possible to guess the plain-text block with relatively few number of attempts. For example for data that has 1000 possibilities the number of attempts can be 500. For more information please see a paper by Gregory V. Bard. (http://eprint.iacr.org/2006/136.pdf) NOTE: The CVSS access complexity assigned by NIST to CVE-2011-3389 is 'Medium' which makes the base score 4.3. But Qualys has assigned access complexity to 'High' for server side, because Javascipt injection and MiTM capabilities and a vulnerable client are required to exploit this vulnerability. Therefore the Qualys CVSS score is 2.6.
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 KB2588513 (http://technet.microsoft.com/en-us/security/advisory/2588513). Using the following SSL configuration in Apache mitigates this vulnerability: SSLHonorCipherOrder On SSLCipherSuite RC4-SHA:HIGH:!ADH Qualys SSL/TLS Deployment Best Practices can be found here (https://www.ssllabs.com/projects/best-practices/). Note: RC4 recommendation is only in situations where upgrade to TLSv1.2 is not possible. RC4 in TLS v1.0 has output bias problem as described in QID 38601. Therefore it is recommended to upgrade to TLS v1.2 or later.
- beast.pl SSL/TLS BEAST Vulnerability Check
Command
beast_check.pl <server ip>
Vulnerable Output
./beast_check.pl <server ip>:<port>
===============================================
SSL/TLS BEAST Vulnerability Check
by YGN Ethical Hacker Group, http://yehg.net/
===============================================
Target: <server ip>:<port>
## The target is PRONE to BEAST attack. ##
Protocol: TLS v1
Server Preferred Cipher: ECDHE-RSA-AES256-SHA
Vulnerable: YES
-----------------------------------------------
N.B. This check assumes no workaround
(i.e. EMPTY FRAGMENT) applied in target server.