java - log4j 漏洞检查：如何快速检测是否在 mavevn/图像中使用了 log4j？“mvn dependency:tree”没有给出完整的图片

Question

score 3 · Accepted Answer

您可以使用：

mvn dependency:tree -Dincludes=*log4j*

它将在其 groupId 的任何位置找到任何具有“log4j”的依赖项和传递依赖项。

输出示例：

\- org.springframework.boot:spring-boot-starter-web:jar:2.6.0:compile
[INFO]    \- org.springframework.boot:spring-boot-starter:jar:2.6.0:compile
[INFO]       \- org.springframework.boot:spring-boot-starter-logging:jar:2.6.0:compile
[INFO]          \- org.apache.logging.log4j:log4j-to-slf4j:jar:2.14.1:compile
[INFO]             \- org.apache.logging.log4j:log4j-api:jar:2.14.1:compile

每个模式段都是可选的，并且支持完整和部分 * 通配符。空模式段被视为隐式通配符。

例如，org.apache.* 将匹配组 id 以 org.apache. 开头的所有工件，而 :::*-SNAPSHOT 将匹配所有快照工件。

另请参阅Maven 文档

编辑

然后，您很可能希望通过以下方式排除这些依赖项：

<dependency>
    <groupId>your dep groupId</groupId>
    <artifactId>your dep artifactId</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
        </exclusion>
        <exclusion>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-to-slf4j</artifactId>
            </exclusion>
    </exclusions>
</dependencies>

笔记

在撰写本文时，它是任何版本 < 2.17.1

具有漏洞的 Log4j 版本可在Maven 存储库中获得

score 1 · Accepted Answer

请记住始终从下面列出的资源中查看最新信息

直接回答问题：
Checking Log4J dependencies in code：

我认为 WesternGun 的答案很好......但我个人认为最简单的做法可能是构建您的应用程序（如果您还没有），然后递归搜索构建应用程序的目录结构以查找与 REGEX 匹配的 JAR 文件log4j-core-2.([0-9]+\.){1,2}jar（将检测易受CVE-2021-45046 ... CVE-2021-44228 ... CVE-2021-45105 影响的版本。如果您还想检测旧版本（它们有自己的严重严重性 CVE 并且还需要升级），那么 REGEX 就可以了log4j，您必须手动找出哪些特定的 jar 是易受攻击的。
- 它实际上可能可以进一步完善......但我不确定特定的jar 文件是否是其他 CVE 的问题：CVE-2019-17571和CVE-2021-4104
Reddit 线程：log4j_0day_being_exploited cntl + ffor.class and .jar recursive hunter将为您提供一些工具来帮助进行递归搜索

检测 Log4J 在运行应用程序中的使用（在容器中与否无关紧要）：

转到Reddit 线程：log4j_0day_being_exploited和cntl+ ffor Vendor Advisories. 在列表中搜索您正在运行的任何软件/插件。如果您正在运行列表中的某些内容并且有可用的更新，请更新。
然后去同一个网站和cntl+f为Vulnerability Detection. 使用那里的工具。如果检测到漏洞，请修复。
然后去同一个网站和cntl+f为Exploitation Detection. 使用那里的工具。这些将检测您是否已经受到攻击。如果您检测到您有，则根据需要进行补救并响应该攻击。

更多资源

https://www.reddit.com/r/blueteamsec/comments/rd38z9/log4j_0day_being_exploited/
- 这个有大量有用的信息，包括检测器、更多资源链接、非常容易理解的修复步骤等等
https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
https://github.com/cisagov/log4j-affected-db
https://logging.apache.org/log4j/2.x/security.html

补救措施：
CVE-2021-45046 ... CVE-2021-44228 ... CVE-2021-45105
虽然大多数需要知道的人可能已经足够了解他们需要做的事情，但我想我还是会把这个如果...

遵循这些资源中的指导......它可能会改变，但是

截至 2021 年 12 月 18 日

基本上是

