Currently many companies follow SAP's strategy to pull customer installations into the cloud. While there may be some advantages, there are also some security risks involved. Let’s take a closer look.
First of all, entrusting a company’s crown jewels to a hosting provider is a decision that demands absolute confidence. Confidence that the hosting provider puts at least the same effort in protecting these crown jewels as the company itself. After all, if the provider fails to deliver cutting edge security, the crown jewels could be destroyed, stolen or held hostage. The consequences for the trusting company would be catastrophic.
Thinking this one step further, the more companies allow a single provider like SAP to host their crown jewels, the more this single provider also becomes a single point of failure. Single points of failure are an attractive target for Denial of Service attacks. And certainly for Ransomware.
When we look at today’s geopolitical climate, a cyber or hybrid war involving Germany is much harder to dismiss than it was 5 years ago. In such a scenario hosting providers could become priority targets. Especially those providers with the largest customer base - the single points of failure. Physical attacks against the data centers of SAP would most probably take thousands of companies offline in the same moment. With little chance of fast recovery. During a recent discussion at the CDRT in Zurich, one participant was quite surprised to learn that the SAP data centers in St. Leon are located alongside other facilities in a standard industrial estate, asking "Are they just standing there in the open like that?". Certainly, tunnels in the Swiss mountains would provide better shelter...
This article, however, focuses on cyber risks rather than physical ones. How effective could a purely non-physical attack be against SAP's hosting model? It is worth looking at the architecture more closely.
SAP offers two distinct cloud models to its customers: SAP RISE (sold as "SAP S/4HANA Cloud Private Edition") and SAP GROW (sold as "SAP S/4HANA Cloud Public Edition").
GROW provides a restricted ABAP development environment — the so-called Embedded Steampunk / ABAP Cloud model — in which customer code may only use released APIs and a constrained subset of the language. RISE, by contrast, provides customers with broadly the same ABAP capabilities they had on their former on-premise systems, including the ability to write and deploy classic ABAP programs.
For an attacker who wants to operate against SAP's hosting infrastructure, a RISE installation is a plausible starting point. A motivated actor — including a nation-state actor — could in principle obtain access either by becoming a legitimate SAP customer (potentially through a front company) or by compromising an existing RISE customer. It is reasonable to assume that a sufficiently motivated party could gain access to some RISE installation by one of these routes.
Any access to SAP RISE would allow an attacker to deploy their own ABAP code in the RISE installation. Since ABAP is by design capable of executing commands as well as storing arbitrary files on the operating system of the SAP installation, it would be easy to deploy and execute OS-based malware from within any SAP RISE system. Detecting custom malware - especially APT-grade malware - would be quite hard on the other end, especially on Linux. There are multiple known cases were APTs lived on Linux systems for significant periods of time before (accidental) discovery. Some APTs managed to stay hidden for years.
For SAP to maintain RISE servers, there must be administrative network access from SAP-controlled systems to every customer installation. However these customer installations will probably be segregated from one another to some extend. A smart malware could try to find an exploit potential weaknesses in SAP’s network security in order to spread to other RISE installations. There are several potential attack vectors from within a compromised Linux installation against administrators logging on remotely. But to be fair, we can't tell if any of them would work in SAP's network environment. From outside, this is necessarily speculation.
However, if the operating system of another RISE server could be reached, it would be easy to gain full access to the installed SAP system, too. Easy because SAP by default installs OS level tools that allow users to deploy ABAP code without needing to authenticate to the SAP system. And such ABAP code would in turn have full read and write access to all business data. Additionally, SAP introduced the “Virtual SAP* User” with release 7.90 that has unlimited privileges and can be activated from the operating system, unless it is explicitly disabled.
As a consequence, the only real challenge to carry out a cross-customer attack would be to overcome network restrictions between the hosted SAP systems. However, ABAP can not only reach out to the operating system of an SAP server. It can also reach out to the operating system of a connected SAP GUI client, especially if this client is running on MS Windows. In such a scenario the rogue ABAP code could execute OS commands with the privileges of the user running the SAP GUI program - potentially an SAP administrator. If such a privilege escalation succeeds, attackers could gain access to client computers of SAP admins. And from there potentially access to other SAP servers that are administered from the same device. Technically such attacks are possible. Their rate of success depends on configuration - or the existence of a zero-day vulnerability in SAP GUI.
The key question therefore is: how well protected is SAP’s infrastructure behind RISE? Only SAP knows, since customers are not given detailed insights. The security of each and every RISE customer depends on SAP's ability to prevent lateral movement between the operating systems of RISE servers. Be it server-to-server movement or server-to-client-to-server movement.
When speculating about SAP's infrastructure security, one may take SAP's product security as a reference. SAP unfortunately has a long an extensive history of various types of security defects in practically all of its solutions. The information they release on their Patch Days provides insights who spotted the corresponding defects - SAP or researchers. We are not arguing that SAP is uniquely insecure — most large enterprise software vendors show broadly similar patterns — but the data does suggest that proactive internal discovery of defects is not a key competence. We discuss the numbers in more detail in our blog post "SAP Security Patch Day decoded: Who’s really keeping your ERP secure?" . These numbers only cover the time span after SAP started the Patch Day. Based on our own experience the situation in the preceding years was no better.
While product security is not infrastructure security, it's still an indication how effective SAP is in providing proactive security.
One additional indication of potential SAP network security issues comes from the Wiz Research Team's study "SAPwned" where they "conducted extensive tenant isolation research" and found vulnerabilities in SAP AI Core. According to WIZ, "The vulnerabilities we found could have allowed attackers to access customers’ data and contaminate internal artifacts – spreading to related services and other customers’ environments." While SAP AI Core is not a RISE environment, this research shows that tenant isolation in SAP environments may not be as robust as expected.
Based on both above observations, it is not entirely unlikely SAP might have overlooked a few security risks in its hosting infrastructure. And these could open the door for lateral movement.
To summarize the above: descending to the OS layer from within SAP RISE (via ABAP) is technically as easy as ascending from the OS layer into SAP RISE (via installed SAP tools). The only real difficulty to compromise other RISE installations lies in lateral movement capabilities between these operating systems. Alongside this cyber-risk dimension there is also a latent risk of physical attacks against SAP data centers, as they are attractive targets for lasting DoS attacks.
Companies should keep this in mind when they weigh the pros and cons of moving their crown jewels into a densely populated cloud environment. No matter who runs this environment.
