Limiting What a Compromised SAP Account Can Do on the Server

Inside SAP, roles and authorizations decide who can do what. On the server underneath, none of that exists. Linux sees a dedicated operating system account, and everything SAP does there, from writing logs to running background jobs, runs through it. If someone gains privileged access inside SAP, the operating system account is the next thing within reach.

Project Ironroot, a joint effort by Fortinet, No Monkey, PwC, and Red Hat, tested how much damage an attacker could do with that account and developed SELinux policies for Red Hat Enterprise Linux to limit it. The work is set out in “No More Free Passes into the Operating System: Detecting and Containing Attacks on SAP Environments,” an article by Matthias Czwikla, Red Hat’s Global SAP Partner Ecosystem Manager. A whitepaper, “Mitigating OS-Level Security Risks from SAP Application Access with SELinux and fapolicyd,” carries contributions from Czwikla and his Red Hat colleagues Bernd Finger and Christoph Brune, as well as contributors from Fortinet, No Monkey, and PwC.

How Far a Compromised SAP Account Can Reach

Attackers can get into SAP through stolen credentials, vulnerabilities, or misconfigurations. Most security programs focus on keeping them out. Project Ironroot asked a different question: once someone is in SAP with privileged access, what can they do on the server? To find out, the team built a controlled test environment and played the attacker.

The team found that a great deal was possible using nothing beyond standard SAP functions. It browsed system files, wrote a small script to the server, and ran it, which returned a harmless “Hello from the OS.” A further test used a built-in SAP report to open a reverse shell, a connection from the server out to a system the attacker controls.

These actions were possible because SAP’s permissions end at the server. SAP is designed to read files and run jobs on its host, so the operating system sees only the account that does the work and treats everything it does as legitimate.

At that point the problem is no longer confined to SAP. The attacker can then work much as someone logged in to the server as that SAP account would, and the whitepaper notes the exposure can reach connected systems, such as file shares and backup systems.

How Red Hat Enterprise Linux Can Limit a Compromised SAP Account

After the attack worked, the team applied controls built into Red Hat Enterprise Linux (RHEL) and repeated the same attacks. SELinux limits what a program may touch, even when it runs as a trusted account, and fapolicyd limits which programs may run at all.

But switching SELinux on was not enough for SAP, the whitepaper reports, because SAP’s processes ran without a policy written for them. Ironroot then built that policy, with modules for SAP HANA, SAP NetWeaver, and the SAP Host Agent, so each stays within its own files. Before the policy, a NetWeaver administrator could read a HANA file through a shared administrator group. After it, the same read was denied.

fapolicyd covers what runs. In the repeat test, it blocked the test script until the script was added to the list of trusted programs, which stops an attacker from launching tools of their own. SELinux also records its denials in the audit log, so a blocked attempt is recorded as well as stopped.

The controls worked where they were applied. An attacker could no longer read files across SAP components or run programs that were not trusted, and a compromised account no longer gets automatic access to the rest of the landscape.

What Organizations Can Do Now, and What Is Still Being Tested

Whether an organization can use these controls today depends on who runs its operating system.

Organizations that run their own landscapes can implement many of them themselves. Red Hat offers a no-cost, 60-day trial of RHEL for SAP Solutions, and its documentation covers configuring SELinux and fapolicyd for SAP HANA.

RISE with SAP customers generally have no direct access to the operating system. The whitepaper says responsibility for its administration and hardening largely sits with SAP, though the boundary between application and host remains.

The Ironroot policies themselves have so far been validated only in test environments, on SAP S/4HANA running RHEL 9 and 10, and the whitepaper calls them a technical starting point that needs adapting to each landscape. The Ironroot team is looking for pilot participants.

The whitepaper is equally direct about limits. The controls do not close every gap, and rules set too strictly can stop an SAP instance from starting. The recommended path is gradual: record what SAP normally does, test the rules against it, review what they block, then enforce.

What This Means for SAPinsiders

SAP security does not end at the application. A compromised account reaches the server and the systems connected to it, so a program built only on roles and authorizations covers part of the exposure. Extending it to the operating system shows security teams the full distance one account can travel.

Containment belongs next to prevention. Ironroot starts from the assumption that an attacker gets in, and asks how much damage the server layer allows. Organizations that plan for a successful intrusion limit the consequences of a breach their other defenses miss.

Responsibility for this layer depends on how SAP is run. Self-managed landscapes put the operating system in the customer’s hands, while RISE with SAP largely places it with SAP. Knowing which applies shows an organization whether it is building these controls or asking its provider about them.