Padding Oracle Hunter. A Burp Suite extension to tackle the padding oracle vulnerability

Tan Inn Fung
CSG @ GovTech
Published in
10 min readApr 13, 2022

Background

After several penetration testing engagements last year, I was surprised to find out that the padding oracle vulnerability was quite common in web applications. The vulnerability could be exploited easily, and the impact was significant. If successfully exploited, it allowed the plaintext to be recovered and modified by purely manipulating the ciphertext without needing the secret key. Attackers could create their own encrypted data to return to the server for decryption and processing. The server would usually implicitly trust this data, as it would not expect unintended parties to possess the secret key used for encryption and decryption. The two most common type of padding schemes that are subjected to the padding oracle vulnerability are PKCS#7 and PKCS#1 v1.5. This article will introduce the padding oracle vulnerability, how the newly developed extension (Padding Oracle Hunter) could be used to tackle the vulnerability and will conclude by highlighting some mitigation measures against the vulnerability.

Introduction to PKCS#7 and PKCS#1 v1.5 padding

PKCS#7 is normally used for block cipher encryptions, particularly in cipher block chaining (CBC) mode. The padding is required because the block cipher works based on its corresponding block size. The padding is added at the end of the last message block to ensure that its block length is equal to the block size. The value of each added byte is the number of bytes that need to be padded.

For example, let’s say a block size is 16 bytes and the plaintext to be sent for encryption is 15 bytes in hexadecimal: 43 53 47 20 69 73 20 74 68 65 20 62 65 73 74.

As the block size is 16 bytes, we will need to pad a byte 0x01 to the message so that it becomes 43 53 47 20 69 73 20 74 68 65 20 62 65 73 74 01.

If the plaintext’s length is more than 16 bytes, every 16 bytes from the start will be used to form a block. If the remaining data is less than 16 bytes, it will be padded with enough bytes so that the resulting block will be 16 bytes long. During the decryption process, the last message block will be decrypted first, followed by the padding and the rest of the blocks.

Unlike PKCS#7, the PKCS#1 v1.5 is a padding scheme used by RSA (Rivest-Shamir-Adleman) cryptosystem and is a common technique for asymmetric encryption. The padding is applied to the message to ensure the length of the message is the same as the modulus length in order to thwart a short message and small public exponent attack. The PKCS#1 v1.5 padding for a message m follows the format 0x0002 || r || 0x00 || m where r = random bytes. The length of the random bytes is |r| = |n| — |m| — 3 where n is the public modulus. Similar to PKCS#7, during decryption, the ciphertext will be decrypted first and the padding will be verified and removed before the plaintext is being returned.

The Attack

Unfortunately, both padding schemes suffer from the padding oracle attack if not properly utilized. If the server responds differently when the padding is correct/incorrect, the attacker can make use of this information to recover and modify the plaintext. The following two diagrams show the login authentication example for a server that is not vulnerable and a server that is vulnerable to a padding oracle attack.

Figure 1: Server that is not vulnerable to a padding oracle attack
Figure 2: Server that is vulnerable to a padding oracle attack

For PKCS#7, once the attacker has identified the vulnerable server as shown in Figure 2, he will apply the divide and conquer approach to first recover one byte of the plaintext by continuously modifying a specific ciphertext’s byte and send it to the server until it returns the valid padding response. After a single byte of the plaintext has been recovered, the attacker will use it to recover the next plaintext byte with the same approach. It is worth mentioning that a similar approach can be used to modify the plaintext as well. More details about the attack can be found here.

For PKCS#1 v1.5, the attacker will perform the Blechienbacher attack by exploiting the homomorphic property of the RSA algorithm. The attacker continuously multiplies the ciphertext with some chosen value(s) until the server responds with a valid padding. The attacker will then continue with the previous step to further reduce the boundary, until a single value (the plaintext) is found.

Introducing the Padding Oracle Hunter

