HTTPS Cracked! SSL/TLS Attacked And Exploited
People who blog about ethical hacking have a very sincere relationship with Cryptographers. They (the Cryptographers) keep bringing in something delightful into the everyday nonsense and we blabber about their accomplishments until its squishy and old - this love goes far beyond then can be comprehended by normal folk. No offence.
It seems like they have swept us off our feet again and this time around, they are flaunting the big guns. Cryptographers have targeted SSL/TLS and done some serious damage to HTTPS. Transport Layer Security didn't face a major blow during the attack as it requires to capture millions and billions of connections consisting of the same plaintext. But this highlights a major issue present in using the RC4 encryption algorithm.
RC4 uses the same key for encryption and decryption, whereas TLS uses a public/private key pair for encryption and decryption which makes it lag therefore it uses a hybrid approach. TLS connection can be setup using public/private key pairs and once established can share encrypted data over a secure network that uses ciphers for encrypting data such as AES, DES, Triple-DES, Blowfish, RC4, etc.
RC4 has been advised against many times in the past but its also a fact that it brings in half of all TLS traffic. So, the attack was done on a part of TLS by AlFardan-Bernstein-Paterson-Poettering-Schuldt (AIFBPPS).
According to NakedSophos team;
RC4 is a stream cipher, so it is basically a keyed cryptographic pseudo-random number generator (PRNG). It emits a stream of cipher bytes that are XORed with your plaintext to produce the encrypted ciphertext.
To decrypt the ciphertext, you initialise RC4 with the same key, and XOR the ciphertext with the same stream of cipher bytes. XORing twice with the same value "cancels out", because k XOR k = 0, and because p XOR 0 = p.
RC4 generates a statistically anomalous output initially in each stream of cipher bytes. Therefore it is not a high-quality cryptographic PRNG. This phenomenon was first observed by Itsik Mantin and Adi Shamir in 2001. They noticed that during the second output byte the value zero turned up twice as often as it should; 256 keys on average to be precise with a probability of 1/128. This resulted in WEP being attacked which was then replaced by WPA.
AIFBPPS have taken this attack further than anyone else "producing statistical tables for the probability of every output byte (0.255) for each of the first 256 output positions in an RC4 cipher stream, for a total of 65535 (256x256) measurements."
By using a sufficiently large sample size of differently-keyed RC4 streams, they achieved results with sufficient precision to determine that almost every possible output was biased in some way.
The probability tables for a few of the output positions (which are numbered from 1 to 256) are show below.
The authors realised that if you could produce TLS connections over and over again that contained the the same data at a known offset inside the first 256 bytes (for example an HTTP request with a session cookie at the start of the headers), you could use their probability tables to guess the cipher stream bytes for those offsets.
Here's a brief description of how it works by NakedSophos team:
"Imagine that you know that the 48th plaintext byte, P48, is always the same, but not what it is.
You provoke millions of TLS connections containing that fixed-but-unknown P48; in each connection, which will be using a randomly-chosen session key, P48 will end up encrypted with a pseudo-random cipher byte, K48, to give a pseudo-random ciphertext byte, C48.
And you sniff the network traffic so you capture millions of different samples of C48.
Now imagine that one value for C48 shows up more than 1% (1.01 times) more frequently than it ought to. We'll refer to this skewed value of C48 as C'.
From the probability table for K48 above, you would guess that the cipher byte used for encrypting P to produce C' must have been 208 (0xD0), since K48 takes the value 208 more than 1% too often.
In other words, C' must be P XOR 208, so that P must be C' XOR 208, and you have recovered the 48th byte of plaintext.
The guesswork gets a little harder for cipher stream offsets where the skew in frequency distribution is less significant, but it's still possible, given sufficiently many captured TLS sessions.
AlFBPPS measured how accurate their plaintext guesses were for varying numbers of TLS sessions, and the results were worrying, if not actually scary:
"However, given the huge number of TLS sessions required, The Register's provocative URL theregister.co.uk/tls_broken might be going a bit far.
Initiating 232 (4 billion), or even 228 (260 million), TLS sessions, and then sniffing and post-processing the results to extract a session cookie is unlikely to be a practicable attack any time soon.
If nothing else, the validity of the session cookie might reasonably be expected to be shorter than the time taken to provoke hundreds of millions of redundant TLS connections.
On the other hand, the advice to avoid RC4 altogether because of its not-so-random PRNG can't be written off as needlessly conservative.
If you can, ditch RC4 from the set of symmetric ciphers your web browser is willing to use, and your web servers to accept.
Go for AES-GCM instead.
GCM, or Galois/Counter Mode, is a comparatively new way of using block ciphers that gives you encryption and authentication all in one, which not only avoids the risky RC4 cipher, but neatly bypasses the problems exposed in the Lucky 13 attack, too."
Cheers!
About the Author:
This Article has been written by Dr. Sindhia Javed Junejo. She is one of the core members of RHA team.
