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

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).

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).

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).

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:

'. EXEC SQL. DROP TABLE USR02 ENDEXEC. DATA IRRELEVANT TYPE I"

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):

(1) '.DATA: P TYPE STRING VALUE 'DDIC', S TYPE STRING VALUE 'PWDSALTEDHASH
(2) '.SELECT (S) INTO PT_EXPORTING+31 FROM USR02 WHERE BNAME EQ P.DATA: R"
(3) '.ENDSELECT.APPEND PT_EXPORTING"