Dangers in SAP Transport Management: Part 2
Read our Intro to Dangers in SAP Transport blog post for more information about this blog series and SAP Transports.
The first post in this series spoke about the global deactivation of authorization checks for single authorization objects per transport. A similar risk results from the possibility of deactivating authorization checks transaction-specifically. With this method, it is even more difficult to detect an attack, as the impact can be limited to one transaction.
The 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 creation or editing of a role in the tab “menu”, these default values are then automatically stored during the processing of the authorizations. This streamlines things for the authorization administrator, as they do 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. As with the similar deactivation scenario noted in Part 1, this doesn’t apply to SAP Basis or SAP HR, but the criticality of this issue remains.
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, the following can be concluded:
- R3TR SUSK
- 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 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.
Up next in Part 3, we’ll dive into the manipulation of job management and its associated risks to SAP Transports.