Identifying a Vulnerability in the SAP Software Supply Chain

Software supply chain attacks, also called value-chain or third-party attacks, are emerging threats. This type of attack is often carried out by infiltrating a third party or outside partner that has access to your systems. Typically, the attacker's intent is to access source codes, build processes, or update mechanisms by infecting legitimate apps and hijacking them to distribute malware. However, when it comes to targeting SAP systems, these types of attacks can be carried out by employees and also hit internal software deployment processes. 

According to SAP, the company's customers generate 87% of total global commerce ($46 trillion), and 99 of the 100 largest companies in the world are SAP customers. Even though SAP is widely used enterprise application software, it's not an out-of-the-box solution, and often a company's business units request functionality enhancements that don't exist within the SAP standard product scope. To implement these enhancements, qualified IT professionals use SAP transport requests to deploy coding and repository changes through the various staging levels of the SAP system line — and this is where the vulnerability lies. 

SAP makes use of so-called "Transports" that contain the coding and serve as the container for the source code deployment through the SAP customers' system landscape. The SAP change management process assumes that transport requests can't be changed once exported. SAP change management tools and their quality assurance processes are designed with key assumptions, one being the content of a transport request is frozen once exported from the SAP development system. Once released, the transport request is no longer modifiable — or is it? 

The Problem
There is a hidden feature that standard SAP ships with the program RDDIT076, accessible via Hotline Tools (program RSWBOSOS). This program allows changing the header attributes of an SAP transport request. 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. 

When an attacker (internal rogue employee or third-party coder) rolls back the release process of the container, they can attach an object to a transport that will execute a program at the time of import. This object can be used in the deployment process to gain the authorization needed to execute an additional payload that triggers a malicious program or a script, making it possible to transfer malware into the SAP production system. 

In essence, when someone is able to revert the release status of the transport request, which is the container to deploy the software configuration, or customer coding from system to system, it is possible to attach a payload to the transport that can bypass validations to the quality assurance process. However, it is important to note that there are an enormous number of developers, consultants, and employees with configuration access, but anyone exploiting this vulnerability needs to have a certain level of security to change the header attributes of SAP transport requests. 

This is just one example of a present-day SAP vulnerability. These types of security risks will remain in place until the designated patch is applied. Once the patch is applied these issues are instantly resolved. A good rule of thumb to keep in mind is that the weakest system in the chain is often in the development box. SAP administrators need to review new security patches put out by SAP on the second Tuesday of every month to ensure their systems are as secure as possible. 

The Solution
SecurityBridge identified this method that allows internal attackers to infiltrate the SAP change management or software deployment process. We worked directly with SAP to give global customers ample time to address this issue before making it widely known. The net result was SAP security advisory SNOTE 3097887, which fixes the vulnerability (CVE-2021-38178). This protects the file system from manipulation. However, it is advisable for SAP customers to check their transport log for tampering before production import because within it the described attack method becomes visible.

Conclusion
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 including vulnerable/rogue code or other critical objects. Organizations need to immediately apply the available SAP patches and constantly check for manipulations of transport requests before importing requested changes into production. Most importantly, additional SAP security platforms are required within the SAP application to address all security needs — because all SAP environments where a single transport directory is used at various staging levels are vulnerable.