Security firm reports vulnerability that allows access to customer cloud environments via AI training service

Security firm Wiz has reported that it has investigated SAP's systems, which provide AI services for businesses, and discovered vulnerabilities that could allow access to customer companies' cloud environments via the AI services.

SAPwned: SAP AI vulnerabilities expose customers' cloud environments and private AI artifacts | Wiz Blog

https://www.wiz.io/blog/sapwned-sap-ai-vulnerabilities-ai-security

SAP's 'SAP AI Core' has a function that uses an access key to read data from other cloud services and use it for AI training. By using the vulnerability discovered by Wiz, a malicious attacker could take over the service and access customer data to contaminate internal deliverables or infiltrate related services or other customer environments.

The overall flow of the attack is shown below. Wiz says that the fundamental problem was that insufficient sandboxing when running AI models allowed attackers to execute malicious code through training with malicious AI models.

Here's how Wiz discovered the vulnerability:

First, I created an AI application as a typical SAP user and started a new Kubernetes Pod using an Argo Workflow file. While any code could be executed within the Pod, network access and other functions were strictly restricted.

So Wiz tried different configurations, and while the admission controller prevented dangerous actions like running the container as root, he discovered that he could use the shareProcessNamespace field to share the process namespace with the sidecar container, which gave him an access token to the cluster's Istio server, which controls the sharing of data between microservices.

In addition, it was possible to become an Istio user using runAsUser and runAsGroup, which gave unlimited access to the network inside the Pod.

Scanning the cluster revealed a Grafana Loki instance, and the Wizard used the API to request the Loki configuration. The response included the AWS secrets that Loki used to access S3.

By using AWS secrets, they were able to access a large number of logs output by the AI Core service and customer Pods stored in AWS S3.

In addition to Loki, we also found an instance of AWS Elastic File System (EFS) on the internal network. The EFS instance is public by default, and if you have access to it, you can view and edit files without authentication. Wiz discovered a large amount of AI data, including actual customer training data.

There were six EFS instances, and a lot of customer data was stored in them.

Continuing to scan the internal network revealed the presence of Tiller, a server component of Helm, a package manager for Kubernetes. Tiller could also be accessed without authentication, making it possible to access SAP's Docker registry and Artifactory servers and launch supply chain attacks.

In addition, by installing a malicious package that generates new Pods with administrative privileges through Tiller, the attacker was able to gain full privileges on the cluster. With full privileges, the attacker could directly access other customers' Pods to steal sensitive data such as models, datasets, and code, or poison AI data to manipulate model inference.

With full permissions, you can access sensitive information outside the scope of the SAP AI Core service.

Regarding the findings of this investigation, Wiz stated that the problem was that the services were set up under the assumption that the internal network was secure, allowing attackers to access a variety of information simply by overcoming the initial network restrictions, and stressed the importance of multi-layered defense.

The vulnerability was notified to SAP on January 25, 2024, and the company has already taken action to address it.