如何从 OpenSSL 中的 Heartbleed 错误中恢复?

Gil*_*il' 95 security openssl

CVE-2014-0160又名Heartbleed是 OpenSSL 中的一个漏洞。看起来很吓人。

我如何确定我是否受到影响?

如果我受到影响,我需要做什么?显然升级是不够的。

Gil*_*il' 98

此漏洞具有很高的潜在影响,因为如果您的系统受到攻击,即使在修补后仍然存在漏洞,并且攻击可能不会在日志中留下任何痕迹。如果你快速修补并且你不是一个引人注目的目标,那么可能没有人会来攻击你,但很难确定。

我脆弱吗?

OpenSSL 的错误版本

有问题的软件是OpenSSL 库 1.0.1 到 1.0.1f和 OpenSSL 1.0.2 到 beta1。旧版本(0.9.x、1.0.0)和修复了该错误的版本(1.0.1g 以上,1.0.2 beta 2 以上)不受影响。这是一个实现错误,而不是协议中的缺陷,因此只有使用 OpenSSL 库的程序会受到影响。

您可以使用命令行工具openssl version -a来显示 OpenSSL 版本号。请注意,某些发行版将错误修复移植到早期版本;如果您的包的更改日志提到了 Heartbleed 错误修复,那很好,即使您看到像 1.0.1f 这样的版本。如果openssl version -a提到 2014-04-07 晚上 UTC 或之后的构建日期(不是第一行的日期),你应该没问题。请注意,即使版本是 1.0.1(指的是二进制兼容性),OpenSSL 包1.0.0名称中也可能包含它。1.0.0

受影响的应用程序

漏洞利用是通过一个应用程序执行的,该应用程序使用 OpenSSL 库来实现SSL 连接。许多应用程序将 OpenSSL 用于其他加密服务,这很好:错误在于 SSL 协议的特定功能“心跳”的实现。

您可能想要检查哪些程序与您系统上的库相关联。在使用 dpkg 和 apt(Debian、Ubuntu、Mint 等)的系统上,以下命令列出了除使用的库之外的已安装包libssl1.0.0(受影响的包):

apt-cache rdepends libssl1.0.0 | tail -n +3 |
xargs dpkg -l 2>/dev/null | grep '^ii' | grep -v '^ii  lib'
Run Code Online (Sandbox Code Playgroud)

如果您运行此列表中的某些服务器软件侦听 SSL 连接,你可能会受到影响。这涉及 Web 服务器、电子邮件服务器、VPN 服务器等。您会知道您启用了 SSL,因为您必须生成证书,方法是向证书颁发机构提交证书签名请求或制作您自己的自签名证书证书。(有可能某些安装过程在您没有注意到的情况下生成了自签名证书,但这通常仅用于内部服务器,而不是暴露于 Internet 的服务器。)如果您运行暴露于 Internet 的易受攻击的服务器,请考虑它受到了威胁除非您的日志显示自 2014-04-07 发布以来没有任何连接。(这假设该漏洞在公布之前未被利用。)如果您的服务器仅在内部公开,

仅当您使用客户端软件连接到恶意服务器时,客户端软件才会受到影响。因此,如果您使用 IMAPS 连接到您的电子邮件提供商,则无需担心(除非提供商受到攻击 - 但如果是这种情况,他们应该让您知道),但如果您使用易受攻击的浏览器浏览随机网站,您可能需要担心。到目前为止,该漏洞在被发现之前似乎并未被利用,因此您只需要担心自 2014-04-08 以来是否连接到恶意服务器。

