In this series of posts I aim to cover in depth some of the publically known infrastructure vulnerabilities that affect SAP (which stands for "Systems, Applications and Products in Data Processing") systems, how to use public domain tools to test your current deployments for these issues and how best to address them. While the industry is slowly taking note of SAP related security beyond segregation of duties, there is still a significant lack of awareness of vulnerabilities and attacks against SAP systems, which prompted this series of posts.
The main focus of these posts shall be on SAP infrastructure security particularly that of Remote Function Call (RFC) security as it is an area where default configurations as well as common mis-configurations can lead to the introduction of high risk entry points into the SAP estate. However, I will start out by briefly covering a few other areas of concern that warrant mention, as they are still prevalent in production systems in use today as Context has encountered a number of times on recent engagements.
The use of SAP’s weak proprietary password hashing algorithms is still something that is seen on production systems more often than not. Numerous industry standard password cracking tools include support for various versions of SAP hashes, giving attackers a fair chance of cracking user passwords if they have managed to gain access to the database tables that contain the hashes through commonly found excessive user authorisation privileges or compromise of the database itself. While SAP’s earlier hashing algorithms were weak, insecure and in some versions employed Microsoft’s old approach of gluing the new strong hash to an earlier weak one for backwards compatibility, the last version ‘H’ has all the ingredients of a properly devised hashing mechanism. If you’re running an older version of SAP that does not support this code version, there are mitigations available to at least disable password downwards compatibility [1], preventing lowering password security even further if upgrading the platform itself is not an option.
Another issue commonly seen relates to an unpatched SAPGUI client, and/or clients that do not make use of their integrated security enhancements. As of version 7.20, the client has a ‘security module’ allowing administrators to set up a policy with a fairly granular approach to limiting the permissions of the client itself. Earlier versions of the client could be exploited by attackers using malicious SAP shortcuts combined with social engineering techniques to gain complete access over a system, and potentially gain further access to the rest of the SAP estate from there. In our experience of assessing the security of SAP systems, patching is often neglected for SAPGUI as it is for many non-Microsoft client applications in large organisations. This leaves client systems containing sensitive data and acting as potential conduits into the rest of the SAP environment open to attack (a critical vulnerability in SAPGUI discovered this year [2]). Although SAP does not provide an easy automated update solution, the risk of an unpatched SAPGUI installation warrants investigation into tying it in with remote update processes that may already exist in your organisation.
RFC
Remote Function Call (RFC) is SAP’s custom protocol for calling functions on remote servers in SAP deployments. Substantial research on this protocol and associated vulnerabilities has been done by Onapsis [3] and Cybsec [4], who also released one of the first public domain SAP penetration testing frameworks. I will be using this framework later in this post to demonstrate the various attacks against this protocol. While buffer overflows and other serious vulnerabilities leading to command execution have existed in default RFC functions in the past, SAP has addressed these issues and they should not cause concern to deployments with up-to-date patch levels. However, insecure configurations and the weak design of some core functionality deserve the same attention and is unfortunately an area that lies in the hands of the administrator.
The two main attacks against incorrectly configured SAP systems (as coined by SAP security researcher Mariano Nunez Di Croce) that use the RFC protocol are; Evil twin and Callback . I will begin by explaining the RFC behaviour that makes these attacks possible, and then go into detail regarding the flaws and how they are exploited. Detailed technical information on how to exploit these issues will be provided in the second part of this blog series.
Both of these attacks focus on exploiting the way external RFC servers interface with a SAP gateway. These external servers could be other SAP servers, or servers of any nature hosting a SAP RFC application. For clients to be able to utilise these external functions, the gateway they are connected to needs to know the external server’s location to be able to forward requests to them when the function they are hosting is called by a client. SAP provides two methods for servers to register themselves with the gateway for this purpose. These are known as “started mode” and “registered mode”.
In started mode, the gateway is statically configured with the information it requires to execute a function, regardless of whether that function is available locally or on an external server. In the case of an external RFC server, the gateway connects to the server, executes the function and closes the connection.
In registered mode however, an external RFC server can dynamically register itself with the gateway, using a program ID that is later used by the gateway to direct function calls to the appropriate host. The protocol has been designed in such a way as to allow multiple systems to register themselves with the same ID in this mode, introducing the possibility of a man-in-the-middle attack if an attacker is able to prevent the genuine host from responding. An attacker would then be able to set up a fake gateway, receiving all requests made by clients to the externally hosted function, leaving the attacker free to interact with the client as they choose (stealing credentials, sniffing sensitive data or modifying data in transit). The extent of this attack depends on the attacker’s familiarity with the function that the client expects to find at this endpoint. This is the Evil twin attack.
A modified version of the previous attack uses the RFC protocol’s callback routine, which allows a server to execute code on the client after a successful connection has been made, in the context of the user running the client application. An Evil twin is first created, and once an unsuspecting user’s request is received, the malicious server can leverage the callback function to gain control of the client’s system.
Both attacks work on a default install of the latest SAP Netweaver, with the program ID being the only piece of information required for successful exploitation. If transport encryption (SNC) is not enabled, the ID can be sniffed over the wire or it may be guessed in cases where the administrator has set it to be the same as the name of the function or the host, as has been seen in production a number of times.
These issues are addressed with configuration changes to restrict hosts that are allowed to register at the gateway. In the next post I will go into detail of how to exploit these issues, as well as the various steps required to lock down your SAP RFC configuration.
References
[1] - Profile parameter
login/password_downwards_compatibility needs to be set to ‘0’ to disable
password hashing downwards compatibility
[2] - DLL hijacking through shortcuts
[3] - Onapsis BizSploit - Opensource ERP Penetration Testing framework
[4] - CYBSEC Whitepaper – Exploiting SAP Internals
Read the next blog posts on SAP Exploitation:
SAP Exploitation - Part 2
SAP Exploitation - Part 3