由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。大家有什么问题可以点击查看原文评论区一起讨论呀。