一个能有效减少基于SSL的中间人攻击的方案

最新推荐文章于 2024-07-01 15:21:01 发布

Ping_Fani07

最新推荐文章于 2024-07-01 15:21:01 发布

阅读量7.1k

点赞数

分类专栏：安全技术与实践文章标签： ssl javascript 服务器 dns服务器脚本

安全技术与实践专栏收录该内容

31 篇文章 5 订阅

订阅专栏

原文：Mitigating Man in the Middle Attack over SSL

来源：Internet Multimedia Services Architecture and Applications (IMSAA), 2009 IEEE International Conference on , vol., no., pp.1-5, 9-11 Dec. 2009

一个能有效减少基于SSL的中间人攻击的方案

作者：Yogesh Joshi, Debabrata Das, Subir Saha

摘要：钓鱼是一种用于盗取用户通行证的社会工程手段，而盗取的通行证可以用来获取经济利益。目前大多数的钓鱼攻击只是很单纯地把重心放在收集通行证上，却没有实时地验证获取的通行证是否正确。显然，下一代钓鱼攻击将会尝试实时地检查获取的通行证并利用它。一个实施钓鱼攻击的人可以很容易地在用户与被钓鱼的目标站点之间扮演中间人的角色。针对中间人攻击采取的启发式防御措施，如监测域名中的特殊字符、使用黑名单以及网页分析等都没有能够阻止钓鱼者。当用户访问的钓鱼网站的URL有别于真实网站的时，本领域的一项重要成果，即PwdHash可以成功阻止针对用户的攻击。本文将提出和实现一种新方法，当钓鱼网站使用的URL和原始站点一样时，这种方法可以解决基于SSL的中间人攻击。为了对抗这样的攻击，我们提出使用服务器的数字证书的公钥对用户口令进行哈希运算。这种方法可以阻止中间人攻击，因为中间人获得的原始口令哈希值不能重用。我们将实现一个浏览器插件来证明此方法的有效性。

关键词：中间人，钓鱼，安全，ID窃取

一、介绍

钓鱼是一种通过伪造成可信实体来盗取用户信息的行为。最简单的钓鱼攻击实例就是钓鱼者设置一个和目标网站非常相像的假网站。然后向用户发送大量的声称来自合法的机构的垃圾电子邮件，来骗取用户访问此假网站。收到垃圾邮件的用户中的少部分人会相信，然后遵循攻击者的指示，给出他们的通行证。众所周知，钓鱼者可以基于几乎任何的社会工程学方法来发动攻击，如电子邮件、电话、与人交谈、短信和即时信息等。钓鱼者也会利用其它技术诡计来骗取受害者访问仿冒的网站。

除了这一类型的钓鱼攻击机制，钓鱼者还可以诱使用户将犯罪软件放在用户的个人计算机上，这些软件会拦截任何敏感的信息，如用户名、口令、SSN等。根据参考文献[7]中反钓鱼工作组(APWG)最近发布的报告，大约35%的计算机受到此类型犯罪软件的影响。

在另外一种更危险的攻击场景中，钓鱼者架设自己的网络节点，比如WiFi接入点，并且允许用户免费接入。一旦用户通过连入此类网络来上网，那么显然攻击者可以非常容易地获取用户的信息。

参考文献[1]中说，根据Gartner最近发布的调查，截止到2008年9月份的前12个月里，有超过500万美国用户在钓鱼攻击中受损，相比一年前，受害用户增加了39.8%。钓鱼攻击中造成的间接损失更高，包括用户服务开销，账户变更开销和由于担心在线交易的安全性以致减少使用在线服务而带来的损失。为了对抗钓鱼攻击，Gartner分析人员建议应对策略要包括持续欺诈检测、加强的用户认证和用户带外传输验证。

随着网络犯罪的增强，认证机制也在增强。传统的认证以明文方式发送用户的通行证，这使得通行证遭到来自黑客的各种攻击。安全专家于是引入了增强的安全传输层/安全套接字层(TLS/SSL)来对抗攻击。这个协议提供服务端到客户端的认证，也提供反向的认证。因此每一方可以验证对方的可靠性。SSL通过要求通信双方具有一个由第三方机构颁发的数字证书来实现双向认证。但是，因为现在大多数因特网用户没有数字证书，所以大多数网站都只有服务端到用户的认证。肯定地说，这个措施加强了通信内容的安全，因为任何窃听到的数据都是加密的。

