Tag Archives: beast attack

Taming The BEAST

ASV, penetration testing, risk, security

This is a follow-up post to our previous article on the subject.

Here we offer technical assistance to those of you trying to fix the BEAST vulnerability, and offer some mitigation practices.

The problem revolves around a vulnerability identified years ago in TLSv1 and SSLv3 protocol CBC mode ciphers (the stronger ciphers). This issue was fixed in TLSv1.1 (2006) and TLSv1.2, however, adoption of these versions has been slow due to lack of any real incentive. Up until now the attack was considered unfeasible, but recent developments have made it viable and it is now a real threat. Please see the whitepaper at http://blog.tempest.com.br/static/attachments/marco-carnut/driblando-ataque-beast-com-pasme-rc4/ssl_jun21.pdf for a deatiled technical analysis of the issue.

The following articles are very useful in understanding and taming the BEAST:

https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls
http://blog.zoller.lu/2011/09/beast-summary-tls-cbc-countermeasures.html
http://vnhacker.blogspot.co.uk/2011/09/beast.html
https://blog.torproject.org/blog/tor-and-beast-ssl-attack
https://blogs.akamai.com/2012/05/what-you-need-to-know-about-beast.html

The current simplest way to mitigate the risk associated with this vulnerability in a secure manner and maintain compatibility between servers and clients is to prioritise TLSv1.1/TLSv1.2 CBC mode ciphers and then TLSv1.0/SSLv3 RC4 ciphers over the deprecated TLSv1.0/SSLv3 CBC mode ciphers. This should catch the majority of sessions before the minority of clients fall back to the vulnerable ciphers, thereby decreasing the likelihood of a successful attack.

The following remediation notes and references may be of use:

Apache
(taken from https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls)

SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

Windows (not including 2003 or XP)
Prioritising Schannel cipher suites is possible, please see:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb870930(v=vs.85).aspx

Windows (Older Flavours)
See the following to control which ciphers are supported:
http://support.microsoft.com/kb/245030

Windows (Recent Versions)
A patch is available:
http://technet.microsoft.com/en-us/security/bulletin/ms12-006
However, problems have arisen from this so the prioritising method may be preferred. See:
http://blogs.msdn.com/b/kaushal/archive/2012/01/21/fixing-the-beast.aspx

OpenSSL
OpenSSL has addressed the issue, however, as the feature was found to cause problems with some SSL implementations it is disabled by default. It is also known that Tomcat, Apache mod_ssl and Exim disable the feature by default. The fix is also claimed not to work by some. (https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls). Again, prioritising ciphers therefore seems to be the only workable route.

Other Systems
Please check for vendor specific patches. Failing that, and if the prioritisation of ciphers is not an existing function, then disabling unwanted ciphers may be the only option in the short term. For a complete list of ciphers and other details, please see: http://www.openssl.org/docs/apps/ciphers.html

Utilities
For an effective way of determining supported SSL ciphers, see the following:

The online Qualys SSL test application:
https://www.ssllabs.com/ssltest

sslscan, a useful tool, can be downloaded from:
http://sourceforge.net/projects/sslscan/

ASV Reports: The BEAST Inside

ASV, pci dss, security,

Many of our ASV customers are seeing scan reports making reference to a “BEAST” attack susceptibility. But what is it, and more importantly, how can you fix it?

The bad news is that our ASV scan report is informing you that the strong encryption on your “secure” web server could be rendered useless and your customers accounts could therefore be compromised. That should be enough to give any of you sleepless nights, but the good news is that a configuration change is probably all that is needed to mitigate this particular attack.

I’ll post a more technical follow-up which includes technical fix information. In the meantime, here’s the background story for those of you who are interested.

About a year ago, two researchers discovered weaknesses in the encryption used on the majority of web sites. Further to their research, they released a tool that claimed to be capable of forcibly decrypting the confidential communication between a user and a web site. As an example, they showed how the tool could be used to break into a connection with PayPal, exposing information that was previously thought to be securely transmitted. As you can imagine, it caused a bit of a stir in the information security community.

The researchers were Thai Duong and Juliano Rizzo, and their tool was “Browser Exploit Against SSL/TLS” – BEAST for short.

Using the BEAST tool to actually break in to secure connections is somewhat tricky, and requires a number of supporting factors to be in play (the web server needs to be configured in a certain way, the attacker needs to be able to access the network traffic emanating from the user, and the vulnerable user needs to be tricked into loading the BEAST tool via a web link of some kind)

However, these factors are in no way insurmountable if the attacker is sufficiently motivated and equipped. Given the fact that there are still many web sites that are configured in a way that would enable a BEAST attack on the user, we should assume that BEAST remains at least potentially viable for the foreseeable future.

Reference: http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/