一. 概述
近日，云安全公司Wiz披露了阿里云数据库服务ApsaraDB RDS for PostgreSQL和AnalyticDB for PostgreSQL的一连串严重漏洞。这些漏洞被Wiz命名为“BrokenSesame”，允许攻击者突破租户的隔离保护机制，从而未授权访问其他阿里云客户的PostgreSQL数据库，并能够对数据库服务进行供应链攻击，严重威胁到阿里云客户的数据安全。
本文将带领读者回顾这一系列数据库漏洞的安全风险细节，并总结事件所得，以提醒其他云厂商和租户注意类似的风险。
文中涉及到的技术仅供教学、研究使用，禁止用于非法用途。
二. 云资源层安全能力发展方向
-
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等国外云厂商的云数据库服务中挖掘出跨租户漏洞之后，开始关注阿里云。
-
利用cronjob定时任务提权至容器内的root权限。 -
利用Pod内容器共享PID命名空间的特性横向移动到Pod中的相邻特权容器。 -
利用特权容器逃逸至宿主机。 -
利用宿主机上的kubelet凭证访问敏感资源，包括密钥、serviceaccount和Pod。 -
利用收集到的凭证访问阿里云私有容器镜像仓库，查看凭证权限。 -
经测试发现凭据具有容器镜像仓库的读取和写入权限，允许发起供应链攻击。
-
利用容器内的文件共享漏洞访问到Pod内相邻管理容器的源代码。
-
代码审计发现源代码中存在远程代码执行漏洞，利用该漏洞获取到相邻管理容器的执行权限。
-
然后利用core_pattern机制逃逸至宿主机。
-
在宿主机上发现其他租户的数据库服务，且经测试发现ApsaraDB服务与AnalyticDB使用相同的私有容器镜像仓库，因此也可使用AnalyticDB的凭证对ApsaraDB RDS进行供应链攻击。
-
严格限制数据库用户权限：由于数据库用户拥有指定链接库的写权限，导致攻击者可以构建恶意链接库完成权限提升。 -
严格限制容器之间的资源隔离：同一Pod的容器之间共享PID/mount命名空间可能导致攻击者在容器之间进行横向移动，扩大攻击面，完成容器内权限提升甚至逃逸至宿主机。 -
增强租户间的隔离性：一旦攻击者完成容器逃逸，便可对同一节点内其他租户的资源造成威胁，建议云厂商提供更安全的隔离机制，例如使用Gvisor或Kata容器来阻止容器逃逸。 -
业务代码安全审计：即使是临时创建的容器和进程，源代码也应该经过严格的审计，防止被漏洞利用。 -
限制特权容器滥用：阿里云的管理平台执行某些操作时，会在同一Pod内启动特权容器执行操作，但也会被攻击者作为容器逃逸的跳板，因此建议通过赋予操作容器指定Capabilities的方式来替代特权容器滥用。 -
集群角色合理分配权限：集群worker节点上的kubelet凭证权限过高便能够访问其他租户的资源，因此需要合理分配权限，保证其他租户的数据安全。 -
限制用户对镜像仓库的操作权限：云服务商倾向于使用私有容器镜像仓库来托管容器镜像。在 ApsaraDB RDS 和 AnalyticDB RDS的案例中，阿里云也使用了私有镜像仓库。但用于拉取镜像的凭证没有正确限制范围且允许推送，导致存在供应链攻击风险。 -
严格管理敏感信息：AnalyticDB 服务中的 Kubernetes节点基础镜像包含构建过程中遗留的敏感凭证。该凭证可能使攻击者能够破坏内部服务资源并在云环境中进行横向移动，因此在业务运行环境中应清理敏感并限制凭证的权限。 -
加强监控机制，及时修复：云服务商应加强威胁检测机制，尽可能减小安全风险的影响面；同时应时刻关注最新安全资讯，及时修复云环境中存在的威胁，保证租户的云环境安全。
-
应用程序漏洞修复：本次事件中的漏洞均是从获取到PostgreSQL数据库权限出发，一般情况下，攻击者可通过应用程序漏洞获取数据库权限或通过暴力破解获取的数据库登录权限，因此及时修复连接数据库的应用程序，可以避免攻击者通过应用程序入侵。 -
保护数据库凭证：建议使用公有云数据库服务时限制内网访问或使用IP白名单，防止攻击者通过批量暴力破解的手段入侵数据库；同时应保证数据库访问凭证的复杂度，并定期轮换，防止凭证猜解、意外泄露等方式威胁数据安全。 -
数据加密存储：建议机密性要求高的数据建议采用加密存储，当发生数据泄露时能够最大限度止损。
三. 云上风险发现与治理
原文始发于微信公众号（绿盟科技研究通讯）：阿里云数据库漏洞分析与思考
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论