但是，钓鱼者可以使用社会工程学方法，然后很容易的在被钓鱼网站和用户之间进行中间人攻击（MITM），不用管被钓鱼网站是否采用了安全措施。一旦钓鱼者成功充当了中间人，他可以持续捕获任何加密的信息和未加密的信息。图1显示了钓鱼者在用户和原始网站之间的情形。现在对钓鱼者来说，充当一个仿冒实体是很简单的一件事情，因此他可以盗取用户和原始网站通信的任何信息。

包括银行网站在内的大多数网站使用简单的TSL或者SSL来进行HTTPS连接。很明显，对于进行中间人攻击的钓鱼者来说，用户和网站之间交换的口令和用户ID信息(或者其他凭证)是可见的。实质上，当前所有的著名网站都使用HTTPS来交换认证凭证，除了HTTPS提供的保护措施，这些通行证没有任何得到其他类型的保护。因此，即使是受保护的网站，进行中间人攻击也是有可能的。

有一些值得参考的方法来抵御中间人攻击，包括参考文献[5]中提到的多因素认证和文献[6]中提到的数字证书。这些解决方案可以阻止攻击者在将来某个时候使用盗窃到的通行证，但是不能阻止中间人攻击者在当前会话中盗取信息。

Blake Ross等人在一篇文章中介绍了PwdHash浏览器插件，这个插件通过将用户名和域名特定的参数值一起做哈希运算来应对中间人攻击。这种方法的好处在于，即使钓鱼者诱骗用户访问了仿冒的网站，钓鱼者获得的口令哈希值也是用户口令和假冒网站的域名参数哈希后的值。因此，对于攻击者来说，这个哈希值是无用的，因为它不能用于与原始网站的通信，原始网站期望的哈希值是通过用户口令和原始网站的域参数哈希运算得到。

我们认为虽然文献[2]中的方案可以阻止当前的大多数钓鱼攻击，但是其可能不能阻止攻击者使用某种方式来控制受害者的DNS从而进行的攻击。至少已经有两种已知的情形，攻击者利用DNS来返回指定的域名信息，一是DNS缓存中毒，二是开启本地DNS。

DNS缓存中毒包括在客户端解析者或者服务端解析者缓存中改变或者增加记录，这样使用DNS查询请求得到的IP地址对应攻击者的域信息，而不是原始网站的域信息。这种攻击会在以下情形中发生：不恰当的软件设计、域名服务器的错误配置或者针对传统的DNS系统的开放架构的弱点而出现的恶意利用情况。

攻击者控制DNS的另外一种情形被称作WiFi钓鱼[8]。看看这种情形，一个用户在机场努力的搜寻WiFi信号，攻击者运行着和用户期望的接入点同样的SSID的WiFi网络。大多数公共场合中的WiFi基本上是不加密的，所以攻击者可以非常容易的在用户和其访问的网站之间潜伏。攻击者也可以轻易的运行自己的DNS服务器，返回完成此次攻击需要的信息。一旦钓鱼者可以控制DNS或者运行自己的DNS服务器，PwdHash不会起任何作用。

我们提出和实现了一种新想法(在第二章会详细介绍)来克服上面提到的中间人攻击所带来的挑战。

本论文接下来的部分如下组织：第二章介绍了我们提出的解决方案及其实现，第三章对比研究了我们的方案和PwdHash方案，第四章针对各种钓鱼给出了一种具体的解决方案，最后第五章总结了我们的工作。

二、提出的解决方案及其实现

由此，我们建议客户端在提交用户口令给网站之前，先将用户口令与SSL证书的参数（而非像参考文献[2]中采用URL参数）做哈希运算，此项运算操作由一个称之为浏览器插件的客户端脚本完成。我们使用的是哈希算法SHA-1。

