By: Moshe Ben Simon & Julian Petersohn
Every SAP customer has a minimum of one SAPRouter Instance running within the infrastructure. In addition, these instances are often directly accessible through the Internet.
As the SAPRouter is a network-level component routing SAP-specific traffic, the network team would be responsible for the SAPRouter. As it is an SAP proprietary solution, the SAP Application team is responsible for this component.
Due to the unclear responsibilities, SAP Customers often do not configure SAP Router properly and leave it exposed to the public in an insecure mode.
The below graphic shows a network connection with SAProuter:
Figure 2: Example Diagram of SAPRouter deployment
The next sections will walk through a scenario where SAP Router was left vulnerable to the Internet and how a threat actor can compromise it.
An administrator has deployed a new Cloud VM to install the SAP Router service on it. The Administrator does not recognize that he did not unselect the creation of a Public IP address.
After the deployment, the Administrator updated the security configuration of the VM to allow inbound traffic to Port 3299/TCP, which is the default port of the SAP Router application, and Port 22/TCP for remote administration. In addition, the Administrator configured a Port forwarding on the FortiGate Firewall Instance to allow external access to the Virtual Machine, as intended.
After the installation of the SAP Router application on the Server, the Administrator faced some trouble to establishing a connection between SAP and the internal SAP Systems, so the Administrator decided after spending time on troubleshooting to keep the last working configuration of SAPROUTTAB, which is shown as follow:
Figure 3: Example SAPROUTTAB
The first permit rule allows access to every SAP port/protocol within the 10.0.0.0/16 network range from everywhere.
The second permit rule allows access to the SSH Ports (22/TCP) to every System within the 10.0.0.0/16 network range from everywhere.
The last rule denies every other traffic that the two rules do not allow.
The Administrator noticed that some Servers had a higher load not long after the deployment than usual. This behavior could have many different reasons, so he did not investigate further.
After some time, the Administrator received a message from the Cloud provider regarding some suspicious server activity. The Administrator started a more detailed analysis of the Server and noticed many login tries via SSH coming from the SAPRouter Server. The last login of the chain was successful, and based on the history of the executed commands, the Administrator found an executed bash script that acted as a stage for further payloads. On the SAPRouter Server itself, the Administrator could not find any indicator of a compromise of the Server, allowing the Attacker to start an SSH Brute Force attack against the internal Server.
But how could the hacker gain access to the Servers? Through mass Port scanning for port 3299 (TCP), the hacker found the forgotten Public IP of the SAP Router.
The SAPRouter, depending on the configuration, is not only able to handle SAP NI traffic (SAP own Network protocol stack). SAPRouter can also handle classic TCP/IP protocols like SSH or Telnet.
As the Administrator has prepared the SAPRouter for possible further Support Sessions with SAP, he allows SSH communication to his internal Server in the SAPRouter ACL file.
Based on the combination of the access to the exposed Public IP interface of the SAPRouter and the insecure ACL file, the Attacker set up SSH communication to the internal servers.
The Attacker did a simple SSH Brute force through the SAP Router to find a weak password configured System. After they found a system with a weak password, the hacker executed the bash script, with which they installed a crypto concurrency miner on the System.
In the last chapter, we talked about a scenario where an administrator configured an SAP Router System and left it vulnerable open to the Internet. This chapter will give you some possible ways to set up a secure SAP Router installation.
Figure 4: FortiGate AppControl detection example of SSH and SAP Router traffic
Figure 5: FortiGate IPS Log example dropping SSH Brute force
4. Use Deception technology for detection and response
Using deception technology like FortiDeceptor helps to detect this type of attack. You can deploy a Decoy that acts like a normal Linux Server and provides an SSH service or act like an SAP System. If the Attacker does a port scan, he will find the Decoys and start the attack against them. The attack will get detected by the FortiDeceptor and trigger a mitigation response action using the Fortinet Security Fabric like blocking the IP Address on the FortiGate, sending Threat Indicators to FortiSIEM, etc.
5. Only use secure SAPROUTTAB
We highly recommend NEVER using wildcards (*) within SAPROUTTAB. SAP implemented fallback security features that prevent allowing ports like SSH and telnet with a wildcard in the Service section. Only SAP-specific ports like 33nn, 32nn are allowed with a service wildcard. Ports like SSH and telnet need to be specified explicitly but sometimes required by SAP Support.
Also, it is important to specify a target IP and not a network range to avoid possible access to other systems like the intended.
To establish only secure connections through SAP Router, configure SNC between SAP Router and the SAP Systems and only allow encrypted communication through SAP Router.
6. Further Links and Guidelines
SAP provides some guidelines and helps to secure the SAPRouter Application itself. This section will find some SAP Notes, which provide the necessary information.
 Shodan Query:
https://www.shodan.io/search?query=port%3A3299+%21HTTP+Network+packet+too+big (from: 22.09.2021)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.