是否存在“内部安全应用程序”场景，在这种场景中，由于早期的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注入攻击（典型的名称：史密斯;我想到的是DROP TABLE客户）。
但是，“全面”解决方案正在寻求降低软件风险，例如
- 内部Java Web应用程序，通过防火墙和DMZ等技术与外界（内外）隔离
- 内部Java批处理程序，我希望它们在执行过程中不会被篡改
- Citrix虚拟桌面确实可以在管理员模式下运行，这取决于用户，但我希望从外部世界完全无法访问。
到目前为止，我听到的“全面攻击”的唯一理由是，恶意行为者可能能够通过隧道进入网络并导致Log4J漏洞被执行，但在这种情况下，似乎通过隧道进入网络的恶意行为者可以直接自己执行恶意软件，而不必费心去寻找使用早期版本Log4J的程序。
1条答案
按热度按时间j8ag8udp1#
在考虑了@f1sh和@hfontanez的评论并与更多人交谈后，我很高兴我对该漏洞的独特方面有了了解，该漏洞表明，尽管内部应用程序在安全环境中运行，但仍应被视为易受攻击。
1.我认为这个漏洞的显著特征是问题在日志记录过程中显现，日志记录无处不在。日志记录甚至发生在代码中，代码本身试图处理企图入侵，这方面可能会打开来自恶意行为者的新攻击路线。
1.关于在一个安全的组织中运行内部代码，我知道前景会有一系列事件从组织外部开始，最终导致Log4J漏洞在组织内部被利用。目前，这可能性大于现实，但鉴于此漏洞的独特性质，它可能会使此类攻击更容易执行。
1.要消除此漏洞的一点是，必须确保内部应用程序在没有必要的情况下无法在组织外部进行网络调用，并且对外部的任何有效调用都被限制在所需的范围内。