Dangers in SAP Transport Management: Part 1
Read our intro to Dangers in SAP Transport blog post for more information about this blog series and SAP Transports.
Opinions on the SAP® authorization concept vary greatly. The granular nature of the model brings a certain complexity and the resulting maintenance effort cannot be denied. Yet, the most important requirement, the gapless protection of all read and write accesses within a program, can be realized quite well—at least in theory. In practice, there are several methods which circumvent authorization 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 security-focus on authorizations while developing the application.
Interestingly enough, SAP allows for the deactivation of authorization checks on individual authorization objects globally or for specific transactions. A notable exception to this is authorization objects belonging to SAP Basis or SAP HR cannot be deactivated. While this reduces the severity a bit, the overall risk remains critical.
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. Through 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. Considering that authorizations on development systems are granted extensively, the circle of users capable of deactivating authorization objects 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
- The object list of the transport request has been manually maintained
- R3TR TABU TOBJ_OFF
- A 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 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.
This blog post on authority checks is part one of a series focused on the possible issues and security risks of SAP Transport Management. The next blog post in this series will focus on transaction specific deactivation of authorization objects.