In the past, SAP made some decisions in the architecture of its solutions that may be important for reliably running them, but that have severe adverse impact on security. In this episode we focus on persistence.
Usually enterprise solutions are shipped to customers in a compiled format as executable files. The vendor is in possession of the source code and customers receive the resulting binaries or byte code representations. SAP is different. While the SAP kernel, i.e. the runtime environment, is shipped in compiled/binary form, the entire ABAP business logic is shipped as source code. The advantage of such a design is that in case a system crashes, SAP's support experts can directly debug the problem on the customer's system and mitigate the cause.
Of course the source code is compiled into byte code before it is executed. This compilation is done by the kernel on the customer's system. Such late compilation is necessary since the actual byte code depends on the operating system in use.
One other ABAP-specific phenomenon is that the shipped source code is not stored in some folder on the server in form of files. The entire ABAP source code is stored in the database. This applies to all SAP standard programs as well as all third-party solutions and all custom development. And the purpose of the SAP standard code is not only focused on business logic. SAP's standard ABAP programs contain the ABAP development environment. They also contain all major configuration tools as well as user management. They also contain administrative tools to maintain Web interfaces and system-to-system communication. And much more.
What consequences arise from an ABAP Malware perspective?
If Malware finds it ways into an SAP ABAP stack (AS ABAP, S/4HANA, RISE or GROW installation), it may find ways to modify critical SAP standard programs (this will be explained in episode 4). But more importantly, SAP's decision to store all code in the database (source code and byte code) means that all ABAP code is also part of the backups. Customers usually backup their entire database, including the code.
But what is a typical first step, if Malware is detected? Recover from backup. However, at every company there is a certain time span in which it is feasible to track and restore all transactions since the point in time the backup was made. Usually in SAP environments, this time span is rather short.
What if a Malware is able to remain undetected for this time span? It would mean that there is no backup from which a company could restore its current state that is not at the same time infected by the Malware.
In other words, SAP's decision to store all code in the database may empower a (stealthy) Malware to become irremovable without major damage to business.
To be continued...
This is the fifth article in our malware series that provides you with insights into ABAP malware research, ABAP malware capabilities and ABAP malware defensive strategies.
If you'd like to know more about ABAP malware risks, please contact us.