​Log4j：从治标到治本

2021年12月，Log4j惊爆“核弹级”漏洞（Log4Shell），之后很快像癌症一样在互联网上迅猛扩散，短时间内就让全球超过40%的企业网络遭遇袭击，于是全世界的企业安全人员瞬间没了周末。该漏洞利用成本极低，可以直接任意代码执行，并接管目标服务器，其潜在危害严重性、影响面堪称2021年之最。 Log4Shell攻击面巨大，一些专家认为，此次漏洞与2014年Shellshock系列安全漏洞不相上下，后者在最初披露的数小时内就被受损计算机的僵尸网络利用，发动了分布式拒绝服务(DDoS)攻击和漏洞扫描。 Log4j漏洞并不罕见，因而应当予以持续关注，以充分识别和修复问题。以下为大家分享一些基本方法。 对Log4j 的担忧主要由于Java 日志库的使用颇具普遍性，以及未经身份验证的攻击者能如此轻松就利用该漏洞实现远程代码执行 (RCE)。我们对配置更新，好像做好了Log4j攻击套件的应对准备，但这一切只是临时抱佛脚。与此同时，此种漏洞已出现变种，但在组织内部，涵盖核心基础设施全面升级的长期解决方案还遥遥无期。 由于随后出现的通用漏洞披露 (CVE) ，加之许多团队在更改配置、扫描资产排查易受攻击软件时过于草率，Log4j要被完全控制还需数月时间。许多组织要么长期停留在排查阶段，试图完全找出系统使用 Java 或 Log4j的地方，要么就一直在修复当中，因为运营或系统限制束缚了他们推出完整补丁的能力。 因为初始配置更改不够充分，漏洞不断变化，或需做好执行全面修复的准备。以下提到的最佳实践及重要论点将帮助安全团队在这方面做好筹谋。 大规模使用资产管理 在Log4j漏洞出现后，安全团队抓紧寻找并优先考虑拥有大量资产的群体。人们共同企盼能有快速、可扩展的方法来查找 Java 和 Log4j 实例。可用检测工具很多，但许多安全组织却忘了一项基本内容：最新的软件资产清单。 资产采集和处理非常关键，安全团队需要如下问题的及时回答：哪些 Linux 服务器正在运行Log4j？哪些虚拟机使用Java？ 强大的资产管理可加快修补周期，每当出现新的 Log4j 时，便立即需要新的补丁。资产管理能力更强的团队对 Log4j 的响应更高效，他们能够更快识别出易受攻击的 Java 实例，同时监控修复对运营的影响。 最佳防御：加快修复周期 安装补丁是应对新兴威胁的最佳方式，但攻击者亦会迅速把新的 CVE 纳入攻击套件。要缓解攻击和保护系统，升级到最新版本是最为可靠的办法。随着时间推移，依靠手动配置更改会导致系统出现漏洞，因为Log4j 等漏洞也在不断演化，仅仅改变一个真/假旗标是不够的。 检查配置 加强资产管理实践，要实施配置检查。当新的 CVE 出现时，资产需要进一步更新和配置更改，确保可以从Log4j追踪到它。在该漏洞管理计划中，首要一点是安全团队发现未知威胁的监控渠道。寻找高优先级威胁需要有稳妥的流程安排，不要靠听小道消息或偏信推特内容，而要建立一个积极主动的流程。 解决遗留系统问题 如果组织还在使用与 Java 更新版本不兼容的遗留软件，那么是时候采取行动，促使领导层（和供应商）建立强大的软件资产清单和循环修复周期。处理技术负债(包括未修复的遗留软件)会消耗过多的资源和带宽，同时需要增加监控和补偿性控制。当Log4j出现，安全团队也就更有话语权，而这也是计划升级遗留系统的好时机。 内网和气隙（Air-Gapped）系统不容忽视 人们通常认为气隙系统和内部设备是安全的，因为如果攻击者接触不到，自然也就无法利用。但这种假设对Log4j来说极为危险，因为未经身份验证的请求，即使通过其他应用程序仍然可能导致远程代码执行(RCE)漏洞。对待气隙系统和内网资产应如面向互联网的资产一样，随时准备全面升级并展开配置跟踪。 安全的自动扩展和部署 识别云环境中可能使用自动部署或自动扩展方案运行的资产。要确保这些配置是安全的，并且任何未来部署都不会使用过时的Java版本或Log4j库。这需要与开发团队合作，确保这些安全配置纳入未来的构建当中。