SAP Security: Change and Transport System
There are some components in SAP that have existed since the early days of SAP R/3. One of these components is the SAP Change and Transport System (CTS). Introduced with SAP Basis 3.1H, it has replaced most of the manual tasks that previously had to be done on an operating system level in order to bring a transport request from system A to system B.
While there were no significant changes to this important core component for a decade, it has been extended during the last 13 years to support the transport of non-ABAP objects (Enhanced CTS or CTS+) as well as the synchronization of dependent changes across different SAP landscapes (Central CTS or cCTS).
The objects to be transported are included in transport requests and can be displayed by accessing the transport request’s object list. While workbench objects are uniquely identified by their type and name, it is much more difficult to identify the data that is transported inside a customizing object. Customizing objects can be transported as individual tables as well as via generated maintenance objects. Maintenance objects are controlled by the transaction SOBJ and can have one of the following types:
With the exception of the Dummy object type (D), all maintenance object types consist of one or several tables, including Logical transport objects (L) which can include dozens of different tables. For example, roles, represented by the logical object ACGR, include data from 27 different ACGR* tables.
Security Aspects
The transport information for most of the object types is tracked in two different tables:
- E071: main object
- E071K: underlying tables and table keys
In exceptional cases, if key fields contain long string values, table E071K_STR is also used to track table key information.
In order to catch the overall information of a customizing object, there are up to three object list levels to check in SAP Transport Organizer.
Example:
A developer updates a monitoring solution periodically with new customizing information. He created a maintenance view for that purpose and as his monitoring tool is a non-critical, read-only application, data of his maintenance view passes all quality checks for production w/o detailed analysis of the recording transport requests.
A look into the object list displays the maintenance view:
Clicking on the key button displays:
Double-clicking on the data row provides the information about the table that is going to be transported with the transport request:
Knowing that this type of transport is not checked in more detail by the quality assurance team, the developer (or anybody else with access to the development system who knows this) could now change the definition of the maintenance view and replace the underlying table with a table that contains critical data, e.g. table USRBF2. This table contains data of the authorization buffer. Transporting it into production means transporting the assigned (and buffered) authorizations on development to production so that they become temporarily active there!
Malicious content and manipulations can only be detected, when checking all three levels of the object list.
What’s more critical than hidden? Invisible!
There is one big difference between logical customizing objects (L) and the other customizing object types–when a logical customizing object is tracked in a transport request, the information about the affected tables and keys is not tracked persistently in table E071K (E071K_STR).
At first glance, a transport request containing a logical object seems to be managed in the same way:
Object list:
Double-clicking the role displays the individual tables and keys that contain information about the role:
Checking table E071K (or E071K_STR) for this request results in an empty list! As can be seen in the header of the above screen, it is only a key simulation that is displayed here. SAP reads the information for that screen dynamically from the Logical Object Definition table. The same applies when starting the export of that table– based on the dynamically retrieved information, the corresponding data is extracted from the development system.
An attacker who has access to the development system can now easily manipulate the Logical Object Definition table and add additional tables (how about salary data?) to the definition of a role. It is even possible to add workbench objects to that definition!
After adding the malicious entries to the repository, he or she only has to wait until anyone exports a role–not noticing that additional data is exported!
As the displayed information is read dynamically and as the manipulation was only applied to the development system, you can’t see the injected entries in the transport request’s object list on any other system of the SAP landscape. If the attacker withdraws the additional entry in the repository table on the development system, the entry also becomes invisible there!
How can SAP customers protect their systems?
The Onapsis Research Labs reported this vulnerability in early 2018 to SAP and a patch was provided with SAP Security Note #2671160 in May 2018 titled, “Missing Input Validation in ABAP Change and Transport System (CTS).” With this patch, SAP introduces a new TMS Parameter, called TLOGOCHECK. It is strongly recommended to apply the patching SAP kernel version and to configure the parameter TLOGOCHECK so that its value matches with the recommended settings in the SAP Security Note. The new kernel version enables the transport tool to check for any manipulation to the definition of a logical customizing object through comparison of the transported object against its definition in the target system.
The Onapsis Platform’s Assess module supports Onapsis customers in automated checking for fixing the kernel version as well as that the parameter TLOGOCHECK is set correctly on all systems.