0x00 背景

---

最近WormHole這個洞炒的比較火，今天看了幾篇漏洞分析文章，都很詳盡，筆者在這裡再補充一些發現。

筆者在10月初就發現了百度地圖的這個漏洞，並報給了BSRC得到確認，但與瘦蛟舞，蒸米等研究人員出發點不同，筆者並沒有從SDK的角度出發去發掘出更多的使用moplus這個庫的app，而是從功能性的角度出發，以地圖類應用作為切入點，嘗試去發現一些問題。雖說沒有發現那麼多存在漏洞的app，但好在也有一些發現。

0x01 百度地圖

---

Wormhole的漏洞報告出來後，很多圈內人士針對“後門還是漏洞”的問題產生了激烈的討論，微博、知乎上各種聲音。

一個事物的出現必然有他的原因，一個應用為什麼要在手機上開放一個埠呢？百度地圖為什麼在修復漏洞依然還開著40310這個埠？可見這個埠存在自然有其存在道理，於是開始進一步分析。

用Chrome模擬手機（Nexus 5）訪問www.baidu.com，在請求包裡明顯看到有訪問http://127.0.0.1:40310/getsearchboxinfo?xxxxxxx的資料包，心中一驚，這不就是wormhole的一個利用麼？

難道百度開放一個埠就是為了能在web網頁裡訪問一下？一次偶然的發現，訪問搜狗網址導航也出現了http://127.0.0.1:40310/getcuid?xxxxxxx之類的資料包，看來除了百度還有其他的地方在“利用這個漏洞”。

幾番試驗，筆者又在模擬手機在其他幾個網站發現了同樣現象，莫非這些網站都知道這個漏洞？幾番研究後，最終鎖定了源頭——百度統計。

百度統計的指令碼是hm.js，而hm.js載入了一個html: http://boscdn.bpc.baidu.com/v1/holmes-moplus/mp-cdn.html

這個html又載入了一個js: http://static1.searchbox.baidu.com/static/searchbox/openjs/mp.js

就是這個js中一段程式碼發出了對本地埠的請求，檢視程式碼不難發現，該指令碼對6259和40310這兩個埠都發出了請求，這也正好印證了wormhole漏洞為啥固定開闢了這兩個埠。

綜上，不難發現百度開放6259和40310是為了百度統計服務的，但目前發現的情況也只是getcuid、getsearchboxinfo之類一些簡單的資訊，至於為什麼在這個介面上實現獲取所有安裝包資訊、寫通訊錄、任意上傳下載檔案等就不得而知了。但毋庸置疑，想要利用這些介面只需在百度統計指令碼里加幾行程式碼就可以了，只是現在未發現利用的證據。所以，至於是漏洞還是後門，筆者不作評價。

0x02 高德地圖

---

仔細看上邊百度的分析，不難得出結論，一個應用開放一個埠，本質上是為了web頁面和app本身達到某種互動。既然百度地圖有問題，那麼其他地圖類應用呢？

筆者先前看到烏雲上有一個關於高德地圖的漏洞http://wooyun.org/bugs/wooyun-2015-0114241，原理和百度這個漏洞類似，也是開放了一個6677埠，那麼高德是怎麼修復這個洞的呢？

研究發現高德採用驗證http_referer的方法，對比之前的漏洞發現高德把http_referer白名單由java層放到了native層

在驗證http_referer時，高德竟然用了contains()這個函式去遍歷，簡直暴力啊

由此可見高德的修復並不徹底，一是contains()很容易被邏輯繞過，二是http_referer很容易偽造，當然高德地圖的最新版本又做了一些改動，但不管怎麼樣修復，高德還是保留著6677這個埠。

這不禁令人生疑，究竟這個埠有什麼用？在高德未修復漏洞時，筆者開發了一個exp，發現這個漏洞可以得到使用者的位置資訊。

我們仍然用Chrome模擬手機進行測試，訪問http://amap.com，發現了對本地6677埠的請求，其目的是為了獲取使用者的地理位置資訊。

0x03 思考

---

1. Wormhole究竟該如何定義？

   顯然出現這種型別漏洞的不僅僅是百度系app，也不止是moplus這個SDK，筆者認為wormhole應重新定義為那些因開放埠導致的漏洞。

   另外，目前列出的一些wormhole影響列表只是用了簡單的靜態掃描去匹配moplus的特徵，事實上部分app僅僅是包含了這個庫但沒有實現，需要動態執行驗證。

2. 怎樣做到安全的開放埠？

   驗證http_referer、remote-addr等顯然不可靠

   埠隨機？如何保證web頁能確切訪問？（facebook安卓版）

   SSLSocket?

3. Web頁面和app之間有必要通訊麼？

   開放埠不同於傳統的client-server結構，傳統的server端是透明的，但app上實現的server容易被逆向出關鍵邏輯，最終通訊機制還是會被破解。

   Web頁用一個token去訪問app，app拿這個token進行伺服器驗證，然後再判斷是否把敏感資料返回給web頁？

4. 如何批次的檢測這種開放埠的漏洞？

   靜態檢測ServerSocket等API? 部分app只是包含了一些API，但是沒有到該部分程式碼的執行路徑。

   動態檢測？部分app在特定情況下才會開放埠，如豌豆莢在插入USB後才會開放埠。

Wormhole之後還有很多地方值得我們挖掘和研究，微博：m4bln，歡迎交流探討！