Cloud I Hack into Google Cloud

原创 langu 电驭叛客

在本月初，Google宣布了去年2021的Google Cloud Platform的六个VRP漏洞（ GCP VRP 奖旨在鼓励安全研究人员关注 GCP 的安全性，从而帮助我们为我们的用户、客户和整个互联网提高 GCP 的安全性），希望鼓励更多的安全研究者涉足云安全领域，这六个漏洞看完非常有趣，接下来我会用自己的理解分析下这几个漏洞。

漏洞1: Bypassing Identity-Aware Proxy

漏洞详情链接：https://www.seblu.de/2021/12/iap-bypass.html

IAP(Identity-Aware Proxy)可以理解为是应用层零信任，在用户和应用之间增加了一层独立的身份认证。https://cloud.google.com/iap?hl=zh-cn

根据作者的漏洞介绍，尝试着画了一下攻击路径(原文描述的有点凌乱，可能有不对的地方，见谅)，大概路径是通过这三个小漏洞，利用重定向，在受害者访问开启了IAP的APP之前先重定向到没有开IAP的APP上，然后捕获链接中的token，实现凭证窃取。

就像作者说的，小的漏洞可以组合成大的漏洞，这或许也是Google为什么将其排在第一位的原因吧。

漏洞2: 通过DHCP泛洪接管VM和获取ROOT访问权限

漏洞详情链接：https://github.com/irsl/gcp-dhcp-takeover-code-exec

ISC 的 DHCP 客户端（Debian 风格的 isc-dhcp-client 包）的实现依赖于 random(3) 来生成伪随机数（非线性加性反馈随机数）。由当前unixtime、dhclient进程的pid和MAC最后四个字节。这三个值可以猜测出来，进而可以伪造DHCP包，在某些环境下，通过DHCP泛洪可以接管目标VM的网络配置。

允许攻击者通过向虚拟机发送恶意 DHCP 数据包并冒充 GCE 元数据服务器来访问 Google Compute Engine 虚拟机。

```

Google 严重依赖元数据服务器，包括 ssh 公钥的分发。连接在网络/路由层是安全的，并且服务器没有经过身份验证（没有 TLS，仅清除 http）。负责处理元数据服务器响应的google_guest_agent 进程通过虚拟主机名 metadata.google.internal 建立连接，该虚拟主机名是 /etc/hosts 文件中的别名。该文件由 /etc/dhcp/dhclient-exit-hooks.d/google_set_hostname 作为 DHCP 响应处理的钩子部分管理，并且别名通常由该脚本在每个 DHCPACK 处添加。通过完全控制 DHCP，可以模拟元数据服务器。

```

漏洞4: 在 Cloud SQL 的中发现的多个漏洞

漏洞详情链接：https://irsl.medium.com/the-speckle-umbrella-story-part-2-fcc0193614ea

作者研究Cloud SQL 攻击向量的过程中发现的多个漏洞

3.1 Postgres 服务帐户可以访问其他 RDS（MySQL、SQL Server 等）的 Docker 映像

3.2 MySQL LOAD DATA LOCAL 滥用

3.3 终端转义序列注入 gcloud

3.4 Postgres IAM 身份验证可能允许窃取其他用户的访问令牌

3.5 Cloud SQL Auth Proxy 通过网络泄露访问令牌 — 中间人攻击

3.6 Cloud SQL — SQL 代理信息泄露漏洞（项目和实例名称）

这一系列漏洞对于研究其它云产品的安全性有着很大的借鉴意义。“在服务器端环顾四周是一次很棒的经历，我学到了很多关于 Google 内部的知识！”

（漏洞2和漏洞4是同一个作者，放在一起，真的牛！）

漏洞3: Google Cloud Dataflow 中的RCE

漏洞详情链接：https://mbrancato.github.io/2021/12/28/rce-dataflow.html

Dataflow 节点暴露了未经身份验证的 Java JMX 端口，但是GCP默认的防火墙规则不会使其暴露在互联网。不过很多GCP用户会调整防火墙规则，导致5555端口暴露在互联网，从而可以被远程获取shell。

这也是个蛮有趣的漏洞，用户的一些配置使安全变成了不安全，这在日常的工作中也经常遇到，任何一方做好都没有漏洞，挺好奇Google是如何修复的？

漏洞5: Managed Anthos Service Mesh 控制面中的RCE

漏洞详情链接：https://lf.lc/vrp/203177829/

控制面（control plane）：用于帮助service mesh 来进行服务发现、流量治理等。

这个漏洞在一般情况下需要在K8s集群中具有高访问权限，才能允许Istio控制面上执行远程命令。但是在某些特殊的场景下，就像Managed Anthos Service Mesh中，它在Google管理的项目中运行Istio控制面，当具备了高访问权限的时候，这个漏洞就变得严重了。（不知道这样理解对不对）

apiVersion: v1kind: Configcurrent-context: defaultclusters:- name: default  cluster:    server: https://127.0.0.1contexts:- name: default  context:    cluster: default    user: defaultusers:- name: default  user:    exec:      apiVersion: client.authentication.k8s.io/v1beta1      command: /bin/sh      args: ['-c', 'touch /tmp/flag']

漏洞6: Google Cloud Shell 中的命令注入

漏洞详情链接：

https://docs.google.com/document/d/1-TTCS6fS6kvFUkoJmX4Udr-czQ79lSUVXiWsiAED_bs/edit#

Cloud Shell 有个功能是可以通过类似下面的链接clone可信代码库的代码

https://ssh.cloud.google.com/?git_repo=https://github.com/GoogleCloudPlatform/gsutilhttps://ssh.cloud.google.com/?go_get_repo=github.com/google/gops

但是在配置文件中有个缺陷，git_repo和go_get_repo两个参数同时存在于链接中时，判断逻辑是or，所以只要git_repo和go_get_repo其中一个存在其中就可以，所以可以在go_get_repo参数上添加命令，同时在git_repo上加载可信代码库。

最终构造的payload为：

https://shell.cloud.google.com/?show=ide&go_get_repo=%22;curl%200/service-accounts/default/token;%23&git_repo=github.com/GoogleCloudPlatform/gsutil

继续滑动看下一个