Visa Europe revealed important stats about the usage of Contactless Cards. Poland, Spain and the UK use this payment methd the most, with UK usage growing by 300% year over year.
Ok, surely not the freshest topic out there as we are looking at going back to the end of 2011 but the BEAST issue does, however, remain valid today as several (slightly worried) customers of ours have made queries to us about it over the last few months. These customers aim to gain a better understanding of what kind of “animal” we're actually dealing with and whether their apps may be presently running a concrete risk of compromise through such an attack.
The fact that there is still no official stance from the Council on this topic so far only increases the concern. The lack of a stance is reasonable, however, since when dealing with technical specifications the PCI SSC simply redirects you to industry standards and similar resources such as NIST’s special publications. Apparently, NIST has not yet updated the specific SP 800-52, dated June 2005, focused on TLS (“Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations”).
Moreover, Qualys (as well as many other ASVs), though labeling the issue - tagged CVE-2011-3389 - under the naming "SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Vulnerability" and giving it a CVSS score greater than 4.0, have not yet included it in the list of PCI-affecting items. This brought us to thinking that it could be worth posting some lines on this matter in the hope that it helps clarify the nature of the issue somewhat, especially when it comes down to deciding whether to address it or not.
The story basically begins some months ago (more or less 10 months), with a couple of researchers discovering a potential vulnerability in TLS v1.0 and SSL v3.0 - the decade-old cryptographic standard that protects web addresses using the https prefix.
Apparently, the vulnerability may allow attackers to silently decrypt data that’s passing between a web server and an end-user browser. This vulnerability can be exploited using a cookie-based technique called “BEAST” (acronym for “Browser Exploit Against SSL/TLS”) that leverages block-oriented cipher implementations such as AES and TripleDES. It turns out that by tampering with an encryption algorithm's CBC (cipher block chaining) mode, hackers could secretly decrypt portions of the encrypted traffic. Qualys even outlines how "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".
As a general clarification on the nature of the issue it might be worth mentioning that SSL/TLS, as a channel encryption protocol, is utilized to encrypt not just a single file but a series of records as part of a data flow. For instance, a single SSL/TLS connection can be used for a series of HTTP requests, each of which is split into one or more records sent over the course of seconds to minutes. All the records (in each direction) are encrypted with the same traffic key.
SSLv3 and TLS 1.0 rely on the second option. This turned out to be an issue and thus, the starting point to devise the BEAST attack which is illustrated by the author himself at the following link: http://vnhacker.blogspot.com/2011/09/beast.html
Apparently, in order to inherently address the issue, recent upgrades of TLS to version 1.1 and 1.2 switched it to the first approach. However, such versions have compatibility issues since not all modern browsers effectively support them.
In terms of the attack's complexity, - apparently significant but not necessarily applicable to any application context - further requirements for successful exploitation include the need to have a target domain which allows cross-origin requests that:
It is important to point out that no exploit or proof-of-concept has been made publicly available to date, so any testing activities may be focused solely on the analysis of the cipher suites being negotiated upon putting up the secure channel with the customer's server end. The aim would be to detect the presence of possible ciphers, based on CBC encryption algorithm, which could lead to security exposures related to the matter in question.
In case one wanted to carry out a quick check on his own, without necessarily having to run a full-blown vulnerability scan, a relatively straightforward bespoke script based on command-line OpenSSL can be helpful. The script, reported hereafter for the sake of clarity, acts as an SSL client that iterates several handshakes with the server on the basis of the available ciphers. This is done in order to determine which cipher suites are accepted at the server side.
When the Beast firstly came out, TLS v.1.0 and SSL v.3.0 were still considered compliant protocols. Thing have changed nowadays so we suggest you to learn more about this topic and stay up to date because the threat landscape is continuously evolving.
If someone wanted to implement a practical countermeasure to protect himself with the aim of improving overall security posture and further mitigate any residual risks, the following should be enough: disable any CBC-based cipher suites leaving only stream cipher-based encryption support enabled. Any other long-term countermeasure would inevitably involve enabling TLS v1.1 and TLS v1.2 support.
A good trade-off that would address both security and compatibility issues could be to put a few TLS 1.2 cipher suites first so that they can be picked up by TLS 1.2 clients (which are not vulnerable) followed by RC4 for TLS 1.0 clients.
Update: When the Beast firstly came out, TLS v.1.0 and SSL v.3.0 were still considered compliant protocols. Things have changed nowadays so we suggest you to learn more about this topic and stay up to date because the threat landscape is continuously evolving.
I am the Founder of Advantio.
Technology has been my passion since I was a kid; when I first heard the handshake of an old 300bps modem I realised security would be key in an interconnected world. Since then it has become my passion and primary focus.
The reason why I've started my own business is to make IT Security simple.
Certifications: CISSP / CCSA (Checkpoint) / ITIL Foundations / ACSA (ArcSight)/ Linux+/ PCI-QSA / PA-QSA