English | Deutsch | Español

Dangers in SAP Transport Management

June 25, 2018 | From Thomas Fritsch, Virtual Forge GmbH

Virtual Forge's research department has discovered an extremely critical vulnerability in the SAP® transport management.

TA_Banner_ENWhy this vulnerability is so dangerous:

  • You can change or delete the content of any table in the productive systems
  • The manipulation is exported by an unaware developer. Unnoticed and in the form of a "Trojan"
  • Checks for "critical objects" do not detect the attack
  • The attack leaves almost no trace
  • The malicious entries can also be imported using external transport requests

The starting point for an attack are the logical objects in customizing. A representative of these objects that are used often are, for example, roles.

Like all logical objects, roles are formed by a set of information from different tables. Determining which tables these are and how their keys for a particular role are composed is stored in table OBJSL. This table cannot be maintained directly, but is maintained indirectly using transaction SOBJ in the form of a piece list:

Fig1

Fig2

 

 

 

 

 

 

 

 

 

 

Several wildcards are available for specifying the relevant keys:

                               /C:       client
                               /L:        language key
                               /&:        name of the specific logical object
                               /*:         any string

SAP performs several checks when you save the settings so that the tables with any keys cannot be copied to the piece list. For example, the system checks whether the placeholder /& is used in the table key (field: object key).

If a role is included in a transport request, only the logical object "role" ( R3TR ACGR <role name> ) is recorded in the object list of the request. The piece list is evaluated at runtime at the time of export. You can also display them at any time by double-clicking on the role in the object list:

Fig3Fig4

 

 

 

 

 

 

 

 

 

 

However, no one will do this for logical objects. Other than with customizing object types (for example, maintenance view data, view cluster data), the information in Fig. 4 is not persisted in the transport request tables E071 or E071K.

Misuse of the method

Developers have extensive authorizations on the development system and can manipulate any table using at least a short ABAP report. In this way, an attacker can first adjust the content of the required table and then add it to the piece list for roles with the required keys in table OBJSL:

Fig5Fig6

 

 

 

 

 

 

 

 

 

 

The key point here is that, unlike the maintenance using transaction SOBJ, no content checks take place. This also applies when exporting the transport request - it can be easily released and exported from the system.

To hide all traces, the attacker then undoes both changes on the development system. If you double-click the role again in the transport request that has already been released, the suspicious entry disappears due to the dynamic determination. In the target systems, too, the malicious entry is of course not part of the object list, since the OBJSL table contains the correct information.

In the end, the attack can only be detected in two places after the export - in the export log and in the log of the main import if the request was imported into a subsequent system:

Fig7Fig8

 

 

 

 

 

 

 

 

 

 

However, who would think of reading through the logs of all transport orders? Once the attacker has reached his goal, he can of course also restore the old dataset in the same way and thus make the cloaking perfect.

Better safe than sorry!

This phrase should probably not serve as a guiding principle in all situations, but it is more than appropriate in the area of IT security. Developers usually have extensive authorizations and need these in the development systems for efficient work. Therefore, they should also be trustworthy. However, it is the responsibility of the organization to close known security gaps for its own employees as far as possible and thus ensure a secure IT landscape.

Conclusion

The security gap described here is an example of the entire risk potential of the SAP transport management system. SAP customers should react now and protect themselves comprehensively against such attacks! Virtual Forge's TransportProfiler is the only product that can detect such manipulation attempts. While other tools simply check the object lists against a list of critical objects (which you as a customer also have to define yourself), TransportProfiler reads the content of the transport files directly for its analyses. Based on the know-how of 12 years of security research in the SAP area and driven by permanent investigations by our research team, TransportProfiler conducts over 100 predefined tests.

Act before it's too late and make an appointment for a presentation today, or take advantage of a free Vulnerability Assessment of your previous transport orders.