Supply chain attacks are an emerging kind of threat that targets software developers and suppliers. The attacker’s intent is to access source codes, build processes, or update mechanisms by infecting legitimate apps to distribute malware. This does not only affect external software, but also internal software deployment processes can be vulnerable to this kind of attack. Changes for SAP production systems are implemented in the development stage, and thereafter, deployed and tested in the test instance before its go live.
SecurityBridge has identified a method that allows internal attackers without privileged authorizations to infiltrate the SAP change management or software deployment process. Here is what we found out about the attack scenario.
Functional enhancements requested from the business, that do not exist within the SAP standard product scope, can be added by custom developments. This is not directly done on the production system since any error may cause disruption of business-critical processes that need to run with high accuracy and availability.
Typical SAP production systems exist at the end of a line of systems consisting of SAP instances that are used for development, testing, and sometimes integration. In many cases, all the instances are sharing a central transport directory. The transport directory is the place where the SAP system stores and sources the transport files. Those files are needed to physically deploy changes from development to the next staging level.
We all use SAP transport requests to deploy coding and repository changes through the various staging levels of the SAP system line. The change management process assumes that transport requests can’t be changed anymore once exported.
Here’s an example: I typically export my transport requests only after I’m done with my change and my unit tests have passed. With the export or release of my transport request the deployment process starts. Behind the scenes, the transport contents, contained in a DATA file, is frozen and the COFILE gets updated with the transport release details. You can see the DATA file as the data container and the COFILE being the action log of any SAP transport request.
Once released, my transport request is no longer modifiable. It may happen you realize a dictionary object, or a customizing entry, was missed in the object list, and you need to create a new follow-up transport.
I cannot re-open the existing transport to add the missing pieces, right? Well, not exactly – read on to learn about how you can rewind your action to make the request editable again – at any time, even after the import into quality stage has been passed.
There is a hidden feature that SAP standard ships with the program RDDIT076, accessible via Hotline Tools (program RSWBOSOS). This program allows changing the header attributes of an SAP transport request:
Now, this is exactly where the problem starts!
SAP change management tools and their quality assurance processes are designed with key design assumptions, one being the content of a transport request is frozen once exported from the SAP development system.
After the export, and before the import into the production system, threat actors have a time window to include malicious objects. A rogue employee with adequate authorizations has the capability to change the release status from ”Released” to ”Modifiable”!
The transport request can be changed, even though it already passed all quality gates established in the Change Management Process. In the example below, we add some extra payload to the transport, a program that gets executed automatically after import into a target system, which could be production. This is how the SAP development supply chain can be attacked!
A similar scenario can be used as seen in the recent Kaseya supply chain attack:
A Bombshell Supply-Chain Hit
Attackers may introduce malicious code into the SAP development stage, unseen, even into requests that have already been imported into the test stage. They could alter the transport request content just before promotion into production, allowing for code execution. Such attacks are very efficient, and all SAP environment are vulnerable if the various SAP staging levels share a single transport directory.
SAP SE has provided a patch for the scenario described in SNOTE 3097887
SAP technicians will confirm, there are genuine reasons for allowing changing the header attributes of a transport request. However, there must be inherent security controls that will generate an alert, triggered automatically when something goes off the baseline, such as changing the release status of a transport request, or when including vulnerable/rogue code or other critical objects. Real-time monitoring can be implemented, to instigate a verification process for all such anomalies.
As an SAP security solution provider, we must deploy the highest level of security.
The filesystem needs to be protected against manipulation and thus only the account that also runs the SAP NetWeaver or S/4HANA Application, the so-called <SID>ADM needs access.
Review the transport protocol looking for manipulation before the production import. The described attack method will be visible within the transport protocols.
Software products from SAP, are at the very core of powering the most successful global brands. Many of these SAP customers provide critical infrastructure, manufacture food, supply energy, and medical supplies, and as such cannot risk an interruption to production.
Although we see an increasing level of sophisticated SAP attacks, the example above illustrates how an insider could infiltrate a production environment.
Together with our team of experts, we support companies by providing the most advanced cybersecurity platform for SAP customers, to ensure that the very essence of their operation is not endangered by persistent cyber threats.
Looking into securing your SAP landscape? This white-paper tells you the “Top Mistakes to Avoid in SAP Security“. Download it now.
