一. 概述

近日，云安全公司Wiz披露了阿里云数据库服务ApsaraDB RDS for PostgreSQL和AnalyticDB for PostgreSQL的一连串严重漏洞。这些漏洞被Wiz命名为“BrokenSesame”，允许攻击者突破租户的隔离保护机制，从而未授权访问其他阿里云客户的PostgreSQL数据库，并能够对数据库服务进行供应链攻击，严重威胁到阿里云客户的数据安全。

本文将带领读者回顾这一系列数据库漏洞的安全风险细节，并总结事件所得，以提醒其他云厂商和租户注意类似的风险。

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

二. 云资源层安全能力发展方向

2.1 研究背景

本次事件并非Wiz首次发现公有云PostgreSQL数据库服务相关漏洞。作为一家2020年才成立的云安全公司，Wiz的增长极为迅速。2023年2月，Wiz在D轮融资3亿美元后，估值达到100亿美元，一跃成为最快实现100亿美元估值的SaaS公司。笔者梳理了Wiz在公有云服务漏洞挖掘方面的成果，如下所示：

  • 2021年8月，在Black Hat US 2021会议中，Wiz发表了关于AWS 跨账户的漏洞，允许攻击者对其他租户的资源执行操作；

  • 2021年8月，在Black Hat EU 2021会议中，Wiz披露了微软云服务Azure的旗舰数据库Cosmos中的严重漏洞，允许对数千名 Microsoft Azure 客户（包括许多财富 500 强公司）的帐户和数据库进行无限制的访问；

  • 2021年9月，Wiz披露了微软云服务Azure开放管理基础设施（OMI）组件的系列漏洞，允许攻击者未授权在情况下远程执行代码；

  • 2021年12月，Wiz披露了Azure App Service中的一个漏洞，该漏洞导致使用“Local Git”的客户暴露源代码；

  • 2022年4月，Wiz披露了Azure PostgreSQL Flexible Server服务中的一个跨账户漏洞，允许未授权读取其他客户的PostgreSQL数据库；

  • 2022年8月，Wiz披露了GCP、Azure的PostgreSQL漏洞，允许突破数据库隔离限制，威胁其他数据库用户；

  • 2022年9月，Wiz披露了Oracle云基础设施（OCI）的一个严重的云隔离漏洞，允许对客户的云存储卷进行未授权访问；

  • 2022年12月，Wiz披露了IBM Cloud Databases for PostgreSQL服务的供应链漏洞，可能导致未授权访问数据库；

  • 2023年3月，Wiz披露了Azure Active Directory的一个错误配置，导致Bing（必应）的结果被控制和账户被接管。

从以上安全漏洞中不难发现，公有云数据库服务的安全性一直是Wiz的关注点。研究发现，多家公有云厂商在提供数据库的多租户环境中都会使用到容器和容器编排平台。虽然容器编排平台简化了管理和维护的过程，但租户的隔离性要得到有效的隔离保护却并不容易。租户间的资源仍然以某种方式关联在一起，容器的网络连接、不正确的权限管理或不完善的容器隔离都有可能打破租户间的隔离。Wiz在从Google、微软、IBM等国外云厂商的云数据库服务中挖掘出跨租户漏洞之后，开始关注阿里云。

2.2 数据库漏洞细节

本次事件涉及到的服务分别是阿里云的AnalyticDB for PostgreSQL服务[1]和ApsaraDB RDS for PostgreSQL服务[2]。

Wiz研究员在先前的漏洞挖掘经验[3]中，总结出利用PostgreSQL数据库中ALTER TABLE与索引函数相结合的技巧获取到数据库容器的shell权限。以下两个数据库的漏洞均在先前的积累之上所得，下面我们将进行简单介绍（文中提及的风险皆已公开且已修复）。

2.2.1 AnalyticDB for PostgreSQL

