Log4j检测与JFrog OSS扫描工具

在无处不在的Apache Log4j包中发现Log4Shell漏洞是一个独特的事件影响和严重性．在Log4Shell漏洞暴露后的几天内，就发现了超过100万次利用该漏洞的攻击企图，我们可能需要数年时间才能看到其全面影响。

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

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

在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漏洞问答-博文