竊聽風暴： Android平臺https嗅探劫持漏洞

0x00 前言

---

去年10月中旬，騰訊安全中心在日常終端安全審計中發現，在Android平臺中使用https通訊的app絕大多數都沒有安全的使用google提供的API，直接導致https通訊中的敏感資訊洩漏甚至遠端程式碼執行。終端安全團隊審計後發現，騰訊部分產品及選取的13款業界主流app均存在此漏洞。

此外，透過這個漏洞，我們發現了國內整個行業處理安全問題存在諸多不足，例如安全情報滯後、安全警告未得到應有的重視、安全行業缺乏良性的溝通環境等等。騰訊安全中心希望透過TSRC這個平臺，跟業界同行和白帽子共同探討、共同提高，打造一個良性的安全生態環境，提升自己產品的安全性的同時也給我們的使用者帶來更好的安全保障。

0x01 原理分析

---

在google的官方文件中，詳細給出了若干種Android平臺中使用https的方法。開發小夥伴在使用了這些程式碼開發測試自己產品的https功能時，會發現發生很多種型別的https異常，相信不少有經驗的白帽子也遇到過類似的問題。簡單來說，根本原因是google的API會檢查https證照進行合法性。而開發或者測試環境的https證照，基本上都無法透過合法性檢查。

API的檢查內容包括以下4方面的內容：

1. 簽名CA是否合法；
2. 域名是否匹配；
3. 是不是自簽名證照；
4. 證照是否過期。

一旦發現任何異常，則會終止請求並丟擲相應的異常。那小夥伴們在產品開發或者測試時怎麼辦呢？終端安全團隊審計後發現，絕大多數產品都採用了覆蓋google預設的證照檢查機制（X509TrustManager）的方式來解決這個問題。一個很典型的解決方案如下所示：

相信許多白帽子看到這段程式碼，已經發現問題在哪裡了：覆蓋預設的證照檢查機制後，檢查證照是否合法的責任，就落到了我們自己的程式碼上。但絕大多數app在選擇覆蓋了預設安全機制後，卻沒有對證照進行應有的安全性檢查，直接接受了所有異常的https證照，不提醒使用者存在安全風險，也不終止這次危險的連線。實際上，現在所有的網頁瀏覽器，都會對這類https異常進行處理並提醒使用者存在安全風險，一個典型的提醒如下圖所示，相信不少小夥伴都曾經見到過這類提醒頁面吧。

類似的問題，還有證照域名檢查（HostnameVerifier）部分，情況和上面說到的及其類似，因此不再贅述。

0x02 惡意場景

---

想要利用這個漏洞進行攻擊，我們需要能夠進行流量劫持，去截獲並修改https握手時資料包：將握手時的伺服器下發的證照，替換成我們偽造的假證照。隨後，全部的https資料都在我們的監控之下，如果需要，甚至可以隨意篡改資料包的內容。下面我們看看典型的惡意場景。

1. 偽造公眾wifi進行劫持

某日，一名駭客帶著他那臺裝滿了“武器”的筆記本，啟用了早已準備好的aircrack，靜靜的在星巴克坐了一個下午，夕陽西下，駭客握著一杯星巴克咖啡，消失在人群中，深藏功與名。隨後，下午在星巴克進行過網上購物的人都發現，自己銀行卡中所有的現金被無聲無息的轉走了。這並不是危言聳聽，本文探討的這個漏洞，完全就能夠做到這個效果。小夥伴們參考下圖我們審計時發現的某app信用卡繫結的https漏洞，所有的信用卡資訊（卡號，有效期，CVV，密碼，驗證碼）全部洩漏。有了這些資訊，盜走你的現金有什麼難度？

從技術層面講，使用成熟的wifi偽造工具（如aircrack），駭客能夠製造出和星巴克官方一摸一樣的wifi訊號。SSID，MAC地址，路由引數，統統都可以偽造。對於普通使用者而言，根本沒法分清楚眼前的wifi是星巴克還是猩巴克。

enter link description here

2013臺灣駭客大會中，主辦方建立的wifi“綿羊牆”（即透過偽造的wifi收集周圍人的密碼明文），旨在提醒人們注意公眾wifi的安全性。整個會議過程中，它抓到了很多密碼明文，其中不乏像phpMyAdmin的管理密碼（如下圖）。

所以，小夥伴們，在不可信的wifi環境中，千萬別做敏感操作。或者，乾脆就不使用不信任的app。

2. 都會網路、DNS等其他形式的流量劫持

相比而言，偽造wifi是比較容易實施的流量劫持方案。而都會網路出口的流量劫持、DNS請求劫持、路由鏈路劫持等攻擊形式雖然相對困難，一旦成功實施，其影響將會是災難性的。大家還記得2010年伊朗駭客的那次dns劫持攻擊嗎？假如配合上我們今天所討論的https漏洞，會造成怎麼樣災難性的後果？

0x03 漏洞現狀

---

為了解此漏洞的業界現狀，我們選取了13款使用https通訊的Android app進行分析，這些app全部來自業內大公司。分析結果顯示全部的13款app都存在上文描述的敏感資訊洩漏漏洞。而洩漏的資訊中，密碼明文，聊天內容，信用卡號，CVV號隨處可見。我們甚至還發現某些app的自動升級過程中使用的https通訊存在同樣的問題，劫持流量後替換升級包的url後，該app會下載惡意的升級包並自動升級，直接造成了遠端程式碼執行。

我們相信，業界絕大多數使用https的app都存在類似的漏洞。在發現此漏洞後，我們已經第一時間將漏洞的技術細節同步給國家網際網路應急中心(CNCERT)以及發現存在此漏洞的友商。

0x04 後記

---

我們在發現、修復、溯源此次漏洞的過程中，發現了國內整個行業處理安全問題存在諸多不足。

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在此也呼籲業界同行放下公司、組織之間的隔閡，為了建立一個良好的溝通環境而共同努力。

國內安全行業任重而道遠，騰訊安全中心跟整個行業一起，我們在路上。

0x05 相關連結

---

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

原文來自：【2014-02-24】竊聽風暴： Android平臺https嗅探劫持漏洞