云原生数据仓库AnalyticDB PostgreSQL版是一种大规模并行处理（MPP）数据仓库服务，可提供海量数据在线分析服务。AnalyticDB PostgreSQL版基于开源项目Greenplum [4]构建，由阿里云深度扩展。

图1 AnalyticDB for PostgreSQL攻击链

针对AnalyticDB for PostgreSQL的攻击链大致如图1所示：

  1. 利用cronjob定时任务提权至容器内的root权限。

  2. 利用Pod内容器共享PID命名空间的特性横向移动到Pod中的相邻特权容器。

  3. 利用特权容器逃逸至宿主机。

  4. 利用宿主机上的kubelet凭证访问敏感资源，包括密钥、serviceaccount和Pod。

  5. 利用收集到的凭证访问阿里云私有容器镜像仓库，查看凭证权限。

  6. 经测试发现凭据具有容器镜像仓库的读取和写入权限，允许发起供应链攻击。

风险点1

cronjob任务中暴露拥有root权限的二进制文件

利用PostgreSQL的命令执行技巧仅仅只能获取到容器的数据库用户权限，并非root，如图2所示：

图2 命令执行获取到postgres权限

研究员在信息收集的过程中发现cronjob任务中执行的二进制文件拥有root权限，而该二进制文件在加载共享库时从自定义目录进行加载，由于数据库用户拥有该目录的可写权限，攻击者可以通过替换动态链接库的方式以root权限执行恶意代码，从而实现权限提升。

风险点2

同一个Pod中的容器之间共享PID命名空间

经过测试，Wiz发现当从阿里云管理平台执行某些操作时，通常会在云托管环境中创建各种容器和进程。根据进程信息中不存在的路径可以猜测，阿里云数据库集群内同一Pod中的容器直接共享了PID命名空间，导致攻击者可以在容器之间进行横向移动。

风险点3

新建的容器内为特权容器且可访问Docker Unix socket

无论是特权容器还是docker.sock，都是容器逃逸常用的手段，因此可以利用它们逃逸至宿主机。

风险点4

kubelet凭证权限过高

一般情况下，运行租户业务容器的宿主机大概率非Master节点。按照Kubernetes的架构组成，每个worker节点上都会运行kubelet服务和kube-proxy容器。逃逸至宿主机后，尝试使用kubelet凭证访问Kubernetes API Server验证权限，如图3、图4所示：

图3 发现kubelet凭证可以拥有list pods权限

图4发现kubelet凭证拥有get secrets权限

经测试，kubelet凭证拥有过高的权限，可以用于访问集群内其他租户的敏感资源。

风险点5

租户环境中的secret凭证拥有容器镜像仓库的push权限

一般情况下，拥有pull镜像的权限即可保证租户的环境正常运行。当获取到镜像仓库的push权限时，攻击者便可将恶意镜像推送至镜像仓库，完成供应链攻击。

风险点6

敏感凭证遗留

通过对宿主机节点进行敏感信息扫描，可以从各种文件中发现敏感凭证，如云IAM凭证、私钥等，攻击者可以利用凭证横向移动至其他云资源或进行权限提升。

2.2.2 ApsaraDB RDS for PostgreSQL

ApsaraDB RDS for PostgreSQL是一个稳定可靠的在线数据库服务（阿里云国际站可以开通该服务），可以弹性地扩展，具有自动监测、备份和灾难恢复功能。

图5 ApsaraDB RDS for PostgreSQL攻击链

ApsaraDB RDS for PostgreSQL的攻击链大致如图5所示：

  1. 利用容器内的文件共享漏洞访问到Pod内相邻管理容器的源代码。

  2. 代码审计发现源代码中存在远程代码执行漏洞，利用该漏洞获取到相邻管理容器的执行权限。

  3. 然后利用core_pattern机制逃逸至宿主机。

  4. 在宿主机上发现其他租户的数据库服务，且经测试发现ApsaraDB服务与AnalyticDB使用相同的私有容器镜像仓库，因此也可使用AnalyticDB的凭证对ApsaraDB RDS进行供应链攻击。

