窃听风暴：Android平台https嗅探劫持漏洞

转：http://www.freebuf.com/articles/terminal/26840.html

0×0 前言

    去年10月中旬，腾讯安全中心在日常终端安全审计中发现，在Android平台中使用https通讯的app绝大多数都没有安全的使用google提供的API，直接导致https通讯中的敏感信息泄漏甚至远程代码执行。终端安全团队审计后发现，腾讯部分产品及选取的13款业界主流app均存在此漏洞。

    此外，通过这个漏洞，我们发现了国内整个行业处理安全问题存在诸多不足，例如安全情报滞后、安全警告未得到应有的重视、安全行业缺乏良性的沟通环境等等。腾讯安全中心希望通过TSRC这个平台，跟业界同行和白帽子共同探讨、共同提高，打造一个良性的安全生态环境，提升自己产品的安全性的同时也给我们的用户带来更好的安全保障。

0×1 原理分析

    在google的官方文档中，详细给出了若干种Android平台中使用https的方法。开发小伙伴在使用了这些代码开发测试自己产品的https功能时，会发现发生很多种类型的https异常，相信不少有经验的白帽子也遇到过类似的问题。简单来说，根本原因是google的API会检查https证书进行合法性。而开发或者测试环境的https证书，基本上都无法通过合法性检查。

API的检查内容包括以下4方面的内容：

1.签名CA是否合法；
2.域名是否匹配；
3.是不是自签名证书；
4.证书是否过期。

    一旦发现任何异常，则会终止请求并抛出相应的异常。那小伙伴们在产品开发或者测试时怎么办呢？终端安全团队审计后发现，绝大多数产品都采用了覆盖google默认的证书检查机制（X509TrustManager）的方式来解决这个问题。一个很典型的解决方案如下所示：

      
    相信许多白帽子看到这段代码，已经发现问题在哪里了：覆盖默认的证书检查机制后，检查证书是否合法的责任，就落到了我们自己的代码上。但绝大多数app在选择覆盖了默认安全机制后，却没有对证书进行应有的安全性检查，直接接受了所有异常的https证书，不提醒用户存在安全风险，也不终止这次危险的连接。实际上，现在所有的网页浏览器，都会对这类https异常进行处理并提醒用户存在安全风险，一个典型的提醒如下图所示，相信不少小伙伴都曾经见到过这类提醒页面吧。

    类似的问题，还有证书域名检查（HostnameVerifier）部分，情况和上面说到的及其类似，因此不再赘述。

0×2 恶意场景

    想要利用这个漏洞进行攻击，我们需要能够进行流量劫持，去截获并修改https握手时数据包：将握手时的服务器下发的证书，替换成我们伪造的假证书。随后，全部的https数据都在我们的监控之下，如果需要，甚至可以随意篡改数据包的内容。下面我们看看典型的恶意场景。

1.伪造公众wifi进行劫持

    某日，一名黑客带着他那台装满了“武器”的笔记本，激活了早已准备好的aircrack，静静的在星巴克坐了一个下午，夕阳西下，黑客握着一杯星巴克咖啡，消失在人群中，深藏功与名。随后，下午在星巴克进行过网上购物的人都发现，自己银行卡中所有的现金被无声无息的转走了。这并不是危言耸听，本文探讨的这个漏洞，完全就能够做到这个效果。小伙伴们参考下图我们审计时发现的某app信用卡绑定的https漏洞，所有的信用卡信息（卡号，有效期，CVV，密码，验证码）全部泄漏。有了这些信息，盗走你的现金有什么难度？

    从技术层面讲，使用成熟的wifi伪造工具（如aircrack），黑客能够制造出和星巴克官方一摸一样的wifi信号。SSID，MAC地址，路由参数，统统都可以伪造。对于普通用户而言，根本没法分清楚眼前的wifi是星巴克还是猩巴克。

    2013台湾黑客大会中，主办方建立的wifi“绵羊墙”（即通过伪造的wifi收集周围人的密码明文），旨在提醒人们注意公众wifi的安全性。整个会议过程中，它抓到了很多密码明文，其中不乏像phpMyAdmin的管理密码（如下图）。

    所以，小伙伴们，在不可信的wifi环境中，千万别做敏感操作。或者，干脆就不使用不信任的app。

1.城域网、DNS等其他形式的流量劫持

    相比而言，伪造wifi是比较容易实施的流量劫持方案。而城域网出口的流量劫持、DNS请求劫持、路由链路劫持等攻击形式虽然相对困难，一旦成功实施，其影响将会是灾难性的。大家还记得2010年伊朗黑客的那次dns劫持攻击吗？假如配合上我们今天所讨论的https漏洞，会造成怎么样灾难性的后果？

0×3 漏洞现状

    为了解此漏洞的业界现状，我们选取了13款使用https通讯的Android app进行分析，这些app全部来自业内大公司。分析结果显示全部的13款app都存在上文描述的敏感信息泄漏漏洞。而泄漏的信息中，密码明文，聊天内容，信用卡号，CVV号随处可见。我们甚至还发现某些app的自动升级过程中使用的https通讯存在同样的问题，劫持流量后替换升级包的url后，该app会下载恶意的升级包并自动升级，直接造成了远程代码执行。

    我们相信，业界绝大多数使用https的app都存在类似的漏洞。在发现此漏洞后，我们已经第一时间将漏洞的技术细节同步给国家互联网应急中心(CNCERT)以及发现存在此漏洞的友商。

0×4 后记

    我们在发现、修复、溯源此次漏洞的过程中，发现了国内整个行业处理安全问题存在诸多不足。

