The Onapsis Blog

The world of business-critical application security is dynamic, with new developments happening on a continuous basis. Check out our blog for recommendations, insights and observations on the latest news for securing your SAP®, Oracle® and Salesforce applications.

Dangers in SAP® Transport Management Part 4

Dangers in SAP® Transport Management Part 4

Welcome back to our blog series on the Dangers in SAP® Transport Management. In this fourth installment, we’re focused on automated code execution while importing. In part one, we gave an overview of SAP Transport Management. In part two, we went over the starting point of this attack, the transaction SU24 and in part three, we took a look at the manipulation of job management and its associated risks to SAP Transports.

Nearly 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 mandatory parameters can be executed, triggered by importing a transport request. If a report is not already on the target system, it can either be imported with the same request or imported with a previous transport request. The latter method is better for covering up attacks as the immediate connection between planting the code and executing it is not as easy to detect.

After-Import Methods are significantly more dangerous. This is due to the fact that planting and executing the code happens almost unnoticeably. After-Import Methods are used by SAP for post-processing activities after importing customizing objects such as generating objects based on new or changed settings or to execute consistency checks (e.g. import of number range objects). An attack via the After-Import Method consists of three steps:

Step 1: 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 this up by transporting the function module within a complete, potentially very extensive function group.

Step 2: Mapping the code
Customizing objects are defined in the transaction SOBJ. In this transaction, a function module can be assigned to each maintenance object as an 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. Onapsis Control for Transport reads the content of the transport file and can therefore determine if an After-Import Method is actually stored inside the object definition).

Step 3: Executing the code
Once the TOBJ definition has been imported into the target system, each import of data for 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, the following 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 is the purpose?
    • Definite attack attempt!
    • This table is intercepted by SAP Standard in transaction SE09/10. It can be added to a transport request and exported with the help of a short ABAP report.

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 those mentioned above helps against such an attack.

*This check, and over 100 others, are conducted automatically in The Onapsis Platform for both internal and external transport objects. Read the SAP Transport Inspection Application note (PDF) for additional details on how the technology works and how it can be integrated into your business process with The Onapsis Platform.

Request a Demo from Onapsis

Ready to eliminate your SAP cyber security blindspot?

Let us show you how simple it can be to protect your business applications.

Request a demo