Even though the vulnerability is easy to identify, it can still take a fair amount of time for a penetration tester to develop a working exploit that can be used to recover and modify the plaintext. For this reason, GovTech’s Cyber Security Group (CSG) has developed a Burp Suite extension named Padding Oracle Hunter which can help testers quickly identify and exploit this issue.

Installation

1. Download the release build of the Padding Oracle Hunter.

2. Launch the Burp Suite.

3. Set up the Jython environment if you haven’t done so.

4. Switch to the Extender tab which is located at the top row.

5. Under the Burp Extensions panel, click Add

6. Under Extension Details, select python as the Extension type and click Select file to select the padding_oracle_hunter.py python script.

7. You should encounter no errors and see a new tab labelled Padding Oracle Hunter on the top row.

Alternatively, you can install it directly through BurpSuite’s BApp Store

A test server was created to simulate the padding oracle vulnerability. To set up the server:

1. Clone this repository

2. Go inside the TestVulServer directory and run docker-compose up command

3. The server can be accessed through http://ServerIP:8000

Figure 3: Test server to simulate the padding oracle vulnerability

Overview

Currently, the extension consists of two separate tabs: PKCS#7 and PKCS#1 v1.5, and they support the following functionalities:

PKCS#7

The following image breaks down Padding Oracle Hunter’s UI to identify and perform the padding oracle attack targeting the PKCS#7 padding scheme on a CBC block cipher. The attack allows plaintext recovery and modification without having the key.

Figure 4: Padding Oracle Hunter PKCS#7 GUI

The components of the GUI (above) are as follows:

  1. Http request window.
  2. Panel to select the payload and its format. To achieve full decryption, the payload is expected to be in the format of IV || ciphertext.
  3. The number of threads used to perform the attack. With more threads, the computation is expected to be faster.
  4. The block size of the encryption protocol.
  5. The unique response from the server (partial or full) due to valid or invalid padding. This is only used during encryption and decryption operations.
  6. The plaintext which will be used to compute the ciphertext. This is only used during an encryption operation.
  7. Output window to display the results.
  8. Test function to verify whether the server is vulnerable to the PKCS#7 padding oracle attack.
  9. Encrypt function to compute the ciphertext from the given plaintext.
  10. Decrypt function to recover the plaintext from the encrypted payload.
  11. Stop function to halt all the current operations.

PKCS#1.5

The following GUI can be used to identify and perform the padding oracle attack targeting the PKCS#1 v1.5 padding scheme on RSA Cryptosystem. The attack allows the plaintext to be recovered with only public key information.

Figure 5: Padding Oracle Hunter PKCS#1 v1.5 GUI

The components of the GUI (above) are as follows:

  1. Http request window.
  2. Panel to select the payload and its format.
  3. The RSA public exponent.
  4. The RSA public modulus.
  5. The unique response from the server (partial or full) due to valid or invalid padding. This is only used during a decryption operation.
  6. Interval to update the decryption results.
  7. Output window to display the results.
  8. Test function to verify whether the server is vulnerable to PKCS#1 v1.5 padding oracle attack.
  9. Decrypt function to recover the plaintext from the encrypted payload.
  10. Stop function to halt all the current operations.

Extension Usage

PKCS#7

The following steps show how the Padding Oracle Hunter can be used to identify and exploit the PKCS#7 padding oracle vulnerability in the test server.

  1. Copy the sample ciphertext for AES at http://ServerIP:8000 as shown in Figure 3. Go to the test server endpoint at http://ServerIP:8000/TestAesPKCS7 with the following POST request and the copied ciphertext. Notice that we logged in as a normal user.
Figure 6: PKCS#7 POST request to login as normal user

2. Pipe the request through Extensions -> Padding Oracle Hunter -> PKCS#7

Figure 7: Pipe the request to Padding Oracle Hunter -> PKCS#7

3. Select the ciphertext value in the Request window, click Select Payload with Hex format, and uncheck Url Encoded. The payload will be enclosed within the § symbol.

