Android漏洞解析之旅---WebView的跨域漏洞分析和應用被克隆問題情景還原(免Root獲取應用沙盒數據)

一、前言

去年年底支付寶的被克隆漏洞被爆出,無獨有偶就是騰訊乾的,其實真正瞭解這個事件之後會發現,感覺是針對支付寶。因爲這個漏洞找出肯定花費了很大勁,主要是因爲支付寶的特殊業務需要開啓了WebView的跨域訪問功能,導致了這個問題,其實Google官方的Android早期版本這個功能默認是開啓的的確是個漏洞,但是最後的版本都默認關閉了,除非應用自己業務需要就開啓。而支付寶的口令紅包是利用了WebView進行操作的。同時開啓了這個功能,騰訊應該是研究了很久的支付寶代碼才分析出來的。不過就在過年前幾天,阿里也爆出了騰訊微信的此類問題。其實現在很多app因爲特殊業務需求會手動打開這個功能。但是這個功能開啓的確有一定風險,而且非常嚴重。當然也不一定需要關閉這個功能,可以在WebView打開的時候做url安全檢查也可以。後面分析這個漏洞就知道了。

當然本文不會針對支付寶問題來說這個問題,因爲沒必要而且支付寶也修復了,本文的目的在於把這個漏洞問題解釋清楚,所以本文就自己寫案例來介紹一下即可。主要包括服務端和客戶端,客戶端大家都知道不多說了,服務端之前我開發過JavaWeb,所以弄起來比較簡單,這裏不給出詳細步驟。首先我們大致瞭解一下支付寶那個事件,支付寶有口令紅包,在網頁中會跳轉到支付內部的WebView頁面,這個主要利用了Android中自帶的Activity啓動協議scheme:

然後可以在網頁html中通過鏈接app://www.wjdiankong.cn這樣的形式打開我們的應用到這個Activity頁面中。

 

二、漏洞情景還原

第一、構建客戶端項目

下面就開始搭建構造案例項目,首先來構建一個客戶端程序:

這裏最主要的就是WebView這個Activity類,因爲後面我們通過系統瀏覽器打開一個頁面,通過協議鏈接打開跳轉到這裏:

這裏我們內部是一個WebView,爲了驗證問題,就手動打開跨域訪問開關,有兩個方法可以操作。通過測試發現這兩個方法隨便打開一個都是可以復現問題的。然後就是通過跳轉過來的鏈接攜帶想用WebView打開的url地址,一般這個地址就是包含惡意功能的網頁,這裏肯定就是利用跨域問題,把案例應用的沙盒數據的上傳到指定服務器中。

 

第二、構建服務端項目

好了,客戶端的項目構建成功了,下面就要構建服務端程序了,首先我們肯定要有一個可以讓客戶端瀏覽器打開的開始頁面,然後就是接受惡意頁面利用跨域問題獲取到沙盒數據上傳的接口,因爲我之前弄過JavaWeb開發,所以操作起來比較簡單,去Eclipse官網下載一個EclipseEE工具,然後新建一個工程即可:

點擊新建,然後選擇動態web項目:

我這裏之前已經配置的tomcat目錄了,首次會提示你選擇服務器tomcat的目錄,這個簡單直接去apache官網下載一個壓縮包,然後解壓到本地目錄即可。繼續下一步直接完成:

默認是用Servlet作爲業務邏輯處理功能的,比如接受客戶端的get和post數據請求和下發功能的,然後就是全局的路徑配置文件web.xml這個文件至關重要,當然還需要一個可以在客戶端瀏覽器打開的頁面openapp_up.html,這裏我們只關心這個頁面,另外一個頁面先不管。然後還需要修改配置文件web.xml:

這裏需要把編寫邏輯的servlet配置路徑訪問即可。這裏配置的路徑是/fourborther/cloneApp,然後在來看看提供客戶端瀏覽器打開的openapp_up.html頁面內容:

這裏看到就用一個鏈接,採用協議app://www.wjdiankong.cn打開我們之前客戶端定義的MyWebViewActivyt頁面,並且會帶一個參數也就是惡意頁面給內部的WebView加載,這個惡意頁面內部就實現了本地沙盒數據的獲取和上傳功能,因爲這個WebView已經開啓了跨域訪問功能了,所以惡意頁面內部就可以從file域到http域的數據傳遞。

注意:這裏有個巨大的坑,導致我在這裏耽誤了兩三天的時間,就是這裏的惡意頁面必須在手機本地,最好是sdcard目錄下,不能在服務端,開始的時候我把惡意頁面也放在了服務端,最後惡意頁面中的跨域功能死活是不成功的,必須放在本地sd下面,所以我們還需要把惡意頁面放到sd卡下面。

瀏覽器自動下載文件問題說明

