Black Hat Flaws in SAP's Core AI service created a gateway to its customers' private data, including code and training materials, until they were patched earlier this year.

This is according to vuln finders at Wiz, which responsibly disclosed details on the five previously unreported - and since patched - bugs within Core AI that it dubbed SAPwned.

The report landed ahead of the Black Hat conference, where the infosec crew will be presenting their findings at their talk, "Isolation or Hallucination? Hacking AI Infrastructure Providers for Fun and Weights."

SAP patched the flaws in May, a few months after Wiz told the German ERP software company about the vulnerabilities.

The Wiz team claimed in the report that exploiting just a single permissions oversight was all it took for the team to gain access to SAP's internal network, among other details. The team said it started by giving an Argo Workflow file to Core AI in order to make a Kubernetes Pod; nothing unusual so far. Wiz notes that it could execute arbitrary code within its Pod, but that a lack of network access via an Istio proxy sidecar made it pretty useless.

However, obtaining that network access wasn't difficult, it seems. SAP had disabled settings that were obviously dangerous, but apparently its admission controller overlooked the shareProcessNamespace and runAsUser options. The former could be used to make the Pod share the name of the sidecar and get Istio's access token, and then the latter was used to run everything as coming from that vendor.

From there, Wiz said it gained access to an instance of Grafana Loki and its AWS-hosted data that included logs and customer Pod info, six instances of AWS Elastic File System (EFS) which contained customers' training data and code, and a Helm server. The researchers seemingly didn't need to find any extra credentials or exploits from here since everything appeared to have been pretty much just left open, according to the report.

Wiz says that by default, EFS and Helm are on specific ports (which they were in SAP Core AI); plus AWS's storage commonly has its default configuration set to public. The infoseccers said the six EFS instances collectively yielded "mass amounts of AI data."

Of particular concern was the Helm server, say the researchers, adding that, like the EFS storage, it contained lots of customer data, but also software builds and images. That's bad enough, but Wiz said it also discovered that the Helm server was exposed to both read and write operations, meaning an attacker could have performed a supply chain attack by replacing good builds and images with ones riddled with malware.

Write access also meant they could install a Helm package to create a Pod with admin permissions, granting unfettered access to basically everything that AI Core touched. This is pretty much the worst-case scenario for cybersecurity.

Thankfully, an SAP representative told The Register that "no SAP customer data or systems were impacted by these vulnerabilities."

The Wiz team was keen to warn the tech community "that AI models and training procedures are essentially code." Wiz security researcher Hillai Ben-Sasson told us that when AI models and procedures "come from an untrusted source, they should be treated as such, and their execution must be properly isolated from any other assets."

Ben-Sasson added: "The specific vulnerabilities we found stemmed from misconfigured services within the internal network. However, the root cause was the ability for attackers to run malicious AI models and training procedures on SAP's infrastructure. This allowed us to gain initial access to the shared network."

"It seems like a lot of trust was placed on the firewall component that was supposed to separate untrusted customer compute from sensitive internal services. However, once we were able to bypass the firewall product, we immediately had free access to the internal network. Proper isolation should be based on multiple 'security barriers,' a number of obstacles that an attacker has to pass. The previous service setup contained only one security barrier, a 'single line of defense.' Once that line is breached, the ability to compromise internal services becomes much easier."

It did not take much time for SAP to sort out an initial fix. Wiz reported the bugs in late January, and a patch came out about three weeks later to fix the Istio exploit.

However, by the end of February, the researchers said they found two new bugs that granted internal network access yet again. By mid-May SAP had fixed all the vulnerabilities.

Ben-Sasson told The Reg: "It would make sense for SAP to prioritize a fix for the firewall bypass vulnerability, as all the other vulnerabilities we reported were dependent on it. This could allow them to quickly and efficiently eliminate the entire attack flow, and then continue to fix the rest of the issues. This is an industry best practice. The SAP security team were very professional in their communications, and kept us updated on the fixes they deployed to make sure we could verify them."

"Our research into SAP AI Core demonstrates the importance of defense in depth," Wiz says. "The main security obstacle we were facing was Istio blocking our traffic from reaching the internal network. Hardening those internal services could have minimized the impact of this attack and downgraded it from a complete service takeover to a minor security incident." ®

https://www.theregister.com//2024/08/06/sap_core_ai_bugs_granted/