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

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

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

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

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

答案1

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

我很脆弱吗?

OpenSSL 的 bug 版本

有缺陷的软件是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 bug 修复,那也没关系,即使您看到的是 1.0.1f 这样的版本。如果openssl version -a提到构建日期(不是第一行的日期)是 2014 年 4 月 7 日晚上 UTC 左右或更晚的时间,那么应该没问题。请注意,OpenSSL 软件包可能有1.0.0中可能有姓名尽管版本是1.0.1(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'

如果你运行一些服务器软件就在这个清单上监听 SSL 连接,你可能受到了影响。这涉及到 Web 服务器、电子邮件服务器、VPN 服务器等。您会知道您已启用 SSL,因为您必须生成证书,方法是向证书颁发机构提交证书签名请求或进行您自己的自签名证书。 (某些安装过程可能在您没有注意到的情况下生成了自签名证书,但这通常仅适用于内部服务器,而不适用于暴露在 Internet 上的服务器。)如果您运行暴露在 Internet 上的易受攻击的服务器,请认为它已受到威胁除非您的日志显示自 2014 年 4 月 7 日发布以来没有任何连接。 (这假设该漏洞在发布之前未被利用。)如果您的服务器仅在内部暴露,则是否需要更改密钥将取决于是否采取了其他安全措施。

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

以下程序不受影响,因为它们不使用 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 连接并检索了您服务器的密钥,他们现在可以解密其记录。 (除非无进展生存期是有保证的——如果你不知道,那就不是。)

其他情况的补救措施

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

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

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

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

如果您在 2014 年 4 月 7 日晚上 UTC 之间执行此操作并升级 OpenSSL 库,请考虑客户端内存中的所有数据都会受到损害。

参考

答案2

要测试您是否容易受到攻击,请转到此处:http://filippo.io/Heartbleed/

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

答案3

没有办法从这个错误中恢复。保存所有日志,如果有人在宣布漏洞之前确实意识到该漏洞确实存在,则将需要它们

相关内容