log4j漏洞检查：如何快速检测是否使用log4j，在mavevn/在图像中？"mvn依赖：树"没有给出一个完整的画面

Question

好吧，我的问题是：

• 如何输出服务/应用程序的完整依赖树，并找出是否在角落的某个地方使用log4j？考虑到mvn依赖关系：树不允许您遍历到底部的底部。检查这个：当我在我的pom.xml上执行mvn依赖：Tree时，它会给出这样的内容：

[INFO] |  |  +- io.quarkus:quarkus-core:jar:2.4.1.Final:compile
[INFO] |  |  |  +- jakarta.enterprise:jakarta.enterprise.cdi-api:jar:2.0.2:compile
[INFO] |  |  |  |  \- jakarta.el:jakarta.el-api:jar:3.0.3:compile
[INFO] |  |  |  +- jakarta.inject:jakarta.inject-api:jar:1.0:compile
[INFO] |  |  |  +- io.quarkus:quarkus-ide-launcher:jar:2.4.1.Final:compile
[INFO] |  |  |  +- io.quarkus:quarkus-development-mode-spi:jar:2.4.1.Final:compile
[INFO] |  |  |  +- org.jboss.logging:jboss-logging:jar:3.4.2.Final:compile
[INFO] |  |  |  +- org.jboss.logmanager:jboss-logmanager-embedded:jar:1.0.9:compile
[INFO] |  |  |  +- org.jboss.logging:jboss-logging-annotations:jar:2.2.1.Final:compile
[INFO] |  |  |  +- org.jboss.threads:jboss-threads:jar:3.4.2.Final:compile
[INFO] |  |  |  +- org.jboss.slf4j:slf4j-jboss-logmanager:jar:1.1.0.Final:compile
[INFO] |  |  |  +- org.graalvm.sdk:graal-sdk:jar:21.2.0:compile

现在我明白了，-和\-是用来替换的和的（但是直到5分钟前我发现它很混乱），所以它们不是未扩展的。但是，如果某些依赖项的pom使用log4j，我不做任何事情就安全了吗？例如，当我检查org.jboss.logging： jboss日志：jar： 3.4.2。最终：编译在https://search.maven.org/artifact/org.jboss.logging/jboss-logging/3.4.2.Final/jar，我看到org.apache.logging.log4j： log4j-core： 2.11被使用，但随后被排除在外。所以我知道Quarkus很安全。但是，我必须检查我在依赖树中找到的每一个jar的pom，以找出什么是使用的，什么不是？

• 如果我使用某个地方的基本图像，如何在步骤1中执行此过程？我怎么知道我的基本映像是脆弱的，因为它在依赖树的某个角落使用log4j2

这里有一些背景：https://nvd.nist.gov/vuln/detail/CVE-2021-44228

编辑：现在我想也许设置环境变量更好，所以它将一劳永逸地解决它。

Answer 1

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

直接回答问题：
检查代码中的Log4J依赖项：

• 我认为WesternGun的答案很好。。。但就我个人而言，我认为最简单的方法可能是构建你的应用程序（如果你还没有），然后递归地搜索构建的应用程序的目录结构，寻找与REGEXlog4j-core-2匹配的JAR文件。([0-9] \.){1,2}jar（将检测易受CVE-2021-45046…CVE-2021-44228…CVE-2021-45105攻击的版本）。如果您还想检测旧版本（它们有自己的严重性CVE，也需要升级），那么REGEX将只是log4j，您必须手动确定哪些特定JAR是易受攻击的。

在运行应用程序时检测Log4J的使用（是否在容器中并不重要）：

• 转到Reddit线程：log4j_0day_being_exploited和cntlffor供应商建议。在列表中搜索您正在运行的任何软件/插件。如果您正在运行列表中的内容，并且有可用的更新，请更新。
• 然后转到同一个网站并cntlf获取漏洞检测。使用那里的工具。如果检测到漏洞，请进行补救。
• 然后转到同一个网站并cntlf获取漏洞检测。使用那里的工具。这些将检测您是否已经受到攻击。如果您检测到您有，然后进行补救并在必要时对该攻击做出响应。

更多资源

• https://www.reddit.com/r/blueteamsec/comments/rd38z9/log4j_0day_being_exploited/
  • 这一个有很多有用的信息，包括探测器，甚至更多的资源链接，非常容易理解的修复步骤，等等

  补救措施：
  CVE-2021-45046。。。CVE-2021-44228。。。CVE-2021-45105
  虽然大多数需要知道的人可能已经知道了足够多的知识来做他们需要做的事情，但我想我还是会把这个放在以防万一。。。

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

  基本上是

  • 如果可能，删除log4j核心JAR文件
    • 从两个正在运行的机器立即修复AND
    • 在您的源代码/源代码管理文件中，以防止未来的构建/发布/部署覆盖更改
    • 如果您运行的是Java8，那么您可以升级到log4j 2.17。0
    • Linux上的权宜之计选项只有一行代码，使用大多数Linux发行版默认附带的zip命令。
    • 安装类似7-zip的东西
    • 找到所有log4j核心JAR文件，并对每个文件执行以下操作...
    • 重命名JAR以将扩展名更改为. zip
    • 使用7-zip解压JAR（现在有一个. zip扩展）
    • 找到并从解压文件夹中删除JndiLookup.class文件
      • 路径是\\path\\to\\unzippeFolder\\org\\apache\\log\\log4j\\core\\lookup\\JndiLookup.class
      • Reddit线程：log4j_0day_being_exploited
      • ctrlffor"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

Answer 2

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

对于我们的代码，我们做到：

mvn dependency:tree | grep log4j

我们发现其他团队的一些dep带来了传递log4j 1.17左右。另一个团队会处理它；在此之前，作为一种解决方案，我们将在我们的内部构件中手动从jar中删除JMSAppender.class和SocketServer.class，以便从那里下载的每个jar会缺少类文件。

在包含log4j的基本映像中查找其他库则更为复杂。我必须先找出图像中的内容。我首先docker保存官方的amq63 OpenShift映像到tarball中；然后，我提取罐子并使用grep搜索罐子。

docker save <image-name> -o amq63.tar

提取tar，输入每个层的文件夹，并使用以下脚本：

#!/bin/bash
for f in $(find . -name "*.jar"); do 
    echo $f
    jar -tvf $f | grep -E "(*JMSAppender*.class|*SocketServer.class|*log4j*.class)"
    if [[ $? -eq 0 ]]; then
        # only uncomment these lines after confirmation!
        #echo Removing class file from $f
        #zip -d $f "*JMSAppender.class" "*SocketServer.class" "*SimpleSocketServer.class"
    fi
done

检查发现的一些罐子，它们也可能受到漏洞的影响。也许JMSAppender.class也应该从那里删除。我发现jib maven插件可以从本地tar文件加载图像，如tar：//path/to/file.tar，所以我们可以修改图像taramq63.tar并再次构建。所以，如果它在Target中，就像tar：//Target/amq63.tar一样。如果是绝对路径，则为：tar：///home/me/amq63.tar。

此外，我们还应该更改配置文件的访问权限，使其成为只读的。

编辑：而且，如果你想从正在运行的pod中编辑jar，它将不起作用，因为你需要重新启动来再次加载类文件，但是pod不能重新启动；它们是不可变的；配置映射更改将持续，但状态在豆荚不会。