使用Cloud Shell在GCP中实现权限维持

Google Cloud Shell 是一项提供基于 Web 的 shell 的服务，可以在其中执行 GCP 管理活动。基于 Web 的 shell 是一个不错的功能，因为它允许开发人员和管理员管理 GCP 资源，而无需在系统本地安装或保留任何软件。从技术角度来看，Google 指出 Cloud Shell 是一个短暂的 Debian Linux 虚拟机 (VM)。用户在使用 Cloud Shell 时与之交互的实际上是一个 Docker 容器。要使用 Cloud Shell，您只需登录 Google Cloud 控制台并单击终端图标，即可启动 Cloud Shell 实例，如下所示。

读了上面，可能看到了“短暂”这个词，并想知道如何在短暂的环境中坚持下去。由 Google Cloud Shell 构建的容器是短暂的，但你的主目录 (/home) 可以容纳多达 5GB 的数据并且是持久的。

之前的研究显示了如何使用 .bashrc 文件在 Cloud Shell 中持久化。那是在 Juan Berner 在 2018 年发表的这篇Medium 帖子中。通过 .bashrc 文件持久化是一种持久化方法，但还有另一种选择。

在研究过程中，我们发现 Google Cloud Shell 在启动时具有独特的功能，可以读取主文件夹中名为 .customize_environment 的文件。默认情况下不会创建此文件，但一旦添加，它将在每次启动 Cloud Shell 时运行。

从管理的角度来看，这很方便。如果管理员经常使用一些工具，但默认情况下没有安装，他们可以在.customize_environment文件中编写一个脚本，以安装任何需要的软件，改变系统的配置等等。

然而，如果你是一个黑客，这个功能可能会因为其他原因引起你的注意。

攻击者、渗透测试人员和红队在最初侵入一个环境后通常有一个类似的目标。这个目标是留在被破坏的网络内，这意味着他们需要至少有一种方法来维持他们的访问。在网络安全领域，我们把这称为权限维持。

.customize_environment文件是在获得对GCP的初始访问后的一个可靠的权限维持选择。这种方法有很大的能力。可以下载一个命令和控制植入程序，并在每次启动Cloud Shell时运行，或者运行一个脚本，窃取令牌并将其发布到攻击者的服务器上，等等。在测试过程中，Cloud Shell的出站过滤似乎极为有限。下面我们检查了我们可以向外连接的开放TCP端口，没有一个被阻止。

对外开放访问意味着可以使用反向的shell。在下面的例子中，我们保持简单，在.customize_environment文件中使用以下代码运行一个Netcat反向shell。这为我们提供了对被破坏的Cloud Shell的远程访问。

下次启动Cloud Shell时，我们会得到一个反向shell。

你可以在进程列表中看到.customize_environment在启动时与Bash一起被自动调用，并且仍在运行反向shell。

然而，这种权限维持方法也有缺点。为了使其有效，受害者必须使用Cloud Shell。如果他们是一个不经常使用的用户或不使用Cloud Shell，这将不是一个可靠或有效的权限维持方法。

另一个缺点是，在Cloud Shell中第一次执行需要认证的操作时，会在用户的浏览器中弹出一个授权窗口，在命令运行前必须接受。如果出现一个意外的弹出窗口，目标可能会起疑心，并摧毁权限维持方法。

一个限制检测的变通方法是监控用户的活动，等到他们进行了API调用后再尝试执行需要认证的活动。最后，如果用户不经常使用Cloud Shell，主目录将在120天的非活动后被删除。

使用Curl试图访问Metadata服务器的命令弹出的授权信息

这种权限维持方法的一个关键优势是，检测或阻止它的能力非常有限。谷歌目前没有提供适用于Cloud Shell的日志、防火墙规则或等。

本文为译文，原文链接：https://securityintelligence.com/posts/attacker-achieve-persistence-google-cloud-platform-cloud-shell/

【火线Zone云安全社区群】

进群可以与技术大佬互相交流

进群有机会免费领取节假日礼品

进群可以免费观看技术分享直播

识别二维码回复【社区群】进群

火线Zone是[火线安全平台]运营的云安全社区，内容涵盖云计算、云安全、漏洞分析、攻防等热门主题，研究讨论云安全相关技术，助力所有云上用户实现全面的安全防护。欢迎具备分享和探索精神的云上用户加入火线Zone社区，共建一个云安全优质社区！

如需转载火线Zone公众号内的文章请联系火线小助手：hxanquan（微信）