English | Deutsch | Español

Dangers in SAP® Transport Management Part 4: Automated Code Execution while Importing

December 7, 2017 | From Thomas Fritsch, Virtual Forge GmbH

steps_en.pngAlmost every SAP® Basis administrator knows how dangerous XPRA entries can be in transport requests (R3TR XPRA <report name>). In principle, any report that does not require any specific parameters can be executed immediately after importing it. If the desired report is not available in the target system yet, it can either be imported with the same request or imported with a previous transport request. The later method is better for covering up attacks as the immediate connection between planting the code and executing it is not as easy to detect.

Significantly more dangerous is the so called “after import method”, though. This is due to the fact that planting and executing the code happens almost unnoticeably. “After import methods” are used by SAP for imports of customizing, e.g. to generate objects based on new or changed settings or to execute consistency checks (Example: import of number range objects). An attack via the “after import method” consists of 3 steps:

  • Planting the code
    Since a function module is accessed during the “after import method”, it first has to be delivered to the target system. It is relatively simple to cover up for this by transporting the function module within a complete, potentially very extensive function group.
  • Mapping the code
    Maintenance objects of the customizing are defined in the transaction SOBJ. In this transaction, a function module can be assigned to each maintenance object as “after import method”. Changes are automatically documented in the respective R3TR TOBJ object.
    TOBJ objects do not attract attention as they are typically used for the transport of maintenance object definitions. If the authorization for the transaction SOBJ is missing, the table OBJM can also be directly manipulated for the mapping.
    (An inspection for TOBJ objects via simple 'critical objects' inspections will lead to many false positives for this. Virtual Forge TransportProfiler reads the content of the transport file and can therefore determine if an “after import method” is actually stored there.)
  • Executing the code
    Once the TOBJ definition has been imported into the target system, each import of data to the respective maintenance object in the target system will trigger the “after import method” to be executed.

Especially critical: XPRAs and “after import methods” are usually executed as an import step in the context of the user DDIC or an equivalently authorized user!

For the request check can be concluded:

  • R3TR XPRA <report name>
    • Possible attack attempt
    • The respective transport should be inspected. One should be especially skeptical in the case of the report to be executed being transported into the target system with the same transport request for the first time or when it is being updated (R3TR PROG, LIMU REPS <report name>) 
  • R3TR TOBJ <maintenance object name>
    • Possible preparation of an attack attempt
    • It should be inspected if the object has an “after import method” assigned to it and if so what purpose it has. 
  • R3TR TABU OBJM
    • Certain attack attempt!
    • This table is intercepted by SAP Standard in SE09/10. It can be added to a transport request and exported with the help of a short ABAP report, though.

In order to further mask an attack, entries to the table OBJM can be concealed within a superordinate object. These include:

  • View Cluster (R3TR CDAT <random object name>)
  • Maintenance View (R3TR VDAT <random object name>)
  • Customizing Data (R3TR TDAT <random object name>)

In these cases, an entry also has to be considered to be a definitive attack attempt! Only checking all transport requests like mentioned above helps against such an attack.

Virtual Forge TransportProfiler automatically conducts this check and over 100 other ones, for internal as well as external transport objects. Take the first step on your path to an actually secure SAP transport management and schedule an appointment today for a non-binding vulnerability assessment and presentation.             

The next entry will deal with the manipulation of logical file names and logical OS commands. 

Read the blog sequence

Dangers in SAP Transport Management Part 1: Circumventing AUTHORITY CHECKS
Dangers in SAP Transport Management Part 2: Circumventing AUTHORITY CHECKS transaction-specifically
Dangers in SAP Transport Management Part 3: Manipulation of Job Management
Dangers in SAP Transport Management Part 5: Logical File Names and Operating System Commands