追溯解密基于 SSL 加密的 RDP 会话

网络窃听者可以记录加密后的RDP(Remote Data Protocol)会话,并且之后可以解密。这种方式可能泄露通过RDP连接发送的所有数据,包括按键动作、用户名及密码。本文主要说一下幕后过程。

更加专业的说法是:这篇文章关于  完全正向保密(Perfect Forward Secrecy – PFS)为何SSL连接往往不是想象中的那样安全。因为RDP使用SSL,所以容易遭遇追溯解密。

使用Wireshark记录加密的RDP连接

我会记录我的以太网接口的所有流量,然后使用mstsc(Microsoft terminal services client)连接到一个RDP服务器,并输入一个密码。输入密码之后我直接停止了数据抓取。

怎样判别RDP会话脆弱可攻击

如果你首先对 TCP 3389 端口流量进行“Analyze | Follow TCP Stream” ,然后“Analyze | Decode As… | SSL”,Wireshark会显示SSL服务器Hello信息。检查是否在用基于 RSA 算法的密码套件。如果是,那这篇文章适用于RDP会话,并会告诉你如何破解它。

rsa

Wireshark跟踪展示SSL服务器Hello消息

请注意,相对基于 CredSSP(SSL+NLA)的连接,我只是尝试了以SSL为基础的RDP连接,所以情况因人而异。

开始解密…

提取服务证书的SSL私钥

随着服务器被渗透,拥有管理员权限的攻击者可以轻易地从证书存储区提取用于服务验证的私钥。

geocerts站点提供如何这样做的逐步解说,它与其它解说一样好。被终端服务器使用的证书位于为“Computer Account”建立的“Personal”或者“Remote Desktop”证书存储区。仅仅使用MMC的“Certificates”插件为SSL证书导出私钥。我导出的文件使用.pfx格式,它需要你设置一个密码。

做这个示例时我使用Windows 2003服务器。我觉得从更新版本的Windows中提取所需证书更加困难。这就把它当作练习留给读者了。

将.pfc格式文件转化为.pem格式

为了解密SSL流量,我们会用到Wireshak,它处理PEM格式文件(这里是.cer格式)时需要使用密钥。而格式的转化仅需要使用以下OpenSSL单行小命令:

使用Wireshark解密流量

使用Wireshare 解密SSL流量时有一点棘手,是因为对我来说,学习使用这个教程时Wireshark首次为我所用。

我指定RSA密钥列表如下:

接下来在Wireshark中有可能看到所有清晰的文本流量。在“Follow TCP Stream”对话框中,我选择了十六进制存储方式并向下翻动对话框。我正在寻找符合我输入密码的按键的一些简短信息。

keystrokes

Wireshare显示符合按键流量的十六进制转储视图

红色字体显示的信息来自于RDP客户端。我们会检查以44 04 00开头的每四个字节一组的信息。这些以44 04 00的信息与密钥按键被按下的动作相符合,而以44 04 01开头的四个字节信息则是与密钥按键被释放动作相符合。

首个感兴趣的信息是:

然后是每种情况中的键扫描码最后四个字节。(漏掉一些不感兴趣的内容):

如果我们依次查询每一项可以得到到:

当我们考虑到SHIFT键的作用,可以将password变化为Password1。

结论

攻击者追溯解密SSL流量的能力在某些情况下是不可取的。这不是某个不寻常或者孤立的例子。因为很大部分HTTPS网站很容易出现同样的问题。

从传统意义上来说,这不是一个漏洞。它引发的这些弱点允许攻击者盗取SSL私钥,从这一点来说,所有的安全声明都形同虚设。

实际上,回顾完全正向保密的缺失非常有趣,完全正向保密与微软的安全漏洞定义相对立。它看上去与微软的定义并不适应。如果正向保密的缺失真的呈现出了问题,那么这问题将会导致“某些标准不完美却被广泛接受”。

当RSA作为密钥交换算法时,禁用对RSA的支持是SSL问题通常的补救方法。然而,我还没有找到Windows 2003上的有效解决方案。阅读补丁KB245030之后,我做了以下设置注册表项的实验:

然而,我只是成功地完全阻止了RDP连接。

未经允许不得转载(声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎发送邮件至:net-net@foxmail.com进行举报,并提供相关证据,工作人员会在10个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。):策信智库资讯网 » 追溯解密基于 SSL 加密的 RDP 会话

赞 (0)