說到這裏得插播一個信息了,就是可以看到騰訊公佈這個漏洞的時候,說到一個細節,就是他其實還需要藉助Chrome的一個漏洞,就是可以自動下載保存一個文件到sd卡的目錄下,這個漏洞就是設置了頭部信息:

我們這裏新建一個AutoDown.jsp功能,然後再內部添加這兩行java代碼,在去手機端用Chrome瀏覽器訪問會發現:

就會提示你是否下載這個文件,點擊下載就將上面的print內容保存到本地 /SD/Download/cloneapp_up.html 中了:

而對於其他瀏覽器就不是這個目錄了,因爲瀏覽器會修改這個保存路徑,比如360瀏覽器的路徑是:

所以這裏會看到,如果想把這個惡意頁面弄到sd卡下面,藉助這個瀏覽器下載功能,還需要用戶授權,做不了靜默的。所以會看到這個操作是上面漏洞問題復現的前提,當然只要能把這個惡意頁面弄到本地就好,還有其他方式都可以。但是這種方式看來最靠譜,因爲網頁很多可以利用的頁面,我們只要做個釣魚頁面,很多小白用戶都會選擇下載的。

好了說了很多了,繼續回來我們的主題,上面已經介紹了把惡意頁面通過瀏覽器會下載到本地的,然後把路徑攜帶給有問題漏洞的案例應用利用WebView打開,下面就來看看這個惡意頁面內部到底是如何跨域訪問沙盒數據的:

其實這個惡意頁面內容是本文的重點,這裏利用ajax先訪問本地的沙盒數據內容,也就是用file協議,我們知道有很多域和協議的,本地域file大家都知道可以在瀏覽器中利用這個協議打開本地文件夾,比如:

而且有很多同學好奇uri和url的區別,這裏就可以看出來,url專指網絡協議,而uri包括所有的域協議,只要類似於這樣的格式xxx://xxx.xxx等。所以這裏看出url是uri的子集,所以這裏因爲WebView開啓了跨域功能,所以利用ajax藉助file協議就可以訪問到本地沙盒數據,而應用自己訪問自己的沙盒數據也是可以的,拿到數據時候就在上傳到服務器中,接下來看看服務器接受代碼:

這個代碼從網上拷貝的,就是接受文件上傳功能,在post方式中進行處理即可。接受惡意頁面中上傳的二進制數據,也就是應用的沙盒數據。然後我們把服務端項目運行起來:

在控制檯看到這樣的信息表示成功啓動服務器了:

然後我們在瀏覽器中訪問頁面看看是否成功:

服務器tomcat默認端口就是8080,看到成功了,爲了能夠讓手機端訪問成功,我們需要把電腦和手機連接在同一個網段,然後獲取電腦的ip地址,把localhost換成ip地址即可在手機端瀏覽器訪問了。

 

三、漏洞攻擊演示

到這裏其實我們把所有的項目都搭建完成了,流程有點複雜,這裏畫個圖說明一下吧:

這張圖世界獨一無二,應該很清楚的介紹了跨域漏洞問題,下面就來還原一個惡意者利用這個漏洞獲取用戶手機中應用的沙盒數據信息:小白用戶用Chrome瀏覽器瀏覽網頁,正好被被惡意者的釣魚鏈家命中了,他點擊了惡意值的頁面鏈接比如是:http://xxx.xxx.cloneapp.jsp;然後這鏈接內部會下載一個惡意html到sd卡下面,小白用戶也不知道就隨手點擊下載了,這時候惡意的html頁面就下載到sd下面了xxx.html,然後在cloneapp.jsp中還有其他鏈接可以打開有跨域漏洞的應用A,比如<a href=“app://xxx.xxx?url=file:///sdcard/Download/xxx.html>好看的,趕快點擊</a>;用戶點擊就跳轉到了A應用的WebView頁面,正好A應用的這個頁面接受url這個參數,這個需要反編譯分析A應用才知道,不然惡意者沒法傳遞參數。然後A應用就用WebView加載了sd卡的xxx.html頁面,xxx.html中包含了訪問沙盒數據並且傳到服務端中的功能。

下面就來用案例演示漏洞場景,這裏爲了方便哈,就手動把上面的惡意頁面cloneapp_up.xml直接手動放到sd卡下面了,因爲上面的AutoDown.jsp中的自動下載內容,需要寫入惡意頁面很多內容,操作太費勁了,後面給出代碼同學可以自己操作吧:

這裏通過手機的瀏覽器輸入http://192.168.253.1:8080/CloneApp/openapp_up.html頁面,其中192.168.253.1是我的電腦ip地址。你們需要自己查看替換就好。訪問這個頁面就會通過協議打開本地的案例應用,然後利用內部的WebView加載已經存在sd卡的惡意頁面cloneapp_up.html,然後cloneapp_up.html會把應用沙盒中的account.xml內容上傳到服務器中:

這是案例應用的WebView加載惡意頁面訪問到沙盒xml數據信息,服務端也成功接收到了:

這個xml值是案例客戶端程序啓動的時候寫入的用戶名和密碼:

 

四、漏洞總結

所以到這裏,我們可以看到就WebView的跨域漏洞問題就完美還原了,可以看到操作步驟還是很麻煩的,但是可以利用一個惡意釣魚頁面就把手機中的某個具備跨域漏洞的應用沙盒賬號信息上傳到服務器了,還是很恐怖的。下面就來梳理一下吧:

客戶端程序:包括一個支持鏈接協議打開的頁面,這個頁面會解析協議帶過來的一個參數url,然後內部用開啓跨域漏洞問題的WebView加載這個url字段值。鏈接協議爲:app://www.wjdiankong.cn

服務端程序:包括釣魚頁面用於客戶端用戶使用瀏覽器訪問,用戶訪問這個頁面之後就會自動下載惡意頁面html到sd卡中,並且該頁面中有一個釣魚鏈接可以協議打開客戶端的頁面把惡意頁面的地址傳遞過去。

客戶端接收到參數就用自己的WebView打開這個惡意頁面了,惡意頁面內部利用跨域把客戶端程序的沙盒數據上傳到了惡意者服務器中。

通過上面的案例流程也可以發現這個漏洞的危害性很大,惡意者只要藉助一個釣魚頁面就把手機中某個具備跨域漏洞的應用沙盒數據比如賬號信息上傳到自己的服務器了,比如支付寶就開啓了跨域漏洞功能,而且包含一個具備協議打開的頁面H5WebView,所以支付寶會被幹。的確存在這樣的問題。支付寶的沙盒數據敏感信息都會被竊取。但是我們也發現這個漏洞利用過程,惡意者必須先分析客戶端程序:惡意者在操作之前必須先要反編譯案例應用分析他的沙盒數據結構(數據庫名,xml名等),以及支持協議打開的WebView頁面傳遞的參數信息,不然是沒法操作的。所以騰訊爆出支付寶的這個問題,肯定反編譯支付寶研究了他的代碼邏輯。

上面跨域漏洞就分析完了,其實說白了就是因爲應用使用WebView的時候,因爲特殊業務手動開啓了跨域功能:

mWebView.getSettings().setAllowUniversalAccessFromFileURLs(true);
mWebView.getSettings().setAllowFileAccessFromFileURLs(true);

跨域就是從file本地域到網絡的跨接這麼理解。本身ajax是不支持跨域訪問,所謂的跨域是指域名不一樣就是跨域,比如http://aaa.bbb.com到http://bbb.aaa.com就是跨域操作,而這裏看到不僅域名協議都不一樣,跨的有點大了。

 

五、應用克隆問題

那麼這個漏洞和支付寶的應用克隆技術有什麼關係呢?什麼叫克隆技術呢?其實上面我們看到已經把應用的沙盒賬號信息都弄到自己的服務器了,那麼惡意者在自己的設備在去自己的服務器獲取這個賬號信息,然後替換同應用的沙盒信息,不就實現了應用克隆吧,惡意者把不知道在地球的哪個地方的人的同一個應用的賬號信息給克隆到自己的同一個應用賬號中。這個過程有一個小問題就是惡意者如何把服務器的賬號信息同步到自己的應用中呢?其實我們看騰訊的演示視頻並沒有看懂怎麼操作的?我原想着把上面的file和http操作反過來,惡意者只需要在自己的設備瀏覽器打開一個頁面實現逆向操作,把服務端的數據在跨域同步到本地。但是我操作失敗了。不過沒關係,因爲數據已經到了惡意者的服務器中了,想克隆同步就很簡單了,比如惡意者可以把手機root了,然後寫個程序先去自己服務器獲取數據,然後藉助root權限強制把數據寫入到同一個應用中,這樣也可以實現克隆了。惡意者不在乎root等操作。他在意的是能夠克隆成功就好。

 

本文的目的只有一個就是學習逆向分析技巧,如果有人利用本文技術進行非法操作帶來的後果都是操作者自己承擔,和本文以及本文作者沒有任何關係,本文涉及到的代碼項目可以去編碼美麗小密圈自取,歡迎加入小密圈一起學習探討技術

 

六、總結

本文通過複雜的操作把WebView的跨域漏洞情景完美還原復現了,整個操作可以看到非常麻煩,復現這個漏洞付出很多,只是爲了能夠給你們講解清楚。自己在項目中用到WebView一定要注意這個操作。

 

《Android應用安全防護和逆向分析》

點擊立即購買:京東  天貓  

更多內容:點擊這裏

關注微信公衆號,最新技術乾貨實時推送

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章