图2展示了我们用以减少中间人钓鱼攻击的解决方案的调用流程。由于我们的解决方案使用了一些嵌入在服务器PKI证书中的信息，因此攻击者几乎没有办法破坏整个系统。举个例子，假设攻击者在第一步中使用了真实服务器的证书，这样一来(用户)通行证就与目标服务器的参数一起做了哈希运算。这会使得攻击者在第一步就缺乏盗取哈希后的(用户)通行证(的手段)。

如下所述，我们的解决方案与PwdHash方案相比是有巨大优势的，因为我们并不需要由任何的口令引导开始。我们可以合理地认为我们的系统(亦即解决方案)具有(较高的)强度，因为PKI证书体系建立在强大的安全性能上(而我们的系统是建立在PKI体系上的)。对攻击者来说，即使是运行他们自己的root权限也很难在基于WiFi的上下文钓鱼中对系统造成欺骗。

与PwdHash采用的机制不同，在我们安装了该插件之后，口令的改变就不再依赖于用户。我们会(转而)要求服务端的验证方式发生转变：将用户输入的口令，与数据库中的密码以及(服务端的)SSL证书参数的哈希值作对比，以替代直接对比原始口令的方式。

插件的目标是确保用户的使用习惯没有发生任何形式的改变。参考文献[3]中说，为了避免被钓鱼攻击，解决方案不应试图依赖于任何的用户参与。基于同样的考虑，我们决定在服务端(的验证方式)做出修改(而用户输入保持不变)。笔者再次强调，本文所讨论的解决方案仅针对那些URL依然是真实的，但钓鱼者使用自己(伪造)的证书代替服务端的数字证书的HTTPS攻击。

设计思路：

客户端

我们开发了一个Firefox浏览器插件来验证我们所提出的解决方案。当浏览器向一个HTTPS站点发出一个(网页)请求时，HTTPS站点会把自己的数字证书发送给浏览器。而后本插件使用Mozilla基金会为Firefox开发所提供的Javascript从该数字证书中提取数字指纹。获取数字指纹之后，本插件会监视网页上的口令输入框。该输入框在HTML文件中使用口令类型参数<input type=”password”>来标志。一旦用户在口令输入框中键入口令的值并且提交表单，本插件就会在口令输入框的内容后面加上前面获取的(服务器证书的)数字指纹，计算它们的哈希值，并使用这个哈希值代替口令输入框中的内容提交给服务器。要在浏览器中实现哈希运算最直截了当的方式是使用现成的SHA-1例程。

服务端

为了让用户的使用习惯保持不变，所必需要付出的代价是必须在服务端进行一定的修改。如果不是因为这样，服务端通常会接受用户提交的口令值并与数据库中保存的口令值作对比(以此完成身份验证)。这种方法所需的变化，是服务方必需用数据库中的口令值后加本站点SSL证书数字指纹做哈希运算生成的哈希值与插件采用上述同样方式生成的哈希值作对比，以此代替直接的口令值对比。

针对本插件的攻击分析

在本段中，我们将会讨论一些针对我们的解决方案可能发生的攻击，并就我们的解决方案为什么会使得这些攻击成为可能的给出分析。

我们的方法可以被一些众所周知的JavaScript技术击败，例如模拟口令输入框，异步提交用户输入等。为了应对这些JavaScript脚本攻击，本插件需要对口令输入框采用智能检测(手段)。前文提到的JavaScript脚本攻击有以下三种实施方式：

1）使用假的口令输入框模拟真实的口令输入框

在这种攻击方式中，钓鱼者确实使用了口令类型的输入框，然而对于每一个按键输入，他也同时传入了一个隐藏类型的输入框。类似的JavaScript脚本如下：

<form>
<input type="hidden" name="rogue" value="">
<input type="password" name="fair" onKeyPress=" this.form.rogue.value+=
String.fromCharCode(event.keyCode); ">
</form>

2）异步提交

在异步提交方式的攻击中，钓鱼者会在网页中嵌入一段异步JavaScript脚本。这段脚本会在用户键入每个字符的同时将该字符提交给钓鱼网站。这种类型的攻击使得(本文所述插件)要在提交口令之前做哈希运算的打算落空，因为在用户点击登录之前，口令已经被提交了。这种攻击可以使用一段简单地异步JavaScript脚本和XML(AJAX)的片段实现。

