如何检测应用程序中的 Log4j 漏洞
昨天，Apache 基金会针对 Log4j 中的一个关键零日漏洞发布了紧急更新，Log4j 是一种无处不在的日志记录工具，几乎包含在每个 Java 应用程序中。[https://logging.apache.org/log4j/2.x/security.html]该问题已被命名为 Log4Shell 并收到标识符CVE-2021-44228[https://nvd.nist.gov/vuln/detail/CVE-2021-44228]。
该问题围绕 Log4j 库中的一个错误展开，该错误可能允许攻击者在使用 Log4j 写出日志消息的系统上执行任意代码。此安全漏洞影响广泛，任何拥有包含 Log4j 的应用程序的人都需要立即注意。
为什么解决 Log4Shell 是一项重大挑战
Log4j 是许多 Java 应用程序使用的库。它是迄今为止最普遍的 Java 库之一。大多数 Java 应用程序都记录数据，没有什么比 Log4j 更容易实现的了。
由于 Java 打包的工作方式，这里的挑战是找到 Log4j。您可能将 Log4j 隐藏在应用程序的某个位置，甚至不知道它。
在 Java 生态系统中，依赖项以 Java 归档 (JAR) 文件的形式分发，这些文件是可以用作 Java 库的包。Maven 和 Gradle 等常用工具可以在您构建 Java 应用程序时自动添加 JAR 文件。一个 JAR 也可能包含另一个 JAR 来满足依赖关系，这意味着漏洞可以隐藏在应用程序中的多个级别。在某些情况下，一个依赖项会引入数百个其他依赖项，从而使其更难找到。
本质上，在 Java 世界中，您可以将一个 JAR 嵌套在一个 JAR 中，该 JAR 嵌套在一个 JAR 中。这会创建许多需要研究的层。仅查看您的项目直接引入的 JAR 可能还不够，因为 Log4j 可能隐藏在另一个 JAR 文件中！
使用开源工具扫描 Log4j
有两个由Anchore[http://www.anchore.com/]领导的开源工具能够扫描大量打包的依赖格式，识别它们的存在，并报告它们是否包含漏洞。在这种情况下，能够扫描 JAR 文件，尤其是 JAR 文件的嵌套层，是我们想要的。
Syft[https://github.com/anchore/syft]生成软件材料清单 (SBOM)，而Grype[https://github.com/anchore/grype]是一个漏洞扫描器。这两个工具都能够检查 JAR 档案的多个嵌套层，以发现和识别 Log4j 的版本。
Syft 还能够辨别 Java 应用程序包含的 Log4j 版本。Log4j JAR 可以直接包含在我们的项目中，也可以隐藏在我们包含的依赖项之一中。例如，使用 Syft 扫描这个示例 Java 项目显示它包含 Log4j 版本 2.14.1，该版本易受 Log4Shell 攻击。
无论包含何种 Log4j 版本，生成和存储 SBOM 以记录您交付的任何软件组件或应用程序中包含的所有内容都是有价值的。当发现一个新漏洞时，例如 Log4Shell，搜索 SBOM 存储库比查找和扫描所有 Java 应用程序要快得多。
Grype 是一种扫描器，它能够告诉我们我们的软件包含哪些特定漏洞。当您在应用程序中包含依赖项时，您还可以通过多级嵌套来识别依赖项包含的漏洞，依此类推。Grype可以直接扫描软件，也可以扫描Syft出品的SBOM。即使在软件已部署或交付给客户之后，这也允许您重新扫描 SBOM 以查找新漏洞。
使用 Grype 扫描相同的示例 Java 项目会发现 Log4j 漏洞并将其识别为严重严重性。
Syft 和 Grype 能够扫描您的应用程序，无论它们位于何处。您可以扫描磁盘上的目录，在本地扫描容器映像，甚至可以扫描远程注册表中的容器。您可以在构建之前扫描源代码，或者在构建之后扫描最终应用程序。在开发的每个阶段扫描您的应用程序很重要，仅仅因为源代码扫描是干净的并不意味着最终构建将是干净的。即使在部署后进行扫描也是一个好主意。也许您上周没有发现严重的 Log4j 漏洞，但本周您可能会发现！
随身携带 Syft 和 Grype
每当发现新的零日漏洞时，受影响的组织都很难快速修复问题。第一步也是最重要的一步是了解特定漏洞是否会影响您，对于 JAR 文件，在没有工具的情况下理解这一点可能是一个挑战。Anchore 的开源 Grype 和 Syft 工具一直挖掘到依赖关系树的底部，以确定是否有 Log4j 的副本隐藏在某个地方。
作为一个行业，我们如何在零日漏洞期间做出反应并相互支持至关重要。现在是分享解决方案和意识以帮助防止未来几年发生此类违规行为的时候了。