Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to analyze Shiro Padding Oracle Attack. The content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Preface

Cookie's cookiememeMe is encrypted in AES-128-CBC mode, which is vulnerable to Padding oracle attacks. Attackers can prefix Padding Oracle Attack with a valid RememberMe cookie and then craft a crafted RememberMe to perform Java deserialization attacks. To reproduce the problem: log on to the website and get the RememberMe from cookie. Use RememberMe cookie as the prefix for Padding Oracle Attack. Encrypt the serialization payload of the syserial to make a well-crafted RememberMe through Padding Oracle Attack. Request a Web site with a new RememberMe cookie to perform a deserialization attack. The attacker does not need to know the password key encrypted by RememberMe.

Shiro framework

Let's first understand what the shiro framework is. According to Baidu encyclopedia, we can know that Apache Shiro is a powerful and easy-to-use Java security framework and it has the functions of authentication, authorization, password and session management. Shiro is simply a privilege management component, and remote execution can be achieved through the vulnerability of shiro-721 combined with deserialization attacks. According to the vulnerability announcement, it is necessary to understand what a padding oracle attack is and what its effect is, why a shiro deserialization attack can be executed remotely through this, and why RememberMe cookie is used as a prefix for the attack.

Shiro deserialization attack

Shiro deserialization attack is actually the process of exploiting shrio-550 vulnerabilities. There are still many records related to the recurrence process of this vulnerability on the Internet. Interested students can look for relevant materials for a reproduction. Here I'll briefly explain why there are shiro deserialization attacks. According to the Apache website, shiro uses CookieRememberMeManager by default. It serializes, encrypts and encodes the user's identity for later retrieval.

The flow chart is as follows:

Analysis of AES encryption algorithm

Experiment: analysis of AES encryption algorithm (Hetian Network Security Laboratory)

Students with CTF experience may be sensitive to the word deserialization, which is a common type of question in CTF competitions. Some students may immediately wonder whether they can construct a malicious object and automatically trigger magic when it is deserialized to achieve the purpose of attack. Yes, this is the de-serialization attack flow of Shiro: a malicious object is constructed and sent to the server, which can trigger the attack when the server executes the reverse sequence. According to the flow chart, RememberMe Cookie uses double encryption, first using Base64 encryption, and then using AES encryption. We all know how to encrypt and decrypt Base64, but AES uses symmetric encryption, and there must be a key Key if you want to encrypt it. This is also the key to the Shiro-550 vulnerability: by default, the encryption key Key is hard-coded, which means that the encryption key Key is encoded in the source code. As long as the source code is available, you can get the Key to carry out deserialization attacks on shiro. But above Shiro1.2.5, officials have fixed this vulnerability and can no longer get KEY.

We know that Shiro Padding Oracle Attack takes advantage of shiro deserialization, and we know that in order to exploit this vulnerability, we must construct a malicious object that can be deserialized by the server, so can Shiro Padding Oracle Attack get the encryption key of AES? Or is there another way to deserialize by bypassing AES decryption?

Next, let's take a look at padding oracle attacks.

Padding oracle attack

Before we understand this attack mode, let's first take a look at the AES-128-CBC encryption mode used by Shiro: AES stands for encryption mode, CBC is packet mode, 128byte, that is, 16 bytes, and PKCS#5 padding mode is used here.

When AES-128-CBC encrypts plaintext, it first groups the plaintext, where each group is 16 bytes. What we can easily think of is that not every set of plaintext can be allocated exactly, that is, the last set of plaintext may need to be populated with data. In fact, when grouping is used, it must be filled, and if it is full, a new group will be filled.

Note: the figure is from the network; this figure is a schematic diagram of 8-bit filling, and 16-bit is similar.

After the plaintext is grouped, the plaintext is grouped and encrypted. The flow chart is as follows:

Note: the picture comes from the Internet.

From the figure, we can see that CBC is packet encrypted. Each group first performs XOR with an initial vector IV (XOR: a XOR: a XOR B gets C Magi C XOR B gets A), and the value obtained by XOR is called the intermediate value (IMV). Then the first group of ciphertext is obtained by encrypting the intermediate value with KEY. The first group of ciphertext is then used as an IV to XOR with the second group of plaintext to get the second intermediate value, which is also encrypted with Key to get the second group of ciphertext, and so on. Seeing here, we can actually think about a question, the last set of plaintext is actually filled in, which is different from the other groups, does it mean that we can have any use in this place?

Next, let's take a look at the decryption process. In fact, decryption is the reversal of encryption.

Note: the picture comes from the Internet.

From the figure above, we can see that the first group of ciphertext blocks are decrypted by KEY to get the intermediate value, which is XOR with IV to get the first set of plaintext. Then, the first group of ciphertext blocks are used as the XOR between the IV and the second group to get the second set of plaintext, and so on to complete the decryption. Here we also need to pay attention to the decryption process of the server: when we submit an IV, the server will use the intermediate value to get an exclusive or value with it and then check the padding first instead of directly comparing the plaintext. At this point, the server returns two situations: the correct ciphertext returns 200 or 302, and the wrong ciphertext returns 500.

Now that we have some understanding of AES encryption and decryption, let's take a look at how the padding oracle attack is implemented. We have mentioned above that there is a fill in the last group, and the fill should be one of the following.

①: plaintext 0x01 ②: plaintext 0x02 0x02 ③: plaintext 0x03 0x03 0x03... ⑧: 0x08 0x08 0x08 0x08 0x08 0x08 0x08 0x08

Cheer up, here comes the important and difficult point:

To sort out the train of thought, now we can capture the ciphertext, and know that the encryption algorithm also knows the initial vector IV. After grouping the ciphertext, as long as we have a way to bypass the process of KEY decryption to get the intermediate value, we can directly use the intermediate value (IMV) and the initial vector IV for XOR operation to get all the plaintext.

According to the key point that the server will report padding errors, we construct a false IV value to deduce the intermediate value. First, it is assumed that the last bit filled in the plaintext is 0x01, that is, ① mentioned in the above eight padding cases. According to the characteristics of XOR, only the unique IV value and the intermediate value can get 0x01. The value range of the last byte of IV value is 0 × 01 ~ 0xFF. As shown in the figure below, when we experimented with 0x66, we found that the server returned 200, so it's easy to know that IMV is the XOR result 0x67 of 0x01 and 0x66.

Thinking back to our decryption process written above, we can get the last plaintext by using the initial vector IV and the IMV value obtained by blasting. Next, we will deduce the second plaintext of the derivative. According to the filling rule, this should be the ② case mentioned in the above eight filling cases. We already know that the last byte of IMV is 0x67, so the last byte of IV constructed this time is the result of 0x67 and 0x02 XOR 0x65. At this point, the last byte is fixed and the penultimate byte is exploded, and so on.

Note: the picture comes from the Internet.

Generally speaking, padding oracle can not get the key of AES, but can bypass it. The normal decryption process requires IV, ciphertext and key;, while padding oracle attacks only need IV and ciphertext.

The above is the use of padding oracle attacks to decrypt ciphertext, similar to the use of padding oracle attacks to encrypt plaintext. We consider whether the IV of the first group of ciphertext is the second group of ciphertext in the encryption process, and this IMV can be deduced at this time, so according to the uniqueness of XOR, can the attacker change the plaintext by changing the ciphertext?

On how to analyze Shiro Padding Oracle Attack to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.