SAP NetWeaver ABAP Security Configuration. Part 5: Open remote management interfaces
Today we are going on with our series of articles where we describe the 33 steps to cybersecurity. The subject is of great significance not only to a small group of SAP infosec specialists but to all those people who work with ERP systems as recent years have witnessed an increased awareness of business data protection problems. Not to go into details, let us get right to the topic.
The SAP NetWeaver platform includes not only the Dispatcher service responsible for SAP GUI user connections, but it also includes a whole range of other services. Each of them listens to a remote port and accepts network connections. Some of these services grant administrative access and remote administration functions. Some of them also grant access to various technical services. Load balancing system of the SAP Message Server and remote administration system of the SAP Management console are among them.
One can connect to these services via the corporate intranet or the Internet. What is more, in case those services’ settings are insecure, they are manageable remotely without authentication data.
So, this section contains information about the most insecure services. Their settings should by no means be accessible via the corporate intranet.
Except those services we are going to discuss, the system has other less critical and widespread services (e.g. the Message Server HTTP). But you should restrict access to them as well. For a full list of SAP services, check out “TCP/IP Ports Used by SAP Applications” paper . The list’s content depends on the installed components of each particular system.
Besides, it is also advisable to check third-party services that may be enabled on this server, such as remote administration interfaces for various DBMS, remote monitoring, and data backup systems, etc. The thing is that you should restrict access to them using authentication both at the network and application levels, if possible.
[EASAI-NA-11] Unauthorized access to the SAPControl (SAP MMC) service functions
The SAP Start Service starts on each computer simultaneously with the SAP solution instance. In Windows, this process is executed with sapstartsrv.exe, in UNIX – with sapstartsrv. The SAP Start Service provides the following functions for the SAP solution, instance and process monitoring:
- start and stop;
- monitoring the active state;
- reading logs, trace files and configuration files;
- technical information, for example, on network ports, active sessions, etc.
These services are accessible via the SAPControl SOAP Web Service and are used by the SAP monitoring tools (SAP Management Console, NetWeaver Administrator and others). When service starts, it uses the following ports:
- HTTP port 5<xx>13 (or sapctrl<txx> in /etc/services), where <xx> is the instance number;
- HTTPS port 5<xx>14 (or sapctrls<xx> in /etc/services), where <xx> is the instance number.
For example, when service starts, either the HTTP port 50013 or the HTTPS port 50014 is used for the instance 00. . This process allows to read various system data without user’s consent. However, it requires user authentication for secure operations, such as to start or stop the SAP instance. Startsrv controls internal list of secured operations (depending on the version of the release, default list may differ). If necessary, you can change the list using service/protectedwebmethods parameter.
By means of many insecure methods, one can get access to system configuration data, request system status, read the log and trace files that may contain user passwords or HTTP session files. Eventually, this data can be used to implement more critical attacks.
In accordance with SAP Security Note 1600846 , sapstartsrv settings must be reconfigured. To do this, you need to set the parameter service/protectedwebmethods to DEFAULT in a default system profile (DEFAULT.PFL). To apply the changes, restart all sapstartsrv services in the cluster. Besides, this change of value, also involves implementation of a list of all critical methods by default. Instead, you can use the value ALL (i.e. all methods), though it is considered excessive (the parameter and its values are described in detail in SAP Security Note 927637 ).
Implementation of SAP Security Note 1439348  along with related recommendations may be seen as an additional method of patching this vulnerability.
It is advisable to restrict access to this service by IP-addreses. To do this, you need to define Access Control List (ACL) by changing values of services/http/acl_file and /https/acl_file.
[EASAI-NA-12] Unauthorized access to the SAPHostControl service functions
The SAP Host Agent is a component designated for other components management, their control and monitoring. It consists of the following services and programs:
- The SAPHostExec is a control program that runs under root (UNIX) or LocalSystem (Windows) accounts. It controls all the functions called for by the specific users of this type, such as saposcol and sapacosprep OS collectors. The program is connected with the sapstartsrv in a host mode via the local socket that provides high-speed and secure connection (see the picture). It also starts simultaneously with the host.
- DB4STATS and SAPILED are the programs that supply IBM I with the SAP Database Performance Collector and the SAP ILE daemon respectively.
- The SAPHostControl (sapstartsrv in the host mode) is the SAP NetWeaver management agent. It is an executable of sapstartsrv run in the host mode under the sapadm user. It is using remote TCP 1128 port. That is why it is responsible not for the SAP instance, but for any host monitoring, which is controlled centrally.
A profile used while starting executable files also determines whether sapstartsrv will run in an instance operating mode (with an appropriate instance profile) or in a host mode (with the host’s own profile that may include parameters SAPSystem = 99, SAPSystemName = SAP). 
For data transmission, the SOAP protocol is used. In case encryption is set up, it encapsulates into the SSL. This service allows reading some system information without user’s consent. It also has vulnerabilities that allow running OS commands remotely.
An authorized adversary can run any random code, caused by the SAPHostControl service maintenance error remotely using the SAP NetWeaver. This happens when this service does not properly validate incoming data of the SOAP management interface. With the SOAP interface running on TCP port 1128, an adversary can exploit this vulnerability to inject and execute random commands to the system having administrative privileges.
Many insecure methods make system configuration or status data requests possible. One can also read logs and trace files that may contain user passwords or HTTP session files. Also, remote execution of OS commands using OS command injection vulnerability becomes available (see SAP Security Note 1341333 ). This data can be used to implement more critical attacks.
Remote execution of random code vulnerability was fixed in May 2012 with SAP Security Note 1341333.
SAP Security Note 1816536  released in April 2012 prevents information disclosure. Resulting from this, it’s sufficient to apply both of these security updates to fix vulnerabilities.
In order to additionally secure the service you can restrict access to it by IP, using a personal firewall or by means of network equipment, granting access only from those servers where you take data from.
[EASAI-NA-13] Unauthorized access to the Message Server service functions
The SAP Message Server is a system component that, on the one hand, manages communication between application servers (dialog instances) within one SAP system and, on the other hand, ensures balancing of a load coming from such clients as the SAP GUI.
In standard, lower than 7.0 versions, Message Server port is used for interaction of both clients and application servers. Starting from the version 7.0, Message Server port is by default divided into an internal and an external port. An internal port is used for application connections to the server, while an external port is used for end-user connections.
In order to control the list of addresses one can connect to the Message Server with, you need to activate the Access Control List (ACL). To do this, use ms/acl_info parameter. It indicates the file where you can configure access to the Message Server. This file contains application server’s host and domain names, IP addresses and/or subnet masks using which you can access the Message Server. External clients that retrieve data from the Message Server are not anyhow affected by this. The data remains accessible. Default parameter value is /usr/sap/<SID>/SYS/global/ms_acl_info.
In case ACL file is absent or misconfigured, malicious software or potential adversaries can access the Message Server, register their own application server and perform “man-in-the- middle” attacks. In other words, intercept credentials of legitimate users trying to connect to the Message Server. This can result in gaining unrestricted access to user accounts.
It is essential to configure ms/acl_info parameter. It indicates the ACL file that has an authorized access to the Message Server.
(default value: /usr/sap/<SID>/SYS/global/ms_acl_info). This file should contain application servers’ host and domain names, IP addresses and/or subnet masks from which application servers are allowed to address the Message Server. They address the Message Server using the following syntax:
HOST = [*| ip | hostname | network mask | domain ] [, …]
Configuration file accepts the “*” wildcard in access control description (e.g., HOST = *.sap.com or HOST = 157.23.45.*). The “*” wildcard should be avoided, especially when in the HOST = * form, as it makes access from any workstation possible.
Access control settings do not affect the retrieval of technical information from the Message Server. It remains always accessible.
As an alternative to ACL file configuration we suggest the following options:
- In 4.5 and lower releases, Message Server port defined by rdisp/mshost and rdisp/msserv parameters should be blocked by the firewall. Only those network segments with SAP servers should be granted access to this port.
- For 6.4 and lower releases, it is highly recommended to distribute Message Server services between the two ports – one for the SAP GUI client access (rdisp/msserv), the other one – to access internal connections with the server (rdisp/msserv_internal).
[EASAI-NA-14] Unauthorized access to the Oracle DBMS
Currently, Oracle Data Management System (DBMS) is the most widely spread DBMS along with the SAP. Unfortunately, if installed together with the SAP, this DBMS has insecure REMOTE_OS_AUTHENT settings. REMOTE_OS_AUTHENT ensures execution of trusted operations between various SAP solutions.
More importantly, it is able to circumvent such security checks, in particular DBMS password check. The only way to mitigate this risk is to restrict remote access to Oracle DBMS port by preserving it only for necessary servers by IP addresses.
This setting is implemented by means of the Sqlnet.ora configuration file. In particular, it has to do with tcp.validnode_checking parameter, which is required to validate host names while they attempt to establish inbound connections. When this parameter is set to yes value, inbound connections are only allowed if they come from the note listed in TCP.INVITED_NODES or TCP.EXCLUDED_NODE. Note that, the first one is of higher priority.
TCP.INVITED_NODES, in turn, requires each client host to be included in the sqlnet.invited_nodes server list.
If restrictions for client nodes are not set, an attacker can connect to the Oracle DBMS without password, using a trusted login $OPS<SID>adm. Thus, the attacker will get almost unlimited access to the DBMS.
Next step is to decrypt SAPR3 user password. One can take it from the SAPUSER table and connect to the DBMS with this user’s privileges. This user has a full access to the SAP data, thus an adversary can get an unlimited control over the system.
Set the tcp.validnode_checking parameter in the sqlnet.ora file to ”
yes. This way it’s possible to check whether there are inbound connections coming from the permitted nodes listed in sqlnet.invited_nodes.
It’s imperative to specify all the necessary client hosts in the sqlnet.invitednodes server. It is recommended to leave only the trusted systems in this list.