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

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

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

如果我受到影响，我该怎么办？显然，升级还不够。

此漏洞具有很大的潜在影响，因为如果您的系统受到攻击，即使进行了修补，它仍将很容易受到攻击，并且攻击可能不会在日志中留下任何痕迹。很有可能，如果您快速打补丁并且您不是一个引人注目的目标，那么没人会四处攻击您，但是很难确定。

我容易受到伤害吗？

越野车版本的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在UTC晚上或更晚提到一个建造日期（不是第一行的日期）为2014-04-07，那应该没问题。请注意，即使版本为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'

如果您运行此列表中的某些服务器软件并侦听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连接并检索了服务器的密钥，则他们现在可以解密其笔录。（除非PFS得到保证-如果你不知道，事实并非如此。）

其他情况下的补救措施

仅在不受信任的用户可以连接到它们的情况下，仅在localhost或Intranet上侦听的服务器才被视为公开。

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

1. 处理机密数据（例如密码，客户证书等）；
2. 然后以相同的过程通过SSL连接到恶意服务器。

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

如果您在2014年4月7日晚上UTC到升级您的OpenSSL库之间进行了此操作，请考虑破坏客户端内存中的所有数据。

参考文献

• Heartbleed错误（由独立发现该错误的两个团队之一）
• OpenSSL TLS心跳（Heartbleed）漏洞利用的工作原理是什么？
• Heartbleed是否为每个SSL服务器都意味着新证书？
• 伤心欲绝：它是什么，有什么缓解方法？

要测试您是否容易受到攻击，请访问此处：http : //filippo.io/Heartbleed/

如果发现存在漏洞，请更新openssl并重新启动Web服务器。

无法从此错误中恢复。保存所有日志，以防万一有人在宣布漏洞之前实际意识到该漏洞的存在