背景

Wiz 的红队小组对 SAP 的 AI 云服务（SAP AI Core）开展了一次渗透测试，发现了其在租户隔离、权限控制等方面存在的严重缺陷，并最终实现了完全托管服务及模拟窃取云服务客户的数据。

攻击路径

Wiz 的研究者绘制的攻击路径图如下：

我们针对这些利用及漏洞逐一进行分析学习。

利用配置不当突破网络限制

AI 云服务顾名思义，是云厂商提供给用户算力和算法平台以辅助 AI 模型类研发的场景。所以购买资源后的用户可被分配一个容器进行训推。

这个环节用户可以运行自定义代码，所以可以视作攻击起点是一个容器 shell 。需要突破的就是针对此场景的隔离策略。

Wiz 的测试人员最先尝试的就是给 Pod 配置更高级别的 privileges。并发现 SAP 部署了准入控制器以阻止绕过安全选项的行为，比如以 root 权限运行容器。

“

关于准入控制器

Admission Controller

功能是拦截通过认证和鉴权之后，对象被持久化之前到达API server的请求。

常用命令：

启动 x 和 y 两个准入控制插件：

kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger

关闭准入控制插件：

kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny,xxx

”

Wiz 的应对策略是：寻找未被准入控制器阻止的配置，尝试提权。

他们发现的第一个配置是：shareProcessNamespace。

这项配置为 ture，可以使 Pod 中的容器共享进程命名空间。因此创建的容器可以和边车容器共享进程命名空间。又因为边车容器是 Istio 代理的，所以 Wiz 的攻击者可以有权限获取 Istio 配置，其中就包括敏感信息：Istiod server 的 token。

“

关于边车容器

Sidecar Container

通常的 Pod 只有一个应用程序容器（比如 web 应用），而使用边车模式运行的如 Web 服务，Pod 下存在边车容器（本地 Web 服务器）与应用程序容器并行运行。

Istio 支持 Sidecar 边车模式。参考官网说明文档：

  https://istio.io/latest/zh/docs/setup/

”

仅有 token 还是不够的，没有其他信息的情况下无法利用。但由于 Istio 的边车模式 proxy 容器的网络是受限的，无法扫描网段。怎么办？

于是 Wiz 发现了第二组配置：runAsUser 和 runAsGroup。

这个大家都不陌生了，securityContext.runAsUser 配置 Pod 中所有容器内进程使用的用户 ID。Wiz 攻击者发现虽然此配置无法以 root 用户的 UID 运行，但高权限用户不止 root 一个，其他的 UID 未被阻止，最终使用 Istio 用户的 UID 成功运行。而占用 UID 1337 的攻击操作或误操作，Istio 对此仅打出 Warning 级消息提示，不会阻断。

PS：Istio 的边车模式 proxy 容器默认以 UID 1337 运行。

Wiz 认为因为 Istio 用户是个“特权用户”不受 Istio iptables 的限制，所以可以扫描网段。但是笔者根据 Istio 文档的说法分析，应该是 Wiz 攻击者以 UID 1337 运行后，导致 iptables 配置发生了冲突，没有生效导致的。

总之，Wiz 攻击者利用此配置突破了流量限制，可以扫描 Pod 内网，再结合利用第一项配置取到的 token ，成功访问 Istiod 服务器读到配置。

本环节的攻击是全部渗透测试过程最关键的一环，后续的攻击都以此为起点，并主要去证明企业网络纵深防御的重要性。

Wiz 在总结中同样认为，他们面对的最大困难就是 Istio 阻止攻击流量进入内网，一旦突破这一点，其余的环节均是无权限压力的对内网资产的信息收集和综合利用。

集群日志实例信息泄露

Wiz 攻击者发现了集群上的一个 Grafana Loki 实例，从 /config 接口取到了用于 AWS 对象存储的 aksk，并获取大量 AI Core 和用户的日志。

“

Grafana Loki 是一个日志工具，查阅它的接口文档，确实发现了 /config api

”

弹性文件系统使用默认配置

AWS Elastic File System (EFS) 的默认配置为公共，因此 Wiz 攻击者内网扫到监听 2049 端口的 6 个 EFS 实例后，不需要凭据就可以增删改文件。包括客户的 AI 训练数据集。

“

查阅 AWS 文档，发现 AWS 的表述为默认禁止公开访问：

但是下面煞有介事的解释了“public”策略的含义：

在之前 Wiz 的某次演讲表明，EFS 确实是默认策略为公开，所以可能是 AWS 已经对此做了修改

见：https://www.youtube.com/watch?v=HcNmkCRXFdE

”

利用 Helm 服务器无鉴权进行供应链攻击

Wiz 攻击者发现一个名为 Tiller 的服务，部署的是 Helm 包管理器的服务器组件。和 Tiller 服务的通信要走 44134 端口的 gRPC 接口，此端口无鉴权。

访问此服务器，Wiz 攻击者获取到 SAP 的 Docker Registry（Google） 及其 Artifactory 服务器的高权限 secret。可以用来窃取高商业价值客户数据，或者直接污染 AI Core 包做供应链攻击。

利用 Helm 服务器无鉴权接管 K8s 集群

Wiz 攻击者利用 Tiller 的 install 命令，部署了一个恶意 Helm 包到 K8s 集群，这个恶意包会生成一个具有 cluster-admin 权限的新 Pod。实现了接管 K8s 集群。

由于此时已经具备 K8s 集群最高权限，Wiz 攻击者不仅可以访问任意客户的 Pod，窃取、干扰其 AI 训练数据和模型，甚至可以访问超出 SAP AI Core 范围的客户自己的机密信息。

同时，Wiz 攻击者还取到了 Google Container Registry 的名为 sap-docker-registry-secret 的 SAP 访问密钥。

此密钥有读写权限，可以扩大对 SAP 做供应链攻击的范围（影响除 AI Core 外的其他服务）。

Wiz 仅以 AI Core 服务的普通租户为起点，黑盒打穿了整个 SAP 云，成果惊人！漏洞细节及攻击思路整理完毕，有些不易说清的攻击逻辑还需要读者自己沉下心品味。