如果可能，删除 log4j-core JAR 文件
- 从两台正在运行的机器上立即修复和
- 在您的源代码/源代码管理文件中，以防止将来的构建/发布/部署覆盖更改
如果这是不可能的（由于依赖），请升级它们
- 如果你运行的是 Java8，那么你可以升级到 log4j 2.17.0+
- 如果您运行的是早期版本的 Java，那么您可以升级到 log4j 2.12.3
- 如果您运行的是旧版本的 Java，那么您需要升级到最新版本的 Java，然后使用最新版本的 Log4J
- 同样，这些更改必须同时发生在正在运行的机器和代码中
如果由于某种原因这些都不可能……那么从 log4j-core JAR 中删除 JndiLookup.class 文件是非补救性的。
- zip默认情况下，使用大多数 Linux 发行版附带的命令，在 Linux 上有一个止损选项的单线。
  - zip -q -d "$LOG4J_JAR_PATH" org/apache/logging/log4j/core/lookup/JndiLookup.class
- 在撰写本文时，Windows 上的权宜之计选项的大多数在线指南都说要执行以下操作（再次...假设您无法执行上述删除 JAR 或升级选项之一）：
  - 安装类似 7-zip 的东西
  - 找到所有 log4j-core JAR 文件，并为每个文件执行以下操作...
  - 重命名 JAR 以将扩展名更改为.zip
  - 使用 7-zip 解压 JAR（现在有.zip扩展名）
  - 从解压缩的文件夹中找到并删除 JndiLookup.class 文件
    - 路径是\\path\\to\\unzippedFolder\\org\\apache\\logging\\log4j\\core\\lookup\\JndiLookup.class
  - 删除旧的 JAR 文件（现在扩展名为 .zip）
  - 使用 7-zip 重新压缩文件夹
  - 重命名新的 .zip 文件夹以将扩展名更改为.jar
- 还有一些使用 Power Shell 的选项
  - Reddit 线程：log4j_0day_being_exploited
  - ctrl+f代表“PowerShell”

如果您只有 1 或 2 个 JAR 文件要处理并且您不介意安装 7-zip 或者您有 PowerShell 可用，这很好。但是，如果您有很多 JAR 文件，或者您不想安装 7-zip 并且无权访问 Power Shell，我创建了一个开源 VBS 脚本，无需安装即可为您完成任何附加软件。https://github.com/CrazyKidJack/Windowslog4jClassRemover

阅读自述文件和发行说明https://github.com/CrazyKidJack/Windowslog4jClassRemover/releases/latest

score 1 · Accepted Answer

好吧，我们面临的情况是，我们正在构建一个foo基于 Red Hat JBoss AMQ 6 的应用程序。使用 jib maven 插件，我们的代码将被构建到一个 uber jar 中并放入/opt/xxx执行，而基础映像将放置将其他罐子放入图像下/opt/amq/lib。

步骤1

对于我们的代码，我们这样做：

mvn dependency:tree | grep log4j

我们从其他团队中找到了一些可以传递 log4j 1.17 左右的 dep。另一个团队会处理它；在此之前，作为一种解决方法，我们将删除

