The Risks of Third Party Software in SAP
The SolarWinds attack was detected in late 2020 and is already considered one of the most critical cyber threats ever. More than 18,000 companies and public institutions were affected by the attack that was carefully prepared over time to fool all modern virus scanners. It impressively demonstrated that installing and updating external software is one of the most critical activities in an administrator’s life.
Looking at the SAP ecosystem, almost every SAP customer is using one or multiple ABAP solutions from different vendors for mission-critical applications such as supply chain management (SCM), product lifecycle management (PLM), enterprise resource planning (ERP), human capital management (HCM), financials and others. In the best case, this third party software is certified by SAP as an official ABAP Add-On and is built by using the official SAP tools like the ABAP Add-On Assembly Kit and the Software Delivery Composer. In the worst case, it is just a small, non-certified consulting company that provides its “smart software solution” via simple SAP transport requests and this solution might require a large number of subsequent patches and hotfixes.
Every new installation and any update of external software implies the potential risk of injecting a Trojan horse. Possible attackers could be:
- The person(s) who created the SAP transport request/Add-On package
- The person(s) who might have had access to the delivery system during the creation of the transport request/Add-On package
- Person(s) that have access to the transport request/Add-On package at any time between its creation and its import into the final customer system
There is a wide range of malicious content that can be injected into a transport request. The Onapsis blog series “Dangers in SAP Transport Management” provides a good insight into possible manipulations. Among others, these manipulations can lead to:
- Execution of arbitrary reports or function modules
- During the import of the transport request
- At any random time after the import
- In the context of a specific user
- In the context of user DDIC
- Disabling of authorization checks
- Importing a complete user master record
- Converting arbitrary function modules into remote enabled function modules
- Redirecting the storage location of sensitive documents
- Disruption or compromise of mission-critical applications such as supply chain management
These are only a few examples, but this shortlist already demonstrates the criticality of possible manipulations. What kind of mechanisms can be established by third-party providers and their customers in order to be protected against malicious manipulations? Let’s take a look.
Third-party provider:
- Restrict access to the delivery system to the necessary people
- Don’t rely only on functional tests of the final delivery request/package
- Establish at least a second-set-of-eyes principle
- Check the object list of the delivery for suspicious objects (Hint: A good starting point is to read the above mentioned Onapsis series and to check against all objects described here)
- Check all levels of the object list (objects, sub-objects, and keys). Malicious objects and settings can be hidden in other objects.
- Execute these checks twice – once before the export and once after the import into a test system. Reason: there are different ways of manipulating object lists so that the malicious objects are only visible before or after the release.
- SAP Software Delivery Composer performs a couple of checks, but:
- The focus is more on the robustness of the delivery and not on security
- Some of the checks can be bypassed by sophisticated manipulations
- Provide a digital signature or at least a checksum, so that your customers can check for the integrity of the shipped unit or at least for manipulations that have been applied to the delivery package after it has been released from the delivery system
Note: SAP provides an implicit check sum for transport requests but this number is stored in the datafile of the request—thus, experienced hackers can not only decompress and manipulate the transport’s content, they can also adjust the checksum.
Customer:
- Ensure, you have protected your SAP Transport Management System (TMS) as explained in Volume 8 of the Onapsis Research Lab’s SAP Security In-Depth Publication, titled Transport Management System: Highway to Production
- Note: The protection of the SAP TMS is key as internal transport requests could also be manipulated by an attacker who has access to your development systems or your transport directories!
- Don’t download transport requests or packages from untrusted sources
- Only apply transport requests or packages of vendors who can ensure integrity of the delivered requests or packages( e.g. with digital signatures or checksums)
- Only allow dedicated users to access the vendor’s download portal
- Setup a sandbox system that has no connections to other systems of the landscape
- Check the integrity of the request or package right before each import/installation
If the solution is shipped via transport request(s):
- Read the object list of each transport request by using one of the following options (all options require the datafile to be located in the transport directory of the sandbox system):
- Execute function module TMS_TP_GET_OBJECT_LIST in transaction SE37 and enter the transport request in the internal table TT_BUFFER
- Execute the following OS command
- tp GETOBJLIST pf=<transport profile> -S <SID of sandbox system>
- Add the transport request to the TMS import queue of the sandbox system and double-click the request
Note: All three options do only provide the first level of the object list. There is no possibility to navigate into details (table data, key information, etc.).
In order to get the whole object information including key information of included customizing objects, you can:
- Add the transport request to the TMS import queue of the sandbox system and then,
- Execute function module TRINT_TP_INTERFACE in transaction SE37
with the following parameters:
- With <TARG_SID> = SID of the sandbox system
<TRANSPORT_REQUEST> = Name of the transport request or execute the following OS command, tp CMD <TRANSPORT_REQUEST> pf=<transport profile> <SID of sandbox system>
- Execute function module TRINT_TP_INTERFACE in transaction SE37
Afterwards you can start any of the transactions SE01, SE09, SE10, STMS to navigate through the object list of the request, including all details.
Note: This solution only populates all transport metadata tables (E070, E071, E071K, etc.), it does not physically import the objects. This has some side effects as e.g. searching for objects in requests via transaction SE03 would display the external transport request in the results, although it was not really imported.
- Don’t rely only on functional tests of the final delivery request/package
- Check the object list of the delivery for suspicious objects (A good starting point is to read the above mentioned Onapsis series and to check against all objects described here)
- Check all levels of the object list (objects, sub objects, and keys). Malicious objects and settings can be hidden in other objects.
- After checking all objects and object details in the object list:
- Import the transport request into the sandbox system
- Check the import logs carefully for any After Import methods that might have been triggered by the transport request
If the solution is shipped via an Add-On package:
There is no chance to check the object list before you have installed the package into the sandbox system:
- Install the package in the sandbox system
- Afterwards, you can start any of the transactions SE01, SE09, SE10, STMS to navigate through the object list of the transport request that was extracted and imported during the installation process, including all details.
- Don’t rely only on functional tests of the final delivery request/package
- Check the object list of the delivery for suspicious objects (A good starting point is to read the above mentioned Onapsis blog series and to check against all objects described here)
- Check all levels of the object list (objects, sub objects, and keys). Malicious objects and settings can be hidden in other objects.
- Check the import logs carefully for any After Import methods that might have been triggered by the corresponding transport request
In Summary
Installing and updating third party software for SAP applications is a common task for SAP administrators. The SolarWinds attack has shown that intervening in the update process is an attractive and powerful way to easily get access to the most sensitive areas of an IT landscape, including the mission-critical applications that power an organization’s business processes. There are various measurements that can be taken by the third party vendor as well as by each customer in order to achieve maximum protection against this type of attack. An optimal security concept should also take internal transport requests into account as insider attacks are a factor that always requires attention, too.
The QA of internal and external transport requests focusses on functional tests – general security relevant aspects are hard to check, due to missing expertise and due to the high volume of objects and customizing settings that come with professional Add-On solutions.
The Transport Inspection capabilities of the Onapsis Platform help SAP customers to automate the process of checking all internal and external transport requests for more than 70 critical aspects. These checks also detect more sophisticated scenarios where attackers use vulnerabilities of the SAP transport concept in order to hide critical objects and settings. Additionally, Onapsis offers automated code analysis to check for errors and security issues in millions of lines of SAP code. Together, these capabilities help ensure that only quality and secure code gets imported into the SAP production environment.
