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

Security firm Wiz has investigated SAP's systems, which provide AI services for businesses, and has discovered a vulnerability that could allow an attacker to access the cloud environment of a customer company via the AI service.
SAPwned: SAP AI vulnerabilities expose customers' cloud environments and private AI artifacts | Wiz Blog

SAP's 'SAP AI Core' has a feature that uses access keys to read data from other cloud services and use it for AI training. By exploiting 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 attack flow is shown below. Wiz states that the fundamental problem was that insufficient sandboxing when executing AI models allowed attackers to execute malicious code through training using malicious AI models.

Here's how Wiz discovered the vulnerability:
First, we created an AI application as a typical SAP user and launched a new Kubernetes pod using an Argo Workflow file. While arbitrary code could be executed within the pod, network access and other functions were strictly restricted.

So Wiz tried various 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, giving him an access token to the cluster's Istio server, which controls the sharing of data between microservices.

Additionally, it was possible to use runAsUser and runAsGroup to become an Istio user, which gave unrestricted access to the network within 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 stored in AWS S3, including logs from the AI Core service and customer pods.

In addition to Loki, Wiz also found an instance of AWS Elastic File System (EFS) on the internal network. The EFS instance is public by default, meaning that anyone with access to it could 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 on them.

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

Additionally, by installing a malicious package that spawned a new Pod with administrative privileges through Tiller, the attacker was able to gain full privileges on the cluster, allowing them to directly access other customers' Pods and 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 results of this investigation, Wiz stated that the problem was that the service was set up under the assumption that the internal network was secure, which allowed 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 reported to SAP on January 25, 2024, and the company has already taken action.
Related Posts:
in AI, Software, Web Service, Security, Posted by log1d_ts







