Log4j检测与JFrog OSS扫描工具

在无处不在的Apache Log4j包中发现Log4Shell漏洞是一个奇异的事件影响及严重性．在Log4Shell漏洞暴露后的几天内，检测到超过100万次利用该漏洞的攻击尝试，我们可能需要数年才能看到其全面影响。

虽然很难从这样一个极端的场景中得出一般的教训，但它提供了一个机会来衡量我们现有的软件开发、测试和发布方法，并考虑在未来可以采取哪些不同的做法来防止这种场景。

的Log4j脆弱性事件还可以提供一个机会，让开发人员在公开此类重大漏洞时思考他们面临的挑战，并考虑哪些工具可以帮助他们更快速、更容易地处理这种情况。对手头的实际问题有一个坚实的理解是选择正确的工具来补救这种情况的关键。在某些情况下，专门为手头任务设计的简单工具将比复杂的通用工具更有效。

在CVE-2021-44228公布后，JFrog安全研究团队迅速着手彻底调查漏洞发现，以便充分评估如何最好地支持开发者社区。除了出版我们的Log4Shell漏洞研究和建议，我们还专门设计出版了一套Log4j开源扫描工具以便开发人员在源代码和二进制文件中检测Log4j的使用和风险。这些工具是可配置的，开发人员可以很容易地对其特定任务进行调整。

在这篇博文中，我们将分享创建这些Log4Shell扫描和检测工具时的思考过程和考虑因素。

我们做的第一个决定是创建被动扫描工具。在调查其他人发布的可用工具时，我们发现其中许多工具都是活跃的——它们试图测试正在运行的服务中是否存在漏洞，甚至通过利用它来修补Log4Shell漏洞。我们决定使用被动代码和二进制Log4j扫描工具，原因有两个:

1. 在活动系统上触发漏洞是一种涉及一些风险的操作，大多数开发人员或安全从业者都不希望这样做
2. 主动Log4j扫描工具试图通过通过用户可访问的接口输入输入并查看结果来触发Log4Shell漏洞，而不分析用户可访问的接口和潜在的易受攻击的日志API函数之间的数据路径。因此，如果触发漏洞的所有尝试都失败了，则可能会错误地得出应用程序是安全的结论，即使Log4j漏洞仍然可以通过输入未经测试的输入来利用。

我们做出的另一个决定是不依赖于使用构建依赖来诊断潜在的易受攻击的包。虽然这种方法显然是有价值的，但我们认为Log4j漏洞的严重程度证明需要进行更深入的研究，以便在构建依赖项错误时不遗漏情况，因为直接包含代码而不是通过包管理器或其他原因。

最终，我们专注于两个主要任务:

1. 使用代码类诊断易受攻击代码的包含来自log4j-core，而不是特定的文件名或元数据。该工具有助于对“正在运行的代码是否包含Log4j”这个问题产生无条件的回答，因为它不假设任何关于文件名、构建信息的完整性或易受攻击的包数据库的信息。
2. 扫描对易受攻击代码的调用．这些工具可以帮助开发人员理解如何在他们的应用程序中使用Log4j。虽然这可能不是他们应该以主动修补软件为代价做的第一件事，但这些扫描工具可能使开发人员能够快速评估未经过滤的用户控制输入是否可能到达Log4j API调用，并得出软件在修补之前是否确实容易受到攻击的结论，或者用作额外的验证层。

随着额外的警告和漏洞被发现，我们将继续添加Log4j扫描和检测工具，以帮助开发人员验证配置和缓解措施，以快速了解他们在哪里容易受到Log4Shell漏洞的攻击。

遵循@jfrog在Twitter上进行Log4Shell更新。

额外的资源:2022世界杯阿根廷预选赛赛程
Log4shell 0-Day漏洞:所有你需要知道的-博客文章
Log4j Log4Shell漏洞解释——网络研讨会
Log4j Log4Shell漏洞问答-博客文章