近年来，云计算的模式逐渐被业界认可和接受。越多来多的企业将其业务迁移上云，业务上云的模式多种多样，包括公有云、私有云、混合云和社区云。其中公有云以其低成本、灵活性等优势备受中小企业的青睐。企业只需承担一定的费用，专注于自身业务，将底层设施的安装和维护工作交给云服务提供商即可。但如今网络安全形势严峻，业务的安全性也是企业必须考虑的重点。

那么公有云的安全性如何？站在攻击方的角度，参考《云上攻防：Red Teaming for Cloud》[1]的思路，公有云环境面临的威胁主要分为两大类：

• 利用公有云上租户的不安全的应用和服务配置为突破口
• 利用公有云本身的服务的自身问题为突破口

本文主要探讨第二种——以云厂商提供的云服务为突破口，最终导致公有云环境沦陷的攻击技术。技术本身可能受限于平台和环境，但其中的思路和技巧值得借鉴和思考。希望读者在了解相关攻击技术之后能意识到：公有云安全需要云服务提供商和云上租户共同维护，缺一不可。

文中涉及到的技术仅供教学、研究使用，禁止用于非法用途。

公有云厂商提供的云服务种类较多，涵盖计算、容器、数据库、存储、无服务器等类别，不同的云厂商提供的云服务也不尽相同。值得注意的是，其中一些云服务可能是将传统产品云化之后提供给客户使用，如数据库类的产品，虽然最终对用户提供的服务大致相同，但不同的云厂商可能会为了适配云环境对产品做二次修改，这对用户来说是难以察觉的，然而却可能成为攻击者的突破口。接下来将通过一些案例来具体说明不同云厂商的云服务存在的真实风险（文中提及的风险皆已公开且已修复）。

三、案例研究

3.1 案例1——Google Cloud云服务漏洞

Google Cloud SQL是一个全代管式的关系型数据库服务，用户无需自行管理，即可部署一个SQL Server、PostgreSQL或MySQL服务器。这些Cloud SQL数据库可以通过特定的命令行工具或应用程序进行访问。云厂商为了保证公有云环境中多租户的隔离安全，会对用户权限和应用程序权限进行限制，以防止出现不受控制的隔离风险。但权限控制并非一项简单的工作，一些研究员已经在Google Cloud中的MySQL、PostgreSQL和Google Guest Agent中发现了相关漏洞，可以用来进行命令执行和容器逃逸，从而威胁其他租户的云环境。下面将分别简单介绍漏洞利用链。

CloudMySQL命令执行+容器逃逸

该漏洞由研究员Ezequiel Pereira发现[2]。在MySQL中，SUPER权限用于系统管理的相关任务，FILE权限用于在运行MySQL守护进程的服务器上进行文件读写。一旦拥有这些权限，便可轻易对服务器造成破坏，因此正常情况下只享受数据库服务的用户不应被赋予上述权限。研究员在Google Cloud控制台界面管理MySQL实例时发现了从存储桶导入和导出数据库的功能，该功能支持一个自定义的SQL查询，如图1所示：

图1 MySQL导出数据库功能界面

经过测试，研究员发现了两个可利用点：

• 连接到MySQL做导出的用户拥有FILE权限，在数据导出到存储桶之前可将其暂存在’/mysql/tmp’目录下。
• 当运行导出工具时，API实际会以某种方式调用mysqldump工具，并将数据库以参数形式传递，也可传递其他参数

调研后发现，mysqldump的参数中有两个似乎可以利用：--plugin-dir和—defualt-auth。其中--plugin-dir参数允许传递存储客户端插件的目录，--default-auth指定认证插件。结合这两个可利用点，构造了以下攻击链：

制作一个具有反弹shell功能的evil_plugin.so插件，将其插入至数据库并上传至存储桶内，然后利用MySQL从存储桶导出数据的功能，自定义SQL查询语句为“SELECT * FROM data INTO DUMPFILE '/mysql/tmp/evil_plugin.so' #”，并修改数据包如图2所示：

图2 修改导出数据库包

最终成功反弹数据库服务所在容器的shell。

容器逃逸

经过信息收集，发现Google Cloud SQL运行数据库服务的容器并非特权容器，执行ifconfig的结果如图3所示：

图3 ifconfig结果

由此判断容器共享了宿主机net命名空间，此种情况下可以拦截宿主机网卡上发送和接收的网络流量。

