(In)security in the SAP landscape
The answer can be found in the SAP landscape, or rather in the Q and Dev systems, solution managers and legacy systems, as well as the users' clients, which the auditors did not have in view. Incomplete or incorrect configurations within the SAP landscape can ultimately lead to the compromise of systems classified as secure.
Two exemplary scenarios illustrate typical "side attacks" on seemingly highly secure and productive systems. Through these, an attacker can gain extensive access without exploiting a vulnerability or misconfiguration in the target system.
Attacks via the workplace
The first scenario describes the path via a user's PC into the productive and highly secure SAP system: Whether phishing, ransomware, APT campaigns or the next wave of malware such as WannaCry, it unfortunately happens time and again in companies that client PCs are hijacked and remotely controlled despite all protective measures such as antivirus programs or firewalls.
Once attackers have control of a client, access is quickly extended to other clients (lateral movement). It is only a matter of time before an attacker controls the client of an SAP Basis or user administrator. This is because it is much easier to gain access via attacks on Windows systems and on the user than it is to attack the SAP system directly.
In addition, many companies use single sign-on (SSO) for authentication to eliminate passwords. As long as no 2-factor authentication is in use, SSO is very well suited for attackers as a door opener into the SAP system - and without a single password! Because as long as the attacker is in the context of the SAP admin on his PC, the SSO mechanism handles authentication in the background, and the attacker can access the SAP system directly and without further effort in the context of the admin user. All the attacker needs to gain access is a few Powershell scripts and an RFC connection to the SAP system.
2-factor authentication
To effectively protect against such attacks, 2-factor authentication is absolutely necessary. In the second scenario, RFC destinations between SAP systems play a crucial role. Whenever new features or releases need to be tested, a sandbox system is not far away. The complete production system is often copied here to enable a realistic test.
The developers or testers are given increased rights in the sandbox system to quickly identify and solve problems. But this sandbox system can quickly lead to the fall of the productive system, which is rated as highly secure. This can happen as soon as a remote function module for password reset and an RFC destination to a productive system can be selected. A selected target user then receives a new password - and the attacker can access the productive system unhindered. Such attacks can be prevented by consistently not allowing privileged connections from "lower" to "higher-class" systems. In addition, all critical RFC destinations must be removed from the sandbox after the system copy.
Even very secure systems with little effort can be compromised. To assess system security, the entire SAP landscape must be checked. Checking only the productive systems or only the ERP line leads to an incomplete assessment. It is important to have auditing software that performs this holistic work. Only those who have an overview of their SAP landscape can effectively identify and prevent side attacks on critical systems!
