QQ登录的加密传输安全

         这几篇文章写得挺好，我整合一下吧

         安全技术团队PST有一篇文章《QQ网站登录的RSA加密传输缺陷分析》，内容大概是QQ登录密码使用了低成本的RSA进行加密传输，从而让黑客有可乘之机，使其可以通过伪造RSA密钥的方法获得QQ密码。

昨天被月光提及，并提供了一种"不传输完整加密数据"的防御方法，作为RSA的补充，加密后的数据会被截断，即使黑客掌握解密匙，也无法获得密码本身。

文中伪造的RSA密钥，将通过ARP攻击发送，这种方法已被广泛应用在木马散播上。目前国内应对ARP攻击的防御能力还十分薄弱，只要被刷得狠一些，大部分中文防御工具都会立即失效。

有人提议，既然ARP攻击，不如直接更改加密程序，跳过RSA，获得完整密码，岂不更好。这种方法，令黑客工作量大增，但上面讨论，也同时失去了效用。

作为最终办法，两篇文章都赞扬了SSL的安全性。不过，云舒的一篇《如何进行https中间人攻击》，却又提供了另一种针对SSL的方法，并且写出了实例。

综上所述，一切措施都是徒劳，用户还是会丢失Q号，听天由命吧。

 

  （一）QQ网站登录的RSA加密传输缺陷分析

           

感谢匿名人士的投递
QQ网站登录处没有使用https进行加密，而是采用了RSA非对称加密来保护传输过程中的密码以及敏感信息的安全性。 QQ是在javascript中实现整个过程的。这个想法非常新颖，但是也是存在严重缺陷的。如果被黑客利用，则可能被捕获明文密码。
分析报告如下：

Author: axis
Date: 2007-11-23
Team: http://www.ph4nt0m.org  (http://pstgroup.blogspot.com)
Corp: Alibaba B2B Corp / Infomation Security

这个想法非常新颖，详细可以参考云舒写过的 《RSA非对称加密的一些非常规应用》，地址为http://www.icylife.net/yunshu/show.php?id=471

这个原理简单描述为下：
1. 在server端生成一对RSA密钥，包括public key 和 private key
2. public key传输给客户端浏览器， 客户端浏览器用public key加密敏感数据，比如密码；加密后的密文传回给server，然后server用 private key解密。
3. 注意private key只保存在server端，而public key则分发给所有人。 由于 private key只有server知道，所以密文即使被截获了，也无法解开。

这个解决方案其实还是非常好的，至少他防住了大部分的攻击，但是为什么说它是无法替代https，是有缺陷的呢？

因为这个方案无法防止中间人攻击 （man-in-the-middle）。

攻击过程如下：
1. 攻击者通过MIM（比如arp欺骗等）劫持server与客户端浏览器之间的http包
2. 攻击者生成一对伪造的RSA密钥： fake public key/fake private key
3. 攻击者将js文件中的public key替换为fake public key，并传输给客户端浏览器
4. 客户端浏览器用 fake public key加密敏感数据，比如密码，并将加密后的数据传输给攻击者
5. 攻击者用fake private key解密，获得明文密码等
6. 攻击者用server的public key加密明文数据，并传送给server

整个过程中不会出现任何提示，而用户的明文数据则被窃取了！

而luoluo则提出来一个更邪恶的想法（顺便在这里祝luoluo今天生日快乐！），他提出可以直接将加密的介质修改。

比如，如果是用js在做加密，则修改js，如果是用flash或java applert做加密，则替换flash或applet，直接去掉这种加密机制，捕获明文密码。

那么为什么说https是不可替代的呢？ 因为当实施中间人攻击的时候，浏览器会提示证书已改变（具体参考云舒的关于https安全性的文章），这种机制是内建在浏览器里的，攻击者无力改变它。所以这种报警是非常有意义的。

而如果像QQ一样使用js进行RSA加密传输，实施中间人攻击的时候，是不会有任何提示的，一切都会在用户不知情的情况下发生。

这种情况和以前windows的RDP中间人攻击情况一样: 当使用3389端口的rdp协议登录时候，证书改变的时候没有任何提示。

而相对设计比较安全的ssh协议，ssl协议等，则都会针对证书改变做出提示，防止中间人攻击。

所 以，QQ的这个方案只能保护传输过程中一般的sniffer攻击，但是考虑到当今网络环境下，大部分的sniffer都是基于arp欺骗的，所以这种保护 机制其实是非常脆弱的。它只能对抗目前已知的arp sniffer软件，而对专门开发的替换关键字的软件，则无法有效防御。一旦这种专门针对QQ网站登录的sniffer软件被开发出来并且提供下载，灾难 就不远了。

不过这个方案还是有积极意义的，除去不能抵抗中间人攻击的缺陷外，其他方面都比较完美，特别是成本低廉。如果与https结合使用来防止中间人攻击的话，整个方案就更完美了。

之前曾与朋友戏言QQ是否会因为我这一篇文章而多花费几百万的经费去购买https证书和https硬件加速服务器，现在让我们拭目以待，看看QQ是否是真正的用户至上。

希望QQ能越做越好。

 

 

（二）网站登录的加密传输安全

          刚才看到了两篇文章，分别是“QQ网站登录的RSA加密传输缺陷分析”和“RSA非对称加密的一些非常规应用”，我这里谈一下我的一些看法。

