SAP Transport Management Part 1: Circumventing Authority Checks

In fact, a missing or faulty authorization check is one of the most common mistakes in custom Abap-programs. Hereafter, we will assume that the developer put the necessary focus on the authorization aspect while developing the application.

Interestingly enough, SAP allows the deactivation of authorization checks  for specific authorization objects globally or for specific transactions.

Global deactivation requires that the value for the profile parameter auth/object_disabling_active is set to ‘Y’. Since this is the standard value, this requirement is fulfilled in many SAP environments. Via the transaction AUTH_SWITCH_OBJECTS, random authorization objects can then be deactivated, causing programs to not take authorization requests for these objects into account. Of course, this transaction is protected by authorizations, meaning that only authorization admins should have access to it.

The transaction AUTH_SWITCH_OBJECTS also allows transporting all settings though. Considering that authorizations on development systems are granted extensively, the circle of users capable of deactivating authorization objects usually widens . The standard function for transporting settings already offers a certain amount of protection by first transporting them into a kind of shadow table (table TOBJ SAV) and only activating them after confirmation by an admin in the target system.

By manually maintaining the transport object list, however, these settings can be transported “actively”. This can be achieved by simply including the table TOBJ_OFF with the desired keys into a transport request. The desired settings are set beforehand via transaction or, if the required authorization is missing, via a quickly developed mini report. With that, an (internal or external) attacker is capable of deactivating authorization checks as desired!

Whether such an attack scenario exists, can of course be found out by manually checking the transports. Be on the lookout for the following:

• R3TR TABU TOBJ_SAV with key “*”
  • Potential attack attempt
  • High test effort since all settings have to be transported

• R3TR TABU TOBJ_SAV with dedicated keys
  • Potential attack attempt; object list of the transport request has been manually maintained

• R3TR TABU TOBJ_OFF
  • Certain attack attempt!
    The object list has been manually maintained. The confirmation of change by an authorization admin in the target system has been deliberately circumvented!

Note: in order to further mask an attack, the listed objects 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, such an entry has to be considered a definitive attack attempt! Only checking all transport requests like mentioned above helps against such an attack attempt.

This test and over 100 other ones, Virtual Forge TransportProfiler conducts automatically for internal as well as external transport objects. You can of course schedule an appointment for a non-binding vulnerability assessment and presentation.    

With this article, Virtual Forge’s Thomas Kastner starts a mini-series of articles that focuses on the possible issues and security risks of SAP Transport Management. The next article will focus on transaction specific deactivation of authorization objects. For ease of use, certain parts of this series will be exempt from our Editorial Guidelines regarding capitalization.