SAP AI 服务脆弱性修复
关键要点
SAP 修复了其 SAP AI Core 服务中的漏洞,这些漏洞可能使攻击者访问共享 SAP 云基础设施中其他租户的敏感数据。研究人员发现这些服务普遍缺乏有效的租户隔离。通过对内部网络的访问,研究人员还发现了大量敏感数据,包括 AI 数据和 AWS 令牌。SAP 最近修复了其 SAP AI Core 服务中的漏洞,这些漏洞可能会让攻击者从共享的 SAP 云基础设施中获取其他租户的敏感数据。研究人员在周三公开披露了这些漏洞,之前这些漏洞在 5 月被修复。这些问题是研究人员发现的第三个 AI 服务未能有效隔离租户的例子。他们之前在 Hugging Face 和 Replicate AI 服务中也发现了类似问题。
研究人员表示:“我们认为这些服务更易受到租户隔离漏洞的影响,因为根据定义,它们允许用户运行 AI 模型和应用程序这相当于执行任意代码。”
Istio 绕过访问内部 SAP 网络
Wiz 研究人员发现,作为 SAP AI 客户,他们在内部网络的活动受到了 Istio 的限制。Istio 是一个开源服务网格,用于管理流量,并充当租户与内部网络之间的一种防火墙。
研究团队使用正常的 SAP AI Core 客户权限生成 Kubernetes Pod,并通过 AI 训练执行代码,试图绕过 Pod 的 Istio 代理侧车,比如以“root”身份运行其容器,但未能成功。
不过,他们最终通过两个没有被阻止的配置实现了绕过“shareProcessNamespace”和“runAsUser”。
前者使他们能够与 Istio 代理共享进程命名空间并访问其配置,其中包括访问群集中集中管理的 Istiod 服务器的令牌,而后者使他们能够以 Istio 的用户 ID (UID) 执行 AI 训练程序即运行代码,该 UID 的值为“1337”。
既然 Istio 本身没有受到类似防火墙的流量限制,作为 UID 1337 运行使研究人员能够在内部网络中横向移动,访问其他租户的服务。
SAP AI 漏洞泄露访问令牌、AI 数据等
通过访问 SAP 的内部网络,研究人员发现了大量敏感数据,攻击者可能利用类似漏洞对其进行破坏。
在一个案例中,他们能够向群集中的 Grafana Loki 实例的 API 端点发送请求,返回的完整配置包括访问该实例 S3 存储桶的 AWS 令牌。该存储桶中包含了其他客户的 SAP AI Core 服务的多个日志。
研究人员还发现了六个实例的 Amazon Web Services (AWS) 弹性文件系统 (EFS),这些实例的默认配置使文件查看和编辑权限在任何拥有网络访问的用户面前都不需要身份验证。
由于他们对 SAP 内部网络的访问以及这六个 AWS EFS 实例的默认配置,研究人员能够获取存储在这些实例上的敏感 AI 数据,包括代码和训练数据集。
然而,研究人员称,“最有趣的发现”是一个未认证的 Helm 服务器,具有读写权限,可能被利用以完全控制 Kubernetes 群集。攻陷 Helm 服务器不仅能访问各种敏感数据,还有可能将恶意代码植入镜像和构建中,导致供应链攻击。
研究人员总结道:“这项研究展示了 AI 研发过程中带来的独特挑战。AI 训练本质上要求运行任意代码;因此,应该有适当的保护措施,以确保不可信的代码能够与内部资产和其他租户得到合适的隔离。”

根据 Wiz 提供的披露时间表,他们的发现最早于 1 月报告给 SAP,2 月进行了初步修复。在 5 月,研究人员演示并报告了绕过 2 月补丁的问题后,所有漏洞的最终补丁完成。