Firebase Installations API 密钥硬编码

Jan 31, 2024

Firebase Installations API 密钥硬编码

起因

新公司让我对应用移动端产品也渗透一下，自然地想到移动端APK相关的自动化检测工具，于是Docker起了一个MobSF跑了下检测，算是做个铺垫。

当然还不如自己手动测来的漏洞直接，自动化扫描得出的结果不一定都具有直接性和威胁性，但MobSF还支持动态检测，实测下来确实能自动化访问activity事件，但每次调用Frida去执行注入测试的时候就会出大大小小的问题：

目前Mac M1/M2芯片由于ARM架构的问题，还无法完全解决Genymotion跑不了ARM包的问题（Genymotion给的MAC客户端实现用的是X86架构，完全不是官方说的因为是ARM芯片就可以直接支持ARM包了，实践出真知），M1/M2可使用的系统目前只有Android11，无法打translation包

很多移动应用做了SSL-Pinning等方式防抓包，需要用各种Posed去解，这些操作可能会与MobSF动态检测的模块冲突与覆盖（如MobSF动态检测会自动植入证书）

虽然对个人的工作不会带来太大的影响（又不是没有扫描器就不会渗透了），但我还是想流畅地使用一回动态检测啊，看看能达到什么层度，有这个执念在，我萌生了一个想法：

互联网上有没有别人搭建好的完整检测平台呢？

资产发现

还真被我找到一个，而且像是官方搭建的站点，此处相关域名隐去，不予展开。

作为一个安全人员，自然会考虑提交检测的包会上传存储在哪及检测内容是否会暴露的问题，于是我先下意识地访问了recent scans：

这是啥？！为什么我能看到今天所有提交检测的应用，并且可以看到完整的检测报告？！而且更哈人的是，举例应用竟然是未对外发布的内部研发版本（官网版本2.0.011 < 研发版本2.0.015），且没有做加固之类的！

这不禁让我想到了两个问题：

MobSF这个线上检测平台肯定是没做好权限划分的，或者从设计来说MobSF可能就没实现这点，因为一般都是在本地部署的检测平台；纵使在后台做了定期清理数据的策略，在短期内这些检测内容还是会留存下来

所有被检测的应用可以被任意的人员查看，如果有安全问题很有可能线上版本也存在类似问题，而且数据泄漏就是泄漏了，在一段时间内一个访问凭证都将是有效的，即使你知道它已经泄露，会因为你不知道多少功能调用用到了这个凭证而不敢直接替换

那么这个应用里有什么呢？

API Key泄露

直接上图，这些码应该够了吧：

除了显而易见的google_maps_key 外，apk内还硬编码了firebase_database_url、google_api_key、google_app_id、google_storage_bucket 等敏感参数（有些是我直接获取源包找的），firebase_database_url 直接访问果然无权限，但是剩下的几个参数是怎么调用的？能获得什么信息呢？

首先猜测和存储空间有关，但不对，Google Cloud并不是用这样的参数类型请求访问的；那既然存在firebase_database_url，会不会和Firebase有关？一番文档翻找下，我大致了解了Firebase是啥，还有一部分的API调用，并知道了相关的API Key是在什么位置被生成又用于何处的：

之后要做的事情就简单了，构造一个请求，就可以获取到与Firebase服务器交互许可的凭证了：

之后的操作就不做了，扩大影响面应该很容易，所以为什么要演奏春日……啊不对，为什么要把应用程序的报告暴露在公开检测平台！