风险点1

同一Pod的容器之间共享mount命名空间

通过收集容器内信息，研究员发现了属于另一个容器的操作日志，记录了对数据库容器的操作，由此判断同一Pod的容器之间也共享了mount命名空间。

利用此特性并结合符号链接，研究员可以看到另一容器的任意文件内容。

风险点2

PostgreSQL 数据库Upgrade Check功能存在RCE漏洞

阿里云提供了一项功能，可以在继续进行选定的升级之前验证 PostgreSQL 实例是否可以升级到较新的版本，本意是为了避免损坏数据库。

但结合共享mount命名空间的特性，研究员可以从操纵容器中获取到源代码，研究员经过代码审计，在代码中发现了一个命令行注入漏洞，从而可以以root权限在负责此操作的容器中执行代码。操作容器为特权容器，因此可以借助较多手段进行容器逃逸。

风险点3

kubelet凭证具有过高权限

与AnalyticDB相同，ApsaraDB集群节点中的kubelet凭证也拥有过高权限，导致可以访问其他租户的资源。

同时，AnalyticDB集群与ApsaraDB集群使用相同的容器镜像仓库，因此也可以使用之前的secret凭证对ApsaraDB集群进行供应链攻击。

2.3 事件教训与启示

图6 YD/T 4060—2022《云计算安全责任共担模型》行业标准

安全性是云上租户在使用公有云时考虑的核心问题，尤其是在多租户场景中。针对此次事件数据库服务暴露出的众多风险点，云服务提供商和云上租户都需要吸取教训。但不同的云服务模型，云服务提供商和云上租户所需要承担的安全责任不同，参考中国信通院发布的《云计算安全责任共担模型》[5]（图6所示），ApsaraDB RDS和ApsaraDB RDS作为两款PaaS服务，云服务提供商需要注意的是：

  1. 严格限制数据库用户权限：由于数据库用户拥有指定链接库的写权限，导致攻击者可以构建恶意链接库完成权限提升。

  2. 严格限制容器之间的资源隔离：同一Pod的容器之间共享PID/mount命名空间可能导致攻击者在容器之间进行横向移动，扩大攻击面，完成容器内权限提升甚至逃逸至宿主机。

  3. 增强租户间的隔离性：一旦攻击者完成容器逃逸，便可对同一节点内其他租户的资源造成威胁，建议云厂商提供更安全的隔离机制，例如使用Gvisor或Kata容器来阻止容器逃逸。

  4. 业务代码安全审计：即使是临时创建的容器和进程，源代码也应该经过严格的审计，防止被漏洞利用。

  5. 限制特权容器滥用：阿里云的管理平台执行某些操作时，会在同一Pod内启动特权容器执行操作，但也会被攻击者作为容器逃逸的跳板，因此建议通过赋予操作容器指定Capabilities的方式来替代特权容器滥用。

  6. 集群角色合理分配权限：集群worker节点上的kubelet凭证权限过高便能够访问其他租户的资源，因此需要合理分配权限，保证其他租户的数据安全。

  7. 限制用户对镜像仓库的操作权限：云服务商倾向于使用私有容器镜像仓库来托管容器镜像。在 ApsaraDB RDS 和 AnalyticDB RDS的案例中，阿里云也使用了私有镜像仓库。但用于拉取镜像的凭证没有正确限制范围且允许推送，导致存在供应链攻击风险。

  8. 严格管理敏感信息：AnalyticDB 服务中的 Kubernetes节点基础镜像包含构建过程中遗留的敏感凭证。该凭证可能使攻击者能够破坏内部服务资源并在云环境中进行横向移动，因此在业务运行环境中应清理敏感并限制凭证的权限。

  9. 加强监控机制，及时修复：云服务商应加强威胁检测机制，尽可能减小安全风险的影响面；同时应时刻关注最新安全资讯，及时修复云环境中存在的威胁，保证租户的云环境安全。

