The SAProuter is a technical infrastructure component of every SAP landscape and most SAP Basis consultants have had to deal with it. Although some sources describe it as a reverse proxy, its original function is to facilitate maintenance access for SAP (or other legitimate external parties) to customer landscapes.
It does so by creating a tunnel (usually on port 3299) between the networks of SAP customers and SAP. The tunnel has 2 distinct operating modes: DIAG or TCP. In DIAG mode, it only allows for traffic using the DIAG protocol that is used between SAPGUI clients and SAP systems, usually an SAP consultant logging on to a customer system. In TCP or native mode, it allows for most TCP protocols to pass through, so SAP consultants can log in to customers systems using a variety of methods: (HTTP, Telnet, SSH etc).
The aim of this tunnel was to lower the amount of network ports to be opened in the customer firewall and to let SAProuter handle the single port needed (usually port 3299) by providing some extra controls.
These controls are listed in the SAProuttab, a file that specifies which external hosts can connect via the SAProuter port.
When the rules maintained in the SAProuttab are not correctly maintained or using too many wild cards, access may be given to non-authorised 3rd parties. It is in this situation that the SAProuter may act as a proxy for illegal access.
SAProuter vulnerability history
The SAProuter acting as a proxy was first discovered in 2010 by Mariano Nunez di Groce[1]. In his HITB presentation he showed that when the SAProuttab is not maintained correctly (for instance using excessive wildcards of a “P * * * *” directive), SAP systems can be exploited remotely using a tool called “Bizsploit”, in many cases directly from the internet. This raised the risk level enormously.
It is a sad fact that many primary (internet-facing) SAProuters use a SAProuttab that contains the fatal “P * * * *” directive (or something to a similar effect), leaving their SAP landscapes wide open to malicious 3rd parties.
When bad SAProuter security is combined with bad SAP Gateway security, SAP systems can be vulnerable to “remote execution of commands” using a remote RFC client via SAProuter, a method hinted at in OSS Note 1298433 (version 12.03.2012). This was mitigated using a higher kernel 7.10 and the “difficult parameter” gw/reg_no_conn_info. In addition, the SAP parameter gw/acl_mode with standard value 1 protects against SAP gateway exploitation by external commands.
In September 2012, Dave Hartley from F-Secure found the way to switch the SAProuter to native mode[2] and again 1 year later in 2013 some new Metasploit modules for SAProuter saw the light, explained in a 2014 blog from Rapid-7[3]:
- sap_service_discovery (author Chris John Riley)
- sap_router_info_request (author Mariano Nunez)
- sap_router_portscanner (author Bruno Morisson)
- sap_hostctrl_getcomputersystem (created by Bruno Morisson)
The last module makes use of a vulnerability inside the 7.03 SAP HostAgent version CVE-2013-3319 described in OSS Note 1816536 in which enabled unauthenticated remote SOAP requests to be executed by the SAP Hostagent via the SAProuter.
OSS Note 1663732 from 14.08.2012 describes a vulnerability for SAProuters started with option -n.
In 2013, OSS Note 1820666 mentioned a buffer overflow in SAProuter enabling remote code execution (CVSS score 9.3)
Another presentation in 2014 from Alexander Polyakov, “Practical Pentesting”[4] highlighted several SAProuter bugs:
- when configured with start parameter -l, info requests are allowed and active connections and their target SAP systems & ports can be remotely disclosed
- DOS attacks by repeated connections attempts on found connections until the max. connection pool has been reached.
- the start parameter -x enables remote administration (starting, stopping, listing connections) of the SAProuter. See also OSS Notes 1853140 and 2019962.
- SAP Router memory and remote compromise (presumably the bug of OSS Note 1820666)
In 2014, Martin Gallo, published a SAProuter Password Timing Attack, aka CVE-2014-0984. This vulnerability allowed for the disclosure of passwords used in the SAProuttab. SAP brought out OSS Note 1986895 to mitigate.
In 2018, OSS Note 2622434 described the possible interception of passwords in subsequent SAProuter connections. Patches for SAProuter versions 7.21, 7.45 and 7.53 were brought out.
There are 2 other bugs described in OSS Notes 2948442 and 2888060 that may cause a SAProuter to crash when queried with the “-l” option.
How to protect your SAProuter
Use the latest versions and patch frequently.
Always use the latest version. Some primary SAProuters are located on dedicated servers on the edge (or in a DMZ) of a customer network. Since these are hard to access and service, the risk may be that they do not get patched too often.
Always use a firewall in combination with SAProuter
See OSS Note 48243 – Integrating the SAProuter software into a firewall environment
Use SNC or VPN to encrypt the SAProuter traffic.
Some good blogs explain how to set up SAProuter using SNC or VPN:
SNC: https://support.sap.com/en/tools/connectivity-tools/saprouter/install-saprouter.html
VPN: OSS Note 486688 – Schedule VPN connection to SAP network
=> Use the latest Cryptolib when using SNC and patch it regularly.
In addition, make sure to configure strong ciphersuites using parameters OSS Note 2338952:
- ccl/snc/client_cipher_suites = HIGH
- ccl/snc/server_cipher_suites = HIGH
Start the SAProuter using the correct options.
- SAProuters can be started using special option flags. Enable logging (-G option) and tracing (-T option). Consider whether to use options -J, -E (not advisable) and -V with value 2 or 3.
- Do not start SAProuter using option -l and when you do, make sure to enforce the use of a password using option -P.
- Never use option -x, -X or -n.
Maintain the SAProuttab properly.
- Maintain only necessary connections in the table. Be as restrictive as possible.
- Do not use wildcards (*) for the destination host (<dest-host>) and the destination port (<dest-serv>) in P or S lines of the route permission table. If the table contains these lines, the SAProuter issues a warning message.
- If possible, use “S” instead of “P” for all positive entries.
- Maintain prohibition rule “D * * * *” explicitly as the last entry in the table.
- Prevent connections of the SAProuter to itself (loopback). For more information, see SAP Note 1853140.
Other interesting options for SAProuter.
OSS Note 525751 – Installation of the SNC SAPRouter as NT Service
How to manage SAProuter with SAPControl (German page that translates well in English).
When using this option, make sure to secure ports 5XX13 and 5XX14 using parameters “service/http/acl_file” and “service/https/acl_file”. (See OSS Note 1495075).
OSS Notes:
1921693 – How to update SAProuter
2910668 – Useful information on configuring the SAPRouter
48243 – Integrating the SAProuter software into a firewall environment
1895350 – Secure configuration of SAProuter
46902 – Security aspects with remote access
Protect4S checks for SAProuter / SAProuttab vulnerabilities.
Protect4S periodically checks SAProuters and SAProuttab for all vulnerabilities described in this article (and many more), making sure that your SAP landscape stays safe by minimizing the risk of remote exploitation.
Learn more from Protect4S. Check our website or Try out Protect4S for free.
[1] http://conference.hitb.org/hitbsecconf2010ams/materials/D2T2%20-%20Mariano%20Nunez%20Di%20Croce%20-%20SAProuter%20.pdf
[2] https://labs.f-secure.com/archive/sap-smashing-internet-windows/
[3] https://www.rapid7.com/blog/post/2014/01/09/piercing-saprouter-with-metasploit/
[4] https://www.slideshare.net/SAPSecurity/practical-sap-pentesting-bsides-san-paulo
