SAP Transport Management Part 2: Circumventing Authority Checks

Starting point of this attack is the transaction SU24. With this transaction, default values for the authorization objects of specific transactions can be defined. If such a transaction is then added in the profile generator during the creating or editing of a role in the tab “menu”, these default values are then automatically stored during the processing of the authorizations.

This is a tremendous facilitation for the authorization administrator, as he does not have to deal with each application in detail.

But the transaction SU24 also offers the possibility of deactivating authorization checks for specific authorization objects. This possibility requires that the value of the profile parameter auth/no_check_in_some_cases is set to”Y”. Since the use of the profile generator also requires this value, this condition is almost always met.

All changes made via transaction SU24 are documented in transport requests. The associated object type is R3TR SUSK. Unfortunately, one cannot determine with a manual inspection of the transport request and its export protocol, if only default values for the profile generator have been maintained with this object, or if specific or all authorization checks of the transaction have been deactivated.

Of course, the transaction SU24 is protected by authorizations, meaning that only authorization admins should have access to it. But considering that authorizations on development systems are granted extensively, the circle of users capable of deactivating authorization objects usually widens.

For example, it is possible to programmatically manipulate the table USOBX_C lodged for R3TR SUSK and add the respective table record or the respective R3TR SUSK object to the respective transaction into a transport request. If the table USOBX_C is then further “hidden” in a maintenance view or a view cluster, it requires great care and expertise to detect an attack.

For the request check can be concluded:

• R3TR SUSK <transaction name>
  • Attack attempt possible
  • Usually used for the maintenance of default values though

• R3TR TABU USOBX_X
  • Certain attack attempt!
    The object list has been manually maintained.

In order to further mask an attack, entries to the table USOBX_C 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. This test and over 100 other ones, Virtual Forge TransportProfiler conducts automatically for internal as well as external transport objects.

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