TLS Attacks - Padding Oracles


TL;DR : Padding Oracle Attacks exploit the way some implementations of TLS handle padding in encrypted messages, allowing attackers to decrypt the messages without knowing the encryption key.


In Layerman"s terms
Protagonists
Bob: A visitor to a small shop.
Alice: The shop owner.
Jack: A prankster.

Jack wants to exploit a weakness in the way Bob and Alice securely communicate using locked boxes.

Bob sends a securely locked box to Alice, but there's a special way the box must be packed for Alice to unlock it correctly. Jack, knowing this, intercepts the box and starts tampering with the contents. Each time Jack sends the altered box to Alice, he waits for a clue—whether Alice can unlock it or not.

When Alice tries to open the box, if she gets it wrong, she sends back a subtle signal indicating the mistake. Jack uses these signals to figure out the correct way to pack the box. By repeating this process many times, Jack eventually learns how to pack the box correctly himself, allowing him to read the message inside without Bob or Alice realizing the communication has been compromised.

This makes the secure communication vulnerable to Jack's manipulation and eavesdropping.

Scenario: Padding Oracle Attack to Decrypt Encrypted Messages

Step 1: Initiating an Encrypted Communication

The user establishes a secure connection with a server, where messages are encrypted using TLS. The encryption uses block cipher modes that require padding, such as CBC (Cipher Block Chaining) to ensure data confidentiality and integrity during transmission between the user's device and the server.

Step 2: Intercepting an Encrypted Message

The attacker intercepts an encrypted message sent from the user to the server. This can be done using a MitM attack, compromising a router, or capturing packets on the network.

Step 3: Manipulating the Encrypted Message

The attacker modifies the intercepted encrypted message by altering the ciphertext to trigger an error response from the server that can provide clues about the padding validation. They then send the manipulated message to the server.

Step 4: Observing the Server's Response

The server attempts to decrypt the manipulated message and checks the padding. If the padding is incorrect, the server sends an error message. The attacker observes whether the server returns a padding error or a different type of error to infer information about the plaintext..

Step 5: Iteratively Refining the Attack

By systematically manipulating the ciphertext and observing the server's responses, the attacker can gradually determine the correct padding and ultimately decrypt the message without needing to know the encryption key.. This process is repeated for each block of the encrypted message.

Effect on Privacy, Anonymity, and Hacking Concerns

Primarily, risks involve data theft, data integrity, and loss of privacy or confidentiality.

  • The "Lucky 13" attack, which targets the TLS protocol was discovered by researchers Nadhem AlFardan and Kenny Paterson in 2013. This attack exploits subtle timing differences in how TLS implementations processed padding errors versus valid padding. By measuring the time it took for the server to respond to requests, attackers could infer whether the padding was correct, allowing them to decrypt the ciphertext without needing the encryption key.

  • The Marvin Attack is a timing-based vulnerability affecting RSA decryption and signing operations, originally discovered 25 years ago. It exploits how servers handle PKCS#1 v1.5 padding errors, allowing attackers to decrypt ciphertexts or forge signatures. This vulnerability impacts various cryptographic implementations, including those in .Net, Apple corecrypto, BouncyCastle, GnuTLS, and others. The recommended mitigation is to stop using RSA PKCS#1 v1.5 encryption and update to more secure protocols.

Note: This type of attack highlights the challenges in implementing side-channel resistant cryptographic algorithms. A lot of internet servers are still at risk in 2018 due to the unaffected implementation of such vulnerabilities and protocolar systemics.

You can read more about Padding Oracle attacks here


Done!

Thanks and Congratulations for reading this to the end. We hope this article brings a little clarity over TLS Padding Oracle attacks.