How the POODLE attack was used to exploit Security protocol SSL v3.0
POODLE stands for Padding Oracle On Downgraded Legacy Encryption. It was a significant security vulnerability where SSL v3.0 can be attacked and the encrypted data between the computers and servers can be potentially intercepted and decrypted.
Too much tech grammar? ... Dont worry as I will demystify this as easy as possible to you. Just stay with me.
Encryption is an algorithm that converts plain-text to a chipher/encrypted text with the aid of a secret key. If encryption is properly done then there is assurance that the data is kept confidential as it cannot be easily decrypted by any malicious person since he has no knowledge of the secret key.
Poodle attacke on the other hans allows the malicious person to decrypt some of the SSL v3.0 trafic. With this they may then be able to get enough information to get access to the victims secured online accounts
This is how the attack works.
1. Imagine you are browsing a secure web say your internet banking platform that is using SSL v3 security protocol. You enter your credentials and click login, the following happens:
2. In SSL v3, the first thing that is done in encrypting the data is to compute a Message Authentication Code (MAC). This serves a a cryptographic checksum ensuring the integrity and authenticity of the data. Note that the MAC can only be computed by parties that have access to the right cryptographic keys. These parties will of course be the client and the server.
So if a malicious person tries to modify the data through Man-in the Middle attack and he doesn't have the cryptographic key, he would be unable to update the MAC value and hence the system will detect that the data lacks integrity and throws it out.
3. After the MAC has been computed there are some paddings that have to be place after the MAC. Padding is placed because many popular encryption algorithms require that the data been encrypted should have a length which is a multiple of a particular size.
For example,
- AES the length has to be a multiple of 16 bytes
- DES the length has to be a multiple of 8 bytes
5. The padding approach used in SSL v3 is fairly simple. It is done as seen below
- Generate a random byte values and
- Generating a final value that indicated the size of the padding ie how many bytes were padded.
- The Original data
- The Message Authentication Code (MAC)
- The Padding with its padding size
There were however flaws in this method of padding
6. The full payload which we already know contains the actual data, the MAC and the padding are then encrypted.
7. The method used for the encryption is called the Cipher Block Chaining Mode (CBC mode)
8. CBC is achieved by breaking the entire data (which is the payload), and breaking them into chunks of blocks.
9. Each chunks of block is then encrypted. Now the interesting part is that all blocks relate and are dependent on each other. That is, the value of the encryption of the 1st block is used to compute the encryption of the 2nd block.etc. This method is called the Exclusive OR (XOR) operation
10. Decrypting the just requires the reverse of the entire process. Which is decrypting the last block and working all the way to the first block.
11. After the decryption of the payload is done the recipients will then perform the following
- Look at the length of the padding to know how much padding to remove
- When the padding is removed the next value in the payload is the MAC value
- The MAC is then checked to verify the authenticity and integrity of the data.
- If the MAC check fails the recipient will drop the connection
- However if the MAC check is successful a session is created for the communication.
How an Attacker takes advantage of these flaws
There are 2 types of errors in SSL v3 decryption which are
- Padding error
- MAC error
These errors are the give-aways in the PODDLE attack. A malicious person attacking using PODDLE must be able to identify and mostly distinguish between these errors.
Let me explain
Supposes an attacker has intercepted an encrypted text and he wants to decrypt it he will perform the following
- Submit a crafted encrypted text and send it to the server
- The server will decrypt the encrypted text and check to see if the padding is valid
- If the padding is invalid it will generate a Padding error and drop connection
- If however, the padding is correct it will check to see if the MAC is valid. Now since it is not the original message but a crafted one, the MAC will be invalid and thus a MAC error is generated and connection is droped.
Now what the attacker is actually looking for is the MAC error. This is because the MAC error tells him that the Padding was successful.
This type of attack can also be referred to as a CHOSEN CIPHERTEXT ATTACK
This permutations will be continued by the attacker until he completes guessing out all the bytes making up the encrypted text.
SSL and earlier versions of TLS (1.0) echoed these error messages making them vulnerable to the PODDLE attack
So how does he really use the Padding error to arrive at the encrypted text
Recall that the full payload to be encrypted will be broken down into chunks of blocks and encrypted.
Also recall that I said the blocks are related to each other. Good.
- Lets assume the attacker intercepted a message and placed the letter "T" in the last byte of the first block.
- The attacker also adds a guess padding to the message say x02. Thus we have a complete crafted message of Tx02.
- Remember the encryption value of the first block will be used to encrypt the second block.
- When decryption is to be performed the 2nd padding will need the value and the padding constructed in the 1st block which it Tx02.
- If a padding error occurs during the decryption, then our guess "T" is wrong and our padding x02 is invalid.
- However if the padding is right it tells us that the MAC address is wrong because the guess "T" is not the entire encrypted text.
- But since the error we are now getting is the MAC, this means that the Padding was correct.
- For the padding to be correct means our guess of "T" is right.
- The attacker will continue with these guesses until all encrypted values are revealed.
Now because of these attack most server have stepped up their prefered security protocols to TLS 1.1 and 1.2.
However for backward compatibility to some clients some server still keep the legacy security protocols (SSLv3 and TLS 1.0).
When a secure communication is to be established (HANDSHAKE) the prefered security protocol is negotiated between the client and the server (for clarity on this read my post on:
HTTPS Secure connection Handshake: 11 Steps on how its established
Attacker have found another way to ensure that the security protocol is always downgraded to SSLv3 for the handshake so that they can mount the PODDLE exploit on the unsuspecting victim.
This is why it is not advisable for a server servicing sensitive transaction and medical data to support SSLv3 and TLS1.0. Please note this.
How to prevent the PODDLE attack
- Avoid the use of obsolete browsers. Its important that you update your browser to teh most recent version.
- Ensure servers handling sensitive data have SSLv3 and TLS1.0 support disabled. With this implemented, such server will no longer be able to HANDSHAKE with the security protocols.
Wow this was a lot more complex than I thought. i hope you didn't sleep off on me.
Anyways thanks for reading my post.
Please do not hesitate to send me feedback through comments.
Cheers


Comments
Post a Comment