[ByteDance] [TikTok] NotificationBroadcastReceiver导出存在任意私有组件启动结合FileProvider机制与FbSoLoader框架导致本地代码执行漏洞
2021.05.01
1.0
完整的漏洞分析与利用
wnagzihxa1n
0x00 漏洞概述
0x01 触发条件
2020.02.08
TikTok
com.zhiliaoapp.musically
14.8.3
https://www.apkmirror.com/apk/tiktok-pte-ltd/tik-tok-including-musical-ly/tik-tok-including-musical-ly-14-8-3-release/
0x02 PoC
0x03 前置知识
0x04 Root Cause
组件com.ss.android.ugc.awemepushlib.os.receiver.NotificationBroadcastReceiver导出
<receiver android:name="com.ss.android.ugc.awemepushlib.os.receiver.NotificationBroadcastReceiver">
<intent-filter>
<action android:name="notification_cancelled"/>
</intent-filter>
</receiver>当Action为notification_clicked的时候,会获取contentIntentURI传入startActivity()进行跳转,由于contentIntentURI外部可控,所以可以跳转调用任意私有不导出Activity组件
0x05 漏洞调试与利用
高版本的安卓系统需要如下使用FileProvider,这里可以看到被设置为不导出
对应的配置文件
先拥有一个任意私有Activity组件打开的能力,去结合FileProvider获取文件读写的能力,再去实现动态库加载
首先是给漏洞组件com.ss.android.ugc.awemepushlib.os.receiver.NotificationBroadcastReceiver发送广播
回顾下漏洞代码段,会获取contentIntentURI字段,用于后续跳转
如下即可实现指定应用获取FileProvider的文件读写权限,从NotificationBroadcastReceiver跳到PoC的MainActivity的时候就获得了对FileProvider的文件读写权限,此处指定的文件是/data/user/0/com.zhiliaoapp.musically/lib-main/libimagepipeline.so,同时指定了Action为TIKTOK_ATTACK_NotificationBroadcastReceiver,会去调用else分支,将我们的SO文件写入上面指定的路径
我们分析下为什么是文件com.zhiliaoapp.musically/lib-main/libimagepipeline.so,这得从Facebook开源的SoLoader说起,这个工具可以自动实现SO文件的加载,能够解决大量动态库的依赖问题,它有个特点是会把所有的动态库放到/data/data/PackageName/lib-main,然后应用启动的时候会去这个路径下加载动态库,但在测试过程中,这个路径下默认是没有库文件的
那我们既然拥有/data/data/com.zhiliaoapp.musically下文件的读写能力,就可以指定其中一个动态库去覆写,应用启动的时候就会加载我们覆写后的动态库,实现代码执行
我们使用如下的代码生成用于攻击的SO,提取其中64位的版本放到PoC的Assets文件夹下
需要注意的是不同版本有不一样的行为,在某些版本并不能生成lib-main文件夹,可以替换成app_librarian/14.8.3.6327148996
攻击过程:先安装TikTok,点击启动运行,再运行PoC,覆写SO,再重启TikTok就会发现漏洞利用成功,这样也会造成问题,有的库函数没有实现会导致崩溃
其实也简单,做中间商,手动调用原来的libimagepipeline.so库函数,并把结果返回
测试过程中也发现了一些其它问题,可能是版本不匹配,也可能是各种权限的错误
0x06 漏洞研究
0x07 References
https://blog.oversecured.com/Oversecured-detects-dangerous-vulnerabilities-in-the-TikTok-Android-app/
附录:调试过程记录
Last updated