4. Click the Test button and it will provide a summary which will indicate if the server is vulnerable to the padding oracle attack with its corresponding invalid/valid padding payload and response.

Figure 8: Test function indicating the server is vulnerable to PKCS#7 padding oracle attack

5. Copy either part of the padding response, or the full padding response from the Output window and put it in the Padding Response textbox. You can choose to use either the valid or invalid padding response. Click the Decrypt button to recover the plaintext.

Figure 9: Decrypt function to recover the plaintext using the PKCS#7 invalid padding response
Figure 10: Decrypt function to recover the plaintext using the PKCS#7 valid padding response

6. To escalate to admin privileges, we will need to modify the plaintext to {“userid”:”100",”isAdmin”:”True”} and convert it to a hexadecimal value.

Figure 11: Convert the modified plaintext to hexadecimal value

7. Copy the modified hexadecimal value to the Plaintext textbox and click the Encrypt button to compute the corresponding ciphertext.

Figure 12: Encrypt function to compute the ciphertext from the modified plaintext

8. Update the http request with the newly computed ciphertext and send the request to the server. Notice that we are now logged in as an admin.

Figure 13: Modify the PKCS#7 POST request to login as an admin

PKCS#1 v1.5

The following steps show how the Padding Oracle Hunter can be used to identify and exploit the PKCS#1 v1.5 padding oracle vulnerability in the test server.

  1. Copy the sample ciphertext for RSA at http://ServerIP:8000 as shown in Figure 3. Go to the test server endpoints at http://ServerIP:8000/TestRsaPKCS1_5 with the following POST request and the copied ciphertext.
Figure 14: PKCS#1 v1.5 Post request with ‘Success’ response

2. Pipe the request through Extensions -> Padding Oracle Hunter -> PKCS#1 v1.5

Figure 15: Pipe the request to Padding Oracle Hunter -> PKCS#1 v1.5

3. Select the ciphertext value in the Request window, click Select Payload with Hex format, and uncheck Url Encoded. The payload will be enclosed within the § symbol.

4. Fill in the public key parameters with public exponent: 65537 and modulus: 91150209829916536965146520317827566881182630249923637533035630164622161072289

5. Click the Test button, and it will provide a summary which will indicate if the server is vulnerable to a padding oracle attack with its corresponding invalid/valid padding payload and response.

Figure 16: Test function indicating the server is vulnerable to PKCS#1 v1.5 padding oracle attack

6. Copy either part of the padding response, or the full padding response from the Output window and put it in the Padding Response textbox. You can choose to use either the valid or invalid padding response. Click the Decrypt button, and the plaintext will be recovered after about 50k requests.

Figure 17: Decrypt function to recover the plaintext using the PKCS#1 v1.5 invalid padding response
Figure 18: Decrypt function to recover the plaintext using the PKCS#1 v1.5 valid padding response

Conclusion

The padding oracle vulnerability has been made known for some time but can unfortunately still be found in many modern applications as it is easily overlooked when developers implement the padding algorithm or utilize the cryptographic functions. Furthermore, since the vulnerability only comes to light during runtime, static code analyses may not pick it up.

One of the simpler, yet effective mitigation is to always return the same response when decrypting packets with either valid or invalid padding. In this case, the attacker will not be able to make use of the side channel information to carry out the attack. Additionally, for PKCS#7, it is recommended to use the encrypt-then-MAC (Message Authentication Code) approach by first encrypting the message and then computing the MAC of the ciphertext. During the decryption operation, the MAC will be verified before the actual decryption take place. In this case, the system will be able to detect whether the ciphertext has been modified by the attacker. For RSA encryption, it is advisable to use the OAEP padding scheme instead of PKCS#1 v1.5 as it is less prone to vulnerabilities due to insecure implementation.

Padding Oracle Hunter is an open-source software, and we welcome contributions to the community to further improve it. Together we can make the Padding Oracle Hunter more useful for the community.

--

--

Tan Inn Fung
CSG @ GovTech

A Security Specialist who is passionate about Cybersecurity and Cryptography