SAP Development System: A Critical Entry Point for Attacks
There is no statement I have heard more often from SAP customers in the last 25 years than, “If I can’t trust my developers, I have a problem anyway!”
Consequently, development systems are always considered last when setting up authorization concepts for SAP projects. This is understandable since compared to a production system, a development system is obviously less critical with regard to confidentiality, integrity, and availability.
The Issue With SAP Development Systems
Another aspect for prioritizing development systems less than authorization projects is that restricting authorizations on such a system can only prevent users from damaging the system accidentally. It cannot prevent threat actors from doing malicious things on purpose.
The main reason is that users usually have developer authorizations on a development system (surprise, surprise). That means:
- Users are allowed to debug and (usually) to change values of individual variables in debug mode. Thus, they can manipulate the return code of every AUTHORITY-CHECK.
- They can manipulate arbitrary tables in the system by coding and executing appropriate ABAP statements.
- With 2), implicit authorization checks that are realized in the SAP kernel (e.g. for file access) are also no obstacle. One easy option to extend the own authorizations is to manipulate the user authorization buffer table USRBF2. In case of missing file access authorizations a simple INSERT of the following record provides access to all app server directories and to all shared directories:
|
|
|
|
|
|
<client> |
<my user> |
S_DATASET |
S_DATASET_AL |
If the directory or file is additionally protected by an SPTH entry, attackers can either delete the restricting record(s) from table SPTH or, if access is allowed for specific authorization groups, they just add an additional record to table USRBF2:
|
|
|
|
|
|
<client> |
<my user> |
S_PATH |
S_PATH_ALL |
SAP Development Systems Are Not Isolated
Being able to manipulate anything on an SAP development system means that attackers are only one step away from manipulating the corresponding production system(s), too. The only thing that it needs is the possibility of transferring the malicious settings somehow from development into production bypassing any established quality gate.
The three main touch points between development and production systems are:
-
Customer-Defined RFC Destinations
Customer-defined RFC connections between development systems and QA or production systems can and should be avoided at all – even if abusing them for malicious data transfer or other types of manipulation through direct calls of remote-enabled function modules requires appropriate authorizations on the target system for the RFC user. The same applies for the opposite direction. RFC destinations on a production system connecting it to development systems (or QA systems) provide the risk of malicious callbacks into production.
-
The SAP Transport Management System (SAP TMS)
The SAP TMS is an indispensable component of every SAP landscape. It is required to transport regular development objects and customizing settings via transport requests from development into production. It also uses RFC destinations for cross-system communication but the corresponding RFC users are very restricted through predefined standard roles.
-
User Credentials Shared Across the Landscape
As SAP implementations are complex and tiered, multiple user accounts are configured across the different systems, many of which are technical accounts with powerful privileges. A highly privileged account in development could potentially access hashed user passwords or even encrypted passwords for technical accounts, which are typically configured using the same credentials in all systems, including production. This is another way developers can traverse the landscape and move from non-production systems to productive environments.
Risks of the SAP Transport Management System
The main risk introduced by the SAP Transport Management System is not the fact that it communicates via RFC. The major risk is that if developers put malicious objects or settings into a SAP transport request (e.g. the two USRBF2 records from above), that will not be detected by the established quality gates. Quality gates can consist of manual or automated checks. The large volume of changes usually requires an automated check. Such automated checks compare the object list of a transport request with a list of critical objects. The problem is that the critical objects list is delivered empty by SAP (either with SAP TMS or SAP CharM) and there is usually no knowledge about what to add there. But even if the list would be perfectly maintained there are some conceptual vulnerabilities in the SAP TMS.
Conceptual Weaknesses in SAP Transport Management System
There is one major issue in the architecture of the SAP TMS that represents a high security issue and in parallel it has already caused a lot of confusion in SAP projects as customers run into it by accident. The problem is that SAP does not check for duplicate transport requests. Example of an exploit:
1. A developer releases a SAP transport request DEVK900123 containing a requested and well-documented change on customer report ZHARMLESS. The report is exported and stored in the corresponding data file R900123.DEV on operating system level:
2. Request DEVK900123 is transported into the QA system – either automatically or after explicit approval by defined people
3. Report ZHARMLESS is tested on the QA system and after successful test it is approved for production. Independent of the approval process (TMS-QA, CharM, etc), the request resides already in the import queue of the production system(s).
4. The same developer (or another one) can easily manipulate the status of the already released transport request on the development system, so that it is reverted from “Released” to “Modifiable”.
5. They can then insert additional objects into the object list of the request, e.g. the malicious report ZSYSTEMKILL and releases it (again).
6. Based on the naming conventions, the export generates again the file R900123.DEV and just overwrites the already existing one.
7. An administrator starts the import of the transport request into the production system(s) (as it was already approved – see Example 3) ), not knowing that it meanwhile contains an additional malicious report.
It is paramount to have a solution that would not only protect production systems from being compromised by the modification of transport requests but also prevent SAP customers from getting duplicate transport requests by accident. Every restore and any refresh of a development system (which is a periodical task in parallel development landscapes) requires special attention to the number range of the transport requests. After a system restore/refresh, SAP transport requests that were already released might have the status modifiable again or do not exist anymore at all so that when creating new transport requests the same transport numbers are generated again and completely different objects might be attached to them compared to their already exported pendant:
Duplicate transport requests in such scenarios always generate a lot of confusion. Object lists no longer match with information that might have been tracked already in change documents or objects are imported untested into production based on the approval status of the original transport request, etc.
In order to avoid inconsistencies, the highest number that was assigned to a transport request must be saved and re-applied before a restored/refreshed system can be released again for development. There are two steps required to achieve this:
- Before the restore/refresh: Write down the current value of field E070L-TRKORR
- After the restore/refresh: Update table E070L so that the value that was tracked in 1. Is assigned to E070L-TRKORR again.
If a tool or script is used to export and re-import some tables before and after the restore/refresh, just add table E070L to the list of tables to be processed.
Further Sources For Malicious Manipulations Via SAP TMS
In 2018, the Onapsis Research Labs (ORL) reported a vulnerability to SAP that allowed threat actors to manipulate the definition of logical customizing objects enabling them to transport malicious settings completely hidden (not visible in the transport request’s object list). The corresponding SAP Security Note #2671160 is tagged with a CVSS score of 5.5, and Onapsis Research Labs could show that arbitrary workbench objects can also be smuggled into production by exploiting this vulnerability. This can become a critical issue and its exploitation is very difficult to detect. SAP has introduced the new TMS parameter TLOGOCHECK to patch the issue and the most recent releases of SAP S/4HANA are shipped with TLOGOCHECK=TRUE, manifesting SAP’s new security by default philosophy.
While the previously described SAP vulnerability can be seen as completely solved and patched, there are two additional risks that still remain. Both are related to the function module TRINT_TP_INTERFACE which is the heart of the SAP TMS. It can be used to start most of the transport activities. Fortunately, this function module is not remote-enabled. Nevertheless, it represents a source of transport request manipulations for local threat actors.
While with regular exports of SAP transport requests via transaction SE01, SE09, or SE10 a set of pre-export consistency checks is involved, these checks can be bypassed when using TRINT_TP_INTERFACE to start an export. This is very critical since threat actors can export tables that are usually not allowed for transports as they can negatively impact a target system’s consistency and integrity. Even more critical is the fact that the consistency check for customizing objects like view data and view cluster data can be bypassed. This enables attackers to use these customizing objects as a container for transporting malicious settings, similar to the vulnerability in logical customizing objects that was patched with SAP Security Note #2671160.
Conclusion
Organizations need to implement additional controls to protect an SAP development system completely against threat actors, especially those with existing access. It’s all the more important that any interface with QA and production systems is secured as much as possible. If not properly protected, the SAP Transport Management system represents a significant risk as it is responsible for migrating thousands of new and updated objects and customizing settings to production systems.
Onapsis Control automates the monitoring of all changes that are leaving the development system and provides additional approval workflows for critical situations. Control is ideal for organizations who want to scan SAP transports for errors before production and provides checks that also cover robustness, compliance, and maintainability aspects.