1.安全情报滞后

      在溯源过程中，我们发现这类型的漏洞其实从Java时代就已经存在，但一直未广泛传播，随后随着dalvikvm Java虚拟机的使用踏入Android平台，随着Android的普及传播的越来越广。国外在CCS`12中出现第一次系统的讨论Android平台的此漏洞[1]， 2012年9月《程序员》刊登的《Android软件安全开发实践》[2]中首次提到此类安全问题。google官方的API文档[3]中也曾提醒，自定义的TrustManger一定要小心实现，否则会引起严重的安全问题。
    但可惜的是，这些关于的讨论并未得到我们和业界同行应有的重视，即使在一年后的今天，国内的app依然大面积的存在这类漏洞。CCS`12报告中指出，google play中17.3%使用https的app存在这类安全漏洞。而据腾讯安全中心审计相关同事的统计，国内app中存在这类安全漏洞的比例，远远高于国外。

2.安全行业缺乏良性的沟通环境

    其实，不管是国内还是国外，都有许多实力超群的白帽子，尽全力在为安全的互联网环境贡献自己的力量，但他们的声音，常常淹没在互联网信息的海洋里。个人的力量和影响终归是有限的，广大白帽子需要一个平台来发出他们的声音，使他们发现的安全问题得到应有的重视，也使这些安全问题尽快得到修复。TSRC正是这样一个良性沟通平台的尝试，诚然，我们现在做得还不够，但是我们一直在为了这个目标而努力。

    腾讯安全中心有责任也有义务，给广大用户一个安全的互联网环境。以后不管是安全情报还是安全团队发现的安全问题，我们都会第一时间同步到国家互联网应急中心(CNCERT)及受影响的友商，帮助业界同行尽快修复安全问题。TSRC在此也呼吁业界同行放下公司、组织之间的隔阂，为了建立一个良好的沟通环境而共同努力。
    国内安全行业任重而道远，腾讯安全中心跟整个行业一起，我们在路上。

0×5 相关链接

[1] http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf

[2] http://www.programmer.com.cn/15036/

[3] http://developer.android.com/training/articles/security-ssl.html

转：https://jaq.alibaba.com/blog.htm?id=60

Android HTTPS中间人劫持漏洞浅析

1. Android HTTPS中间人劫持漏洞描述

      在密码学和计算机安全领域中，中间人攻击 （ Man-in-the-middle attack，通常缩写为MITM ）是指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。在中间人攻击中，攻击者可以拦截通讯双方的通话并插入新的内容[1]。
      Android HTTPS中间人攻击漏洞源于：1没有对SSL证书进行校验；2没有对域名进行校验；3. 证书颁发机构(Certification Authority)被攻击导致私钥泄露等。攻击者可通过中间人攻击，盗取账户密码明文、聊天内容、通讯地址、电话号码以及信用卡支付信息等敏感信息，甚至通过中间人劫持将原有信息替换成恶意链接或恶意代码程序，以达到远程控制、恶意扣费等攻击意图。
      在乌云漏洞平台上，有大量存在HTTPS证书不校验漏洞，例如国内绝大部分Android APP存在信任所有证书漏洞[2]、亚马逊最新官方android版存在一处信任所有证书漏洞[3]、Yahoo雅虎在国内访问遭遇SSL中间人攻击[4]、携程旅游网最新android客户端https未校验证书导致https通信内容完全被捕获[5]。

2.  Android HTTPS中间人攻击漏洞影响范围

      Android系统

3. Android HTTPS中间人攻击漏洞详情

1) 中间人攻击漏洞位置:

      X509TrustManager 、HostnameVerifier 、 setHostnameVerifier (X509HostnameVerifier hostnameVerifier)

2) 漏洞触发前提条件：

      自定义的X509TrustManager不校验证书；
      或实现的自定义HostnameVerifier不校验域名接受任意域名；
      或使用setHostnameVerifier (ALLOW_ALL_HOSTNAME_VERIFIER)；

3) 漏洞原理：

      由于客户端没有校验服务端的证书，因此攻击者就能与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。在中间人攻击中，攻击者可以拦截通讯双方的通话并插入新的内容[1]。

4. Android HTTPS中间人攻击漏洞证明

      1) 客户端不校验SSL证书（包含签名CA是否合法、域名是否匹配、是否自签名证书、证书是否过期）包含以下几种编码错误情况：

      a. 自实现的不校验证书的X509TrustManager接口的Java代码片段 (其中的checkServerTrusted()方法实现为空，即不检查服务器是否可信):

      b. 不检查站点域名与站点证书的域名是否匹配的Java代码片段:
 
      c. 接受任意域名的Java代码片段：

SSLSocketFactory sf;
……
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

      2)针对某个不校验SSL证书的客户端进行中间人攻击演示如下图所示，可通过中间人劫持获取到登录用户名和密码(该密码参数只是对明文密码进行了一次MD5)：
 

 

5. Android HTTPS中间人攻击漏洞修复建议

      1. 对SSL证书进行强校验

      出于安全考虑，阿里聚安全建议对SSL证书进行强校验（签名CA是否合法、证书是否是自签名、主机域名是否匹配、证书是否过期等），详细修复方案请参照Google官方关于SSL的安全建议[6]；

引用

[1] http://zh.wikipedia.org/wiki/%E4%B8%AD%E9%97%B4%E4%BA%BA%E6%94%BB%E5%87%BB
[2] http://www.wooyun.org/bugs/wooyun-2010-079358
[3] http://www.wooyun.org/bugs/wooyun-2010-079350
[4] http://www.wooyun.org/bugs/wooyun-2010-080117
[5] http://www.wooyun.org/bugs/wooyun-2010-081966
[6] https://developer.android.com/training/articles/security-ssl.html