SeaCat Application Security Technology Is Not Impacted by the SWEET32 Issue (CVE-2016-2183)

Friday, August 26, 2016

The new vulnerability CVE-2016-2183 ^[1] affects the 3DES block cipher. It can be found in software like OpenVPN, OpenSSL, Apache Server, etc. During an attack, attackers need to find a collision of any encrypted block of CBC data stream to decrypt the traffic between the victim and the server.

A successful attack requires the following prerequisites:

• Long lasting connection that uses CBC mode of operation and 3DES or DES cipher
• Control the victim’s browser
• Perform the attack for approximately two days
• Capture at least hundreds 785 GB of traffic between the victim and the server (generated by malicious JavaScript code injected to victim’s browser)

Recommendation:

While it is hard to perform a SWEET32 attack, we strongly recommend you to disable 3DES/DES block cipher support. If you would like to know more about the anatomy of a SWEET32 attack, please continue.

Go deep for sweet

CBC mode of operation

To understand how the attack vector of SWEET32 works, we need to explain CBC mode of operation. In the following diagram you can see the usual encrypted connection using CBC mode of operation between two parties. Don’t be afraid, it is simple; you’ll see.

The Green parts represent shared secrets - exchanged between the sender and the recipient (using asymmetric cryptography at the beginning of the communication. you don't need to know more because it's not related to CBC or SWEET32).

Initialization vector (IV) is randomly generated by the sender. In an encryption process, IV is used to XOR the plaintext to produce a randomized first block. This means that CBC produces different output for the same plaintext for different connections. The Key, used as a password for symmetric encryption of transferred data, stays the same for the whole connection. This operation produces the first ciphertext block. Then, the first encrypted block is used as an “IV” for another block, etc.

Decryption works the same way but in reverse order. The key is used to decrypt a data block; then the IV is used to XOR the data and as a result, we can see the first block of data in plaintext. The encrypted block is then used as an “IV” input for second block etc. Easy.

The role of data block collision

In a typical situation, both communication parties know the shared secrets. For hackers, the shared secrets are unknown. What can they do to break the encryption?

Please have a look at the following diagram.

Let’s imagine the attacker can generate the plaintext, for example, all zeroes. The text has two blocks with the same content, represented by the green “block cipher encryption” rectangle in the diagram. The key is the only unknown which can be calculated from other green parts. Voila.

The attacker use collision to calculate the symmetric key, and thus, decrypt a 8kB-block of data from the sender. The attacker then needs to find another collision to decrypt the next 8kB of data.

The collision probability is related to the initialization vector length. Initialization vectors are randomly generated and have the same length as the data block.

Attack against CBC

As you can see from the diagram, CBC mode of operation security is related to the uniqueness of IVs. IVs length is the same as data block (you need to XOR all blocks of input data.) DES encryption uses data block equal to 64 bits, so do 3DES and Blowfish. The block length is not related to the key size, so even Blowfish-256 data block uses 64-bit length.

When an encryption with data blocks equal to 64 bits is used (e.g. 3DES, DES, Blowfish), we have 2⁶⁴ of possible IVs combinations. For 512 bytes long requests, this represents 1024 exabytes of data without the IV collision. I don’t want to capture this amount of traffic. But because of the well-known Birthday attack, the number of possibilities is significantly reduced to 2^64/2. For 512 bytes long requests it represents only 256GB of data to be captured.

"The Sweet32 attack requires only 2^29.1 short queries of 512 bytes (280 GB in total), which can be reduced to 2^27.6 longer queries of 4 kB (785 GB in total). In our demo, it took 18.6 hours and 705 GB, and we successfully recovered the 16-byte authentication token." - Karthikeyan Bhargavan and Gaëtan Leurent ^[2]

AES and Twofish use data blocks with 128bits length which results in an enormous amount of traffic to be captured in order to find a collision.

Go beyond CBC

IVs or nonces are used by other modes of operation like CTR, GCM, OCB, etc. The only difference is that other modes calculate the IVs differently. It's easier to preserve the uniqueness of the IVs, so it's difficult although not impossible to perform the described attack.

Prerequisites of a SWEET32 attack

SWEET32 attack can be performed only when certain prerequisites are met. And it is worth to say, that it is not easy to do it. Consider yourself:

Attacker needs to

• 3DES/DES/Blowfish in combination with CBC as a preferred cipher suite. About 1.1% of the top 100,000 web server from Alexa, and 0.5% of the top 1 million are vulnerable.
• Find a long lasting (in days) connection without renegotiation the communication.
• Inject the victim’s browser and execute a JavaScript to start generating requests with predefined content to the vulnerable server.
• Capture the traffic and find the collision.
• Have luck to find a session or a token string inside decrypted data packets to hijack the victim’s session.

Not an easy attack, but do you want to risk it?

How to protect yourself from a SWEET32 vulnerability?

Protection against SWEET32 is related to attack prerequisites:

• Use AES GCM. Do not use cipher suites with 3DES/DES or Blowfish encryption in combination with CBC mode of operation.
• Renegotiate connection once in awhile.

SWEET32 vulnerability and SeaCat technology

SeaCat Mobile Secure Gateway and SeaCat IoT platform do not use 3DES. Our technology configures only the two most secure cipher suites that do not contain 3DES encryption. We use exclusively AES with 256-bit key size. This cipher has 128-bit data blocks. We use AES in the GCM mode of operation.

All mobile and IoT applications secured by SeaCat technology are safe, and you don’t need to take any action.

If you have any question or concern, please contact support@teskalabs.com. Alternatively, look at our documentation to know more about SeaCat application security.

Reference:

1. https://www.openssl.org/blog/blog/2016/08/24/sweet32
2. https://sweet32.info