以下程序不受影响,因为它们不使用 OpenSSL 来实现 SSL:

  • SSH(协议不是 SSL)
  • 铬/铬(使用 NSS
  • Firefox(使用 NSS)(至少在 Ubuntu 12.04 上使用 Firefox 27,但不是所有版本?

有什么影响?

该错误允许任何可以连接到您的 SSL 服务器的客户端一次从服务器检索大约 64kB 的内存。客户端不需要以任何方式进行身份验证。通过重复攻击,客户端可以在连续尝试中转储内存的不同部分。这可能允许攻击者检索服务器进程内存中的任何数据,包括密钥、密码、cookie 等。

攻击者可能能够检索的关键数据之一是服务器的 SSL 私钥。有了这些数据,攻击者就可以冒充您的服务器。

该错误还允许您的 SSL 客户端连接到的任何服务器一次从客户端检索大约 64kB 的内存。如果您使用易受攻击的客户端来操作敏感数据,然后使用同一客户端连接到不受信任的服务器,这将是一个令人担忧的问题。因此,这一端的攻击场景比服务器端的可能性要小得多。

请注意,对于典型的分发,对软件包分发没有安全影响,因为软件包的完整性依赖于 GPG 签名,而不是 SSL 传输。

如何修复漏洞?

修复暴露的服务器

  1. 使所有受影响的服务器脱机。只要它们在运行,就有可能泄露关键数据。

  2. 升级 OpenSSL 库包。所有发行版现在都应该有一个修复程序(使用 1.0.1g,或者使用补丁修复错误而不更改版本号)。如果从源代码编译,请升级到 1.0.1g 或更高版本。确保所有受影响的服务器都重新启动。
    在 Linux 上,您可以检查可能受影响的进程是否仍在运行grep 'libssl.*(deleted)' /proc/*/maps

  3. 生成新密钥。这是必要的,因为该漏洞可能允许攻击者获得旧私钥。按照您最初使用的相同程序进行操作。

    • 如果您使用由证书颁发机构签署的证书,请将您的新公钥提交给您的 CA。获得新证书后,将其安装在您的服务器上。
    • 如果您使用自签名证书,请将其安装在您的服务器上。
    • 无论哪种方式,将旧的密钥和证书移开(但不要删除它们,只需确保它们不再被使用)。
  4. 现在您有了新的未妥协的密钥,您可以让您的服务器重新联机

  5. 撤销旧证书。

  6. 损害评估:服务 SSL 连接的进程内存中的任何数据都可能被泄露。这可能包括用户密码和其他机密数据。您需要评估这些数据可能是什么。

    • 如果您正在运行允许密码身份验证的服务,那么自漏洞公布前不久就连接的用户的密码应被视为已泄露。检查您的日志并更改任何受影响用户的密码。
    • 还要使所有会话 cookie 无效,因为它们可能已被泄露。
    • 客户端证书不会被泄露。
    • 在漏洞发生之前交换的任何数据都可能保留在服务器的内存中,因此可能已泄露给攻击者。
    • 如果有人记录了旧的 SSL 连接并检索了您服务器的密钥,他们现在可以解密他们的成绩单。(除非确保PFS - 如果您不知道,那就不是。)

其他情况下的补救

仅在不受信任的用户可以连接到它们时,仅在 localhost 或 Intranet 上侦听的服务器才会被视为暴露。

对于客户端,只有极少数情况下可以利用该漏洞:漏洞利用需要您使用相同的客户端进程来

  1. 操纵机密数据(例如密码、客户证书等);
  2. 然后,在同一过程中,通过 SSL 连接到恶意服务器。

因此,例如,您仅用于连接到您的(并非完全不受信任的)邮件提供商的电子邮件客户端不是问题(不是恶意服务器)。运行 wget 下载文件不是问题(不会泄露机密数据)。

如果您在 2014 年 4 月 7 日晚上 UTC 和升级 OpenSSL 库之间这样做,请考虑客户端内存中的任何数据都会受到损害。

参考

  • “通常,如果您运行某个 ** 服务器,您在某个时候生成了 SSL 密钥**,则会受到影响。” 可能会误导。强调一下,如果您在一台服务器上生成您的密钥,并在另一台服务器上使用它,那么如果使用它的服务器运行 OpenSSL 的易受攻击版本,您就会遇到麻烦。 (5认同)
  • 客户端证书也受到影响 IIRC (3认同)
  • @ElazarLeibovich 不是专门的客户端证书(实际上,此错误不太可能泄露客户端证书),而是客户端内存中的任何数据,如果使用易受攻击的库版本的客户端使用支持服务器启动的心跳的协议连接到恶意服务器。[我问过专家](http://chat.stackexchange.com/transcript/message/14778531#14778531),还没有明确的答案。 (2认同)

小智 11

要测试您是否易受攻击,请访问:http : //filippo.io/Heartbleed/

如果您发现自己易受攻击,请更新openssl并重新启动您的网络服务器。