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 lateral movement.
In the four previous blog posts, we have looked at the damage an ABAP Malware can do to the database and the operating system. We have also pointed out that Malware may sink into the backups and become very hard to remove. And we explained how malware can take full control of the SAP server itself.
This final episode will focus on risks related to SAP design decisions that may give ABAP Malware the potential for lateral movement in an SAP landscape.
Since SAP servers perform business operations, they also need to exchange data. Documents in various formats need to be processed, i.e. imported and exported. Data needs to be synchronized between different servers. One channel to perform such data exchange is RFC - remote function call. Via this protocol a server can invoke a function on another server. There are tens of thousands of SAP function modules that can be called this way. Since this data exchange needs to be performed also as part of automated processes, it is possible to store user accounts and credentials together with a given RFC connection. This way, any process sending data over the defined RFC connection is automatically logged on to the destination server. The protocol itself is proprietary and usually also encrypted. Therefore security solutions can't determine what is being transmitted.
From an ABAP Malware perspective, this practice is an excellent way to e.g. pull critical configuration data from other servers in the landscape or to even execute commands on these servers remotely. There are several function modules that are designed to execute OS commands or deploy ABAP code. However, access rights to execute these modules can be significantly restricted. But then again, a single mistake in such a configuration may seal the fate of the server on the other end of the connection.
One other aspect of lateral movement are the SAP clients. SAP has created a proprietary fat client called SAP GUI which is still widely in use to access the ABAP backends. SAP built several very risky features into SAP GUI clients that affect the local workstation of a user: read and write access to the clipboard, read and write access to local files and curiously also the ability to perform OS commands on the client. The ABAP server can invoke all of these features remotely. While SAP has at some point in time added configuration settings to restrict this access, you never know what users do when a message pops up that the (trusted) SAP server wants to perform such an action. And some SAP programs obviously need such access. Otherwise the feature would not exist in the first place. The communication protocol between a SAP server and SAP GUI clients is also proprietary and at many companies encrypted. Again, standard security solutions can't determine what is being transmitted.
Looking at all of this from an attacker's perspective, an ABAP Malware could try to spread to the operating systems of all connected SAP GUI clients (simultaneously) and launch a large scale attack against the company's IT landscape. In such a scenario the SAP installation would not be the target of an attack, but the means to further penetrate the network - a cyber weapon.
This is the seventh 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.