谷歌Firebase托管被暂停及“恶意软件分发”绕过技术分析

亲爱的各位，

我们最近经历了一次网站[1]的“服务中断”/不可用，原因是谷歌暂停了我们的Firebase项目（我们网站托管的根目录）。

2025年10月16日（中欧时间23:20），我们收到了谷歌云合规团队的消息[2]，指出我们的托管项目可能因“托管、分发或促进恶意软件、不需要的软件或病毒的分发”而违反谷歌政策/服务条款。同时（2025年10月16日23:20中欧时间），Web服务器日志中开始出现404 HTTP错误[3]。

在其消息中，谷歌指向2016年一个安全问题的Java SE概念验证代码[4]作为索赔（和暂停）的依据。

这并非谷歌首次（很可能是自动方式）指出此代码或类似代码（大多数情况下已超过10年历史）可能违反谷歌云政策/服务条款。

我们过去已经经历过类似的警告和/或暂停：

2024年8月7日（暂停约1天）
2025年2月19日（暂停约1天）
2025年6月11日（提出上诉，未暂停）
2025年7月17日（提出上诉，未暂停）
2025年8月21日（提出上诉，未暂停）

案例1) 更有趣，因为谷歌指出的明显违规与我们影响谷歌自家App Engine的研究的概念验证代码以及10多年历史的概念验证代码[5]有关。

这次发生的暂停是针对Java SE概念验证代码，而谷歌在一年多前已认定该代码符合要求[6]（我们曾就此提出上诉，2024年8月8日谷歌通知我们目标代码符合公司政策并恢复了我们的项目）。

我们不知道谷歌为何再次因该代码投诉（并暂停）我们的网站。

最近的暂停解决时间比往常更长。我们提交了几次上诉，向谷歌提供论据表明目标代码没有问题，还联系了谷歌支持。但均未成功。

在等待谷歌解决超过4天后，我们决定自行处理。

有一个明显的方法可以绕过谷歌对可能“托管、分发或促进恶意软件、不需要的软件或病毒的分发”的Firebase项目的暂停。

只需创建一个新的Firebase托管项目：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


/www $ mkdir semirror
/www $ mkdir semirror/public
/www $ cd semirror

/www/semirror $ firebase init

     ######## #### ########  ######## ########     ###     ######  ########
     ##        ##  ##     ## ##       ##     ##  ##   ##  ##       ##
     ######    ##  ########  ######   ########  #########  ######  ######
     ##        ##  ##    ##  ##       ##     ## ##     ##       ## ##
     ##       #### ##     ## ######## ########  ##     ##  ######  ########

您即将在此目录中初始化一个Firebase项目：

  /www/semirror
...
✔ Firebase初始化完成！

将原始文件复制到其中：

1

/www/semirror $ cp -R ../se/public .

这包括“违规”文件（显然不符合谷歌服务条款/政策并导致暂停）：

1
2
3
4


/www/semirror $ ls -la public/materials/se-2012-01-69.2.zip
-rw-r--r--    1 nobody   test         25446 10月21日 07:30
public/materials/se-2012-01-69.2.zip
/www/semirror $

并将目标项目部署到谷歌Firebase服务器：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


/www/semirror $ firebase deploy -m "SE镜像设置"

=== 正在部署到 'xxxxxxxxxxxxxxx'...

i  部署托管服务
i  托管[xxxxxxxxxxxxxxx]：开始部署...
i  托管[xxxxxxxxxxxxxxx]：在public中找到553个文件
✔  托管[xxxxxxxxxxxxxxx]：文件上传完成
i  托管[xxxxxxxxxxxxxxx]：最终确定版本...
✔  托管[xxxxxxxxxxxxxxx]：版本已最终确定
i  托管[xxxxxxxxxxxxxxx]：发布新版本...
✔  托管[xxxxxxxxxxxxxxx]：发布完成

✔ 部署完成！

配合适当的DNS记录设置（以及域名所有权验证），目标Firebase站点可以在不到1小时内手动恢复（我相信一些熟练的管理员可以快10倍并以自动方式完成）。

如果某人确实在托管恶意软件，上述方法将构成对谷歌云政策的明显且简单的绕过（只要谷歌将站点暂停视为安全/保护措施，则假定存在绕过）。

谷歌对我们网站的暂停暴露了几点问题。

它揭示了公司实施的恶意软件和/或病毒扫描远非完美（误报，即使问题已解决仍报告相同问题）。不是阻止目标文件（可疑内容），而是整个站点被暂停。这与项目所有者创建新项目实例（并继续托管任意内容）的能力（权限）不一致。

谷歌暂停还揭示了在身份验证/权限传播方面（显然谷歌支持已知，有待解决）或我认为可能是内部协议/通信的异步性质导致的一些事情未能按预期工作。

此时我不想做出任何无根据的结论，但考虑到事物（GCP）的复杂性以及过去在安全方面的经验，我开始怀疑我遇到的这些小问题是否可能是某些潜在更严重问题的表现。

还有一个与谷歌在暂停给定托管项目时强制执行/显示的网页相关的问题。该网页极具误导性。如果谷歌采取行动暂停托管项目，此行动也应向外界明确传达。当前方法（“站点未找到”页面）暗示目标网站要么被所有者配置错误，要么被黑客入侵。

最后，让我说明，谷歌暂停也对第三方产生了一些后果。

根据我们的Web服务器日志，我们最近关于eSIM安全[7]的项目已成为许多移动网络运营商、手机和eSIM供应商在eSIM技术安全问题方面的信息来源。

通过暂停我们的网站，谷歌切断了所有这些方获取最新（或仅仅需要）的项目信息（参见最近4周内仅访问此页面的220多名WebEx代理/电话会议参与者）。

讽刺的是，如果发现的一些eSIM安全问题（Kigen之后的那些）影响到谷歌Pixel手机（参见EID 89 033 023 … 芯片ID），我们的网页可能成为谷歌自身的信息来源。

谢谢。

此致， Adam Gowdiak

Security Explorations - AG Security Research Lab https://security-explorations.com