当使用Google提供的公共镜像启动虚拟机时，系统会自动在虚拟机实例上安装google-guest-agent。该代理的作用是监控元数据的变化，其中数据之一便是SSH公钥。当在元数据中发现一个新的SSH公钥时，google-guest-agent会将这个公钥写入用户的.authorized_key文件中，必要时会创建一个新的用户并将其加入sudoer。结合google-guest-agent代理的功能和容器共享宿主机net命名空间的特点，研究员通过定制的工具rshijack[3]进行流量劫持，成功在虚拟机上创建指定SSH用户，连接至虚拟机完成容器逃逸。

CloudPostgreSQL权限提升+容器逃逸

PostgreSQL作为最流行的数据库之一，也被公有云厂商云化改造用来提供服务。因为PostgreSQL有一套非常有限的权限模型，基本上不允许用户只有某些管理能力，所以云厂商不得不对权限模型进行改造，在保证用户有某些管理功能的同时，限制一些不安全的操作。不同的云厂商改造的方式有所差别，一些通过引入扩展或自定义配置来修改，还有一些通过修改PostgreSQL引擎代码进行改造，但这种改造很有可能会带来意想不到的安全问题。

Wiz Research在多家公有云厂商的PostgreSQL发现漏洞[4]，可以用于权限提升，尤其是在Google公有云环境上，当利用数据库服务获取容器shell时，便可以结合前文中劫持google-guest-agent流量的方式进行容器逃逸，威胁公有云环境安全。

Google提供PostgreSQL服务时的账户为postgres，属于cloudsqlsuperuser角色的一部分。通过查看官方文档，查询该角色拥有的权限如图4所示：

图4 Google cloudsqlsuperuser角色权限说明

该角色并非PostgreSQL的默认行为，而是Google对其进行了修改。观察文档发现，该角色允许改变表的所有权给数据库中的任何用户和角色，本意是将一些高权限的能力授予给低权限的用户，但却给了攻击者可乘之机。

PostgreSQL中ALTER TABLE与索引函数相结合

值得关注的是，当PostgreSQL的INSERT/UPDATE/ANALYZE命令在一个有索引函数的表中执行时，该函数被作为命令的一部分调用，且是以表拥有者的权限调用。

图5 索引函数被执行示意

因此，可以构造以下攻击链进行利用：

• 创建一个新的表
• 在表中插入一下任意内容
• 在表中创建一个恶意的索引函数（包含具有反弹shell功能的恶意代码）
• 更改表的所有者为cloudsqladmin（Google云平台的超级用户角色，仅用于维护和管理CloudSQL数据库）
• 对表执行ANALYZE命令，使得索引函数以cloudsqladmin权限调用，从而执行恶意代码

最终成功获得容器的shell，权限为postgres用户。然后，在拥有可写权限的目录下，发现了一个由root账户拥有的文件，利用符号链接攻击提升权限至root（本文不再详述，感兴趣的可以阅读原文），最终利用前文提到的劫持google-guest-agent流量的方式完成容器逃逸，获得宿主机上的SSH登录权限。

3.2 案例2——Microsoft Azure云服务漏洞

AzurePostgreSQL权限提升漏洞

与Coogle一样，Microsoft Azure在提供PostgreSQL云服务时，也对其引擎做了二次修改，但Azure在PostgreSQL的权限管理方面有所不足。经过测试发现，使用Azure PostgreSQL服务的用户被授予了CREATEROLE权限。

CREATEROLE是一个十分强大的权限，被授予该权限的用户可以创建新用户，并将它们与特定的角色关联起来。PostgreSQL本身内置了一些强大的角色，如pg_read_server_files、pg_write_server_files和pg_execute_server_program，这些角色的权限如下：

pg_read_server_files -赋予用户从文件系统中任意读取文件的能力。

pg_write_server_files -赋予用户向文件系统任意写文件的能力。

pg_execute_server_program - 最强大的角色，赋予用户在操作系统层面执行任意命令的能力。

PostgreSQL的官方文档也警告说，CREATEROLE角色几乎为“超级用户”。然而Azure在引入该角色时并未做修改和限制，导致用户可以结合PostgreSQL的COPY功能在系统上任意执行命令，从而获取容器的权限。

Service Fabic权限提升漏洞

2022年6月，来自Unit 42实验室的研究员公开了Microsoft Service Fabric的漏洞——CVE-2022-30137，该漏洞允许攻击者在容器内提升权限至主机节点root权限，且利用门槛低，危害较大。

Server Fabric是一款分布式系统平台，可方便用户轻松打包、部署和管理可缩放的可靠微服务和容器。产品定位类似于Kubernetes，但又有所不同。Service Fabric目前为许多微软服务提供支持，包括Azure SQL数据库、Azure Cosmos DB、Cortana、Microsoft Power BI以及许多Azure核心服务。