　　我以前曾经写过一篇文章“网站的安全登录认证设计”，对于QQ登录使用RSA进行加密传输，的确是一种低成本的替代SSL的方法，因为SSL本身需要数字证书颁发机构(CA)的介入，还需要一定费用，因此对于安全程度不高的系统使用RSA加密进行“网络传输”上的加密安全也是一种选择。

　　然而，不使用SSL带来的后果就是安全性的降低，相当于网站自己当CA，自己颁发数字证书。数字证书颁发机构(CA)在互联网安全生态链中扮演一个非常重要的角色，因为CA充当可信任的第三方在验证申请者的真实身份后才颁发SSL证书。因此，CA从一定程度上保护了最终用户的信息安全，并预防了网站自己“内鬼”从中窃取用户信息的可能性。因此，使用RSA并不能完全替代SSL的作用。

　　不过如果黑客通过arp欺骗的方法伪造的RSA密钥的话，我觉得也不一定能窃取用户的密码。因为用户验证密码并非将客户端用户的密码传到服务器上进行验证，通常情况下只要客户端用户密码的“消息摘要算法（Hash function)”和服务器端的一致即可，因此，验证的方法可以这样进行：客户端将用户密码的HASH数值（MD5或者SHA1）使用服务器端生成的公钥进行RSA加密，并传输到服务器端，服务器端接收到以后，使用私钥进行解谜，解密出HASH码后和数据库中计算出的HASH码进行比较，从而进行认证。

　　这样，即使黑客使用arp欺骗窃取了用户传输的数据，也仅仅窃取了用户密码的HASH值，并不是用户的密码明文，而从密码的HASH值反推用户密码则是十分困难的，详见“密码学基础”一文，因此得到的数据也没有多大用处。

　　总的来说，增强QQ登录密码的安全强度的方法还有很多种，最安全的方法可以使用类似网上银行的USB Key进行登录验证，那样的安全性就基本达到了相当高的程度了，不过使用成本也达到很高的程度了。

 

    （三）如何进行https中间人攻击

     先说说伪造证书的方法。首先使用openssl来生成一个证书，我这里生成了一个example.crt和example.key两个，保护密码为1234。然后连接到真实的HTTPS服务器，获取真正的证书。再对开始伪造的证书进行修改，将伪造证书的几个字段改成和真实服务器的一样，增加迷惑性。

这个程序也包含在下面了，代码很短，可以自己看看，我不多描述了，主要用了X509_set_version，X509_set_serialNumber，X509_set_subject_name和X509_set_issuer_name等4个API修改的。不过比较郁闷的是windows下面编译的openssl竟然有点小问题，X509_NAME这个结构体是undefined的，写代码的时候想办法避开就好了。这样做出来的证书，开起来和真实的一样，不过公钥不同，因为如果公钥也用真是服务器的，我们没私钥那么中间人就白做了。

现在要说的就是怎么做中间人攻击了，对于一般的站点，会同时具备HTTP和HTTPS两种，所以需要在中间人的机器上监听tcp 80和tcp443，然后对数据进行转发。这一部分没什么难的，就是程序写得比较乱。本来forward等几个文件的函数可以合并到一起的，去年我就是这么做的，但是结果bug非常多。这几天突然想起对HTTPS的攻击，就把代码翻出来重写了。代码变长了很多，但是效果好了很多。唯一遗憾的是，貌似对firefox无效，不知道为什么，需要进一步分析。

我对自己登录xfocus的论坛过程做过测试，密码什么的还是能抓到的，gmail我也测试过，基本没太大的问题。附件里面是代码，编译好的程序和我的测试证书也在，不说了，代码描述吧（代码非常乱，嘿嘿）……

攻击的时候可以这样：
代码:

D:/Projects/HttpsMiM/Release>MakeCert.exe 125.208.7.30 write fake cert to 125.208.7.30.crt, use this to do the mim attack! D:/Projects/HttpsMiM/Release>HttpsMim.exe 125.208.7.30 125.208.7.30.crt POST /bbs/index.php HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shoc wave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, applicatio /msword, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms xbap, application/x-ms-application, */* Referer: https://www.xfocus.net/bbs/index.php?act=Login&do=00 Accept-Language: zh-cn Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2. .50727; .NET CLR 3.0.04506.30) Host: www.xfocus.net Content-Length: 90 Connection: Keep-Alive Cache-Control: no-cache Cookie: PHPSESSID=033eebeaf4af7c73243ff3901c70f292 act=Login&do=01&UserName=ph4_yunshu&PassWord=wrongpassword&submit=%CE%D2%D2%AA% 5%C7%C2%BDssl2 recv erro: error:00000000:lib(0):func(0):reason(0) GET /images/title.gif HTTP/1.1 Accept: */* Accept-Language: zh-cn Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2. .50727; .NET CLR 3.0.04506.30) Host: www.xfocus.net Connection: Keep-Alive Cookie: PHPSESSID=033eebeaf4af7c73243ff3901c70f292

代码下载：
http://www.icylife.net/pic/httpsmim/MakeCert.zip
http://www.icylife.net/pic/httpsmim/HttpsMim.zip