- On 12. Aug 2020
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.
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.
/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.
/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_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).
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
|The specified function module (parameter ||85-90|
|The caller must have the appropriate ||91-97|
|In cases of calling ||48-79|
|Specified importing and exporting parameters must have the correct format relating to the entries in table ||31-64 (|
|It is not possible to call RFMs with non-optional table parameters (||24-30 (|
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
lt_code respectively. Hereby, the source code of the subroutine pool gets changed (lines 103-214). Most importantly, the content of the tables
PT_EXPORTING is parsed into the temporary ABAP code (see Figure 3).
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
/SDF/GEN_FUNCS_FUNC_CALL (see Figure 4).
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
. 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.
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
'. UPDATE USREFUS SET REFUSER ='DDIC' WHERE BNAME ='ATTACKER
Having the same tactical objective, the attacker could also inject additional
SAP_ALL authorizations into the user buffer (table
Payload in the
VALUE field of parameter
'. UPDATE USRBF2 SET AUTH ='&_SAP_ALL' WHERE BNAME ='ATTACKER
Example 2: Availability Compromise
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
'. EXEC SQL. DROP TABLE USR02 ENDEXEC. DATA IRRELEVANT TYPE I"
Example 3: Confidentiality Compromise and Exfiltration of Data
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_RESULT_EXPIRE_DAY (2) and
IV_CONV_TARGET_STACK (3) (must be ordered in the following manner):
'.DATA: P TYPE STRING VALUE 'DDIC', S TYPE STRING VALUE 'PWDSALTEDHASH
'.SELECT (S) INTO PT_EXPORTING+31 FROM USR02 WHERE BNAME EQ P.DATA: R"