Each application has several security settings that do not fit into any of the critical issues groups mentioned in our series of articles.Among such settings there are both standard settings (such as password length or the number of attempts given to enter invalid password) and the specific to the system, individual settings. In this article we are going to use as an example the SAP Gateway service access settings.
[EASAI-NA-15] Minimal password length
Description
While choosing a new user password, consider that passwords should meet the SAP system requirements and correspond to the corporate policy. Various profile parameters are set up in order to control that passwords meet the requirements. Out of all those parameters, login/min_password_lng is the main one. It specifies the allowed minimal password length. This parameter’s default value is 6, although its acceptable to use values ranging from 3 to 40.
Threat
In case the minimum password length is set to less than 8 symbols, an adversary can easily decrypt a password using USR02 table hash. Alternatively, one can gain access remotely by bruteforcing the password, if the login/fails_to_user_lock parameter is set incorrectly. The login/failstouserlock parameter defines the number of available invalid login attempts, before the user’s account is locked out by the system.
Solution
Set the login/min_password_lng parameter value for more than 8, otherwise choose the value which is in accordance with the company’s security polity. This way, you can lessen the risk of potential attack.
[EASAI-NA-16] Number of invalid logon attempts before the user account lock out
Description
The login/fails_to_user_lock parameter defines the maximum number of incorrect passwords allowed to be entered before the user account is locked out. It’s very important as it interacts directly with the login/min_password_lng parameter. Thelogin/min_password_lng parameter, in turn, defines the minimum password length, and thus, prevents remote password bruteforcing. This parameter’s default value is 5, although it’s acceptable to set values ranging from 1 to 99.
Threat
If the login/fails_to_user_lock parameter is set incorrectly or has a low value, an adversary may succeed in carrying out a brute force attack and get an unauthorized access to user credentials.
Solution
Set the login/fails_to_user_lock parameter value for not more than 6. This way, you’ll lessen the risk of potential brute force attack.
[EASAI-NA-17] Password compliance with the security policies in place
Description
The login/password_compliance_to_current_policy parameter is highly important. If this parameter is absent or or is set to 0,the password length and complexity settings would affect only newly created users. Thus, the settings would not be automatically applied to all the other users. Consequently, all of those old users would have insecure passwords.
If this parameter is set to 1, the settings would affect old users with insecure passwords and force them to choose secure ones upon their logging into the system.
Threat
If the login/password_compliance_to_current_policy parameter is set to 0, password policy compliance for old users is not set. This allows users to have insecure passwords. As a result, these user accounts are easy to be compromised.
Solution
Set the login/compliance_to_current_policy parameter to 1 to apply the password policy requirements for all users, including those newly created.
[EASAI-NA-18] Access control settings for RFC-service (reginfo.dat)
Description
The SAP Gateway is the application server technical component with RFC-based functionality that manages communications between various SAP systems. Since the gateway is an interface of application server for external connections (with other SAP systems, external programs, etc.), higher security requirements are applied to it.The SAP Gateway security is managed by the reginfo and thesec_info files. The reginfo file is defined by the gw/reg_info parameter and the sec_info file is defined by the gw/sec_infoparameter.
Some clients may be allowed to register their services on the server. Specify the services registered in the reginfo file to control the access to them, cancel their registration, determine external server services allowed to be registered on the gateway. The file name (file path) is defined by the gw/reginfo parameter. The default file path is: /usr/sap/<SID>/<INSTANCE>/data/reginfo.
If this file doesn’t exist, any server processes may be registered from any hosts. Speaking of which, starting from the kernel version 7.20 and higher, for security purposes, this process is restricted by the gw/acl_mode instance profile parameter. For further references, see SAP Security Note 1480644 . However, if this file exists but it is empty or has no valid records, it is not allowed to register.
If somebody tries to register a service on the gateway, valid record is searched for in the file. The record specifies this user’s right to register this particular service. If the record is not found, user’s registration is denied. It is crucial to understand that the reginfo file can be read only ONCE, when a program is being registered. All the further changes and restrictions in the reginfo file do not affect successfully registered programs.
Threat
In case the reginfo.dat file is absent or its configuration is incorrect, an adversary may register any service on the SAP Gateway and get an unauthorized access to the SAP server. As an example, a wildcard “*” can be used in host definitions, signifying that service’s registration is available from any host. One may register a new service that would perform malicious functions. It may be registered under the same name, as has the service that already exists. Thus, a legitimate user would be able to run it.
Solution
Unauthorized service registration may be avoided by means of creating a reginfo.dat file in the SAP Gateway data directory. If the file exists, the system checks the availability of rights to call remote RFC functions from this file. This way, it prevents unauthorized access.
File records should have the following syntax (note that each line must have TP record, all the other parameters are optional):
TP=name [NO=<n>] [HOST=<host>] [ACCESS=<host>] [CANCEL=<host>], where:
TP=name is a registration ID of the external server program.
NO=n shows what number of registrations with that ID is allowed.
HOST=<host> is (a) name(s) of a host using which registered servers are allowed to enter the system. Here you may specify host names’ list, IP addresses, domain names or subnet masks. The registration is allowed only if the server enters the system from this node. Without this optional parameter, it is allowed to register from any host.
ACCESS=<host> is(are) host name(s) that has (have) the right to use the registered service. Here you may specify the list of host names, IP addresses, domain names or subnet masks. The local system is always allowed to use the server. Without this optional parameter, the server is accessible from any node.
CANCEL=<host> is(are) (a) host name(s) that allow(s) to log off the registered system server. The same rules are applied as has theACCESS parameter.
Starting from the version kernels 6.40, patch 212; 7.00, patch 139; 7.10, patch 80, and higher, permit and deny values are added to the syntax. They are indicated by the Latin upper-case letters P and D respectively (see SAP Security Note 1105897 ). P means that a program is allowed to be registered, (as in the old syntax line); D prevents registration. The first line layout in such file is#VERSION=2. All the next lines are structured the following way: P|D TP=name [NO=<n>] [HOST=<host>] [ACCESS=<host>] [CANCEL=<host>]
Warning! The system reads key words only if they are written in upper-case letters. Incorrect specification leads to HOST=* wildcard value, which would probably be undesired (there are instructions on how to fix it in SAP Security Note 1473017).
In all the host names’ lists (HOST, ACCESS and CANCEL), key words must be separated by commas. Any space would indicate the end of host names’ list.
You can find detailed syntax review in SAP Security Note 1069911 .
For the correct reginfo.dat configuration use recommendations from SAP Security Note 1425765 and 1408081.
[EASAI-NA-19] Access control settings for RFC-service (secinfo.dat)
Description
In the secinfo file, you may specify which external services may be started. Also, you can specify who can register external server services on the gateway. And lastly, which external services can be registered on the gateway. Note that this concerns only kernel versions 46D and lower. Starting from the version 6.40, service registration from external servers is controlled with a separateRegInfo file. In other words, secinfo security file is used to prevent unsanctioned start of an external program. File name is defined by the parameter gw/sec_info. Default file path is: /usr/sap/<SID>/<INSTANCE>/data/secinfo.
If the file does not exist the system runs all external programs. In case, this file is empty or has no valid lines, no external service may be started.
Upon the start of an external service, the system scans the file, searching for a valid record. If it was not found, the system shows error message, and cancels the service start.
Threat
In case secinfo.dat file is absent or misconfigured (e.g., it has “*” wildcard in host, program of subnets definitions), an adversary may run a service registered in the SAP Gateway, and get an unauthorized access to its functionality. In some cases, if the program can execute OS commands, one may access the SAP server.
Solution
You should create secinfo.dat file in the SAP Gateway data directory. This way it would be possible to prevent unauthorized program launching. If the file exists, the system checks the availability of rights to call remote RFC functions from this file. This way, it prevents unauthorized access.
File records should have the following syntax ( USER, HOST and TP lines are obligatory, and other parameters in each line are optional):
TP=name HOST=<host> USER=<user> [USER-HOST=<user-host>], where:
TP=<program name> is the name of a program, you would like to run (in addition, you can specify a wildcard for program ID, e.g.,TP=XYZ*)
HOST=<host> - name of the host where you would like to run a program. It defines destination address. Note the following difference: in the reg_info file syntax, this parameter specifies client address; it is available starting from the version 6.40, patch 194; 7.00, patch 119 and higher versions.
USER=<user> is the name of the user who would like to start a program. In case the program starts from application server, this is username for the system. However, if the program is external, this is OS username.
USER-HOST=<host> (or a source address) is a hostname of the user who would like to start a program. For security purposes, it is strongly recommended to install this option (SAP Security Note 1434117 ).
In 6.40 and lower versions, PWD=<Password> parameter was supported (ignored in newer systems).
In 6.40, patch 212; 7.00, patch 139; 7.10, patch 80, and higher kernel versions, there appeared additional permit and deny values indicated by the Latin upper-case P and D respectively (see SAP Security Note 1105897 ). P permits to run the program (the same as the old syntax line); D denies it. The syntax of the first line in such file is #VERSION=2, and that of all posterior lines is:
P|D TP=<tp> HOST=<host> USER=<user> [USER-HOST=<userhost>]
Warning: the system reads key words in the upper-case only. Incorrect specification leads to the HOST=* wildcard value, which is undesired. (there are guidelines on how to fix it in the SAP Security Note 1473017).
For detailed explanation of this syntax check out the SAP Security Note 614971 .
For the correct secinfo.dat configuration refer to SAP Security Notes 1408081, 1525125, 1425765.
Further steps.
The number of various security settings to be fine-tuned is enormous, and there are specific ones to each particular SAP solution or module. As the starting point, you can refer to the document called SAP NetWeaver Security Guide. There you can find the User Authentication section. Afterwards, you better switch to a more detailed description of the papers where each module and service security configuration is described.
Comments