Full Report
Wiz Research uncovers vulnerabilities in SAP AI Core, allowing malicious actors to take over the service and access customer data.
Analysis Summary
As a vulnerability research specialist, here is the summary of the findings regarding SAP AI Core, structured for actionable insight.
# Vulnerability: Chain Attack Against SAP AI Core Leading to Tenant Isolation Breach ("SAPwned")
## CVE Details
Since the article details a comprehensive vulnerability chain disclosed privately to SAP and fixed, *specific public CVE identifiers and CVSS scores are not provided in this text*. The research was reported to SAP on January 25, 2024, leading to remediation.
- CVE ID: Not specified in the text (Private disclosure to vendor).
- CVSS Score: Not specified.
- CWE: Likely related to Improper Isolation/Sandboxing (e.g., CWE-284: Improper Access Control, CWE-664: Improper Control of Resource Acquisition or Release) due to cross-tenant access.
## Affected Systems
- Products: SAP AI Core.
- Versions: Undisclosed (Applies to the version running prior to fixes deployed in May 2024).
- Configurations: The attack leverages the ability for users to execute arbitrary code via legitimate AI training procedures (e.g., providing an Argo Workflow file).
## Vulnerability Description
The research discovered a vulnerability chain stemming from insufficient isolation and defense-in-depth measures within SAP AI Core when executing customer-submitted AI models/training jobs (which inherently involves running arbitrary code).
The initial execution context was limited, but researchers identified two key bypasses:
1. **`shareProcessNamespace`**: Allowed process namespace sharing with the Istio sidecar container, which exposed an access token to the cluster’s centralized Istiod server.
2. **`runAsUser(1337)`**: Allowed the execution context to successfully impersonate the Istio user (UID 1337), granting access/privileges associated with that identity.
Bypassing the Istio network restrictions using these methods provided unwarranted access to the internal network, which was implicitly trusted. This led to a complete service takeover, including access to:
* Cluster administrator privileges on the SAP AI Core Kubernetes cluster.
* The ability to read/modify Docker images on SAP’s internal registry and Google Container Registry (for SAP’s images).
* Access to artifacts on SAP’s internal Artifactory server.
* **Crucially, access to customers’ private AI artifacts and cloud access credentials (AWS, Azure, SAP HANA Cloud).**
## Exploitation
- Status: *Disclosed/Fixed*. The vulnerability chain was successfully exploited internally by researchers to demonstrate impact. (Not explicitly stated as "Exploited in the wild" prior to disclosure).
- Complexity: Medium (Required specific, non-standard configuration manipulation within allowed parameters to bypass admission controls and then leverage sidecar identity).
- Attack Vector: Network (Internal lateral movement leveraging container context).
## Impact
- Confidentiality: **High** (Access to customer cloud credentials and private AI artifacts).
- Integrity: **High** (Ability to read and modify Docker images and internal artifacts).
- Availability: **Medium/High** (Potential for disruption via control plane compromise, though the primary focus was data access).
## Remediation
### Patches
- SAP acknowledged the fixes were deployed for all reported vulnerabilities by **May 15, 2024**. Specific patch versions are not detailed in this summary, users should consult SAP security advisories referencing the disclosure date/research findings.
### Workarounds
- The root cause points to insufficient isolation standards for running AI workloads. General workarounds include:
* Implementing stronger sandbox controls on compute environments where untrusted code (AI models) is executed.
* Strengthening internal network segmentation and trust boundaries; internal services should not inherently trust traffic originating from customer compute contexts, even if adjacent (Defense in Depth).
## Detection
- **Indicators of Compromise:** Look for unusual activity originating from customer-provisioned Kubernetes Pods attempting to access internal services like Istiod, internal registries, or Artifactory, especially using escalated or service UIDs (like 1337).
- **Detection Methods and Tools:** Monitoring network traffic originating from container workloads that bypass expected outbound proxies or sidecar egress policies. Review Kubernetes admission controller logs for failed attempts to set restrictive security contexts, as the successful exploitation relied on configurations that *initially* appeared blocked.
## References
- Vendor Acknowledgment: [support.sap.com/en/my-support/knowledge-base/security-notes-news/credits-for-security-researchers.html?anchorId=M7#M7]
- Wiz Research Presentation: [wiz.io/events/blackhat-wiz-talk]
- Previous Research on Hugging Face: [wiz.io/blog/wiz-and-hugging-face-address-risks-to-ai-infrastructure]
- Previous Research on Replicate: [wiz.io/blog/wiz-research-discovers-critical-vulnerability-in-replicate]