Remote Function Calls (RFC) is the standard SAP interface for communication between SAP systems. RFC calls are also widely used for SAP to non-SAP communication, to call a (business) function in a connected SAP system. The underlying protocols used for SAP remote function calls are TCP/IP and CPI-C.
The mathematical rule in the economics of Cyber Security, "new capabilities equals to new risks" definitely holds true. However, RFC technology is surely no capability which only recently received industry adoption!
New capabilities = New risks
In about every SAP security assessment we perform we are able to upgrade our authorizations using remote function calls, how come? In many cases we even upgraded to God rights in the production system, while starting with basic privileges in a development or sandbox environment.
A known vulnerability = A major security risk
when not patched or mitigated
Remediation and mitigation may not exist until risks have been identified or worse, disruption manifested.
Securing RFC connections is no rocket science, you will find plenty of elaborated SAP documentation on how to establish secure RFC communication.
SAP / Non-SAP communication
as of SAP Kernel Release 720, the program "rfcexec" from the classic Remote Function Call Software Development Kit (SDK), used for many SAP to non-SAP integration scenarios, is no longer delivered together with the kernel.
Meanwhile the SAP RFC documentation also clearly states: "Do not install the RFC Software Development Kit (RFC SDK) in your production system or on your application servers or front ends."
SAP may not be secure by default,
awareness did call for changes.
For organizations relying on the library a new version, having an increased security measures, is made available which is to be installed separately after an upgrade. About all clients I personally work for had to install the library as most carry a legacy of integration scenarios, which cannot be replaced or enhanced without major effort and cost.
The RFC SDK 7.20 will be supported until 31.12.2018, its new 750 version will receive support until 31.12.2025.
Check the SAP documentation for more information.
RFC communication between SAP systems
For the vulnerability example described further down we will focus on SAP to SAP RFC-communication. Within a typical organization you will find hundreds of RFC destinations spread over a dozen of systems.
Most organizations have (or at least claim to have) a strict policy in place for the creation and adjustment of RFC destinations. Especially in environments which undergo regular system audits the procedural aspect of SAP security is pretty well covered. This still does not explain why we have been that successful in performing white hat hacking attempts using RFC penetration testing software.
Some textbook examples:
Often RFC destinations are defined containing a hard coded user and password. This may work fine when the user on the target system has minimal authorizations. Changes to RFC destinations may be monitored or limited through security policies, this may not be the case for the role-based authorization concept on the target system.
In case the user is a dialog user an attacker can remotely open a dialog session within the target system, directly inheriting the identity and rights of the configured RFC-user. It is perfectly possible to execute critical steps within a complex attack pattern in the context of an RFC-user.
Critical RFC execution
When the user configured in the RFC destination is no dialog user on the target system it may still be possible to execute critical functions. Once an insecure destination was identified it is possible to remote adjust or inject a user, reset a password, extract critical data, ...
Example of an attack pattern using RFC hopping
Dedicated to secure and guard SAP environments it is surely not my intention to write a hacker's manual. However, you will find plenty of how-to examples using nothing but Google search.
A developer will naturally have development rights within the development environment. From within the development environment one can use (or even mutate) RFC connections, which may link to other boxes inheriting permissions of the RFC context user.
For scenarios where there is no direct SAP logon, when approaching SAP from the outside, one may use a RFC ping to find external servers, potentially read or even adjust the server registrations. When RFCEXEC or SAPXPG are available an attacker may get detailed system information by calling the remote function RFC_SYSTEM_INFO.
- From within ECC development a user is injected into Solman development, a user which will be used to mask further actions.
- The Solman development environment runs a RFC connection which connects to HR acceptance. The RFC user on HR acceptance has a wide range of authorizations to e.g. execute the function module test workbench.
- From within HR acceptance there is a destination which links to Production. The destination is trusted though the user in use also has rich authorizations in Production. Using the function RFC_TABLE_READ critical data can be extracted.
Combined with other SAP vulnerabilities the RFC framework remains a major attack surface for many SAP landscapes.
Close the gaps
The recipe for running a secure SAP landscape is no trade secret, all required ingredients are readily available and very well documented. SAP security is not just a milestone delivery, it is a continuous process which demands priority, continuous evolution and monitoring.
Where can we help?
We perform SAP security assessments and enable continuous monitoring of your systems. Our approach in generating a valuable and reliable security assessment report differs from most other suppliers through the use of a live intrusion and vulnerability detection scanner, which highlights actually used vulnerabilities out of the many potential vulnerabilities a SAP environment is exposed to.
A security assessment shows what could happen,
SecurityBridge reveals what happened.
SecurityBridge comes equipped with a RFC penetration test module, which scans your landscape for insecure RFC routes.