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

Apache Shiro 1.2.4 deserialization loophole example analysis, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, hope you can gain something.

0x00 Apache Shiro

The loophole in this component was exposed a long time ago, but I encountered it again recently in my work, and I happened to be looking at Java deserialization recently, so I decided to take it out and analyze it again, and I also encountered some strange problems during that time.

Most of the online analysis articles add commons-collections4-4.0dependencies manually in order to use the CommonsCollections2 payload generated by ysoserial. However, the situation I encountered is that using CommonsBeanutils1 can directly type successfully, so here we will not repeat the online analysis of CommonsCollections2.

Debugging and Analysis of 0x01

Debugging environment:

JDK 1.8.0_72

Tomcat 8.0.30

First of all, let's bring back the source code clone of shiro and cut it to the branch in question.

Git clone https://github.com/apache/shiro.git shiro-rootcd shiro-root

Git checkout 1.2.0

In order to make the sample that comes with shiro run, to make some changes to the samples/web/pom.xml file, you need to change the version of jstl to 1.2 and delete the scope field of servlet-api. At the same time, place jstl-1.2.jar under WEB-INF/lib. Then you should be able to run and debug.

We call the breakpoint to the resolvePrincipals method in org.apache.shiro.mgt.DefaultSecurityManager and send a request with rememberMe Cookie, which should break it.

Let's follow up on this getRememberedIdentity method:

Continue to follow to the getRememberedSerializedIdentity method:

In this method, the Cookie we passed in is read out and the base64 is decoded:

Next, shiro calls convertBytesToPrincipals and passes in the base64 decoded byte array as a parameter:

You can also guess from the function name here, and two operations have been carried out, namely, decryption and deserialization. After simple debugging, we find that it is an AES decryption and there is a preset key Base64.decode ("kPH+bIxk5D2deZiIxcaaaA=="). In the sample included with shiro, this key is not set in any other way, so this default value is used here.

The IV encountered in AES decryption is also obtained from the first few bytes of the Cookie we passed in, so we can easily construct a cookie value containing any content, and the decrypted plaintext is serialized content, and deserialize is called for deserialization.

The org.apache.shiro.io.DefaultSerializer#deserialize method is eventually called for deserialization:

The whole process is very simple, briefly summarized as follows: read cookie-> base64 decode-> AES decryption-> deserialization

So our payload construction is also very simple, the complete PoC I will put on my GitHub.

0x02's doubts and doubts

In the process of debugging, encountered some problems, and did not successfully pop up the calculator, record here.

1. Why is it that when you build a local environment and use CommonsBeanutils1 to hit unsuccessfully, why does it always prompt for an ClassNotFound exception?

I debugged this problem for a long time. I once thought that there was something wrong with payload or that the code of shiro had changed because of the age, because the case I encountered at that time was fascinated by this payload, indicating that I was very confused. Later, a key problem was discovered. In the sample we clone to on github, the dependent version of commons-beanutils is 1.8.3, while the version of payload generated by ysoserial is 1.9.2, so it is not successful in the default sample. So I changed the version number to 1.9.2, and I was fascinated.

So in the case encountered, the actual dependent environment version may also be like this, so it can be directly hit successfully.

two。 What if I don't have a higher version of commons-beanutils and commons-collections packages in my dependency?

After the clone of this project comes down, you can see that there is a package of commons-collections:

However, it is not successful to use the CommonsCollections1 provided by ysoserial. An exception will be thrown:

This is very strange, why it is impossible to deserialize the byte array type, debug the exception found to be thrown here:

I checked the difference between Class.forName () and ClassLoader.loadClass () in Java and found that forName () always uses the caller's ClassLoader (), while loadClass () can specify a different ClassLoader on its own. So how did the ClasssLoader in shiro come from? Is obtained through Thread.currentThread (). GetContextClassLoader ();, that is, WebappClassLoader. But why didn't the prompt load byte array? after searching for it, I saw the discussion below on the orange blog and learned the truth of the whole thing:

Shiro resovleClass uses ClassLoader.loadClass () instead of Class.forName (), while ClassLoader.loadClass does not support loading class of array type.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

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.