Code Injection in SAP Application Server ABAP - Solution Tools Plugin ST-PI


As one of the largest business software providers, SAP SE products are widely used by companies in all industry sectors all over the world. Vulnerabilities in the core solutions from SAP SE can affect the heart of corporate IT infrastructures.

Code injection in SAP main pic - SEC Consult


During analyses of different Remote Function Modules (RFMs) built upon the fundamental SAP NetWeaver Application Server ABAP, SEC Consult identified a critical vulnerability in the proprietary ABAP code. During our investigations of the /SDF/GEN_FUNCS_FUNC_CALL RFM, an ABAP code injection vulnerability was identified enabling unauthorized code execution, sensitive information disclosure, and denial-of-service (DoS) attacks. This blog post outlines previously unreleased technical details of CVE-2020-6262 and showcases its potential impact on mission-critical business systems.

The module /SDF/GEN_FUNCS_FUNC_CALL is part of the ST-PI plugin which is used in SAP landscapes for central administration with the Solution Manager (SolMan). As such, the module is present on all satellite Netweaver ABAP systems connected to the SolMan.


Function module in transaction screen - SEC Consult
Figure 1: Function module /SDF/GEN_FUNCS_FUNC_CALL in transaction SE37.

The RFM /SDF/GEN_FUNCS_FUNC_CALL of the function group /SDF/GEN_FUNCS can call other RFMs. To do so, it features one import parameter FUNCNAME to specify the desired RFM and two tables PT_IMPORTING and PT_EXPORTING for the corresponding importing and exporting parameters of the RFM to be called. The user can utilize these tables to supply import and export parameter names, types, as well as values for the import parameters themselves (see Figure 1 and Figure 2).

Specs of the function module screen - SEC Consult
Figure 2: Specifications of the function module /SDF/GEN_FUNCS_FUNC_CALL.

Before calling the requested RFM, the /SDF/GEN_FUNCS_FUNC_CALL module performs several checks on the provided user input. In this manner, some restrictions on the choice of the RFM are applied. The following table shows the limitations of the function modules that can be called via /SDF/GEN_FUNCS_FUNC_CALL:

Limitation Check Lines
The specified function module (parameter FUNCNAME) must be remote enabled 85-90
The caller must have the appropriate S_RFC (FUGR; ACTVT 16) authorizations for the function group of the called RFM 91-97
In cases of calling APPL_LOG_DISPLAY, SUSR_USER_MAINT_WITH_DIALOG or TOPOLOGY_BROWSER additional authorizations are required 48-79
Specified importing and exporting parameters must have the correct format relating to the entries in table FUPARAREF 31-64 (/SDF/GEN_FUNCS_IF_CHECK)
It is not possible to call RFMs with non-optional table parameters (PARAMTYPE T in table FUPARAREF) 24-30 (/SDF/GEN_FUNCS_IF_CHECK)
Writing of source code of subroutine pool screen - SEC Consult
Figure 3: Construction of the source code of the subroutine pool within /SDF/GEN_FUNCS_FUNC_CALL.

To call the specified RFM, the module /SDF/GEN_FUNCS_FUNC_CALL dynamically generates an internal ABAP report (through the use of the GENERATE SUBROUTINE POOL instruction; see line 217) during run time. For this purpose, predefined instructions and user input are concatenated into the variables lf_code and lt_code respectively. Hereby, the source code of the subroutine pool gets changed (lines 103-214). Most importantly, the content of the tables PT_IMPORTING and PT_EXPORTING is parsed into the temporary ABAP code (see Figure 3).

Generation & Execution of subroutine pool screen - SEC Consult
Figure 4: Generation and Execution of the subroutine pool within SDF_GEN_FUNCS_FUNC_CALL.

Following the successful initialization of the subroutine pool, the generated code segment is executed. Within the program logic, this in turn leads to the specified RFM being invoked. Subsequently, the results of the conducted call are returned to the end-user via the VALUE field of the table PT_EXPORTING in /SDF/GEN_FUNCS_FUNC_CALL (see Figure 4).

Writing of source code of subroutine pool screen - SEC Consult
Figure 5: String quotation bypass example payload in PT_IMPORTING.
Figure 6: Injected ABAP code in the subroutine pool.

The use of the function module /SDF/GEN_FUNCS_FUNC_CALL should be clarified. Acting as a proxy module, it allows the restricted execution of other RFMs. Whereas the module itself verifies the existence of the corresponding S_RFC authorizations of the user, the called RFM may conduct further additional authorization checks through its programmatic implementation.

During investigations, we observed that data from the VALUE field within the table PT_IMPORTING never gets checked for malicious input or is otherwise validated or sanitized. In consequence, an attacker can break out of the desired syntactic instructions. Injecting ABAP code in the VALUE field allows the attacker to manipulate the source code of the generated subroutine pool and thereby the execution logic of the entire module. Since the attacker can freely choose the characters that can be used in this field, arbitrary ABAP code can be injected. To exploit this behavior an attacker can supply special characters like ‘ and . to escape the string quotation that is built into the source code. Afterwards an attacker can simply specify any semantically valid ABAP code that gets executed by the application server (see Figure 5 and Figure 6).


