There has been a lot of attention in the news recently about vulnerabilities in SAProuter and how these vulnerabilities could be leveraged. The news spun out of a report that a piece of malware was actively learning about SAP systems known to any PC the malware infected. We wrote about this malware and the possible implications in a recent blog post; but the summary is it seems that the professional bad guy community is starting to take an interest in SAP.
So what is the SAProuter? It is a lot like the name suggests; an application produced by SAP which facilitates, logs (if enabled) and filters communications and network connections between different SAP systems, or between a SAP system and other networks or resources. However it is not a gateway/firewall technology; it only filters communications if the clients are configured to send their communication to the router; and not directly to the end point.
Because of this it should be used in conjunction with a firewall; or else a user who the SAProuter is configured to deny access to a specific backend SAP system could simply manually reconfigure their SAP client to attempt to connect directly with the sensitive SAP systems and start interacting with them directly; bypassing all the ACLs and controls in the SAProuter. A firewall is required to block those direct connections and only allow users to access SAP systems via SAProuter; thus allowing the SAProuter’s rules to be enforced (and connections to be logged).
The SAProuter is intended to enforce ACLs to ensure that defined machines/users are the only ones with the ability to communicate with sensitive SAP systems. So, by design the SAProuter has the ability to communicate with every critical SAP system. Because of the scope of the access the SAProuter has we have been publishing, presenting and training on the importance of securing the SAProuter for years now. In fact as part of our ongoing SAP Security In-Depth (SSID) series we published a paper entitled “SAP Security In-Depth Vol. 6: Securing the Gate to the Kingdom – Auditing the SAProuter”.
In fact we consider this risk to be so important that we produced a two part blog post providing details on how to assess a SAProuter’s security using the free and open source tool Bizploit (released 2009) – ensuring anyone could take steps to measure the risk to their SAProuter. You can read the blogs, Part I here and then Part II here.
The risk present in any exposed SAProuter system is of an attacker exploiting a vulnerability in the SAProuter and then leveraging the access the SAProuter has. However the risk has a known and simple solution, bring the SAProuter instance up to date. For Onapsis X1 users the sense of urgency being generated by the threat to SAProuter is a source of some dry amusement; as they have the capability to point Onapsis X1 at any instance of their SAProuters at any time and immediately know if it is out of date and then schedule their remediation efforts.