一个Service Fabric集群由许多节点组成，每个节点都运行一个容器引擎，执行所需的容器化应用，其每个节点上运行的组件大致如图6所示： 

图6 Service Fabric Linux节点示例

Service Fabric支持将应用程序部署为容器，在每个容器初始化期间，会创建一个新的日志目录，并以读写权限加载到每个容器中。所有容器对应的目录都集中在每个节点的同一个路径上。例如，在Azure Service Fabric产品中，这些目录在/mnt/sfroot/log/Containers。

Data Collection Agent（DCA）是Service Fabric集群中的一个组件，负责从这些目录中收集日志，以便后续处理。为了访问这些目录，它需要很高的权限，因此在每个节点上该组件都以root身份运行。通过挖掘DCA的旧源代码，研究员在函数GetIndex（PersistedIndex.cs:48）中有一个潜在的竞争条件的任意写入。攻击者可通过创建符号链接的方式，利用恶意内容覆盖节点文件系统中的文件，最终获得节点上的代码执行权限，其攻击链大致如图7所示：

图7 FabricScape攻击链

• 利用GetIndex的竞争条件的引起任意写入和DCA在主机上以root身份运行的特点，创建符号链接覆盖主机上的/etc/environment文件。
• 利用ServiceFabric节点上默认运行的CronJob的特点，在执行作业时导入/etc/environment文件。
• 在Cronjob启动进程初始化时，加载/etc/environment文件中的LD_PRELOAD环境变量指向自定义的共享对象。
• 最终成功执行共享对象中的反弹shell代码，获取到节点root权限。
• 在/var/lib/waagent/目录下发现ServiceFabric集群管理工具sfctl所需的证书，利用sfctl工具接管整个集群，如图8所示：

图8 sfctl工具执行实例

3.3 案例3——AWS云服务漏洞 

Log4Shell热补丁容器逃逸和权限提升漏洞

Log4Shell（CVE-2021-44228）是2021年最严重的漏洞之一。AWS为了帮助用户防御这个漏洞，针对不同的环境开源了几个热补丁解决方案。热补丁是向有漏洞的运行中的应用程序注入一个修复程序的过程。它的目的是作为一个短期的解决方案，直到新的固定版本的应用程序被部署。

但研究人员发现这些补丁可以被利用来进行容器逃逸和权限提升[5]。为了修补容器内的Java进程，热补丁调用了容器的 "java "二进制文件两次：一次是检索Java版本，另一次是注入热补丁。问题出现在调用容器二进制文件时没有正确地将其容器化，而是以主机root用户运行。因此，攻击者可以通过在恶意容器内运行一个名为 "java "的恶意二进制文件，让热补丁识别并以高权限调用，最终逃离容器并宿主机。

除了容器之外，热补丁服务也以类似的方式对主机进程进行修补。因此攻击者也可以通过创建并运行一个名为 "java "的恶意二进制文件，从普通进程权限提升至root权限。

四、总结与思考

综合文中提及的案例可知，公有云在提供便利的云服务的同时，也有可能带来意想不到的风险。即使是AWS、Google这样的头部厂商，也可能在设计和管理云服务时出现纰漏，给攻击者以可乘之机。

站在攻击者的角度来看，可以借鉴PostgreSQL等传统产品上云后权限管理不当的案例，深入挖掘那些云服务中的“钉子户”，分析其脆弱性是否在上云之后有所改善以及改善方案是否也存在一定的利用点，尤其关注官方文档中提示的风险警告点。

站在防御者的角度来看，攻击者在攻击利用公有云服务时，大多情况下无法看到其代码逻辑，只能通过黑盒的方式进行攻击测试，因此公有云厂商应加强公有云环境中的入侵检测系统，案例1中的研究员们在利用MySQL和PostgreSQL逃逸到宿主机之后均第一时间被Google员工发现并尝试联系，其他云厂商也应如此。公有云环境作为黑客的一个“主战场”，防御能力需要实时升级。

[1] http://avfisher.win/archives/1175

[2] https://www.ezequiel.tech/2020/08/dropping-shell-in.html

[3] https://github.com/kpcyrd/rshijack

[4] https://www.wiz.io/blog/the-cloud-has-an-isolation-problem-postgresql-vulnerabilities

[5] https://unit42.paloaltonetworks.com/aws-log4shell-hot-patch-vulnerabilities/