【发布时间】：2021-12-22 11:51:21
【问题描述】：
是否存在“内部安全应用程序”场景，即由于较早的 Log4J 版本，软件比没有它时更容易受到攻击？
我在下面概述了有关此问题的一些详细信息。
我正在做一些工作来减轻最近的 Log4J 漏洞带来的风险。我知道一些方法涉及从组织的所有计算机、服务器、远程桌面和所有东西中删除早期 Log4J jar 文件的所有痕迹，在完成此操作之前，该组织被视为“处于危险之中”。但是，我也想知道如此大的全面努力是否是相称的[编辑 22-Dec-21 12:15 - 道歉：要清楚我试图通过“相称”来理解的是我们是否会考虑到在相同的组织工作负载中可能存在我们可以解决的其他非 Log4J 漏洞，通过将大量精力集中在一些 Log4J 代码的使用上而减少对其他代码的使用，从而获得更好的结果]。
我对该漏洞有一个基本的了解，例如来自https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/，其中一个不良行为者发送了一条包含 JNDI 命令的 HTTP 消息，然后在程序下一次尝试写入日志时执行该消息。对于面向公众的应用程序而言，那里的风险似乎很明显，这让我想起了众所周知的 SQL 注入攻击（我想到了经典的姓氏：SMITH；DROP TABLE CUSTOMERS）。
但“一刀切”的解决方案正在寻求降低软件的风险，例如
- 内部 Java Web 应用程序通过防火墙和 DMZ 等技术免受外部世界（进出）的影响
- 内部 Java 批处理程序，我希望它们在执行期间不会被篡改
- Citrix 虚拟桌面确实可以在管理员模式下运行，具体取决于用户，但我希望外界完全无法访问。
到目前为止，我听到的“全面”的唯一理由是，不良行为者可能能够通过隧道进入网络并导致 Log4J 漏洞被执行，但在这种情况下，不良行为者似乎进入网络的隧道可以直接执行恶意软件，而无需费心寻找使用早期版本 Log4J 的程序。
【问题讨论】：
-
“我还想知道，如此大的全面投入是否合乎比例。” - 这个漏洞允许完整的远程代码执行。你应该尽一切努力尽快修复它。
-
问题是任何来自外部世界的值都可能被滥用来放置恶意的 jndi 表达式。 http 标头、已发布的 xml 或 json 文档的一部分，任何东西。因此，它不必是面向外部的应用程序，只要它可以接收外部输入的任何部分即可。
-
感谢@f1sh，这是有道理的。我可以看到 Log4J 漏洞涉及在代码通常拒绝输入的情况下记录消息，因此它比 SQL 注入攻击更糟糕。我的想法是了解外部输入的一部分如何影响内部应用程序，考虑如何设置网络安全以试图防止这种情况。这将有助于了解这里是否发现了一般风险，作为 Java 开发人员，我们应该更加了解（并且可能应该在修复 Log4J 版本的同时解决）。
-
修复所有问题的另一个原因是，即使某些应用程序今天可能无法被外部实体访问，但您不知道明天的情况。而且很可能，您会在部署受影响的软件之前忘记修复。也许它们会排在最后，但必须在所有面向客户的应用程序之后立即修复它们。
-
@westwell 您需要记住的一件事是，如果您使用其他 3rd 方库，它们很可能使用 Log4J，因此，即使您升级了应用程序，它们也容易受到攻击到 Log4J 的补丁版本。所以...您必须（很可能）升级所有 3rd 方库。
标签： java security log4j code-injection network-security