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

In this issue, the editor will bring you about how to carry out Fastjson 1.2.24 deserialization vulnerability analysis. The article is rich in content and analyzes and describes for you from a professional point of view. I hope you can get something after reading this article.

0x00 fastjson

Fastjson is a very popular library that can convert data between JSON and Java Object, but in 2017, officials took the initiative to expose fastjson deserialization vulnerabilities and upgrade announcements. This time we will learn about this vulnerability.

The final payload will be put on my GitHub.

The fastjson used this time is version 1.2.23:

Com.alibaba

Fastjson

1.2.23

Before analyzing the vulnerabilities, let's take a look at what the library does. Let's create a User object:

Class User {private int age; public String username; private String secret; public int getAge () {return age

} public void setAge (int age) {this.age = age

} public String getUsername () {return username

} public void setUsername (String username) {this.username = username

} public String getSecret () {return secret

}

}

We mainly focus on the method of restoring Object from JSON. There are two main API, JSON.parseObject and JSON.parse. The main difference is that the former returns JSONObject while the latter returns objects of the actual type. When there is no definition of the corresponding class, JSON.parseObject is usually used to get data.

The JSON accepted by fastjson can specify what type of object the JSON should be restored to through the @ type field, which is convenient for deserialization.

String myJSON = "{\" @ type\ ":\" me.lightless.fastjsonvuln.User\ ",\" age\ ": 99,\" username\ ":\" lightless\ ",\" secret\ ":\" 2333\ "}"

JSONObject U3 = JSON.parseObject (myJSON)

System.out.println ("U3 = >" + u3.get ("secret"))

If you need to restore private members, you also need to add Feature.SupportNonPublicField:

User U3 = (User) JSON.parseObject (myJSON, User.class, Feature.SupportNonPublicField)

0x01 tracking analysis

According to the WAF detection method in the official announcement, the problem is most likely due to the RCE caused by deserializing any type of class.

From the payload found on the Internet, we can also see that the command is executed by TemplatesImpl, which has been analyzed in the previous JDK7u21, and there may be other ways to execute the command, which we will not talk about for the time being, mainly looking at the part of fastjson.

We build a simple Web application to accept the JSON from the user POST and deserialize it:

@ RestControllerpublic class IndexController {@ RequestMapping (value = "/ fastjson", method = RequestMethod.GET) public String fastjson () {return "Hello World!"

} @ RequestMapping (value = "/ fastjson", method = RequestMethod.POST) public JSONObject testVuln (@ RequestBody String data) {

JSONObject obj = JSON.parseObject (data, Feature.SupportNonPublicField)

JSONObject ret = new JSONObject ()

Ret.put ("code", 1001)

Ret.put ("data", "Hello" + obj.get ("name")); return ret

}

}

Pass in our JSON string of type @ type and start debugging. Break at JSON.parseObject and start to follow downwards.

The JSON.parse method is followed up at first, and the parse () method is called to continue matching the JSON format. Continue to follow the parser.parse () method.

