2021年12月，一个“核弹级”漏洞（Log4Shell ）被爆出，惊扰了全世界的企业安全人员的美梦。Log4j漏洞利用成本极低，可以直接任意代码执行，并接管目标服务器，它的潜在危害严重性和影响面可以说是2021年之最，在短时间内就让全球近半数的企业网络遭遇了攻击，并在互联网上迅猛扩散。
那么Log4j漏洞到底是怎么一回事？负责保护和交付数字化体验且深受全球企业信赖的解决方案提供商阿卡迈技术公司（Akamai Technologies, Inc.，以下简称：Akamai）对Log4j 漏洞的背景、漏洞利用攻击和环境措施、以及经验教训等情况进行了详细回溯分析。
漏洞利用攻击形式多样、攻击面广泛
Log4j是Apache的一个开源项目，通过使用Log4j，可以控制日志信息输送的目的地是控制台、文件、GUI组件，甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等，也可以控制每一条日志的输出格式，通过定义每一条日志信息的级别，还够更加细致地控制日志的生成过程。这些可以通过一个配置文件来灵活地进行配置，而不需要修改应用的代码。
Log4j 库的普及，以及它提供的查找、嵌套和 JNDI 等丰富的功能，使该漏洞给攻击者大开方便之门。这些强大的功能给开发者提供了便利，但也让攻击者有机可乘，让他们能通过传递请求来引发数据渗漏或远程代码执行 (RCE)。
JNDI（Java 命名和目录接口) 是 Java 开发和运行环境中原生构建的一种机制，它通过一个通用接口简化了查询各种不同目录服务以获得信息的过程。如果没有 JNDI 查询，这个漏洞也就不会存在。
JNDI 不仅允许查询 Java 运行时环境内的本地数据，还允许查询 DNS 和 LDAP 等远程系统。攻击者可以将 JNDI 与远程系统、env 查找和嵌套相结合，创建出只需添加到要记入日志的文本中就能引发数据渗漏的攻击载荷。只要向 Log4j 传送精心编制的攻击载荷，就能轻易泄露出目标环境的数据。
简而言之，只要某个环境中运行的软件包含能被 Log4j 查找表达式访问且存在漏洞的代码，那么攻击者就能通过嵌套的手法，轻而易举地将该环境中的信息强制传送到由攻击者控制的系统中。
另外，某些 Java 版本中的 JNDI 实现默认允许一些目录服务直接或间接地通过远程代码响应查询，随后发起查询的机器可以在本地执行这些远程代码。例如，在存在漏洞的安装环境内，LDAP 目录服务提供程序允许 LDAP 服务器使用称为 引用的内容来响应查询。这种引用会列出将下载到本地并在本地执行的代码的远程位置。
这些威胁极大的攻击都需要向 Log4j 传递专门编制的消息，攻击者利用受攻击系统可将其提供的信息记录到日志中的任何机会。
据Akamai观察发现，基于 Web 的应用程序目前是主要攻击目标，遭受攻击的频率远超过其他任何攻击目标。但值得注意的是，符合以下条件的任何服务都有可能成为漏洞利用者的攻击媒介：
- 运行 Java
- 利用存在漏洞的 Log4j 版本记录日志消息
- 记录攻击者提供的任何信息（URL、标头、Cookie、查询等）
此外，Akamai 还在现实攻击环境中观察到另一种针对 DNS 的攻击媒介，攻击方法是在 DNS 响应中嵌入攻击载荷。
Log4j 是 Java 世界中应用最广泛的日志库之一，而全世界有数十亿的设备运行 Java。可想而知，这个漏洞实际的威胁面远超我们的想象，严重性也不言而喻了。
Akamai建议及时安装系统补丁，正确实施缓解措施
随着时间的推移，攻击者可用来针对Log4j 漏洞发起攻击的攻击媒介数量也越来越多， 而唯一真正的解决方案就是为所有存在漏洞的系统装好补丁。对此，Akamai 提出了一些行动方案建议：
- 对于能够安装补丁的系统，立即予以修补。此举可提供理想的防护措施，确保您运行的 Log4j 是最新版本。
- 如果您已经确定某些系统存在漏洞，但由于客观原因无法立即为其升级 Log4j，那么应该尽可能使用如下设置减小威胁面：
- 对于 Log4j 2.10 及更高版本，在启动时向应用程序传递“-Dlog4j2.formatMsgNoLookups=true”，这样做可以禁用查找表达式。对于 Java，确保您的系统上采用了如下设置：com.sun.jndi.ldap.object.trustURLCodebase=false com.sun.jndi.rmi.object.trustURLCodebase=false
- 运行 WAF（比如 Akamai 卓越的 Kona 解决方案）来保护您的所有 Web 应用程序，以帮助过滤掉攻击企图。无论是内部还是外部服务器，都应该采取这种保护措施。
- 运行 DNS 防火墙（比如 Akamai Enterprise Threat Protector），以监测在您的环境中横向移动的可疑 DNS 攻击载荷，并予以阻止。
- 运行相关工具来全面监测整个环境中运行的内容，包括本地物理机器与云环境。利用各种工具（比如 Akamai Guardicore Segmentation 提供的工具）来监测您环境中运行的所有内容，利用这些工具来寻找您先前可能并不知道存在漏洞的应用程序。
- 尽可能减少涉及到受影响应用程序的通信。利用基于身份的细分机制（例如 Akamai Guardicore Segmentation 的细分机制）来限制可以与哪些存在漏洞的系统进行通信。
Akamai 还建议，在设计和执行修补策略时，同时实施这些抵御策略可以显著降低存在漏洞的系统面临的风险。
Akamai 发挥自身优势，进行漏洞风险量化评估
随着Log4j 漏洞危机的持续发酵，其风险广泛程度也引起了大家的密切关注。对于此，Akamai 威胁研究实验室利用自身对于全球海量数据中心的监测能力，从全球 200 多个不同行业、不同规模的数据中心收集了相关数据，评估了 Log4j 漏洞给企业带来的实际风险：
- 在所有接受检查的 Java 服务器中，有三分之二的服务器使用存在漏洞的 Log4j 框架。
- 在所研究的数据中心内，有 91% 在运行 Java 服务器端应用程序；在这部分数据中心内，40% 以上具有面向互联网的 Java 服务器。
- 观察出站通信模式时，我们所研究的绝大多数 Java 应用程序都通过少数几个端口通信。
- 分析出站通信模式可以帮助企业检测异常行为，并且缓解 Log4Shell 所造成的部分风险。
Akamai 威胁研究实验室通过探究 Java 服务器的通信模式发现，对允许从数据中心的不同服务器和进程外发的通信加以限制十分重要。针对迄今为止始终通过一组特定端口通信的一个进程，识别其第一次与某个目标端口通信的情况，这样就能有效地辨别攻击企图，可以为安全和 IT 从业者提供必要的信息，帮助其检测和抵御环境中的异常问题，最终阻止 Log4j漏洞利用攻击，并让正常的业务运营不受干扰。
据悉，在全球各地有数百个数据中心使用 Akamai Guardicore Segmentation 来实现进程级网络监测，以及相关措施的实施。因此Akamai能够观测在网络内进行的所有网络连接，能够研究数据中心和云端网络内部以及跨越其安全边界的网络通信模式，从而总结出了Log4j 漏洞给我们的数字生活带来的风险的整体量级参考。
Log4j 漏洞的爆发为我们敲响了网络安全的警钟，每个企业都应该准备一套应对策略，以备不时之需。Akamai 针对 Log4j 漏洞的分析与研究，理清了事件本质， 明确了缓解措施，为网络安全人员抵御安全风险提供了重要参考和借鉴。
