While some of the mitigations are general network security recommendations, such as appropriate network segregation and filtering, others are specific to SAP and the security risks posed by a default Netweaver installation. The recommendations listed here by no means constitute a complete SAP hardening guide, and only serve to address the issues described in my previous blog posts. In September 2010, SAP released a fairly comprehensive Netweaver security guide [1] taking into consideration attacks currently possible and further reading is highly recommended.
Network Restrictions
SAP environments are fairly complex, comprising of a large number of network services and functions that are, by default, enabled out of the box leading to an increased attack surface. This security concern is compounded by some of the more risky methods SAP have chosen to use in their product design, such as the remote operating system authentication requirement when made to work with an Oracle database, that I will be expanding on later in this post. As SAP environments are commonly entrusted with sensitive data, secure network design and extensive filtering policies preventing direct access to these crucial servers would normally be expected. More often than not however, organisations do not do this, and is the reason for re-iterating the importance of these security measures in this post.
Generally, users do not require direct access to the database, management consoles and services or RFC endpoints. A suitable filtering policy and segregated network design should restrict access to these servers and services to only those systems that require them to function; reducing the overall attack surface. This is a crucial step in the hardening of the SAP landscape and provides a first layer of defence against most of the current attacks against SAP systems.
Password Hashing and Default Accounts
The password hashing mechanisms in SAP, as explained previously, have had security issues in the past. Widely used password cracking tools have support for the older SAP hashes, and should be reason enough to ensure the latest code version ‘H’ is being used in your environment (this is default for Netweaver 7.02 onwards). ‘Downward compatibility’ should be disabled in order to benefit from the security enhancement provided by this version:
password_downwards_compatibility = 0 (transaction RZ11)
Netweaver will not automatically remove any hashes previously stored with older code versions or with downward compatibility enabled; this needs to be performed manually.
A strong password policy should also be enforced for all SAP accounts using the policy parameters found under ‘login’ (transaction RZ11); such as enforcing a minimum password length (min_password_lng) and the minimum number of special characters (login/min_password_specials). Special consideration should be given to the login/no_automatic_user_sapstar configuration in Netweaver prior to 7.00, as having this enabled will result in a new administrative SAP* user with a default password being enabled automatically upon the creation of any new client.
Further to the topic of password management, several default accounts are created during install with commonly known passwords allowing attackers easy access if these have not been changed. The following table shows these accounts with their default passwords – they should have their passwords changed in all SAP clients:
Additionally the EARLYWATCH, SAPCPIC and DDIC users can be locked if they are not explicitly used in your environment.
SAPGUI
SAPGUI, as of version 7.10, includes numerous security features that offer improved end user security. SNC (Secure Network Communication) enables transport level encryption between SAPGUI users and SAP servers to prevent traffic from passing over the wire in the unencrypted DIAG protocol. This can be enabled in the server’s instance profile by setting the following parameters in transaction RZ10:
Snc/enable=1 and Snc/accept_insecure_gui=0 (to disallow unencrypted connections altogether)
SAPGUI’s inbuilt functionality that grants application servers client OS level access has been abused by attackers in the past, and possibly prompted the implementation of ‘security rules’ to restrict the types of calls permitted. These can be built to target several types of objects including files, registry keys and ActiveX controls. The three security levels currently supported by SAP and their corresponding parameter values are:
Deactivated 0
Customized 1
Strict Deny 2
The ‘Customized’ level automatically activates several rules to protect SAPGUI and its configuration files, as well as allowing for a default response to be set if an action is requested that does not match any existing rules. Further granularity can be achieved using the ‘context-dependant’ rules where an administrator can restrict permitted actions to specific SAP systems or even transactions, which I highly recommend looking into [2]. Since patch level 4 of the 7.20 SAPGUI client, functionality has been included to protect against attacks utilising malicious SAP shortcuts that were described in the first post of this series.
A last point worth mentioning here about SAPGUI security is the default enabled local history database that stores all information, except passwords, typed into the client. For shared computing environments, or if users are dealing with extremely sensitive data it would be advisable to deactivate this option (see SAP Notes 925639 and 924376).
Securing RFC
As demonstrated in the last post, there are a number of RFC misconfigurations that can be exploited by attackers using publically available tools which result in complete system compromise. It is therefore an area I believe warrants special attention. While a suitable network filtering policy would prevent users from being able to access the service endpoints required to launch these attacks, it is highly recommended to use SAP’s built-in security features also, such as encryption of data and access control lists for the various RFC services that can be abused.
The first of these is the encryption of RFC data with SNC, the same encryption protocol that is recommended for SAP’s client server connections (such as SAPGUI). This is a somewhat longer process than for SAPGUI, and requires an additional SAP cryptographic library which is not bundled with Netweaver due to cryptographic export restrictions, but can be downloaded by all customers from the SAP market place. Once downloaded, further information is provided by SAP on how to use the library and ensure all RFC network traffic is encrypted [3] [4].
An RFC related service providing the crucial information required to attack externally registered RFC applications is the Gateway Monitor. While disabled by default in later versions of Netweaver, it has been seen left enabled for debugging purposes in production systems. This service provides information about registered RFC programs that attackers require to launch the previously described man-in-the-middle style attacks. If it is not in use, it can be disabled by setting the following parameter in transaction RZ11:
gw/monitor = 0 (No monitor commands are accepted)
If disabling is not an option, the monitor can be limited to local access only with:
gw/monitor = 1 (Only monitor commands from the local gateway monitor are accepted)
As demonstrated in the previous post, allowing unrestricted RFC program registration can lead to attacks such as the ‘Evil Twin’ and ‘Callback’. While this is still the default behaviour for a standard Netweaver install, access control lists can and should be implemented to restrict registration to only those hosts that require it. The files ‘reg_info’ and ‘sec_info’ are responsible for this. More information on how best to configure these can be found in SAP’s document on the subject [5].
Security issues are also commonly introduced by static RFC connections made from systems of lower security such as development and test, to production systems with a higher level of security. Where this is the case, it is recommended not to store credentials for these connections and to run the RSRFCCHK transaction regularly to monitor for new connections that deviate from this.
Oracle and remote OS authentication
For SAP to work with Oracle databases, it is required that remote OS authentication in Oracle is enabled. This functionality enables the database to trust that the OS of the connecting user has already authenticated them, and therefore does not need to perform further authentication checks itself. In SAP environments, this is commonly abused by attackers with network access to the Oracle database, whereby this form of authentication can be easily bypassed and access to the database tables containing password hashes is possible.
Oracle has deprecated this function as of 11g, however SAP still requires it. Disabling this functionality is therefore not an option, however filtering at both the network and database level can ensure that only the application server is allowed network access. Consideration for this restriction at the network level should be made when designing a filtering policy and implementing VLAN segregation and access control lists. As an additional protection, the Oracle database itself allows the restriction of connectivity through a list of valid invited nodes. These can be configured using the following parameters:
Tcp.validnode_checking = yes
Tcp.invited_nodes = (IP Addresses allowed to connect)
The deprecation of this insecure functionality in 11g should hopefully push SAP towards looking at a more secure method of handling database authentication in the future. In the interim, restricting access to the database itself should be considered a priority.
Patching
While SAP offers the EarlyWatch Alert report to inform administrators about newly released patches, this report is limited and should not be solely relied upon, as can be seen in the following quote by SAP: "Due to technical restrictions, the report can currently not check all SAP Security Notes automatically". It is therefore of importance that the administrator ensures a process for keeping updated on SAP’s latest patches is included in the organisation’s patch cycle. This should not be limited to SAP core components only, but include client applications such as the SAPGUI as well.
References
[1] - SAP Netweaver guide
[2] - SAPGUI guide
[3] - ‘Configure Secure Network Communication’
[4] - "Using the SAP Cryptographic library for SNC"
[5] - ‘sec_info’ and ‘reg_info’
Read the previous blog posts on SAP Exploitation:
SAP Exploitation - Part 1
SAP Exploitation - Part 2