ABAP Code Injection

We continue describing categories from the list that we discussed in our Introduction to Secure ABAP Development Guide and pursue “Injections”, a type of vulnerabilities occurs when an application provides no or a bad user input validation. An attacker can inject malicious data, thus performing non-intended actions in a system. Such vulnerability may result in the major SAP risks (Espionage, Sabotage, and Fraud).

Among other things, in ABAP programs, ABAP code itself can be directly injected. It can be done via “INSERT REPORT” and “GENERATE SUBROUTINE POOL” statements. For example:

INSERT REPORT Example

TYPES:
 source_line(72) TYPE c.

DATA:
 src TYPE TABLE OF source_line,
 prg_name type string value 'ZGENPROG'.

PARAMETERS:
 u_input(72) TYPE c.

APPEND u_input TO src.
INSERT REPORT prg_name FROM src.
 SUBMIT (prg_name) AND RETURN.

An attacker can pass malicious code to “u_input parameter” and then execute it. Also, the statement “INSERT REPORT” can pose another danger in case a user input is used to generate a program name. If an attacker knows the name of a critical program, he or she can rewrite its source code by passing the necessary name to the “prg_name” parameter.

GENERATE SUBROUTINE POOL Example

TYPES:
  source_line(72) TYPE c.

DATA:
  src TYPE TABLE OF source_line,
  prg_name TYPE string.

PARAMETERS u_input(72) TYPE c.

APPEND u_input TO src.
GENERATE SUBROUTINE POOL src NAME prg_name.

In this example, the ABAP code from an untrusted source is passed to the subroutine “prg_name” and then executed.

Business Risks

If an unfiltered user input passes to statements “INSERT REPORT” and “GENERATE SUBROUTINE POOL” properly, an attacker can execute arbitrary code, which will lead to different security threats such as reading any business-critical information including HR data or credit cards as well as executing any malicious code on the server.

Besides, an attacker can inject ABAP code in a message log via ‘BAL_LOG_MSG_ADD’ and thus hide the traces of compromising the system.

Remediation

Avoid using a dynamic program generation or use whitelists to restricts an access to specific programs or functionalities. As you can remember from the previous post, CHECK_WHITELIST_STR and CHECK_WHITELIST_TAB methods of CL_ABAP_DYN_PRG class will help you do so:

TYPES whitelist TYPE HASHED TABLE OF string
  WITH UNIQUE KEY table_line.

  PARAMETERS p_input TYPE string.

 DATA(whitelist) = VALUE whitelist( ( `STRING1` ) ( `STRING2` ) ( `STRING3` ) ).

  TRY.
  p_input = cl_abap_dyn_prg=>check_whitelist_tab(
  val = to_upper( p_input )
  whitelist = whitelist ).
  CATCH cx_abap_not_in_whitelist.
  cl_demo_output=>write(
  `Only the following strings are allowed:` ).
  cl_demo_output=>display( whitelist ).
  LEAVE PROGRAM.
  ENDTRY.

The whitelist here contains values ‘STRING1’, ‘STRING2’, ‘STRING3’ – the list of allowed lines of code.

This is all for today and we hope the article has clarified all your questions about ABAP Code injections. Stay tuned and we’ll consider HTTP Header injection in the next post.

The post ABAP Code Injection appeared first on ERPScan.

This is a Security Bloggers Network syndicated blog post authored by Research Team. Read the original post at: Blog – ERPScan