About these ads

Archive

Posts Tagged ‘TLS’

More Details on CRIME Attack: Takes Advantage Of TLS Compression [VIDEO]

September 13, 2012 2 comments

More details have been released about CRIME, the brand new attack against TLS developed by Juliano Rizzo and Thai Duong.

The attack takes advantage of a flaw in the compression ratio of TLS requests wich allows the attacker to decrypt the requests made by the client to the server. The attacker is able to steal the user’s login cookie and then hijack the user’s session, impersonating him on other destinations such as banks or e-commerce sites.

Not only the attack works on any version of TLS, but also the number of requests needed for the attack to be sucessful is quite small, as low as six requests per cookie byte.

Each browsers that implements either TLS or SPDY compression (SPDY is an open standard developed by Google to speed up Web-page load times) is vulnerable. The list includes Google Chrome, Mozilla Firefox, and Amazon Silk. The attack also works against several popular Web services, such as Gmail, Twitter, Dropbox and Yahoo Mail. In any case Google and Mozilla have already developed patches to defend against the CRIME attack.

Meanwhile the researchers have released a video with the exploit in action against Dropbox and Github (which patched the servers before the release of the video).

Best way to protect yourself? Upgrade browsers to the latest version and disable compression on servers.

About these ads

What Security Vendors Said One Year Ago…

January 10, 2012 2 comments

I did not resist, so after publishing the summary of Security Predictions for 2012, I checked out what security vendors predicted one year ago for 2011. Exactly as I did in my previous post, at the beginning of 2011 I collected the security predictions in a similar post (in Italian). I also published in May an update (in English) since, during the Check Point Experience in Barcelona held in May 2011, the Israeli security firm published its predictions. Even if the latters have been published nearly at the half of 2011, for the sake of completeness, I decided to insert them as well in this year-to-year comparison.

Then, I included Symantec (for which this year I did not find any prediction), McAfee, Trend Micro, Kaspersky, Sophos and Cisco. I included Check Point in a second time and I did not include Fortinet, At that time I missed their five security predictions, which I only discovered later so I decided to provide an addendum for this post including Fortinet as well in order to provide a deeper perspective.

The security predictions for 2011 are summarized in the following chart, which reports what the vendors (with the partial above described exception of Checkpoint) expected for the past year in terms of Information Security trends.

But a strict side-by-side comparison with the 2012 information security predictions (extracted by my previous post) is more helpful and meaningful:

As you may notice mobile threats were on top even among the predictions for 2011. This prediction came easily true most of all for Android which suffered (and keeps on suffering) a huge increase in malware detection samples (even if the overall security risk remains contained). Social Media were on top as well: they have been crucial for the Wind of the Changes blown by the Arab Spring but in the same time Social Media have raised many security concerns for reputation, the so called Social Network Poisoning (who remembers Primoris Era?). Although 2011 was the year of the Anonymous, hacktvism ranked “only” at number 4, behind Advanced Persistent Threats, which however played a crucial role for information security (an APT was deployed for the infamous RSA Breach, but it was not an isolated case).

Also botnets, web threats and application vulnerabilities ranked at the top of Security predictions for last year (and came true). As far as botnets are concerned, fortunately 2011 was a very important year for their shutdown (for instance Hlux/Kelihos, Coreflood, Rustock). In several cases the botnets were taken down thanks to joint operations between private sectors and law enforcement agencies (another prediction came true). On the application side, this prediction came true most of all thanks to the Sony breach, the Liza Moon infection and the huge rate of SQLi based attacks and ASP.NET vulnerabilities. We have also assisted to an hard blow to SSL/TLS and XML Encryption.

But what is more surprising (and amusing) in my opinion is not to emphasize which predictions were correct, but rather to notice  which predictions were dramatically wrong: it looks like that, against the predictions, virtualization threats were snubbed by cybercrookers in 2011 (and nearly do not appear in 2012). But the most amusing fact is that no security vendor (among the ones analyzed) was able to predict the collapse of the Certification Authority model thanks most of all to the Comodo and Diginotar Breaches.

Browsing Security Predictions for 2012

January 8, 2012 4 comments

Update 01/11/2012: Year-to-Tear comparison with 2011 Security Predictions

