多租户技术是一种在云计算环境中广泛使用的架构设计方法，用于在单个应用程序或服务中同时支持多个独立的租户或用户。
在传统的单租户架构中，每个应用程序或服务只为一个租户提供服务。而在多租户架构中，应用程序或服务被设计成可以同时为多个租户提供服务，而且每个租户都被隔离在彼此之间，彼此独立且互不干扰。
多租户技术的关键特点是资源共享和隔离。多个租户共享相同的基础设施，包括硬件、网络和软件组件等，从而实现资源的高效利用。同时，每个租户之间的数据和运行环境是相互隔离的，确保租户之间的安全性和隐私性。
多租户架构通常在平台即服务（PaaS）和软件即服务（SaaS）等云服务模型中得到广泛应用。在这些模型中，云提供商为多个租户提供相同的应用程序或服务实例，而每个租户都可以定制和管理自己的数据和配置。
在云上多租户技术广泛应用的场景下，跨租户漏洞应运而生。跨租户漏洞是指存在于多租户环境中的安全漏洞，可能导致一个租户能够访问或干扰其他租户的数据或资源。这种漏洞可能会引起严重的安全问题，攻击者可以通过跨租户漏洞获取租户的数据或系统控制权，严重破坏了租户之间的隔离性和安全性。
逻辑隔离是一种十分简单的租户隔离方式，租户在共享数据库实例中拥有一个专用数据库。但是每个客户都拥有自己的凭据，来保证不同用户之间的隔离。
这种隔离方式在工业实践中有良好的可操作性，软件架构简单且易于实现，成本较低。但是一旦出现单点故障，将影响数据库实例下的所有租户。
此外，当一个数据库被攻击者攻破后，比如攻击者从当前租户权限提升到管理员权限，攻击者就可以访问其它租户的数据。此外，对于一些运维人员来说，在配置数据库实例的时候，很容易出现配置不当的问题。在这种情况下，攻击者甚至不必利用 0-day 提升权限，通过只是滥用某些错误配置，就可以达到访问其它用户数据的目的。
基于容器的隔离相比于上面的隔离方法具有一定优势。在这种隔离方法中，不再是多个客户共享同一个数据库实例，每个客户都有自己的数据库实例，在相对独立的容器内运行， 并且多个客户可能共享同一个虚拟机。
这种隔离方式同样相对便宜且易于实施。当攻击者想要突破隔离时，需要打破两层安全边界，即：第一层数据库，与上一种方式相同；第二层容器。一旦攻击者从容器中逃逸出来，就可以在虚拟机上执行任意代码，在虚拟机中，可以看到其它租户的容器，并能够访问他们的数据。
虽然这种隔离方式看上去是一个更好的方法，与前面的方法相比，它仍有其缺点。正如一些安全研究人员所认为的那样，容器不被认为是一个非常强大的安全屏障，每隔一段时间 Linux 都会发布一些内核漏洞，部分漏洞通过武器化，可以被用来容器逃逸。
Wiz 团队针对阿里云数据库披露了一个报告，具体细节在第三章节进行阐述。
第三种隔离租户的方法，也是大多数服务提供商倾向于做的，即：基于虚拟机的隔离。在这种隔离方法中，每个租户都有自己的数据库实例，在单独的专用虚拟机中运行。因此，客户现在共享的是物理计算资源，而不是像之前的隔离方法那样，共享一个虚拟机。
如图所示，攻击者想要打破这种隔离方式，需要打破两到三层安全边界，第一层然需要数据库漏洞，能够执行任意代码。第二层可能需要进行容器逃逸，第三层虚拟机漏洞。通常来说，VM 逃逸漏洞更难挖掘。
当每一个租户都有自己专用的虚拟机，云服务提供商的成本变得相当昂贵。与此同时，架构也开始变得很难维护，隔离服务越强，越难实际调试服务，并解决服务中的问题。
租户隔离不仅仅是要实现隔离计算资源。还有有其它资源和其它资产。首先来看，在一个常见的租户隔离系统中，有哪些风险暴露面：
比如像 Kubernetes 或 service Fabric 这样的编排器、内部 API。此外通常托管服务运行在共享网络环境中，数据可以通过共享网络进行交互。另外存储、身份认证设施等也同样需要考虑隔离。
云原生数据仓库AnalyticDB PostgreSQL版是一种大规模并行处理（MPP）数据仓库服务，可提供海量数据在线分析服务。
针对 AnalyticDB for PostgreSQL 的攻击链大致如下：
利用 cronjob 定时任务提权至容器内的 root 权限。
利用 Pod 内容器共享 PID 命名空间的特性横向移动到 Pod 中的相邻特权容器。
利用特权容器逃逸至宿主机。
利用宿主机上的 kubelet 凭证访问敏感资源，包括密钥、serviceaccount 和 Pod。
利用收集到的凭证访问阿里云私有容器镜像仓库，查看凭证权限。
经测试发现凭据具有容器镜像仓库的读取和写入权限，允许发起供应链攻击。
已有相关文章分析该漏洞，在此不做赘述。
在 Azure Database for PostgreSQL 中，不同租户间的数据库并没有做网络隔离，也就是说两个租户间是有网络联通的。Wiz 的研究人员首先通过漏洞获得了对自己数据库的访问权，又因为当前机器能够与其它数据库通信，并通过伪造 SSL 证书，并绕过对其它数据库的身份验证，获取对其它租户数据的完全读取权限。微软对此漏洞的修复是对租户间的网络进行隔离，来保证租户间的相对独立。
IBM Managed Databases 这个案例比较有趣，在这个案例中，IBM 服务的架构比较完善，资源分离也设计得很好，每个租户有专门的 Kubernetes 命名空间：
但是研究人员在容器中发现了 K8S API 的网络连接，同时，由于 K8S 本身配置不当，将高权限 service account 挂在到当前 pod 中，因此可以利用该 Token 向 K8S API 直接发送请求，执行 K8S 相关操作。经过研究人员的测试，该 Token 有在私有仓库拉取镜像的权限：
因此，攻击者可以拿到镜像仓库的所有镜像：
镜像中包含大量数据，包括源码、配置等。通过对镜像内容进行分析，找到内部 CI/CD 服务器凭证，具有读写权限，可以实施供应链攻击。
笔者在公司内部某产品线做安全测试时，也曾遇到过类似的安全问题，由于租户间未做好隔离，导致获取大量租户权限与数据的问题。
以其中一个为例：
在某站点创建远程计算资源（在线 IDE）时，用户会收到一封接入内网的 VPN 配置连接邮件，在拨入 VPN 后，发现内网并未做隔离，租户间网络互通。
直接在内网申请的资源主机上扫 10.208.0.0/16 网段，发现做了隔离。但是，尝试在本机上对 VPN 网段 172.36.0.0/16 进行扫描，发现未做隔离，结果如下：
以内网一台租户申请的机器为例，由于在线 IDE 具有 Terminal 功能，且未对用户权限做校验，因此可以执行命令，在线 IDE 中的用户为 devkit 普通用户：
经过信息收集，发现此类主机均为云上统一下发的机器，查看查询 ECS 的用户自定义数据找到初始化 SSH 登录密钥：
1
curl http://169.254.169.254/openstack/latest/user_data
在 user_data 记录了 SSH 的明文密码，可以直接利用该密码切换到 root:
通过这种方式，可以批量横向到各个租户，获取大量租户资源机器的 root 权限，并登录 SSH，获取机器内存放的各种资源文件。
作者：Geekby 如有侵权，请联系删除
进交流群 请添加管理员
备注：进群，将会自动邀请您加入 渗透测试网络安全 技术 官方 交流群
好文分享收藏赞一下最美点在看哦
还在等什么？赶紧点击下方名片开始学习吧！