Securing the SAProuter from Remote Attacks

The surge in remote working has led to an increasing reliance on the SAProuter as a means to facilitate secure remote access to SAP applications. As a reverse proxy between external networks and SAP landscapes, the SAProuter enables organizations to apply more granular policies for filtering and securing connections to SAP systems than network firewalls. However, far from improving security, an improperly configured SAProuter can expose organizations to dangerous exploits that could lead to the compromise of SAP servers.

Since the SAProuter is an internet-facing proxy that provides a direct path to SAP systems, it is an accessible and high-value target for attackers. Port scans against exposed IP addresses will reveal SAProuters available on the standard port 3299. Attackers can send information requests to detected SAProuters to enumerate the scheme for internal IP addresses based on the details of connected hosts disclosed in the response. Once the internal IP address scheme is determined, attackers can then scan the internal network by sending connection requests from the SAProuter to connected hosts. The responses can enable attackers to discover open ports for not only SAP services but services such as HTTP, SMTP, FTP, and SSH if the SAProuter supports native connections.

The information can be used to connect to open and vulnerable services in SAP servers by pivoting through the SAProuter. Once connected, attackers can execute targeted exploits against the servers. For example, an unauthenticated SOAP request to the SAP Host Agent on port 1128 can disclose operating system users that can be targeted using brute force and other attacks. Attackers can also route malicious payloads to SAP servers through the SAProuter.

The secure configuration of the SAProuter can prevent or mitigate such attacks. The route permission table defined in the saprouttab file should specify the source hosts permitted to connect to specific services and target hosts. The use of wildcards in route strings should be avoided. Native connections should be blocked using S entries for the saprouttab rather than P entries. KT and KP entries are recommended to enforce SNC for connections. Information disclosure via the SAProuter should be prevented using the option -Z for info requests. Switching to a non-standard port for the SAProuter is advisable. SAProuter binaries should be updated to the latest available version to apply patches for program vulnerabilities. This includes critical vulnerabilities addressed by notes 1820666 and 1663732. Finally, the SAProuter should be installed in a Demilitarized Zone (DMZ) on a host with a hardened operating system. SAP recommends a C2 class compliant operating system.

Logging for the SAProuter should be enabled using option -G. Once enabled, the SAProuter log can be monitored using SAP Solution Manager to alert for suspected attacks against including accepted or rejected information requests, connection requests, port scans, and native connections.

Leave a Reply

Your email address will not be published.