org/apache/log4j/net/SocketServer.class
org/apache/log4j/net/SimpleSocketServer.class（以防万一）
org/apache/log4j/net/SocketAppender.class
org/apache/log4j/net/SMTPAppender$1.class
org/apache/log4j/net/SMTPAppender.class
org/apache/log4j/net/JMSAppender.class
org/apache/log4j/net/JMSSink.class
org/apache/log4j/net/JDBCAppender.class
org/apache/log4j/chainsaw/*.class

在我们的内部工件中手动从 jar 中下载，这样从那里下载的每个 jar 都将缺少类文件。

如果你不能修复你的内部 Nexus repo/artifactory，你可以在本地 Maven 注册表（在下~/.m2）找到 log4j 的 jar 并删除该类；然后你再次构建你的应用程序；但请记住不要使用-U从远程注册表重新下载 jar。

第2步

在包含 log4j 的基本映像中查找其他库更为复杂。毕竟，删除类文件的篡改层不能被 Docker 守护进程检测到。sha256 值发生变化，您必须将主目录中 json 文件中的 sha256 值替换为 new sha256sum layer.tar；但即便如此，当您加载 tar:Cannot open /var/lib/docker/tmp-xxxx/...: file not found左右时，Docker 守护程序也会出错。所以最后，我创建了一个脚本来在运行时删除类，就在运行应用程序之前，并在运行应用程序之前在 jib 中定义一个新的入口点来运行它。

剧本：

#!/bin/bash
# Script to fix log4j 1.x CVEs. Initially it is only for CVE-2021-4104, but
# since there are multiple CVEs regarding log4j 1.x, they are all fixed here:

# Class File                                        CVE
# org/apache/log4j/net/SocketAppender.class         CVE-2019-17571
# org/apache/log4j/net/SocketServer.class           CVE-2019-17571
# org/apache/log4j/net/SMTPAppender$1.class         CVE-2020-9488
# org/apache/log4j/net/SMTPAppender.class           CVE-2020-9488
# org/apache/log4j/net/JMSAppender.class            CVE-2021-4104
# org/apache/log4j/net/JMSSink.class                CVE-2022-23302
# org/apache/log4j/net/JDBCAppender.class           CVE-2022-23305
# org/apache/log4j/chainsaw/*.class                 CVE-2022-23307

cves=(
'CVE-2019-17571'
'CVE-2019-17571'
'CVE-2020-9488'
'CVE-2020-9488'
'CVE-2021-4104'
'CVE-2022-23302'
'CVE-2022-23305'
'CVE-2022-23307'
)

size() {
    stat -c %s "$1"
}

extract_remove_repackage() {
    before=$1
    # jar xf -C some_dir only extract to current dir, we have to cd first
    jar_dir=$(dirname "$2")
    jar_file=$(basename "$2")
    temp_dir=$jar_dir/temp
    mkdir "$temp_dir"
    cp list.txt "$temp_dir"/ && cp "$2" "$temp_dir"/
    cd "$temp_dir"
    jar xf "$jar_file"
    # provide file and dir names to rm with list.txt
    xargs rm -rvf < list.txt && rm list.txt "$jar_file"
    jar cf "$jar_file" .
    mv "$jar_file" ../
    # go back and clean up
    cd "$before" && rm -rf "$temp_dir"
}

find_vulnerable_jars() {
    jar -tvf "$1" | grep -E "$pattern" | awk '{ print $8 }' > list.txt
    if [ "$(size list.txt)" -gt 0 ]; then
        echo ">>>>> Removing class file from $(realpath $1)":
        extract_remove_repackage "$(pwd)" "$1"
    else
        return
    fi
}
remove_classes_from_jars() {
    echo Starting to fix all CVEs regarding Log4j 1.x...
    cd $root_dir
    # exclude jolokia.jar(link)
    find . -name "*.jar" -not -type l -exec bash -c 'cd "$root_dir"; find_vulnerable_jars "$@"' bash {} \;
    echo All vunerable classes removed. CVE addressed:
    printf '%s\n' "${cves[@]}"
}

# to be able to use in find -exec child shell, we need to export all vars and functions
export root_dir=/opt/amq
export pattern=".*(JMS|JDBC|SMTP|Socket)Appender.*.class|.*SocketServer.class|.*JMSSink.class|org/apache/log4j/chainsaw/.*"
export -f size
export -f extract_remove_repackage
export -f find_vulnerable_jars
remove_classes_from_jars

新的 jib 入口点：

<!-- was "INHERITED" -->
<entrypoint>/opt/amq/bin/fix_and_launch.sh</entrypoint>

新的端点脚本：

#!/bin/sh
/opt/amq/bin/fix_log4j_1.x_cves.sh
/opt/amq/bin/launch.sh # the original, inherited entrypoint in jib

有关安全漏洞扫描报告处理的更多讨论，请参见此处

java - log4j 漏洞检查：如何快速检测是否在 mavevn/图像中使用了 log4j？“mvn dependency:tree”没有给出完整的图片

3 回答 3

截至 2021 年 12 月 18 日

步骤1

第2步

Related

Reference