December 18, 2014

POODLE has Morphed??????

Recently, new exploits for the  RC4 stream cipher suite have come to light. It is used in almost half of the internet's SSL/TLS implementations, that "https" stuff that you see in front of your url, and many well know companies, including internet giant Google, are still using the protocol. However, at this time, security professionals are saying that an attacker would have to cause hundreds of millions of TLS connections while executing a Man-in-the-Middle attack, in order to glean enough information about the traffic being encrypted to mount a feasible attack.

For the moment, researchers are saying that we are safe, but administrators should not wait too long before disabling the SSLv3 fallback vulnerability. Security experts believe that development of GCM, Galois/Counter Mode symmetric key cryptographic block cipher, will be accelerated to help phase out RC4 cipher.

The security research company Qualys has created a testing page that can be used to check domains for the vulnerability. The site will also offer some tips for making your domain "more secure" by grading it and giving explanations as to why it received the grade that it did. The site looks to be fairly in depth and insightful. Qualys also has some vulnerability mitigation recommendations for the near future. I am going to list the ones pertinent to system administrators, as these are the individuals that will be needing this information the most. If you would like to read on about the others listed, please click here.


System Administrators
  • Disable TLS compression. This attack is similar in nature to the recent RC4 attacks, but practical. 
  • Support TLS 1.2 and GCM as soon as possible. 
  • Also, if you have not disabled SSLv3 compatibility, go ahead and do so. 

Example Use Case
The problem here (as usual) is your browser.
fYou see, there are certain common elements that your browser tends to send at the beginning of every HTTP(S) connection. One of these values is a cookie -- typically a fixed string that identifies you to a website. These cookies are what let you log into Gmail without typing your password every time.
If you use HTTPS (which is enforced in many sites by default), then your cookies should be safe. After all, they'll always be sent over an encrypted connection to the website. 
Unfortunately, if your connection is encrypted using RC4 (as is the case with Gmail), then each time you make a fresh connection to the Gmail site, you're sending a new encrypted copy of the same cookie. If the session is renegotiated (i.e., uses a different key) between those connections, then the attacker can build up the list of ciphertexts he needs.
To make this happen quickly, an attacker can send you a piece of Javascript that your browser will run -- possibly on a non-HTTPS tab. This Javascript can then send many HTTPS requests to Google, ensuring that an eavesdropper will quickly build up thousands (or millions) of requests to analyze.
Source: http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html

No comments:

Post a Comment

Twitter: @Th3MattWilson