The new year has just come, vacations are over, and, as usually happens in this period, information security professionals use to wonder what the new year will bring them from an infosec perspective. The last year has been rich of events, whose echo is still resounding, and as a consequence, if RSA and Sony breach were not enough, the main (and somehow obvious) question is: will 2012 stop this trend or rather bring it to unprecedented levels, or, in other words, which threat vectors will disturb the (already troubled) administrators’ sleep?

Unfortunately my divination skills are not so developed (in that case I would not be here), but security firms can give a crucial help since they started to unveil their security predictions for 2012, at least since the half of December, so putting them together, and analyzing them is quite a straightforward and amusing task. Maybe even more amusing will be, in twelve years, to see if they were correct or not.

The security prediction that I take into consideration included, at my sole discretion (and in rigorous alphabetical order):

•    Cisco;
•    Fortinet;
•    Kaspersky;
•    McAfee;
•    Sophos;
•    Trend Micro;
•    Websense;

That is the only leader vendors for which I found predictions issued with original documents (feel free to indicate if I missed someone and I will be very glad to include them in the chart).

In any case, the landscape is quite heterogeneous since it encompasses security vendors covering different areas: one vendor, McAfee, covering all the areas (network, endpoint and content security), two vendors and one half focused on network and content security (Cisco, Fortinet and partially Sophos thanks to the Astaro acquisition), and two vendors focused essentially on endpoint security (Kaspersky and Trend Micro).

The following table summarizes their predictions:

In order to correctly understand the chart a premise is needed: as you will probably have already noticed, in several cases the predictions reflect the specific security focus for the analyzed vendor. For instance, Websense is focused on DLP, and that is the reason why the adoption of DLP is one of its predictions. Analogously McAfee is investing huge resources for Security on Silicon, and this implies that embedded systems and Malware Moving Beyond OS are present among its predictions. Same speech could be applied for Trend Micro and its Cloud Prediction and so on.

Some trends for this year are clearly emphasized: easily predictable Hactivism appears on 6 of the 7 vendors, as mobile (with different connotations) does. Social Media is on the spot as well as are SCADA, Embedded Systems and, quite surprisingly in my opinion, cloud. I would have expected a greater impact for APTs, but for a complete and more accurate analysis one should consider them together with threats targeting embedded systems or ICS. Even because according to several security firms, for instance Kasperky, APT Stuxnet-like will be used for tailored campaigns, whilst more “general purpose malware”, including botnets will be used for massive campaigns (this item is summarized as Mass Targeted Campaigns).

 

Some “old acquaintances” will be with us in 2012: consumerization, at least according to Sophos and Trend Micro (even if consumerization is strictly connected, if not overlapped with mobile) and, if the Comodo and Diginotar affaires were not enough, Rogue Certificates, according to McAfee. Instead some “new entries” are absolutely interesting, such as the threats related to NFC (even if in this case I would have expected a greater impact) or related to Virtual Currency. Besides let us hope that the prediction to adopt DNSSEC be more than a prediction but a consolidated practice.

The most conservative security firm? In my opinion Cisco. The most “visionary”? Maybe Fortinet, I found the “Crime as a Service (CaaS)” absolutely awesome, and most of all not so visionary, since there are already some (even if clumsy) attempts.

In any case with this plenty of Cyber Nightmares is not a surprise the fact the Enterprise security market is going to reach $23 billion worldwide in 2012 with a 8.7% growth year-on-year.

The Beauty (RC4) and The BEAST (TLS)

September 25, 2011 5 comments

Hard times for Information Security and for the authentication models it had been built upon. The inglorious falls of  SecureID and Certification Authority Authentication models were not enough in this troubled 2011 and now it looks like the last authentication bastion was breached after Thai Duong and Juliano Rizzo unleashed their BEAST (Browser Exploit Against SSL/TLS) attack.

The attack exploits a well known vulnerability on CBC mode encryption algorythms (such as AES and 3DES) which affects SSL and TLS 1.0. CBC mode encryption divides the plaintext in fixed size blocks (usually 128 bits). In this mode of operation each block of ciphertext is not directly encrypted, rather, before undergoing the operation, is XORed with the previous Ciphertext. Of course the first block of the message may not be XORed with any previous Ciphertext and for this reason an hard-guessable random vector, called IV or Inizialization Vector is chosen to inizialize the encryption process.

