Dynamic ABAP Calls

With this article, we start the second section of Secure ABAP Development Guide called ‘Critical Calls’.

Not only injection vulnerabilities are able to harm the systems but also some statements in ABAP. In this category, most of them (not all!) are not so severe as injections but the inadvertent operation can lead to critical vulnerabilities.

This section is divided into several topics:

1. Dynamic ABAP Calls [EASAI-AD-05]
2. Dynamic Code Execution [EASAI-AD-06]
3. Native SQL [EASAI-AD-07]
4. Sap Technology Development Statements [EASAI-AD-08]
5. Function Modules Critical Calls [EASAI-AD-09]
6. Highly Critical Calls [EASAI-AD-10]

Today we’ll go briefly into Dynamic ABAP Calls and run through business risks and remediation.

In ABAP, there are few dangerous dynamic calls. They can be used:

• to call system function via CALL statement;
• to execute a report (program) via SUBMIT statement;
• to call function module via CALL FUNCTION statement;
• to call transaction via CALL TRANSACTION or LEAVE TO TRANSACTION statements.

Generally, those calls are acceptable, but if they got an input from the untrusted source (such as user input), it can result in serious repercussions.

Dynamic generated program name in SUBMIT statement is provided as an example:

PARAMETERS rep TYPE string.
DATA: jobname TYPE string.
DATA: jobcount TYPE i.
 
SUBMIT rep
  via job jobname number jobcount
  with update = ' '
  with active = 'X'
  with verbose =' '
  and return.

Consequently, the attacker can call any (!) executed program by providing it as an input to REP variable.

Business Risks

Using user input data in this statements can lead to serious security hole that allows an attacker to execute any existing report in the system thus perform different types of attacks depending on the report functionality:

• espionage – an access to business-critical data;
• fraud – the substitution of data;
• sabotage – the damage to business-critical systems along with the downtime that can be estimated at hundreds of thousands of dollars.

Remediation

It’s recommended to use whitelists of allowed programs, functions or transactions. Whitelisting can be implemented by means of CHECK_WHITELIST_STR and CHECK_WHITELIST_TAB methods of CL_ABAP_DYN_PRG class.

An example is provided below.

TYPES whitelist TYPE HASHED TABLE OF string
  WITH UNIQUE KEY table_line.
 
  PARAMETERS prg_name TYPE string.
 
  DATA: jobname TYPE string.
  DATA: jobcount TYPE i.
 
  DATA(whitelist) = VALUE whitelist( ( `ZPROG1` ) ( `ZPROG2` ) ( `ZPROG3` ) ).
 
  TRY.
  prg_name = cl_abap_dyn_prg=>check_whitelist_tab(
  val = to_upper( prg_name )
  whitelist = whitelist ).
  CATCH cx_abap_not_in_whitelist.
  cl_demo_output=>write(
  `Only the following reports are allowed:` ).
  cl_demo_output=>display( whitelist ).
  LEAVE PROGRAM.
  ENDTRY.
 
  SUBMIT prg_name
  via job jobname number jobcount
  with update = ' '
  with active = 'X'
  with verbose =' '
  and return.

In this example, user-controlled variable ‘prg_name’ that contains program name is checked by using whitelist that contains values ‘ZPROG1’, ‘ZPROG2’, ‘ZPROG2’, so any other program can not be executed.

That’s it for Dynamic ABAP Calls. The next entry of ‘Critical Calls’ section will cover Dynamic Code Execution.

Keep in touch and follow us on Twitter, Facebook, and LinkedIn and get more information from our ERPScan Research team.

The post Dynamic ABAP Calls appeared first on ERPScan.