Backdoors in SAP ABAP Code Part-1

ABAP Intro:

ABAP is SAP's proprietary programming language used since last 30years. Almost 90% of the Business logic and functionality were written in ABAP. SAP delivers standard Business functionality and with standard programs(Developed by SAP, Shipped during installation). Any new developments or modification to ABAP Programs are logged in the system and later moved to Production system via SAP Change And Transport System (CTS).

Modification to Standard Programs:

SAP will not allow their customers to modify Standard Programs, but instead customers can perform modifications to standard ABAP programs only after following a process called SAP Software Change Registration (SSCR). According to this registration, SAP does not guarantee that the modified programs will not be overwritten in the future SAP upgrades.

Custom Developments:

In order to meet the business requirements of their customers, SAP allows them to develop their own custom ABAP programs and custom business scenarios via builtin development environment. All the custom developments and program names will start with letters 'Y' and 'Z' (also called zprograms).

ABAP Backdoors:

Like many other application, SAP is vulnerable to backdoors. Backdoors can be used to bypass authorization checks and authentication mechanisms in an application. These backdoor can take different forms like hardcoded usernames within ABAP program, hardcoded credentials in RFC connections without use of encryption, Maintaining default User names and Password.

All the SAP standard and custom ABAP programs are stored at Database level in table "REPOSRC". Source code of all the programs exists in "DATA" field of table "REPOSRC" in compressed format.

Hard-Coded Usernames:

It's been found that many custom developed ABAP programs contain hardcoded usernames like below code snippets and were moved to Production systems. Even the SAP Standard Programs have room for hardcoded usernames, these hardcoded usernames were left by developers for testing purpose and were delivered to the SAP customers. Attacker can take advantage of these hardcoded usernames to bypass security controls and can perform critical business transactions.

Lets check the first ABAP code snippet with hardcoded Username "Dev":

...
Snippet-1
.........
TABLES: USR02.
 DATA:  YLOCK(1) TYPE X VALUE  '0', ZLOCK(1) TYPE X VALUE '64'.
 parameters: client like sy-mandt.

CHECK SY-UNAME = 'Dev'. (SY-UNAME contains the name of currently logged-on user)

      select * from usr02 client specified
       where mandt = client.
       usr02-UFLAG =  ZLOCK.
       UPDATE  USR02 client specified.
      endselect.
...

Execution Flow:

• Program checks if the current user account is "Dev" or not.
• If the current user is "Dev", system locks all the users available in the specified client.
• If the user is not "Dev", it does nothing.

Risk:

• In general, locking down all the users in an SAP system can lead to DOS(Denial Of Service) attack.
• Here an attacker can take advantage of these hard-coded checks to bypass security controls.
• In this case, if attacker creates the user account "Dev" and execute the program in Production system. All users will be locked.

Snippet-2 with hardcoded Username "DEVELOPER"

ABAP System field "SY-UNAME" in the code snippets always contains the name of currently logged-on user. ABAP developers make use of statement "AUTHORITY-CHECK" to performs the authorization checks wherever required. These checks are performed based on arguments (authorization object, field, values) passed in "AUTHORITY-CHECK" statement.

...
Snippet-2
.........
IF sy-uname <> 'DEVELOPER'. (SY-UNAME contains the name of currently logged-on user)
    AUTHORITY-CHECK OBJECT <authorization object="">
     ID <authority 1="" field=""> FIELD <field 1="" value="">. 
     ID <authority 2="" field=""> FIELD <field 2="" value="">. 
ENDIF.
...

Execution Flow:

• Above code snippet makes use of IF statement to check whether the current user is "DEVELOPER" or not.
• If current user is different from the account "DEVELOPER", then system performs the authorization checks as defined.
• If the user account is equal to "DEVELOPER", then system skips the authorization checks and continues the execution with other code.

Risk:

• Attacker can take advantage of hard-coded checks to bypass security controls.
• If the attacker doesn't have required authorization, he creates a new user account "DEVELOPER" and execute the program, which in this case if user account is "DEVELOPER" system does not perform authorization checks thereby bypasses the security check.

Countermeasures:

• Before moving ABAP developments to Production, use SAP standard report RS_ABAP_SOURCE_SCAN to search and detect dangerous ABAP code snippets.
• As recommended by SAP check and apply the security notes on regular basis.

Reference:

Onapsis