竊聽風暴:Android平台https嗅探劫持漏洞
0x0 前言
去年10月中旬,騰訊安全中心在日常終端安全審計中發現,在Android平台中使用https通訊的app絕大多數都沒有安全的使用google提供的API,直接導致https通訊中的敏感信息洩漏甚至遠程代碼執行。終端安全團隊審計後發現,騰訊部分產品及選取的13款業界主流app均存在此漏洞。
此外,通過這個漏洞,我們發現了國內整個行業處理安全問題存在諸多不足,例如安全情報滯後、安全警告未得到應有的重視、安全行業缺乏良性的溝通環境等等。騰訊安全中心希望通過TSRC這個平台,跟業界同行和白帽子共同探討、共同提高,打造一個良性的安全生態環境,提升自己產品的安全性的同時也給我們的用戶帶來更好的安全保障。
0x1 原理分析
在google的官方文檔中,詳細給出了若干種Android平台中使用https的方法。開發小夥伴在使用了這些代碼開發測試自己產品的https功能時,會發現發生很多種類型的https異常,相信不少有經驗的白帽子也遇到過類似的問題。簡單來說,根本原因是google的API會檢查https證書進行合法性。而開發或者測試環境的https證書,基本上都無法通過合法性檢查。
API的檢查內容包括以下4方面的內容:
1.
簽名CA是否合法;
2.
域名是否匹配;
3.
是不是自簽名證書;
4.
證書是否過期。
一旦發現任何異常,則會終止請求並拋出相應的異常。那小夥伴們在產品開發或者測試時怎麼辦呢?終端安全團隊審計後發現,絕大多數產品都採用了覆蓋google默認的證書檢查機制(X509TrustManager)的方式來解決這個問題。一個很典型的解決方案如下所示:
相信許多白帽子看到這段代碼,已經發現問題在哪裡了:覆蓋默認的證書檢查機制後,檢查證書是否合法的責任,就落到了我們自己的代碼上。但絕大多數app在選擇覆蓋了默認安全機制後,卻沒有對證書進行應有的安全性檢查,直接接受了所有異常的https證書,不提醒用戶存在安全風險,也不終止這次危險的連接。實際上,現在所有的網頁瀏覽器,都會對這類https異常進行處理並提醒用戶存在安全風險,一個典型的提醒如下圖所示,相信不少小夥伴都曾經見到過這類提醒頁面吧。
類似的問題,還有證書域名檢查(HostnameVerifier)部分,情況和上面說到的及其類似,因此不再贅述。
0x2 惡意場景
想要利用這個漏洞進行攻擊,我們需要能夠進行流量劫持,去截獲並修改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漏洞,會造成怎麼樣災難性的後果?
0x3 漏洞現狀
為瞭解此漏洞的業界現狀,我們選取了13款使用https通訊的Android app進行分析,這些app全部來自業內大公司。分析結果顯示全部的13款app都存在上文描述的敏感信息洩漏漏洞。而洩漏的信息中,密碼明文,聊天內容,信用卡號,CVV號隨處可見。我們甚至還發現某些app的自動升級過程中使用的https通訊存在同樣的問題,劫持流量後替換升級包的url後,該app會下載惡意的升級包並自動升級,直接造成了遠程代碼執行。
我們相信,業界絕大多數使用https的app都存在類似的漏洞。在發現此漏洞後,我們已經第一時間將漏洞的技術細節同步給國家互聯網應急中心(CNCERT)以及發現存在此漏洞的友商。
0x4 後記
我們在發現、修復、溯源此次漏洞的過程中,發現了國內整個行業處理安全問題存在諸多不足。
轉載自《騰訊安全應急響應中心》