QQ手機瀏覽器“蟲洞漏洞”挖掘分析全過程

0x1.引子

前段時間盤古的同學發現了QQ手機瀏覽器的“蟲洞漏洞”，在這個漏洞的挖掘分析過程中，盤古的同學和我們針對這個漏洞做過內部技術交流，我們也同步分析出了該漏洞，最終由于是盤古的同學第一個發現，所以由盤古的同學報告給騰訊。目前該漏洞已經修復，我們和大家分享一下這個漏洞的分析和挖掘全過程，供大家參考。

0x2.樣本信息

下載鏈接：http://mb.qq.com/

文件名稱：qqbrowser_6.9.2.2665_20820.apk

文件md5：64FE443F770BA9433E23D689C78DAF99

versionCode: ‘6922665’

versionName: 6.9.2.2665

云盤備份地址：https://yunpan.cn/cM8JVT39xQnhw  訪問密碼 d7d6

0x3.特征定位

查看手機所開端口發現一處可疑端口本地未校驗。

所以需要對本地所有dex文件進行掃描，看看此部分功能到底是在哪里，在做什么。

通過搜索端口號以及判定是打開Sokcet，我們確定此處地址。

即確定文件所在包為：

assets/dex/com.tencent.mtt.sniffer.jar

0x4.代碼深入

現在我們就可以繼續往下進行分析了。

我們用jeb查看一下java代碼。

既然g.b是獲取的端口8786數字，那么g類很可能就是初始化socket的類，所以我們按照代碼邏輯往下看一下這個g類，發現這里this.i的數值是new j(this.a)，而這個j類則包含很多數據。

如下圖所示：

第一個紅框是方法名，處理申請的訪問鏈接流程的。

第二個紅框是請求的網址，根據不同的請求執行不同的功能。

第三個紅框就是執行的功能，在代碼下面有很多類似結構。

這里我們先看一下/getWifiInfo這個請求。

在j.a(this.a,arg13)方法我們往后跟一下。

這里有兩處需要分析的地方，一處是數據處理，即請求訪問協議的數據的加密與解密；一處是Message的發送，即不同的請求走不同的方法分支。我們先看第一處紅框這個位置，是將數據進行處理，this.a(v2.toString)方法我們跟進去。

可以看到執行的是e.a和e.b方法，我們看到這個，一般是可以猜測到是加解密的方法。

這樣，我們就明顯的確定是通過的3des進行的加解密處理。

然后密鑰的獲取可以直接靜態分析得到。

密鑰的獲取：

l. b = b. b + h. c ;

b . b = “kM7hYp8lE69U” ;

h . c = e. b + d. f ;

e. b = “jidhlPbD9” ;

d . f = “8Pm” ;

密鑰==” kM7hYp8lE69UjidhlPbD98Pm ”

在尋找密鑰的過程中，我們發現訪問請求的數據加密，和服務器返回的數據解密，都是通過3des加密解密，然后進行Base64編碼解碼處理的。

所以我們整理一下思路，先對剛才的getWifiInfo請求進行測試模擬。

流程也就是先在本地進行8786端口轉發一下。

然后用python寫一下網絡請求即可，在上面截圖中的url大家可以直接看到。

0x5.漏洞利用

上一條測試通過之后，我們繼續往下看，有更多的協議需要分析。

我們這里可以看到，第一條getWifiInfo協議沒有判斷，直接會進行請求，而后面的請求，都是基于uuid來進行判定，如果uuid存在并且合法，那么才會進行后續請求，所以主要問題在于我們如何構造uuid并且使之合法化。

我們繼續分析代碼，也就是上圖第二個紅框標識的地方，如果uuid不是空，同時本地的一個hashmap中沒有記錄過它，那么將會往下走if的流程，所以看到這個/bind協議，我們就可以猜測，這條協議是否是綁定uuid的呢？

跟進去看一下this.a.a(arg12);

我們看到這個紅框，可以發現上文中我們在跟getWifiInfo方法的時候，也跟進去了，所以我們分析一下這個是什么意思。

經過代碼流程的跟蹤，我們到了這個類，發現這里是處理Message流程的地方。

當前bind走的是case 0，也就是this.a.b(arg5.obj);

再跟一下。

這里的是我們請求的v0_1，即需要post數據的json字符串，可以看到保證code有數值，或者qq有數值即可。

然后走this.a(“ok”，v0_1)；是正常綁定的流程，所以我們繼續跟進去。

看到這兩個紅框標識的位置，我們保證剛才傳過去的字符串包含ok，而json數據中包含上面提到的code數值，以及uuid數值即可，這就是bind的過程，即綁定uuid的過程。測試一下。

我們簡單截圖一下：

下面是請求訪問成功的截圖。

這里綁定好uuid之后，后面的請求我們按部就班地跟著分析就行，沒有什么難度了。

比如getapplist協議，getappInfo協議。

獲取手機安裝的app列表信息不算太可怕。

我們往下分析。

根據名稱，我們推測一條是下載安裝app的，另外一條是在手機上顯示對話框的。

訪問構造參數根據代碼分析一下就好，這里就不貼了。

直接發一下測試結果。

好了，這樣就測試完畢了。因為這里下載，安裝，沒有走su的流程，也就是沒有使用靜默安裝的，而是調用的系統安裝頁面，所以是上圖所示。

0x6.安全建議

1).使用RSA加密操作，對所有的請求進行RSA加密，然后本地存儲RSA公鑰進行身份驗證。

2).去除這部分命令執行功能，使用應用層的intent實現打開網頁。

3).監聽0.0.0.0的端口轉為127.0.0.1，或給相關執行動作加入用戶安全提示，需用戶允許才能打開網頁。

 

 

來自：http://appscan.#/blog/?p=165