到目前为止，我还没有看到可以利用客户端应用程序中的错误的单个工具。在客户端利用该漏洞难吗？客户实际上是否脆弱？
#1 楼
事实上，是的，客户很脆弱。到目前为止，注意力已经集中在服务器上，因为它们更容易受到攻击。 （几乎）每个人都可以连接到公共HTTP / SMTP / ...服务器。该博客描述了该错误的实际工作方式（它提到了
dtls_process_heartbeat()，但是tls_process_heartbeat()受到相同的影响）。此功能可用于客户端和服务器应用程序，因此客户端确实也容易受到攻击。根据RFC 6520，握手期间不应发送心跳信号。实际上，OpenSSL在发送ServerHello之后立即接受心跳（这是Jared Stafford的ssltest.py所做的事情）。经过进一步测试，我发现服务器也可以在发送ServerHello之后立即发送心跳信号来滥用客户端。它会触发相同的错误。
可以在我的仓库中找到概念证明，网址为https://github.com/Lekensteyn/pacemaker。从其自述文件：
握手之前，以下客户端已经针对1.0.1f和泄漏的内存进行了测试：
MariaDB 5.5.36
wget 1.15（释放以前的连接和自身状态的内存）
curl 7.36.0（带有--ftp-ssl的https，FTP / IMAP / POP3 / SMTP）
git 1.9 .1（经过测试的克隆/推送，泄漏不多）
nginx 1.4.7（在代理模式下，泄漏先前请求的内存）
链接2.8（泄漏先前访问的内容！）
KDE 4.12.4（kioclient，Dolphin，使用kde4-ftps-kio测试过的https和ftps）
例4.82（传出SMTP）
已证明实际上可以返回64 KiB的内存（65535字节）。还已经证明，客户端（
wget，KDE Dolphin等）可能会泄漏数据，例如以前的请求，可能包含密码。评论
客户的任何回报都表明它很脆弱，对吗？像：连接来自：127.0.0.1:53459客户端返回7（0x7）字节
– scuzzy-delta
2014年4月9日在17:16
@ scuzzy-delta更有可能是一个警报。 15 03 03 00 02 02 28是致命的握手失败。当不支持密码套件时，我就有了。您不能由此得出服务器易受攻击的结论。
– Lekensteyn
2014年4月9日在17:48
从理论上讲，有人可以在挖掘您的机器时接管您的ISP的DNS服务器并通过其代理来代理流量。国家安全局可能会在美国的IXP上这样做。如果未对Google搜寻器或任何其他搜寻器进行修补，则可能可以通过其搜寻器从Google / Yahoo提取数据...鉴于每个人都在集中TLS服务器，这可能是一个非常合理的攻击媒介。
–姆旺吉
2014年4月9日在21:11
Ubuntu saucy上具有所有更新的客户端不会显示任何漏洞。但是，Ubuntu上带有更新的rar的客户端正在流血。
–HRJ
2014年4月16日下午6:32
@HRJ 13.04自2014年1月27日起终止了雇佣关系，因此您可能需要担心更多。仍支持并修复了12.04 Precise，12.10 Quantal和13.10。这可能有点出乎意料，但是Canonical已将从Raring开始的支持周期从18个月降低至9个月。
– Lekensteyn
14年4月16日在8:04
#2 楼
我编写了一个Metasploit模块来对其进行测试，该模块目前正在审核中，但应该会很快进入master分支。此时第一个版本已合并到master分支中。https://github.com/rapid7/metasploit-framework/blob/38a2614fbee1851252462c858057738c06a9f2ab/modules/auxiliary/server/openssl_heartbeat_client_memory.rb
与服务器端攻击不同，您必须实现大多数TLS，因为根据SSL会话密钥对心跳答复进行了加密。我使用wget，curl和openssl命令行进行了测试。一个有趣的花絮是，针对wget和openssl（1），无论证书验证如何，攻击都会成功。 curl二进制文件需要-k或有效证书，以保持会话打开足够长的时间，攻击才能起作用。相对于这些相对综合的测试，我可以可靠地泄漏TLS会话密钥（AES-128-CBC），但这并不能提供很多，因为服务器在握手期间知道相同的密钥。
EDIT1：看起来，起搏器代码无需完全TLS握手即可完成此操作（甚至更好！）。我会对人们在实现之间可能获得的任何测试结果感兴趣。 IOW，如果客户由于自签名证书而导致连接断开，起搏器是否成功？
EDIT2：@Lekensteyn在起搏器中使用的方法（在Server Hello之后发送心跳）是一种更好的方法，因为CA验证不是问题。我提交了一个新的Metasploit PR，默认使用此模式，并使用NEGOTIATE_TLS选项保留TLS协商代码路径（将旧模式设置为NEGOTIATE_TLS为true）。 @Lekensteyn的道具！
评论
您应该针对您不久前写的那些Digi设备尝试此操作。其中许多厂商和其他制造商可能会将OpenSSL用于其VPN和隧道功能。
– MToecker
2014年4月9日在20:22
我回顾了其中的不少固件/内存转储和SDK（主要是Digi和VxWorks），由于内存需求，很少使用OpenSSL。 Allegro Software和Wind River等公司的专有加密库可能还有其他错误，但可能与该错误不同。即使如此，它也值得进行认真的测试。我的0.02美元是，由于依赖于库存的Linux / busybox / openssl设置，数量不合理的DVR和NAS设备将很容易受到攻击。
–HD Moore
2014-4-9 20:33
达恩，我希望在这里有一个明显的ICS角度。我在进行一些评估时遇到了带有openssl的busybox，可能是将其耗尽的好时机。谢谢！
– MToecker
2014年4月9日在20:41
@HDMoore心脏起搏器在我测试过的所有openssl客户端上均能可靠运行（请参阅其自述文件），它会在击中密钥交换甚至证书之前执行所有操作。你做得不错！我考虑过这样做，但是由于我应该准备一些考试，所以我放弃了这一耗时的想法;）
– Lekensteyn
2014年4月9日在20:59
您可能要更新链接，差异以某种方式为空。我在github.com/rapid7/metasploit-framework/commit/找到了您的模块
– Lekensteyn
2014年4月9日21:00
#3 楼
可以利用客户端中的错误。该测试器可用于向任意客户端发出“恶意” URL，并查看它们是否诱饵。我发现3个排名前100位的网站（在这里我不会对其命名）使用截至2014-04-09时容易受到攻击的客户端来获取URL。评论
我试过这个网站，有点可疑。它说它能够捕获大约16 KiB，但是当观看s_client输出和数据包捕获时，我看到继续请求。在5 MiB捕获的信息后，我手动中止了操作。他们的隐私政策在哪里？
– Lekensteyn
2014年4月10日在7:44
#4 楼
如果您使用的是Android设备，则可以安装测试该漏洞的Heartbleed应用程序之一，如下所示：https://play.google.com/store/apps/details?id = com.lookout.heartbleeddetector
我在两台Android手机上对此进行了测试，其中一台使用4.3，另一台使用4.4，两者均报告为易受攻击，但是对于这两种OpenSSL均未使用，所以一切都很好。 ...
所以一切都很好。太好了，没有应用程序正在使用OpenSSL。但是，如果我安装了使用它的应用程序该怎么办？我会收到通知吗？我猜不是！
4.4手机是Sony的全新手机，在首次使用后，它下载了系统更新，但是我认为这对固定不重要吗？！
评论
查看该程序的源代码，它在库文件中搜索模式（例如grep -F 1.0.1a /system/lib/libssl.so）。不是完全可靠的方法，因为可能已应用补丁程序来修复此错误。实际上，一种更可靠的方法是测试诸如起搏器所做的错误。
– Lekensteyn
2014年5月26日17:43
评论
您将如何在“真实”服务器上野外测试该工具以确保其正常工作？在您所在地区进行剥削实际上合法吗？@Pacerier您可以设置实验室环境（例如，使用虚拟机）。这样就没有非法侵入的问题了。