When we get here, we start parsing the JSON in turn, and the first character we pass in is {, so go into the branch of LBRACE and continue to the parseObject (object, fieldName) method to parse the object.

At this point, the character of the lexer is ", and you will enter the following branch to continue parsing the JSON string, and get the string between the double quotes through the scanSymbol method, that is, @ type.

It then gets the value of the @ type field and tries to get the Class of the class. After a series of judgments, the deserializer.deserialize (this, clazz, fieldName) method is called for deserialization.

At first, I couldn't find out where the sortedFieldDeserializers was generated, so I wanted to follow the code carefully, so I looked at the getDeserializer (clazz) section from beginning to end and found that it was generated here. The purpose of this function is to get a deserializer that can deserialize the class we specified through @ type. Since it is not in the scheduled list, we will continue to call createJavaBeanDeserializer () to generate one, which actually calls the ParseConfig.build () method, in which we will get some information about our specified class through the reflection mechanism. Through some filtering of method, we can guess getter and setter and deduce some possible field.

The specific guessing rules will not be explained here. If you are interested, you can follow them by yourself.

Then each field in the JSON string is processed in turn. When matching to the _ tfactory field in payload, since the JSON string we passed is an empty object, after entering the parseField method, we will call the JavaBeanDeserializer.deserialize () method. Here, a TransformerFactoryImpl object will be created and assigned to _ string.

Similarly, we have passed in an empty object in the _ outputProperties field and will enter the same process as above. Take a closer look at this code, which is the key part of triggering the execution of the command.

First of all, you will still enter the parseField method

After entering, the smartMatch (key) method is called, and the main function of this method is to do some "intelligent matching" to facilitate the subsequent acquisition of the getter and setter of the corresponding variables. When called, this method removes the-from the string, removes the underscore at the beginning, and so on, so when we pass in _ outputProperties, it is actually processed as outputProperties and the corresponding FieldDeserializer object is returned, after which the parseField method of that object is called. After entering this method, the setValue (object, value) method is called to continue the follow-up.

After follow-up, it is obvious that getOutputProperties has been called:

The malicious bytecode we constructed in _ bytecodes is then executed, causing the command to execute.

0x02 has some questions.

According to the above process, we should be able to write PoC, so I won't take up any space here and put it directly on my GitHub.

At the beginning of the construction, we found that there are many invisible characters in the bytecode. Base64 is used to encode in the online public PoC, which feels very magical, why will fastjson help us decode it? So after constructing the array, we find that fastjson will call lexer.bytesValue () when dealing with [B-type array, where lexer is JSONScanner, and this bytesValue () method will automatically help us to perform base64 decoding, so we only need to pass in the base64-encoded content when we construct payload.

At this point, in fact, the whole process is over, but there is another thing that makes us very uncomfortable, that is, we set Feature.SupportNonPublicField when receiving JSON in our demo. By default, fastjson only deserializes the methods and properties of public, and the PoC we construct has private member variables _ bytecodes and _ name. In order to assign values to these variables, we must assume that the server has enabled the SupportNonPublicField function.

In reality, most of them are parse (json) and parseObject (json) shuttles, and not many people use this feature, which leads to the lack of good versatility of our PoC, so is there a solution? The answer, of course, is not to use TemplatesImpl, but to use a different way to trigger RCE. After searching the Internet, we found some methods that can be used.

Mainly using the JNDI+RMI method, which can refer to the previous spring-tx.jar deserialization problem, which was triggered in this way at that time. However, the call chain is not easy to find. Multiple utilization chains are given in this PPT. The call chain here will be analyzed later, and verification will not be done here.

In this way, as long as the developer directly deserializes the JSON passed in by the user when writing the code, it is possible to cause RCE, and the attacker does not have to worry about whether the SupportNonPublicField is turned on or not, and the harm is much higher.

0x03 repair measures

In fastjson's official patch, replace loadClass (typeName, config.getDefaultClassLoader ()) with config.checkAutoType (typeName), and expand the blacklist, compare the passed class names with the blacklist one by one, and stop deserializing if you find a class with the same beginning.

/ / newly added blacklist

Bsh

Com.mchange

Com.sun.

Java.lang.Thread

Java.net.Socket

Java.rmi

Javax.xml

Org.apache.bcel

Org.apache.commons.beanutils

Org.apache.commons.collections.Transformer

Org.apache.commons.collections.functors

Org.apache.commons.collections4.comparators

Org.apache.commons.fileupload

Org.apache.myfaces.context.servlet

Org.apache.tomcat

Org.apache.wicket.util

Org.codehaus.groovy.runtime

Org.hibernate

Org.jboss

Org.mozilla.javascript

Org.python.core

Org.springframework

You can see that most of the commonly used classes have been added, but if you don't maintain this list often, it's easy to bypass this limitation once new classes are available later.

The above is the editor for you to share how to carry out Fastjson 1.2.24 deserialization loophole analysis, if you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

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.