During an encryption session (think for instance to an HTTPS session) several TLS messages are transmitted inside the same encryption channel and here come the troubles: unfortunately TLS 1.0 implementation does not use a new IV for each TLS message, that is the ciphertext of the last block of the previous message is used as the Inizialization Vector of the new message. Unfortunately this approach limits the unpredictability of the Inizialization vector: an attacker could in theory try to guess some plaintext somewhere in the encryption stream and inject a crafted plaintext so that if the encrypted output of that block corresponds exactly to the ciphertext of the block in which the guessed original message was encrypted, this means that the attacker’s guess was right. The attack is made possible in theory just because the CBC mode use the output of the previous block as the IV for the next plaintext block.

From a more formal point of view a nice and very clear description is reported at this link which I report in the following lines:

Consider the case where we have a connection between Alice and Bob. You observe a record which you know contains Alice’s password in block i, i.e., Mi is Alice’s password. Say you have a guess for Alice’s password: you think it might be P. Now, if you know that the next record will be encrypted with IV X, and you can inject a chosen record, you inject:

X ⊕ Ci-1 ⊕ P

When this gets encrypted, X get XORed in, with the result that the plaintext block fed to the encryption algorithm is:

Ci-1 ⊕ P

If P == Mi, then the new ciphertext block will be the same as Ci, which reveals that your guess is right.

The question then becomes how the attacker would know the next IV to be used. However, because the IV for record j is the CBC residue of record j-1 all the attacker needs to do is observe the traffic on the wire and then make sure that the data they inject is encrypted as the next record, using the previous record’s CBC residue as the IV.

So apparently nothing new under the sun, except the fact the attack scenario is higly unlikely since the attacker should find a way to guess some patterns and inject some well known patterns inside the encrypted channel unless…

Unless the attacker could inject a large amount of known malicious data at a time (in order to limit the guessable plaintext in each block) and use a Web server side method to inject them.

This is exactly where the two main features of the BEAST attack rely: what if an attacker could guess where the encrypted password is located inside the encrypted channel, and split the original block in several 16 bytes blocks in which a single byte contains the original character of the password and the remaining 15 bytes contain the malicious known padding? Quite Easy! The attacker should try “only” 2^8 (256) possible values in order to guess the first character and obtain the same encrypted output than the crafted plaintext. Once guessed the first character, he could obtain the IV for the next block from the ciphertext, and guess the next character of the password in the next block with the same method: the first byte is known to be the first character of the password, the second byte is the unknown quantity and the other 14 bytes contain the malicious known padding. Shifting up to the last block the attacker could obtain the password.

Of course in theory there is still a big issue consisting in the injection of the known pattern in the encryption channel. In order to overcome it the attackers used a method (for which so far few details were disclosed) leveraging Web Sockets, a technology which provides for bi-directional, full-duplex communications channels, over a single TCP Socket. In a meshed-up world, Web Sockets are used for instance when a Web Server redirects a browser to another server to get a certain content (for instance an embedded Image). In Web Socket models, the browser handshakes directly with the remote server and verify if the connection is ok from the first server (origin based consent).

The same article mentioned above delineates how Web Sockets may be exploited to perpetrate the attack:

Say the attacker wants to recover the cookie for https://www.google.com/. He stands up a page with any origin he controls (e.g., http://www.attacker.com/. This page hosts JS that initiates a WebSockets connection to https://www.google.com/. Because WebSockets allows cross-origin requests, he can initiate a HTTPS connection to the target server if the target server allows it (e.g., because it wants to allow mash-ups). Because the URL is provided by the attacker, he can make it arbitrarily long and therefore put the Cookie wherever he wants it with respect to the CBC block boundary. Once he has captured the encrypted block with the cookie, he can then send arbitrary new packets via WebSockets with his appropriately constructed plaintext blocks as described above. There are a few small obstacles to do with the framing, but Rizzo and Duong claim that these can be overcome and those claims seem plausible.

Although TLS 1.1 and 1.2 introduce a randomizaton of the IV for each message, the dramatic thing is that TLS 1.1 has been published in 2006 but it is far from being commonly adopted. The funny thing is that in order to mitigate the attack Web Servers should use a cipher which does not involve CBC mode, as for instance RC4 (back to the future).

Google servers already use RC4 while Chrome developers are testing a workaround. Will RC4 be enough to save the infosec world from the fall of authentication?

Follow

Get every new post delivered to your Inbox.

Join 3,172 other followers