Log4J漏洞是否会打开内部安全网络中本来不存在的漏洞？

Question

是否存在一种“内部安全应用程序”场景，其中由于早期的Log4J版本，软件比没有它时更容易受到攻击？

我在下面概述了这个问题的一些细节。

我正在做一些工作来减轻最近Log4J漏洞的风险。我知道有一些方法涉及从组织的所有计算机、服务器、远程桌面等中删除早期Log4J jar文件的所有痕迹，在完成之前，组织被视为“处于危险之中”。然而，我也想知道如此大规模的全面努力支出是否相称[编辑22-12月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）。

但一个“全面”的解决方案正在寻求减轻软件的风险，例如

• 通过防火墙和DMZ等技术保护内部Java web应用程序不受外部世界（包括内部和外部）的影响
• 内部Java批处理程序，我希望在执行过程中不会被篡改
• Citrix虚拟桌面确实可以在管理员模式下运行，具体取决于用户，但我希望外部世界完全无法访问它

到目前为止，我听到的“全面”的唯一理由是，一个坏角色可能能够隧道进入网络，并导致Log4J漏洞被执行，但在这种情况下，似乎一个坏角色隧道进入网络可能会消失直接执行恶意软件，不用费心去寻找使用早期版本Log4J的程序。

Answer 1

在考虑了@f1sh和@hfontanez的评论并与另外两人交谈后，我很高兴我了解了该漏洞的独特之处，即尽管在安全环境中运行，内部应用程序仍应被视为易受攻击。

>

我认为该漏洞的显著特征是，问题在日志记录过程中表现出来，日志记录无处不在。日志记录甚至发生在代码中，而代码本身正试图处理试图入侵的行为，这一方面可能会打开坏角色的新攻击线。

关于在一个安全的组织中运行内部代码，我了解可能会有一系列事件从组织外部开始，最终导致组织内部利用Log4J漏洞。此时，这可能是一种可能性而不是现实，但鉴于此漏洞的独特性质，它可能会使此类攻击更容易执行。

要消除此漏洞的一点是，必须确保内部应用程序在没有必要的情况下不能在组织外部进行网络呼叫，并且对外部的任何有效呼叫都仅限于所需。