以上方法中的任意一种，都是用户(将口令)输入一个口令类型的输入框。因此为了检测到这种攻击行为，我们提供的方案是，一旦(检测到)用户开始在口令输入框键入内容就禁用JavaScript脚本。当用户失去口令输入框的焦点 (即用户完成了口令的输入) 时，JavaScript脚本又被允许使用。这种方法也再次表明了我们(提出的)哈希运算过程中无需用户参与的理念。

3）使用文本输入框模拟真实的口令输入框

在这种攻击方法中，钓鱼者使用了一个简单的文本类型的输入框，而非一个口令类型的输入框来接受用户的输入。对于用户的每一个键盘输入，钓鱼者将之存入一个隐藏类型的输入框，并在冒充的文本输入框中用一个星号来显示。这样就使得一个文本类型的输入框看上去像一个口令类型的输入框一样。(以下是一段类似的JavaScript脚本：)

<form>
<input type="hidden" name="rogue" value="">
<input type="password" name="fair" onKeyPress=" this.form.rogue.value+=
String.fromCharCode(event.keyCode);event.keyCode=42; ">
</form>

针对上述攻击方式的一个可行解决方案是为每一次按键调用一个监听器。监听器会检查那些输入内容以星号形式展示的文本框，看当前产生星号的文本框(接受输入时)是否禁用了JavaScript脚本，是否得益于上一小节提到防御机制。

三、我们提出的解决方案与PWDHASH方案的对比研究

在本章中，我们对参考文献[2]中提出的PwdHash方案和我们的方案做了对比研究，并总结了两种方法的优缺点。为了继续本章所进行的讨论，我们假设读者知道PwdHash方案的相关知识。PwdHash方案建议使用目标服务器的域名参数与用户通行证一起做哈希运算，以此对抗钓鱼攻击。另一方面，我们在参考文献[2]中所讨论的针对SSL的攻击，是(服务器)呈现给用户的是一个合法的URL和网站，然而数据发送和接收的信道在窃听的威胁下并不能保证其安全性。尽管两个方案中一个是基于非SSL通信的，另一个基于SSL通信，但二者具有相同的目标：抵抗中间人攻击。我们由此觉得，通过对这些个方案的对比研究，我们或许可以找到一个可以应对所有类型钓鱼攻击的单一解决方案。

这从本质上改变了用户的使用习惯，因为它会带来手动更改密码的开销。如图3所示，用户必须向网站发出口令更改请求，根据口令更改页面的提示输入新口令。PwdHash(插件)然后将(用户)输入的口令与服务器的URL一起做哈希运算，并将哈希值提交给服务器。这样一来，服务器存储的(用户)口令就成了(用户)输入的口令与服务器的URL的哈希值。对于(用户会访问的)所有网站，这个过程必需一直重复。

再加上如果用户不小心把口令忘了并且请求更换一个口令，这种情况也会对用户造成不便。在(用户发出)一个新口令请求后，服务器通过邮件发送给用户一个新口令。现在正如图4所示，用户的浏览器安装了会将用户(新)口令与(服务器)域名一起做哈希运算的插件(即PwdHash)。同样当服务端需要鉴别用户时，被哈希过的口令就会被呈交给服务器，正如图3中所描述的手动更改口令(的过程)一样。如此一来，当用户输入新口令时，PwdHash插件将之做哈希运算，服务器收到一个哈希值。然而服务端存储的口令并未经过这一手动更改过程，就会导致验证失败。

除了(以上)这些明显的限制，对于网站所有者来说，PwdHash方案还有另一个局限性。由于用户口令与网站的URL一起做哈希运算，网站的URL就不能轻易改变，因为这会导致(用户的正确输入与)网站存储的哈希值不匹配。我们必须谨记，为了防止内部攻击者，网站会存储口令的哈希值而非原始的明文口令。反之，对于(银行站点的)PKI证书来说，我们并不期望它如同银行站点的URL一般频繁地改变。这就使得我们的解决方案对网站来说，比PwdHash方案更易实现。

鉴于前文所述方案在某些使用情况下所会造成的开销与复杂性，在我们的方案中，我们采用(相应)修改服务端的方式实现。我们的方案同样会提交新口令的哈希值给服务器，归功于服务器的(相应)修改，服务器会计算新口令的哈希值，(在用户更改口令时)发送哈希值给用户并(在鉴别用户时)与收到的哈希值做比较，如果匹配成功，就授予用户访问权限。

