由DeepLink攻擊切面產生的漏洞 - 網安 - 專業的網絡安全產業、社區、知識平臺

DeepLink介紹

首先大家需要了解一下什么是 DeepLink ，簡單來說， DeepLink 是一種在網頁中啟動 App 的超鏈接。點擊鏈接之后， Android 系統會按順序嘗試以下操作：

1.如果用戶指定了可以處理該 URI 的首選應用，就打開此應用。

2.打開唯一可以處理該 URI 的應用。

3.允許用戶從對話框中選擇應用。

然后就會打開應用中指定的活動。一般是在 AndroidManifest.xml 中指定 intent 過濾器，當然也只是一般來說。

      android:name="com.example.android.GizmosActivity"    android:label="@string/title_gizmos" >    "@string/filter_view_http_gizmos">       "android.intent.action.VIEW" />       "android.intent.category.DEFAULT" />       "android.intent.category.BROWSABLE" />                 http"              android:host="www.example.com"              android:pathPrefix="/gizmos" />                        @string/filter_view_example_gizmos">          android.intent.action.VIEW" />           android.intent.category.DEFAULT" />                                 example"                android:host="gizmos" />

如上代碼可以看到

http://www.example.com/gizmos和example://gizmos

都可以解析到該 activity 。

       ...      "https" android:host="www.example.com" />      "app" android:host="open.my.app" />

如上所示，這不僅僅支持https://www.example.com和app://open.my.app，還支持https://open.my.app和app://www.example.com.

URL驗證不足

該漏洞原型類似于著名的價值8500刀的Facebook app漏洞，首先我們來看一下活動注冊界面

"insecureshop" android:host="com.insecureshop"/>

可以看到，根據data，我們可以構造出insecureshop://com.insecureshop這一類的deeplink鏈接，然后再查看一下com.insecureshop.WebViewActivity類下的代碼。

首先對于

(StringsKt.equals$default(uri.getPath(), "/web", false, 2, null))該語句來說

意味著我們需要在insecureshop://com.insecureshop的基礎上，再構建上/web參數，然后后面會發現沒有進行url驗證，那么我們就可以在后面構造意圖來加載任意內容。

比如說此時構造一個insecureshop://com.insecureshop/web?url=的鏈接。

寫出POC：

"insecureshop://com.insecureshop/web?url=">click here to exploit

進行測試。

使用python搭建簡單的本地服務器

python -m http.server 8000

點擊我們的 POC 代碼。

此時點擊打開后進成功進入 webview 。

然后此時我們將poc更改

href="insecureshop://com.insecureshop/web?url=file:///sdcard/1.txt"，

查看能否打開本地文件。

不出所料也是可以成功打開。

這就是由于URL驗證不足而導致的開放重定向。

弱主機校驗

還是相同的類下，在下方還有一段添加url驗證的代碼

對于以上代碼可以分析看出，確實是驗證了url后面的內容，但是StringsKt.endsWith$default該語句表面，此時只需要后綴為insecureshopapp.com,還是可以利用deeplink鏈接進行重定向，此時只需要是attackerinsecureshopapp.com此類型的網址都有效。此處大家可以自行驗證一下嗷。100%成功率。

總結

以上總結了簡化后的兩類deeplink漏洞，主要的難點其實還是在deeplink的收集上，因為目前的app中，deeplink的protocol://hostname比較好找，但是完整的URI還是比較難拼湊的。

何牛在之前的文章中提供了5種方法：

本地搜索：

通過Mainifest文件篩選出自定義的 deeplink URL scheme，進而在本地逆向代碼中正則匹配，提取出盡可能完整的 deeplink URI，注意不要漏過所有文件。因為以經驗來看，deeplink 可能出現在 App 的Java 代碼中、Asset 目錄的資源文件 /js 中，甚至還可能出現在 so 當中；

流量監控：

對app進行抓包，利用HTTP抓包工具或者實現成burp插件監測流量中的deeplink，盡可能在app中點擊各種場景，從請求包和返回包中正則匹配出完整的deeplink；

IPC監控：

通過hook動態監測IPC通信中出現的deeplink，將Intent中的data提取出來，可以利用burp插件brida，甚至與流量監控整合；

遠程爬取：

對app Web端網頁進行爬取，篩選出deeplink。不過這種方法我沒有實踐過，只是偶爾在網頁源碼中發現過。

基于deeplink特征：

如果APP使用了一些路由分發的sdk，由于這類sdk有特定的規律，因此可以通過正則解析這類規律來獲取到完整的deeplink。以ali arouter為例，可以通過提取build Route后面的path作為deeplink URI的path。

提取build Autowired后面的name作為deeplink中的parameters。然后和第一步中獲取到的內容進行拼接，從而獲取到一個完整的deeplink。

何牛YYDS。大家有什么問題可以點擊查看原文評論區一起討論呀。