Keeping the number of authorizations required for successful exploitation as low as possible, suitable RFMs were searched for as input parameters, which meet the requirements mentioned above and do not need further authorizations. As it turns out, it is possible to use specific RFMs from the function group /SDF/GEN_FUNCS itself. Consequently, the authenticated attacker only needs the S_RFC authorizations (see Figure 7). Additional authorization checks within the selected RFM are irrelevant since the injected payload will be executed before the application logic of the RFM is reached.

Injected ABAP code screen - SEC Consult
Figure 7: Authorization trace during exploitation in transaction ST01.

Note The distribution of wildcard (*) S_RFC authorizations is quite common in corporate SAP landscapes. Especially system or service users will usually be equipped with full authorizations for this object as a preventive measure to avoid potential occurring complications in the productive use of remote and background services.

To assess the impact of this vulnerability several payloads have been tested. Following the least-privileges approach, the RFM /SDF/GEN_FUNCS_S4_RELEVAN_CHK has been used for demonstration purposes. The following examples illustrate how an authenticated attacker can compromise all three security goals (Integrity, Availability, and Confidentially) using different payloads and bypassing existing restrictions. Please note that the provided screenshots demonstrate the exploitation throughout the transaction SE37. Nevertheless, Figure 12 is intended to show that the exploitation can be scripted and be performed via RFC over the network.

Example 1: Integrity Compromise and Privilege Escalation

The following proof-of-concept demonstrates how an attacker can assign himself the reference user DDIC by injecting an OpenSQL query and thus gaining unlimited authorizations on the affected SAP system (see figure 8).

Payload in the VALUE field of parameter IV_CONV_TARGET_STACK:


Attacker inherits authorizations from DDIC user reference table - SEC Consult
Figure 8: Reference user table that shows that the attacker inherits the authorizations from the all powerful DDIC user.

Having the same tactical objective, the attacker could also inject additional SAP_ALL authorizations into the user buffer (table USRBF2).

Payload in the VALUE field of parameter IV_CONV_TARGET_STACK:


Example 2: Availability Compromise

Successful deletion of system table screen - SEC Consult
Figure 9: Deletion of the system table USR02 was successful.

The following proof-of-concept demonstrates how an attacker can disrupt the functionality of an SAP system by deleting essential system tables (e.g. USR02) using native SQL (see Figure 9).

Payload in the VALUE field of parameter IV_CONV_TARGET_STACK:


Example 3: Confidentiality Compromise and Exfiltration of Data

Payload dev for data exfiltration with multiple input parameters screen - SEC Consult
Figure 10: Payload construction for data exfiltration using multiple input parameters in PT_IMPORTING.

The following proof-of-concept demonstrates how an attacker can exfiltrate data (e.g. user password hashes) of an SAP system.

It must be noted that an attacker is limited by the character length (71 chars) of the VALUE field in the table PT_IMPORTING. All other previously mentioned payloads didn’t exceed this limit. However, for extensive exfiltration of data, it is necessary to combine payload substrings throughout different importing parameters (see also Figure 10 and Figure 11). In this manner, the limitation is bypassed and all the information laying within the database (e.g. transactional data or customer data) could potentially be exfiltrated by the attacker abusing the PT_EXPORTING table (see Figure 12 and 13).

Payload substrings in the VALUE fields of the parameters IV_TEST_API (1), IV_RESULT_EXPIRE_DAY (2) and IV_CONV_TARGET_STACK (3) (must be ordered in the following manner):


Note Previously described proof-of-concepts summarized alternatives to compromise the confidentiality, integrity, and availability of the affected SAP systems. Most notably, example 3 has shown that the attacker can bypass character-length related limitations and therefore is not restricted in the injection of arbitrary ABAP code. Hence, several additional attack vectors arise:

  1. Invoking OS commands in the context of the <sid>adm user via different kernel calls (e.g. CALL SYSTEM)
  2. Putting connected SAP systems at risk by abusing stored RFC destinations (e.g. via CALL FUNCTION <RFM> DESTINATION)
  3. Putting connected SAP systems at risk by exfiltrating the content of secure storages (e.g. Secure Storage in the Database RSECTAB)
  4. Establishing backdoors for post-exploitation access.


SEC Consult contacted the SAP® Product Security Response Team in April 2020. SAP has since released an SAP Security Note 2835979 to address the issue. The note was made available in the Patch Tuesday in May 2020. As such, SEC Consult advises all SAP customers to implement note 2835979 immediately.

SEC Consult would like to thank the SAP® Product Security Response Team for their very fast and professional handling of this vulnerability.

For more information check out:

This research was conducted by Alexander Meier and Fabian Hagg on behalf of the SEC Consult Vulnerability Lab.

Want to improve your own cyber security with the experts of SEC Consult?