Security researchers have discovered a practical way to exploit a vulnerability in older versions of TLS/SSL (TLSv1.0, SSLv3.0 and lower), commonly used for HTTPS connections. The theory behind this attack has been known for some time, but previously no practical attack had been found.
This theoretical flaw was remediated in TLSv1.0’s successor, TLSv1.1. SSLv2.0 was the first publicly available version of SSL, and is now disabled by default by all newer browsers due to its inherent flaws. It was replaced by SSLv3.0. This was then replaced by TLSv1.0, TLSv1.1 and then TLSv1.2. This current TLS version is the first to no longer offer downgrade capabilities to SSLv2.0.
BEAST is short for Browser Exploit Against SSL/TLS. This vulnerability is an attack against the confidentiality of a HTTPS connection in a negligible amount of time [1]. That is, it provides a way to extract the unencrypted plaintext from an encrypted session. Demonstrations of the exploit by the researchers, Thai Duong and Juliano Rizzo, can be found on Duong’s blog [2]. A good technical write-up of the flaw can also be found at EKR's blog [3].
How would an attack take place?
BEAST has three conditions that must be met for this attack to take place:
- JavaScript or applet injection into the same origin of the web site
- Network sniffing of the connection must be possible
- A vulnerable version of SSL must be used which is using a block cipher
The BEAST attack that was demonstrated used a flaw in Java’s Same Origin Policy. However there may be other weaknesses within the website that allow us to include malicious content within the Same Origin, for example weaknesses within a file upload feature.
If we have the ability to inject content within the same origin policy, whether through a browser bug or otherwise, there is already a large array of attacks we can perform; we have access to the page content, we can perform any action that the victim user could do and we can steal the cookie and hijack the session. We can even display a new login prompt that tricks the user into sending their credentials to us. And we can do all of this without needing to sniff the network traffic.
So if we can do all this, what is the point of the BEAST attack? Well there are a number of ways in which a developer can either increase the complexity or mitigate some of these attacks, adding an additional layer of protection. One example is the HTTPOnly property that can be set on cookies. With this property, a browser will not allow applets or JavaScript to gain access to the cookie value. This can prevent session hijacking.
If we can extract the plaintext of the HTTPS session, then we can gain access to the HTTPOnly cookie and this is the demonstrated attack, possibly the only one.
Therefore in terms of risk, the BEAST attack is akin to not setting the HTTPOnly property on cookies. Many websites don’t set this property, and thus are no more vulnerable. If you are concerned about the BEAST attack, we suggest you first concern yourself with the HTTPOnly property which is more likely.
Rich Internet Applications
Rich Internet Applications (RIA) are much more similar to desktop applications, providing a richer array of functionality which makes many more complex tasks much easier and possible to develop and deliver from a web site. RIAs include Java applets, Flash, and Silverlight.
In order for an RIA such as a Java Applet to be injected into the page or site, the RIA must appear as if from the same origin as the website. This is typically performed by using a browser flaw in the Same Origin Policy or a vulnerability within the website that allows it to be uploaded and hosted from within the same domain. This can then either be injected into a pre-existing page, for example using Cross Site Scripting, or a custom page to load it can be used.
Please note that the demonstration and blog by Duong uses a Java applet and a Same Origin Policy (SOP) exploit in a browser that also requires a man-in-the-middle attack. It also states that a flaw in the SOP will still prevent access to existing cookies. Existing cookies (with the exception of ones with the HTTPOnly flag) are accessible by all web content within the SOP, whether by an SOP flaw or not; thus Context has assumed the issue is with HTTPOnly cookies. All cookies are of course accessible once the channel’s plaintext has been accessed, however as already mentioned we already have access to this without the need for a network sniffer.
JavaScript
It appears to be possible to perform a BEAST attack using HTML5 WebSockets (v.76 and lower) in Safari. It is not known whether there are other JavaScript mechanisms, as a pure binary socket is needed, however changes to the specification or new features may in the future introduce more mechanisms. Using a feature such as WebSockets to perform a BEAST attack could result in the ability to use a Cross-Site Scripting (XSS) vulnerability to inject the BEAST agent. This is especially concerning given the prevalence of XSS.
Can't I just limit my web server to TLS 1.1 and 1.2 only?
It’s not as simple as that, unfortunately.
Many browsers do not support TLS 1.1 or 1.2. This includes all versions of IE on Windows XP. Those browsers that do support TLS 1.1/1.2 have it turned off by default. The reason it is off is because older web servers, which account for a large portion of the internet, are unable to handle a TLS 1.1/1.2 connection, and due to the error condition that takes place, the connection won’t downgrade to an older protocol.
Therefore not only will most of your users be unable to access your web site, but those that can, will not have it enabled. Those that enable it will probably be stuck in a position of needing to turn it on and off depending on which website they want to access.
It is also worth considering your corporation’s standard build for end users, as many have yet to roll out Windows 7. In fact, a significant but minor number of the applications we test only support IE7, and it appears there are new applications being developed towards IE7 only compatibility, as that is the standard build internally.
The following table shows the browsers that support TLSv1.1, and the percentage of users [4]:
There is limited information available regarding OSX and Safari TLSv1.1 support however the general consensus appears to be that it is not supported.
Microsoft Windows accounts for 85.6% of current operating system usage. This is broken down as follows:
(* This assumes that the portion of IE users per Microsoft OS is constant across the OSs, i.e. 56.49%).
Thus there are roughly 21% of users who are equipped with browsers that can support TLSv1.1. This support is off by default, and it is not known how many users have changed this default but it is assumed to be low as users generally don’t change default settings.
Is it possible to fix TLS 1.0?
It looks like it. The major vendors of both browsers and server-side technologies have all announced that they are working on a patch. In some cases, patches have already been released. This appears to be mainly a trade-off between finding a solution quickly, and minimising compatibility issues.
For example, OpenSSL based servers (e.g. Apache) can make use of an option to prevent the attack, however it is incompatible with IE6 which still accounts for around 2.7% of users.
Microsoft as of yet have not released a patch for their servers, and have not provided details on which versions and products will be patched.
What can I do to ensure our users are secure?
Due to the compatibility issues mentioned above, you are going to have difficulties in enforcing a secure HTTPS connection. A decision between usability and security is needed.
Upgrade
Within a controlled environment, for example an internal network, although a potentially large task, it may be possible to upgrade all users and servers to products that support TLS 1.1 or 1.2 only. If already upgraded, it should be possible to roll out a policy change. However, be aware that users may have difficulties accessing some external sites, and these may be sites needed for their work. A secondary browser could be supplied for this purpose.
It is however, a worthy exercise to upgrade your servers to provide support of TLS 1.1 and 1.2, in addition to the older versions. This allows you to provide those users who are security aware and proactive, with a secure environment and is likely to protect you against other attacks that might come to light.
If you are going to throw usability to the wind and limit the server to TLS 1.1 and 1.2 only, we suggest you do this in such a way as to allow for a friendly user error message to be presented to the user. This can be used to educate the user as to how they can access your site.
It is also important to make sure you aren’t running one of the servers that doesn’t support browsers with TLS 1.1 or 1.2 enabled; otherwise these users must change their settings to view your website, which may require restarting the browser. They will probably also not get a decent error message informing them why they can’t view the website, so there is a high chance they won’t know what they need to do to fix the situation.
Get Tested & Fix Security Flaws
Although the demonstrated attack utilises a browser bug, there is the potential for other methods to be employed to inject the BEAST agent into the browser. Some of these may utilise flaws in the application, and thus it is important to ensure a high security standard is being adhered to.
There are also a number of areas in which the use of session hijacking can be reduced or made more complex, for example:
- Transferable session prevention – prevent the ability to use a session token from a different IP and a different user agent, to increase complexity (this won’t prevent an attack)
- The existence of a logout button, which functions correctly
- Session timeout set to a sensible time and functioning correctly
- Regenerating a new and unique cookie value per session
- One-time passwords
- A secure HTTPS configuration
What about stream ciphers?
As suggested earlier, stream ciphers are not vulnerable to the BEAST attack. Therefore, if you disable support for all block ciphers, you are also protected. However, RC4 is pretty much the only commonly occurring stream cipher. This narrows your support considerably to just those clients that also support RC4.
On top of this, RC4 has its own security flaws [5]. However, these flaws are not as easy to exploit, and in some cases not applicable to HTTPS. Giving RC4 ciphers a higher priority than block ciphers will reduce the use of block ciphers and therefore reduce the number of clients vulnerable to the BEAST attack. Details on how to do this on Windows Servers can be found at [6].
I want TLS 1.1 or 1.2, what do I need to do to enable this?
OpenSSL (i.e. Apache)
TLS 1.1 and 1.2 have been implemented in OpenSSL version 1.0.1 and above, thus browsers that support these can use these versions. However, most distributions come with 0.9.x. A fix to BEAST has been implemented in 0.9.6d however it is frequently disabled due to incompatibility with IE6. It is disabled using the following flag:
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
This flag is also included with:
SSL_OP_ALL
IIS on Windows Server 2003
TLS 1.1 and 1.2 are not supported in Windows Server 2003, and Microsoft is currently investigating this issue:
“We are actively working with partners in our Microsoft Active Protections Program (MAPP) to provide information that they can use to provide broader protections to customers.
Upon completion of this investigation, Microsoft will take the appropriate action to help protect our customers. This may include providing a security update through our monthly release process or providing an out-of-cycle security update, depending on customer needs.” [7]
IIS on Windows Server 2008 R2
Windows Server 2008 R2 supports TLS 1.1 and 1.2. can be enabled by changing the SCHANNEL\Protocol DisabledByDefault keys to 0x0 [8].
Conclusion
First, I’d like to reiterate that we are solely talking about HTTPOnly cookies. If you have not enabled HTTPOnly cookies, you are no less secure. In our testing, we find that a significant number of web applications do not enable this cookie property and this may include you. Now that this issue has grabbed your attention, now is a good time to ensure you have enabled this across your applications. We would normally rate this as a low impact finding.
The HTTPOnly property provides protection against pretty much just one type of attack – session hijacking. A stolen cookie can typically be used by an attacker to access the application as the victim user until that user logs out – that is assuming your log out functions correctly, we find that sometimes it does not terminate the session properly.
In order to ‘man-in-the-middle’ a network connection, the attacker needs to be positioned at a point on the network between the victim and the application server. This is not necessarily a difficult task as the use of Wi-Fi hotspots and mobile devices has increased. However it is a very limited one as the attacker must first target these points and gain access (or create rogue points that masquerade as legitimate access points). It would need to be a fairly targeted attack against groups of individuals. Another possibility is an attacker within an organisation, such as the victim’s workplace, ISP, or the application’s hosting environment.
The BEAST attack utilises a flaw in TLS/1.0 that is mostly seen by the security community as one that needs to be remediated within the browser rather than the server. Although there are avenues you can take to offer a secure connection to those of your users who are more technically and security savvy, the take-up numbers will be low.
Overall, due to the number and complexity of mechanisms needed by an attacker to take advantage of this vulnerability, and also the number of greater value attacks that could take place in these circumstances, I believe it is highly unlikely this attack will be used often, if at all in the wild.
References
[1] - http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/print.html
[2] - http://vnhacker.blogspot.com/2011/09/beast.html
[3] - http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html
[4] - http://www.statowl.com
[5] - http://en.wikipedia.org/wiki/RC4#Security
[6] - http://blogs.msdn.com/b/kaushal/archive/2011/10/03/taming-the-beast-browser-exploit-against-ssl-tls.aspx
[7] - http://technet.microsoft.com/en-us/security/advisory/2588513
[8] - http://support.microsoft.com/kb/245030