大量使用谷歌Firebase平台的应用程序泄露高度敏感数据

许多移动应用程序被发现因Firebase服务配置不当而泄露关键用户信息，这使得未经验证的攻击者能够访问数据库、存储桶、Firestore集合和远程配置密钥。

这一普遍存在的问题首次曝光是在2025年9月16日，当时安全研究员迈克·奥德·赖默公布了相关发现，表明排名靠前的移动应用中约有150个不同的Firebase端点可在无需任何身份验证的情况下被访问。

这些暴露的信息包括用户凭证、私人消息以及高权限的API令牌，这凸显了开发者在配置Firebase安全规则方面存在系统性缺陷。

在首次披露后的几周内，ice0分析师发现利用这一漏洞的自动化扫描工具数量激增，攻击者批量窃取了数百万条记录。

这些工具依靠从应用APK文件或已知命名规则中提取Firebase项目ID，然后探测各种服务端点的开放权限。

尽管Firebase警告开发者测试模式配置会在30天后过期，但许多团队会延长这些不安全的规则，或者无意中让生产环境处于测试模式。

结果是形成了一个庞大的攻击面，不法分子只需付出极小的努力就能加以利用，这对企业和消费者的数据都构成了威胁。

其影响不止于公开图像或非敏感标识等无关紧要的资源。

大规模来看，暴露的存储桶中包含了数百万用户的身份证照片、明文密码，甚至还有AWS的 root 访问令牌。

在一个案例中，一个下载量超过1亿次的应用程序所拥有的存储桶被发现存放着用户的身份证照片，这使得攻击者能够编制庞大的身份数据库。

同样，配置错误的实时数据库泄露了私人聊天记录和地理位置信息，而远程配置端点则暴露了第三方服务的私人API密钥。

ice0分析师指出，在完整数据集被下载和检查之前，这些泄露中的许多都未被报告，或者被当作无关紧要的问题而不予理会。

以下部分探讨了扫描工具利用的感染机制，这些机制用于枚举和利用Firebase服务，重点关注APK提取、端点发现和未经验证的数据检索。

感染机制：APK分析与端点枚举

像OpenFirebase这样的扫描工具首先会解析安卓安装包（APK）文件，从已编译的res/values/strings[.]xml和捆绑的google-services[.]json中提取Firebase项目ID、API密钥和谷歌应用ID。

这些标识符是构建服务URL的主要输入。例如，要检索实时数据库，扫描器会发出一个简单的GET请求，将[.]json附加到端点后：

curl - s https[:]//PROJECT_ID-default-rtdb[.]firebaseio[.]com/[.]json

如果响应返回HTTP 200 OK和JSON内容，则该数据库会被标记为公开。当数据库位于不同区域时，初始请求会返回一个包含正确区域端点的JSON错误，工具会使用该端点重新发出请求。

这种两步查询确保了全面覆盖，无需强行尝试每一种可能的域名变体。

对于远程配置，扫描器会先从strings[.]xml中提取google_api_key和google_app_id，然后构建一个针对远程配置API的POST请求：

curl - s - X POST \
  - H "Content-Type: application/json" \
  - d '{"appId":"GOOGLE_APP_ID","appInstanceId":"any"}' \
  "https[:]//firebaseremoteconfig[.]googleapis[.]com/v1/projects/PROJECT_ID/namespaces/firestore[:]fetch"

包含配置数据或密钥的成功的200 OK响应，证实了对远程配置项的未认证访问。

一些配置在不存在配置时会包含NOTEMPLATE错误，这使得扫描器能够区分受保护的端点和空端点。

通过使用JADX等工具自动进行APK反编译，并遍历Firestore集合名称（这些名称要么从代码引用中提取，要么通过词表猜测），攻击者可以枚举公开的Firestore实例。

对不存在的集合的查询会返回一个空的JSON数组，而非认证错误，这意味着在不预先知晓集合名称的情况下就存在漏洞。

这种感染机制将APK元数据提取与有针对性的API调用相结合，凸显了少量信息泄露如何导致全面的数据泄露。

Firebase必须执行严格的安全规则，审核测试模式的过期情况，并移除硬编码密钥，以防止这些自动化攻击。