有效应对 OpenSSL 3.x 漏洞
更新（2022 年 11 月 1 日）：通过 HTTP 和 HTTPS 进行的 Akamai 内容交付不受此漏洞的影响，因为服务器使用的是未受影响的 OpenSSL 版本。此外，Akamai 系统利用行业标准的堆栈保护机制来抵御所述攻击媒介。Akamai 正在修补任何可能受影响的内部系统，但我们预计这些修补工作不会导致我们的客户停机。
10 月 25 日，OpenSSL 项目团队 宣布 针对 OpenSSL 版本 3.x 中的一个严重漏洞进行安全修复。该修补程序计划于 2022 年 11 月 1 日 13:00 至 17:00（UTC 时间）期间发布。
由于 OpenSSL 使用广泛，因此该公告引起了很大的轰动。通过本文，我们希望消除干扰，并提供如何在不进行推测的情况下检测和抵御威胁的相关背景和技巧。博文的第一部分将概述 OpenSSL 及该漏洞的影响范围。第二部分将介绍应用程序中如何使用 OpenSSL，并且将提供工具来检测易受攻击的资产。如果您愿意，可以随时 直接跳转到这些实用程序。
注意： 此博文介绍的事件在不断发展，随着收集到的信息更多和修复程序的发布，博文内容将进行相应更新。
此漏洞的影响范围有多大？
此漏洞引起了安全社区的关注，因为 OpenSSL 团队将漏洞评级为“严重”级别的情况很罕见，该漏洞严重级别后来被降级为“高”。自从在 Heartbleed（导致内存泄漏的漏洞，还有可能造成密钥泄露）之后引入这些漏洞标签以来，只有一个 CVE-2016-6309 漏洞被归类为“严重”级别。
根据 OpenSSL 团队的要求，被评为“严重”级别漏洞即表示漏洞会影响常用配置并且很可能会被利用。此类漏洞的示例可能包括“服务器内存内容的重大泄露（可能泄露用户详细信息）、可以轻松远程利用以破坏服务器私钥的漏洞，或者被认为在常见情况下可能执行远程代码的漏洞”。
考虑到 OpenSSL 库的普遍性，其中存在漏洞可能危害不小。不过，尽管有必要保持警醒，但目前还没有必要为此而恐慌。OpenSSL 很常见，但其较为普遍的版本是 1.X.X， 而该漏洞仅影响 OpenSSL 3.0.0 及以上版本 （2021 年 9 月才发布）。因此，该漏洞可能 不如 OpenSSL 库本身的分布那么普遍 。
我们已经在现有的一些托管网络上执行了检测工具，并了解到以下情况：
大约 50% 的受监控环境至少有一台计算机， 其中至少有一个进程依赖于易受攻击的 OpenSSL 版本。
在这些网络中，对易受攻击的 OpenSSL 版本有一定依赖性的计算机占比在 0.2% 到 33%之间。
中位覆盖率为 6.1% ，平均值为 11.3% ，标准差为 11.6%。
这些统计数据不考虑不易受攻击的 OpenSSL 的使用情况。唯一的指标是计算机中至少有一个进程依赖于易受攻击的 OpenSSL 版本 (3.0–3.6)。也不考虑在同一台计算机上运行的其他进程。
什么是 OpenSSL？
OpenSSL 是一个开源软件工具包，所以 OpenSSL 版本基本上可以说是源代码版本。然而，这对检测来说意味着，应用程序可以通过多种方式加载或依赖 OpenSSL，因此该漏洞可能导致严重影响。
首先，我们需要定义 OpenSSL 的三个组件。
libcrypto —— 实现了多项协议（例如 AES、RSA、ChaCha 等）的加密库
libssl —— 实现了所有 TLS 协议（直到 TLSv1.3）的库
openssl —— 用于各种操作（例如生成证书）的命令行实用程序
对于依赖 OpenSSL 的应用程序，必须调用 libcrypto 或 libssl 的一些代码逻辑（openssl 本身就是依赖二者的应用程序）。
抵御 OpenSSL 漏洞
抵御 OpenSSL 威胁的第一步是检测易受攻击的资产。虽然这个建议很常见，但很少有实用的方法。我们提供了已知的易受攻击应用程序列表（如下），以及在您的网络中查找易受攻击应用程序的常规方法。
分段 —— 修补前后的抵御措施
尽管可能无法立即进行修补，因为对 OpenSSL 的大多数依赖来自供应商的软件（他们需要自己应用修复程序），但我们仍然可以充分利用通过检测所获得的监测能力。我们可以使用分段和路由来减少攻击者可能通过滥用漏洞进行的传播。
我们可以采用（更严格的）DMZ 的形式对面向互联网的资产进一步施加限制。
我们可以在整个域中创建更多分段，这样遭到入侵的内部计算机就无法用于将攻击传播到整个网络。这也可用来将易受攻击计算机的攻击面缩小到计算机实际需要与之通信的网络部分。
此外，我们还可以利用这种监测能力和检测来创建修补行动计划，并确保不会跳过任何抵御措施。修补程序发布并完成修补过程后，我们可以重新运行检测逻辑并比较结果。理想情况下，将不会再存在任何易受攻击的计算机。
哪些已知应用程序易受攻击？
BoringSSL（在 Google Chrome 中使用）和 LibreSSL 是两个基于 OpenSSL 代码的库，这两个库尚未受到近期漏洞的影响。
不同的 Linux 发行版通常附带 OpenSSL 库。如果您运行 Linux 环境，可能需要检查您是否使用以下版本之一，这些版本附带的 OpenSSL 存在漏洞。
Red Hat Enterprise Linux 9
Ubuntu 22.04+
CentOS Stream9
Kali 2022.3
Debian 12
Fedora 36
如果您使用的 Linux 发行版不在列表中，也无法保证您免受漏洞的影响。如果您主动更新了库（例如，作为包管理器升级命令的一部分），也会很容易受到攻击。您可以在终端中输入“openssl version”以输出库的版本。
Docker 还 发布了 他们对即将发布的版本的公告，他们估计大约 1,000 个镜像存储库可能会受到各种 Docker 官方镜像和 Docker Verified Publisher 镜像的影响。这包括基于上述 Linux 发行版变体的镜像。
此外，还有一些框架可能也会受到影响。Node.js v18.x 和 v19.x 使用的是 OpenSSL 3，因此假定它们会受到该漏洞的影响。他们将在此 博文中宣布任何新的更新。
另一种让开发人员担忧的编程语言是 Golang。Go 二进制文件中的库采用静态链接，可能需要 Go 开发人员重新编译他们的软件。当 Golang 团队在即将发布的 OpenSSL 修补程序的同一日期宣布包含安全修复程序的新次要版本时，人们会将二者联系起来并假设二者相关。别担心：完全是虚惊一场。 Golang 的发布与即将发布的漏洞修补程序无关。
在未来几天里，易受攻击的应用程序列表可能会增加，我们将相应地更新此博文。下一节将提供检测方法和工具，帮助您确定环境中的哪些应用程序使用 OpenSSL 3，因此也容易受到攻击。如果您愿意，可以 直接跳转到检测机制。
检测使用 OpenSSL 3 的应用程序的常规方法
注意： 本节介绍了应用程序如何使用 OpenSSL 的内部细节。如果您只对检测感兴趣，可以直接跳转到我们的 YARA 规则 或 OSQuery 查询。
OpenSSL 可以静态和动态地链接到应用程序。通过静态链接，OpenSSL 的源代码作为应用程序代码的一部分包含在内，并且二者一起编译成同一个二进制文件。通过动态链接，OpenSSL 被单独编译成一个共享库（Windows 上的 libssl.dll 和 libcrypto.dll；Linux 上的 libssl.so 和 libcrypto.so）。然后，应用程序代码引用共享库，这些引用由操作系统在加载应用程序时进行解析。
这如何转化为检测？ 实际上，检测静态编译的二进制文件的方法就足够了。为什么？因为如果正在运行的应用程序动态加载 OpenSSL，或者即使动态加载一个库，而这个库又动态加载 OpenSSL（等等），最终也会加载一些静态编译的 OpenSSL 库。由于所有动态加载都发生在同一个进程的上下文中，我们只需要查看加载到每个进程中的库列表，并找到静态编译的库。
因此，我们需要了解静态编译的 OpenSSL 的特征。幸运的是，这相当简单。OpenSSL 的所有静态编译都包含一个版本字符串，如下所示： OpenSSL 3.0.6 11 Oct 2022，其中 3.0.6 是版本号。检测此字符串非常简单，可以使用 Regex 或 YARA 来完成。
但是，这可能无法获得完美匹配。由于 OpenSSL 是开源代码，用户可以轻松更改版本控制逻辑以满足其需求（从而导致我们的检测失败）。这种情况我们只见到过一次（Cisco 改用字符串 CiscoSSL 1.1.1k.7.2.225 ），但其他供应商也可能遇到这种情况。
现在我该怎么做？
尽管在修复程序发布之前我们无法了解太多信息，但防御者可以先发制人地采取一些措施来为修补做好准备。我们的团队构建了一些实用程序，您可以在环境中运行这些实用程序，以提高监测能力并缓解风险。 启用了 Insight 功能的 Akamai Guardicore Segmentation 客户可以在其环境中轻松运行此逻辑。
YARA
我们可以编写的主要规则是上面提到的字符串。为了简洁起见，我们将仅检测受该版本影响的 OpenSSL 的实际版本，但我们可以轻松修改我们的标准。
rule openssl_version {
strings:
$re1 = /OpenSSL\s3\.[0-6]{1}\.[0-9]{1}[a-z]{,1}/
condition:
$re1
}
如果不想依赖字符串，我们还可以查找依赖 OpenSSL 的主应用程序，但解析可执行文件的导入。不过，这是一个不那么万无一失的方法，应该谨慎使用。
import "elf"
import "pe"
rule elf_import_openssl {
condition:
(elf.type == elf.ET_EXEC or elf.type == elf.ET_DYN) and
(
for any i in (0..elf.symtab_entries):
(
elf.symtab[i].name contains "@OPENSSL_3"
)
)
}
rule pe_import_openssl {
condition:
pe.is_pe and
(
for any i in (0..pe.number_of_imports):
(
pe.import_details[i].library_name contains "libcrypto-3" or pe.import_details[i].library_name contains "libssl-3"
)
)
}
osquery
使用上述查询，我们还可以利用 osquery 的 YARA 表在所有正在运行的进程上运行这些规则。
WITH FIRST_QUERY AS (SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid))
SELECT *
FROM FIRST_QUERY
JOIN yara ON yara.path = FIRST_QUERY.mmap_path
WHERE sigrule = 'rule openssl_3 {
strings:
$re1 = /OpenSSL\s3\.[0-6]{1}\.[0-9]{1}[a-z]{,1}/
condition:
$re1
}
'
AND yara.count > 0
当然，您也可以放入我们提到的其他 YARA 规则，或者添加更多或更少的筛选条件来减少或增加检查的文件数量。
总结
OpenSSL 团队采用了一种令人关注的方法，即通知安全团队即将发布的修复版本。该公告使防御者有时间准备和映射排队等待修补的关键资产。在这篇博文中，我们力图帮助用户找到需要在修补程序发布当天解决的应用程序和资产。
此事件在不断发展，随着新信息的发布，我们将更新此博文，因此请务必返回此处查看更新内容。您也可以关注我们的公众号，以获取更多实时更新。