虽然云服务出现漏洞时，云上租户会“被迫”受到影响，但借助一些主动的手段也能加强租户的数据安全：

  1. 应用程序漏洞修复：本次事件中的漏洞均是从获取到PostgreSQL数据库权限出发，一般情况下，攻击者可通过应用程序漏洞获取数据库权限或通过暴力破解获取的数据库登录权限，因此及时修复连接数据库的应用程序，可以避免攻击者通过应用程序入侵。

  2. 保护数据库凭证：建议使用公有云数据库服务时限制内网访问或使用IP白名单，防止攻击者通过批量暴力破解的手段入侵数据库；同时应保证数据库访问凭证的复杂度，并定期轮换，防止凭证猜解、意外泄露等方式威胁数据安全。

  3. 数据加密存储：建议机密性要求高的数据建议采用加密存储，当发生数据泄露时能够最大限度止损。

幸运的是，阿里云安全团队称，在此次事件中Wiz漏洞挖掘的过程被实时监控，且并未发现任何证据表明阿里云系统或服务被其他方利用。因此阿里云数据库租户的数据安全并未受到威胁。

三. 云上风险发现与治理

除了云数据库服务之外，对象存储服务也是近几年较为流行的公有云服务，如阿里云对象存储服务OSS。为了方便随时随地访问，越来越多的企业和用户使用云存储服务存储数据，但当使用服务时配置错误或发生凭证泄露，存储桶内的数据也将增加泄露的风险。

绿盟科技星云实验室致力于云安全研究，包括公有云上的风险发现工作，不安全的对象存储服务、泄露的公有云凭证、对外暴露的云原生服务以及源代码仓库等都是云上风险发现工作的关注点。先前我们应用网络空间测绘等技术对国内外暴露的代码仓库进行了全面测绘，部分代码仓库包含有泄露的公有云凭证，涉及阿里云、腾讯云、七牛云、百度云、AWS等，凭证类型涉及对象存储服务、OCR服务、短信服务、小程序密钥、支付接口Key等，如图7、图8所示：

图7 从代码中发现阿里云OSS凭证

图8 短信接口调用代码

更多相关信息可以移步《绿盟科技2022年度网络空间测绘年报—云上风险测绘篇》[6]深入了解。

四. 总结与思考

通过分析此次事件，笔者带大家了解了AnalyticDB for PostgreSQL 和 ApsaraDB RDS for PostgreSQL 中的漏洞细节以及Wiz挖掘云服务漏洞的思路和技巧。笔者猜测，继阿里云之后，大概率还会有其他云服务提供商的同类型云服务被Wiz盯上。漏洞的披露无疑为云服务利用提供了切实可行的思路，但公有云的使用者更希望云服务提供商能够及时修复云环境中的安全风险，为云上租户提供更安全的云环境。

参考文献

[1]. https://www.aliyun.com/product/apsaradb/gpdb?spm=5176.22133730.J_3207526240.494.3bcf7b5eNf7DUp&scm=20140722.M_9130369._.V_1

[2]. https://www.alibabacloud.com/product/apsaradb-for-rds-postgresql

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

[4]. https://greenplum.org

[5]. https://hbba.sacinfo.org.cn/stdDetail/65f9104378e423d06560c25356042b4fc77511c93dab912c655aa8f9f1d65e62

[6]. https://book.yunzhan365.com/tkgd/jqoc/mobile/index.html

内容编辑：星云实验室 李来冰

责任编辑：创新研究院 董炳佑

本公众号原创文章仅代表作者观点，不代表绿盟科技立场。所有原创内容版权均属绿盟科技研究通讯。未经授权，严禁任何媒体以及微信公众号复制、转载、摘编或以其他方式使用，转载须注明来自绿盟科技研究通讯并附上本文链接。

声明：本文来自绿盟科技研究通讯，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。