PwdHash方案依赖于当前服务器的域名作为salt，在诸如ARP欺骗等攻击手段中，尽管用户在地址栏输入了一个真实的URL，用户依然会被重定向到恶意网站。在这种情况下，由于用来作为salt的域名是真实的，钓鱼者获得口令(与域名)的哈希值后可以在原始的(真实的)网站上使用。与之不同，我们建议的方案在哈希运算中用来作为salt的是SSL证书的参数，例如证书的数字指纹或者公钥。由于中间人使用伪造的自签名证书代替(真实网站的)原始证书，因此(中间人获得的)(用户)通行证的哈希值并不能(原始网站上)重用。

最后，参考文献[2]中提到，允许用户不用安装插件，转而通过提供一个可以生成口令哈希值的网页来使用口令哈希功能。(我们说)这个主意为钓鱼者(进行攻击)开辟了一个新途径，因为钓鱼者可以生成一个该网页的副本来获取明文口令，(显然)该明文口令可以在原始网站上使用。

四、网络钓鱼的完整解决方案

在以上观察的基础上，我们可以得出结论，一个特定的解决方案对钓鱼攻击来说是不够的。因此，我们建议使用多个启发式的方案来检测和减少钓鱼攻击。大部分的解决方案以黑名单法作为基础来检测钓鱼网站，然而，在网站的建立和其被报道为钓鱼网站之间总是存在一个时间差。在这一章中，我们提出了一个不依赖于一个黑名单，也不依赖于任何第三方组织的减少钓鱼攻击的可行方案。

在参考文献[4]中，我们谈到了向网站提交随机化的通行证，这看上去很简单但确实可行。我们的这个方法将会迫使钓鱼者实时地进行他的攻击，因为一旦(用户接到)通行证失效的报告后，用户就会更改他的通行证。此外，钓鱼者为了绕开这一解决方案会被迫成为中间人。充分认识到这种情况，我们综合本文提出的解决方案与参考文献[4]中提出的PhishGuard一起来更有效地检测和减少钓鱼攻击。在这样的综合解决方案中，会(首先)检测网站是否为钓鱼网站，检测会给出一个固定(格式)的答复。如果钓鱼网站同时还采用了中间人方式(访问原始网站)，那么它(本文所提出的插件)会将口令与SSL证书一起做哈希运算并将哈希值提交给网站。在第一种情形中，我们可以成功地检测出钓鱼网站，而在第二种情形中，我们可以减少钓鱼攻击。

PwdHash方案对于抵御没有使用SSL证书的中间人攻击还是十分有效的。然而，(美中不足的是)它在一定程度上改变了用户的使用习惯。

致谢

作者们想要对摩托罗拉印度研究所和班加罗尔(Bangalore)国际信息技术学院对本项研究的支持表达谢意。本文作者之一的Subir Saha在加入诺基亚西门子通信公司之前曾在摩托罗拉印度研究所工作。

参考文献

[1] http://www.gartner.com/it/page.jsp?id=936913

[2] Blake Ross, Collin Jackson, Nick Miyake, Dan Boneh, John C Mitchell, “Stronger Password Authentication Using Browser Extension”, Proceedings of the 14th Usenix Security Symposium, 2005.

[3] Min Wu, Robert C. Miller, Simson L. Garfinkel, “Do Security Toolbars Actually Prevent Phishing Attacks?”, Conference on Human Factors in Computing Systems, 2006.

[4] Yogesh Joshi, Samir Saklikar, Debabrata Das, Subir Saha, “PhishGuard: A Browser Plug-in for protection from Phishing”, IEEE COMSOC sponsored 2nd International Conference on Internet Multimedia Services Architecture and Application (IMSAA-08), 10-12th December, 2008, Bangalore, India.

[5] http://en.wikipedia.org/wiki/Two-factor_authentication

[6] http://www.ietf.org/rfc/rfc3280.txt

[7] http://www.antiphishing.org/reports/apwg_report_H2_2008.pdf

[8] htttp://www.wlanbook.com/wifi-phishing/