With this article we are starting a new series of guidelines describing some basic assessment procedures one can carry out on various business applications that would help security professionals to expand their ERP systems’ immunity to attacks.

As we all know, ERP systems such as SAP may favour the quality of management of all the information and resources involved in a company's operations.

However, while ERP applications promote the way business processes are organized, they also may undermine information security within organizations.

We should not forget how important it is to secure enterprise applications and various ERP systems.

No need to say, that the ERP system is in the core of any large company: it deals with all processes critical for business – purchases, payments, logistics, HR, product management, financial planning etc. All information stored in the ERP systems is sensitive, and any unauthorized access to this information can cause huge damages up to a business interruption.

According to the report[1] by the Association of Certified Fraud Examiners (ACFE), in 2006 - 2010, the organizations losses caused by the internal fraud (the IT-frauds ) amounted to app. 7% of annual revenue [2].

For the last five years, a widespread myth that the ERP security is only a SOD matrix was over, and today this belief seems to become a history for many people. For that time, the SAP security experts have presented lots of detailed reports on various attacks on the internal SAP subsystems:

— the RFC protocol, 
— the SAP ROUTER access control system, 
— the SAP web-applications, 
— the SAP GUI client workstations, and many others.

The interest for this area grows exponentially every year: compared to only 1 report on SAP Security [3] in 2006, more than 30 of such reports were presented in 2013 at specialized hacking and security technical conferences. Lately, a number of hacking utilities were released, and thus confirmed the possibility of attacks on the SAP solutions.

According to the business application vulnerability statistics [4] and [5], more than one hundred vulnerabilities in the SAP products were fixed in 2009, while this figure was more than 500 in 2010. In July 2014, there were more than 3000 SAP Security Notes, i.e. notifications on various SAP components vulnerabilities.

(Read more:  My Key Learning While Implementing Database Security)

This entry will help you to get extended info about what is going to come next. And why it is so important to know everything about it.

General information

"The Enterprise Application System Vulnerability Assessment Guide" describes 9 most known business application security areas relating to implementation and operation. This top list was prepared by the authors during vulnerability assessments of multiple business applications; this list may be applied to any of them. These areas are weighty factors for many emerging threats and related attacks. Securing of these areas means getting ready to prevent numerous attacks targeted at business application security.

This series of posts contains a detailed analysis of the most widespread business application platform - the SAP NetWeaver ABAP. During this analysis 33 key settings were identified and distributed between 9 areas mentioned above. This post will show how to protect against the most widespread vulnerabilities in this area as well as provide further steps on securing all 9 areas .

The top-9 critical areas for business applications

Below, you can find the list of Top-9 critical areas for vulnerability assessment of business application. They are ranked from 1 to 9 according to their severity and impact on the ERP system, business applications and related security. For this list, 3 main parameters were considered:

1. initial access to exploit the vulnerability; 
2. severity of vulnerability (a potential impact if exploited); 
3. complexity of vulnerability exploitation.

This list is the same for all the business applications. In the next chapters, checks for each of these items (specific to the SAP NetWeaver ABAP platform) are described in detail. However, these description are stated in a way to ensure understanding of the basic principles relating to vulnerability assessment for any enterprise application systems.

Critical area	Access	Severity	Simplicity
1. Patch management flaws	Anonymous	High	High
2. Default passwords for access to the application	Anonymous	High	High
3.Unnecessary functionality	Anonymous	High	High
4. Open remote management interfaces	Anonymous	High	Medium
5. Insecure settings	Anonymous	Medium	Medium
6. Unencrypted connections	Anonymous	Medium	Medium
7. Access control and SOD conflicts	User	High	Medium
8. Insecure trusted connections	User	High	High
9. Security events logging	Administrator	High	Medium

The Guide description

Our approach contains 33 steps to securely configure SAP NetWeaver ABAP platform, that were distributed among 9 areas mentioned above.

The authors' efforts were to make this list as brief as possible but also to cover the most critical threats for each area. This approach is the main objective of this Guide: as despite best practices by the SAP, ISACA and DSAG, our intention was not to create just another list of issues with no explanation on why a particular issue was (not) included in the final list, but to prepare a document that may be easily used not only by SAP security experts. Report should also provide comprehensive coverage of all critical areas of SAP Security.

At the same time, the development of the most complete guide would be a never-ending story as at the time of writing there were more than 7000 checks of security configuration settings for the SAP platform as such, without those of specific role-based access and in-house applications.

As a result, each of the 9 areas includes major checks that must be implemented first and can be applied to any system regardless of its settings and custom parameters. It also important that these checks are equally applicable both to production systems and those of testing and development.

In addition to major all-purpose checks, each item contains a subsection called "Further steps". This subsection gives major guidelines and instructions on what should be done in the second and third place, and then how to further securely configure each particular item. The recommended guidelines are not always mandatory and sometimes depend on a specific SAP solution. On the one hand, with this approach, the authors were able to highlight key security parameters for a quick assessment of any SAP solution (from the ERP to the Solution Manager or Industry Solution) based on the NetWeaver ABAP platform and, on the other hand, to cover all issues and give complete recommendations on them.

In terms of quality, this makes the present Guide different from the SAP best practices that also contain few items, but do not cover the overall picture, as well as from best practices by ISACA and DSAG that have a lot of items, but the priorities are unclear and too complicated for the first step (though these papers are highly valuable and necessary).

(Read more:  Database Security Vendor Evaluation Guide)

33 steps to security

So, here it is. Our list of most critical checks for SAP NetWeaver ABAP - based systems

1. Patch management flaws 
[EASAI-NA-01] Check for components update (SAP Notes) 
[EASAI-NA-02] Check for kernel updates

2. Default passwords for access to the application 
[EASAI-NA-03] Default password check for a SAP* user 
[EASAI-NA-04] Default password check for the DDIC user 
[EASAI-NA-05] Default password check for the SAPCPIC user 
[EASAI-NA-06] Default password check for the TMSADM user 
[EASAI-NA-07] Default password check for the EARLYWATCH user

3. Unnecessary functionality 
[EASAI-NA-08] Access to the RFC-function via the SOAP interface 
[EASAI-NA-09] Access to the RFC-function via the form interface 
[EASAI-NA-10] Access to the Exchange Infrastructure (XI) via the SOAP interface

4. Open remote management interfaces 
[EASAI-NA-11] Unauthorized access to the SAPControl (SAP MMC) service functions 
[EASAI-NA-12] Unauthorized access to the SAPHostControl service functions 
[EASAI-NA-13] Unauthorized access to the Message Server service functions 
[EASAI-NA-14] Unauthorized access to the Oracle DBMS

5. Insecure settings 
[EASAI-NA-15] Minimal password length 
[EASAI-NA-16] Number of invalid logon attempts before the user account lock out 
[EASAI-NA-17] Password compliance with the security policies in place 
[EASAI-NA-18] Access control settings for RFC-service (reginfo.dat) 
[EASAI-NA-19] Access control settings for RFC-service (secinfo.dat)

6. Access control and SOD conflicts 
[EASAI-NA-20] The check for SAP_ALL profile accounts 
[EASAI-NA-21] The check for accounts that may start any programs 
[EASAI-NA-22] The check for accounts that may modify USH02 table 
[EASAI-NA-23] The check for accounts that may execute OS commands 
[EASAI-NA-24] Check for disabled authorizations

7. Unencrypted connections 
[EASAI-NA-25] The SSL encryption to protect HTTP connections 
[EASAI-NA-26] The SNC encryption to protect the SAP GUI client connections 
[EASAI-NA-27] The SNC encryption to protect RFC connections between systems

8. Insecure trusted connections 
[EASAI-NA-28] RFC connections that store user authentication data 
[EASAI-NA-29] Trusted systems with low security level

9. Logging of security events 
[EASAI-NA-30] Logging of security events 
[EASAI-NA-31] Logging of HTTP requests 
[EASAI-NA-32] Logging of table changes 
[EASAI-NA-33] Logging of SAP Gateway activities

As you can see – the guide is not as enormous as it could have been due to the complicity of the topic. We tried to maximize the clarity of the guide to security assessments for you.

Stay in touch with us as next week we’ll come back with the new article where the guideline will reappear in its all glory. We’ll provide you with detailed explanation of each step.

(Read more: How effective is your SIEM Implementation?)

 -----------------------------------------------------------------------------------------------------------------

Why current SAP Security Guides Always Provide So Little Help?

This article will be about different guidelines, which can help to secure your SAP system. But nothing to worry about - this post will nevertheless remain useful and interesting, even if it does not contain information about 0-days or have no words like “cyber” or “weapon” in title. So, let’s go.

This blog post will be about new guideline, or standard, for securing - or testing of the security - of SAP implementations, which is going to be a first standard of the EAS-SEC standard series. There were 2 things that push us unto developing this guideline and give a second birth for our project. We thought about making some kind of guideline from the very beginning, and finally made it, when we’ve got a clear idea of how it should be done and what customers really needed.

(Read more:  Top 5 Application Security Technology Trends)

And the reason we decided to make this… 
… Is simple like one, two three.

One. Questions like "why?" and "what for" are the alpha the omega of every research. For us, as it sometimes happens, the answer came from one more additional question. After implementation of our Security Monitoring Suite for SAP in huge enterprises, making dozens of POC’s and completing numerous penetration tests against SAP systems (as well as other business critical systems), the thing we were asked more often than any other was: “Guys, you are awesome! And you are doing a great job so far, finding so many problems in our installations. It's absolutely fantastic, but we don’t know, where should we start to solve them. Could you provide us with top 10/20/50/100/ [put your favorite number here] most critical bugs in every area?”

Two. At the same time we had to do something completely different from just top-10 of the most critical bugs, like the one, when you can select missing SAP security notes with highest CVSS. Even if you patch all of the notes there still could remain lots of problems. For example, you may have SAP_ALL assigned to every user or you have your logs disabled so that next time, when you forget to close sapnotes, it would be easy to hack your system, because of non comprehensive approach. So, the number one challenge is to understand all security areas of SAP platform and to have an opportunity for every area select a number of most critical issues. So our research first aim was to cover all SAP security areas and be simple to implement - the second one.

Three. We started to analyze existing guidelines and standards. Currently there are not many of them, which cover SAP security and all of them are supported by ERPScan. The guidelines we have are as follows: Secure Configuration of SAP NetWeaver® Application Server Using ABAP by SAP, ISACA Assurance (ITAF) by ISACA, and DSAG by German SAP User Group. All those standards are great, but unfortunately all of them have at least one big disadvantage. But let’s be patient and have a better look. On those standards:

Secure Configuration of SAP NetWeaver® Application Server Using ABAP

First official SAP guide for technical security of NetWeaver ABAP in general. Before it only dozens of specific guidelines for every application were made. The first version of this guide was published in 2010, and was followed by version 1.2 in 2012. As far as it happened almost 2 years ago, we have to put in mind, that in our fast-changing world some critical things could be missing for now. This guideline was created for rapid assessment of most common technical misconfigurations in platform and consists of 9 areas and 82 checks in total.

Advantages: very brief, but quite informative (only 9 pages) and covers application platform issues, applicable for every ABAP- based platform either ERP or Solution manger or HR, it doesn’t matter.

Disadvantages: 82 checks is still a lot for a first brief look on secure configuration. But what’s more important, standard doesn’t cover access control issues and logging and even in platform security miss some things. Finally, it gives people false sense of security if they cover all checks. But it wouldn’t be completely true.

ISACA Assurance (ITAFF)

Probably, the first guideline for SAP Security. Guideline was made by ISACA consortium. There were 3 versions published in 2002, 2006 and finally - in 2009. And it means that 5 years passed from the last release and many areas are outdated now. In general, checks cover configuration and access control areas, application platform security part covers less than access control and miss some critical areas. Guideline consists of 4 parts and about 160 checks in total.

Advantages: detailed coverage of access control checks.

Disadvantages: Outdated. Technical part is missing. Guideline consists of too many checks, and can’t be easily applicable by non-SAP specialist. Also it can’t be applicable to any system without prior understanding of the business processes. And finally, this guideline could be found officially only as part of the book or you should be at least an ISACA member to get it.

DSAG (Deutschsprachige SAP-Anwendergruppe)

Set of recommendations from German-speaking SAP User Group. Checks cover all security areas from technical configuration and source code to access control and management procedures. Nowadays it is a biggest guideline about SAP Security. Last version was released in Jan 2013. Consists of 8 areas and 200+ checks.

Advantages: Ideal as a final step for securing SAP. Great for SAP Security administrators, covers almost all possible areas.

Disadvantages: Unfortunately, has the same problem as ISACA. It is too big for a starter, and no help at all for Security people who are not familiar with SAP. Also it can’t be directly applicable to every system without prior understanding of business processes. Many checks are recommendations and user should think by himself, if they are applicable in each every case.

Fig.1. How SAP security looks like with three guidelines

(Read more:  5 easy ways to build your personal brand !)

What goes around that comes around

So, we didn’t want to make just another security guideline. But also we saw, that all of the current approaches miss something.

Finally we understood that there is a real need in new guideline. Fortunately, now we knew, what we should do to make it not good, but perfect. They all miss one general thing – they are big from one side and still doesn’t cover everything but pretend to do that, which finally gives people false sense of security if they cover all checks

The authors' efforts were to make this list as brief as possible but also to cover the most critical threats for each area. This approach is the main objective of this Guide: as despite best practices by the SAP, ISACA and DSAG, our intention was not to create just another list of issues with no explanation on why a particular issue was (not) included in the final list, but to prepare a document that may be easily used not only by SAP security experts but by every Security specialist who wants to check if his SAP is Secure and guideline should also provide comprehensive coverage of all critical areas of SAP Security.

At the same time, the development of the most complete guide would be a never-ending story as at the time of writing we had more than 7000 checks of security configuration settings for the SAP platform.

We need a guideline, which will consist of few checks, but selected and what’s more important it will have future steps so that everybody will know that they made just a part of a job by implementing the standard, really critical part but not everything. So, we talking about 80/20 rules, and we will implement it in SAP Security.

Result

As a result, of more than 7 years experience in Security assessment of Enterprise Business applications of different types from different vendors including of cause SAP, Oracle, Microsoft, IBM but also taking into account different industry-specific systems like Retailix for Retail, MES/SCADA systems for Oil and Gas and ABS systems in Banking area our broadly experienced Pentest and Research team known for sending 450+ advisories in different products and participating in 50+ events in every continent collected information about most critical vulnerabilities and misconfigurations to understand the most critical areas. Our auditors who were responsible for different certifications like ISO, PCIDSS, PADSS, SOX and NIST in previous work analyzed those business applications from a compliance and risk point of view and finally we got 9 critical areas which are essential for security of every Enterprise Business Application and which are sorted by priority (Based on mix of Criticality, Probability, Popularity and Data needed for conducting attack).

After that we pick most critical vulnerabilities and configurations of SAP NetWeaver ABAP based applications from each of those 9 areas, and finally got 33 most critical checks.

Those are major checks that must be implemented first and can be applied to any system regardless of its, type, settings and custom parameters. It is also important that these checks are equally applicable to production systems and the ones of testing and development both.

In addition to major all-purpose checks, each of 9 critical areas contains a subsection called "Further steps". This subsection gives major guidelines and instructions on what should be done in the second and third place, and then how to further securely configure each particular item. The recommended guidelines are not always mandatory and sometimes depend on a specific SAP solution.

Fig.2. How SAP security looks like with EAS-SEC

Wrap-up

On the one hand, with this approach, the authors were able to highlight key security parameters for a quick assessment of any SAP solution (from the ERP to the Solution Manager or Industry Solution) based on the NetWeaver ABAP platform and, on the other hand, to cover all potential problems and give complete recommendations on them.

In terms of quality, this makes the present Guide different from the SAP best practices that also contain few items, but do not cover the overall picture, as well as from best practices by ISACA and DSAG that have a lot of items, but the priorities are unclear and too complicated for the first step. Though these papers are highly valuable and absolutely necessary as a next steps and they are mentioned in Further steps" areas.

And finally, you are ready to use the guideline itself (click here), made with help of overwhelming experience of ERPScan research team. Read, learn, stay secured!

(Read more:  How the Heartbleed bug was found by Antti Karjalainen - discoverer ...)

-------------------------------------------------------------------------------------------------------------------

SAP NetWeaver ABAP Security Configuration Part 4: Open remote management interfaces

Today we are going on with our series of articles where we describe the 33 steps to security. 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.

Further steps

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 [1]. 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

Description

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. [2]. 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.

Threat

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.

Solution

In accordance with SAP Note 1600846 [3], sapstartsrv settings must be reconfigured. To do this, you need to set the parameterservice/protectedwebmethods to DEFAULT in a default system profile (DEFAULT.PFL). To apply the changes, restart all sapstartsrvservices 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 Note 927637 [4]). 
Implementation of SAP Note 1439348 [5] 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

Description

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 thesapstartsrv 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 daemonrespectively.
• 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). [6] 
For data transmission, the SOAP protocol is used. In case encryption is set up, it encapsulates into the SSL. This service allows to read some system information without user’s consent. It also has vulnerabilities that allow to run OS commands remotely.

Threat

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 Note 1341333 [7]). This data can be used to implement more critical attacks.

Solution

Remote execution of random code vulnerability was fixed in May 2012 with SAP Security Note 1341333[8]. 
SAP Security Note 1816536 [9] 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

Description

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.

Threat

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.

Solution

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

Description

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_checkingparameter, 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 orTCP.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.

Threat

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.

Solution

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.

-----------------------------------------------------------------------------------------------

SAP NetWeaver ABAP Security Configuration Part 3: Unnecessary Functionality

Third critical area. Unnecessary functionality

What is the most common problem of any more or less complex application? In essence, they almost always have numerous unnecessary functions aimed to perform multiple tasks. 
Obviously, that makes the whole system vulnerable. The more functionality is available, the higher becomes the number of vulnerabilities. "Complexity Kills Security" 
More importantly, all those functions are enabled by default right from the start, thus making security threats inevitable. However, there is a growing trend that in every next following version of SAP there are positive changes concerning unnecessary functionality as more and more safety measures are being taken (extra functions are now deactivated by default). 
Besides, very often those are not the functions themselves that make the whole system subjected to treats. It is evident that only those additional functions that are misconfigured can perform critical actions. 
So, that is why it is crucial to regularly carry out security checks for misconfigured unnecessary functions. This critical area is the third one in our list and it involves three security assessment steps:

1. [EASAI-NA-08] Access to the RFC-function via the SOAP interface;
2. [EASAI-NA-09] Access to the RFC-function via the form interface Description;
3. [EASAI-NA-10] Access to the Exchange Infrastructure (XI) via the SOAP interface;

But first, let us start with the basis. Web-applications and internal system objects (such as programs, transactions, RFC, etc.) - that is where most unnecessary functions are typically concentrated. 
As far as it is quite easy for low-privileged or even anonymous users to get access to web-applications via the Internet, the decision was taken to describe in the present article only the checks related to web-applications. 
Also, when it comes to the ways of getting access to web-applications we should keep in mind that it is the Internet Communication Framework (ICF, the SAP Web Application Servercomponent) that makes it possible to implement standard protocols, such as HTTP, HTTPS and SMTP for intersystem connections management via the Internet.

Further steps

Standard environment contains about 1500 various web-services that are available remotely on behalf of any registered user. Also, about 40 services are accessible to anonymous users. Note that remote access is only possible if the service was enabled by default. 
Besides, after you have completed the three checks mentioned in this article, you should also disable all the services that anonymous users can get access to. Secondly, you should analyze all the installed services in order to detect those of them are not necessary for the system. Lastly, restrict access to the necessary ones using additional authorizations. 
Check out «Secure Configuration of the SAP NetWeaver Application Server Using ABAP» [1]. In this paper 13 critical services are indicated. As mentioned above, those are only the main, basic services. 
Another step to be taken, after you have completed web-services configuration is disabling all unnecessary internal functions, such as unnecessary critical transactions, programs, profiles, roles, etc. This step requires a thorough analysis of each module in each particular case. 
Nevertheless, there are several transactions within the productive system to be disabled (1 see the paragraph end). They are mentioned in ISACA guides[2]. 
For the record, in the present guideline we only recommend you to do this, this item was not included in the main list because it only has to do with productive systems.

Transactions recommended to be blocked (disabled):

• archive administration: KA10, KA12, KA16, KA18, SARA;
• reset transaction data: OBR1;
• structural authorization OICP, OOSB;
• user maintenance: OMDL, OMEH, OMWF, OOUS, OPF0, OTZ1, OY27, OY28, OY29, OY30;
• profiles: OMEI, OMWG, OOPR, OP15, OPE9, OTZ2, OY21;
• privilege and profile maintenance: OMG7, OMWK, OPF1, OTZ3, OY20;
• structural authorization: OOSP;
• maintenance of user profiles: OVZ6;
• copy by transport request: SCC1;
• deleting a client: SCC5;
• transport organizer (extended): SE01;
• workbench organizer: SE09, SE10;
• table maintenance: SE16, SM30, SM31; external OS commands: SM49, SM69;
• deleting all users: SU12.;

[EASAI-NA-08] Access to RFC-functions via the SOAP interface

Description

RFC stands for Remote Function Call. Accordingly, RFC is a SOAP-interface based service which allows to get remote access to some of the functional modules, also called RFC-functions. This service is available by the following link: /sap/bc/soap/rfc. 
Firstly, you need to have /sap/bc/soap/rfc service activated. Secondly, you need to have legitimate system or default user with a default password available in the system. In this case, it becomes possible to access and execute RFC-functions of the ABAP platform.

Threat

One can start RFC-function execution via HTTP channel using SOAP requests. Sometimes SOAP requests are even sent from the Internet. 
An adversary can use default account details to gain access to RFC service. Subsequently, having access to RFC crevice one can carry out various types of attacks. For example, a regular user with any set of privileges can perform a DoS attack using incorrect SOAP request.

Solution

Providing that you have /sap/bc/soap/rfc service activated, make sure that the number of users allowed to access RFC is somehow restricted. Whereas, if there is no real need to use RFC, deactivate it using SICF transaction.

[EASAI-NA-09] Access to the RFC-function via the form interface Description

When it comes to /sap/bc/FormToRfc service, we should bear in mind that this service is intended only for internal needs of SAP. It should be by no means kept within the production system. The reason is that this service misses some authorization checks. Starting from the version 6.20, this service's functions are performed by the SOAP (/sap/bc/soap/rfc). As regards to ICF services, they are disabled by default.

Threat

It is risky to use /sap/bc/FormToRfc service within the production system, as it lacks some authorization checks. One can exploit this vulnerability using RFC-function, and get an unauthorized access to any business data.

Solution

In case the /sap/bc/FormToRfc service is not used, it is highly recommended to deactivate it with the help of SICF transaction.

[EASAI-NA-10] Access to Exchange Infrastructure (XI) via SOAP interface

Description

SOAP interface based surface which is used to access the so-called Exchange Infrastructure (XI) may be implemented to remotely call some critical functions. Moreover, it allows to send requests to a third- party system.

Threat

On the condition that the service was activated incorrectly or the number of restrictions is insufficient, it becomes possible to start execution of XI-function via HTTP channel using SOAP requests. Sometimes SOAP requests are even sent from the Internet. 
An adversary can use default account details to gain access to this service. In this case one can carry out various types of attacks, both on the target system and on those systems that are integrated with it depending on the type of performed function, which is set in the Enterprise Service Bus. In the worst-case scenario, an adversary may get an unlimited access to this server together with the related ones.

Solution

In case the service is not used, it is highly recommended to deactivate it with the help of SICF transaction. Otherwise, it is better to set up additional access restrictions. To do that, you should put into practice the use of appropriate authorizations or network access control procedure.

Summarizing our discussion let us once again remind you of the fact that presently no ERP system is immune to security threats. There is no exception to this rule. That is why solid information should be regularly provided on how to rise security control to higher levels. 
Next time we'll come back with a description of new security assessments procedures concerning the fourth critical area from our list. Bye, and remember to keep a wary eye on business data.

-------------------------------------------------------------------------------------------------------

SAP NetWeaver ABAP security configuration part 2: Default passwords for access to the application

Second critical category. Default passwords for access to the application

For the two previous weeks we’ve been discussing the top-9 critical areas and the 33 steps to be taken for security assessment. Ultimately, we’ve covered patch management flaws - the first critical category in our list. As you should have probably guessed, today it’s time we take a closer look at the next item from our list of critical issues - default passwords.

It is a wide reaching vulnerability with multiple attack vectors. As it requires little skill, default passwords vulnerability exploitation is now among the most frequently used ways of getting access to company’s data. Once installed, SAP system has several standard clients: 000, 001, 066. They all have high privileges set by default (usually, they have the SAP_ALL profile). When it comes to creating new clients, SAP system automatically generates default usernames and passwords.
In the version 6.10 of SAP Web Application Server, the so-called Master Passwords [1] were first put into practice. 
Users should be particularly careful, as the fact is, vendor's default accounts and their passwords are well known. Have a look at the following table; we’ve gathered default passwords here for you:

USER	PASSWORD	CLIENT
SAP*	06071992, PASS	001, 066, Custom
DDIC	19920706	000, 001, Custom
TMSADM	PASSWORD, $1Pawd2&	000
SAPCPIC	ADMIN	000,001
EARLYWATCH	SUPPORT	066

(Read more:  Can your SMART TV get hacked?)

Further steps

Some additional SAP components also have their unique default passwords. For example, old versions of such services as SAP SDM and SAP ITS have their own pre-installed default passwords. 
After you have finished checking whether there are default passwords, you should check user passwords for simple dictionary passwords. We suggest that you use efficient password bruteforcing utilities, in particular, such utilities, as John The Ripper would fit you great. Alternatively you can use ERPScan Security Monitoring Suite. 
Besides, default passwords should be checked in all associated systems. Don’t forget to check your network equipment, operating systems and DBMS that store SAP system data. Oracle DBMS, for instance, contains a lot of default passwords, including those specific for SAP systems.

[EASAI-NA-03] Default password check for a SAP user

Description

The SAP* users are created in all clients immediately after installation. Those are dialog users who work via SAP GUI (user type = dialog). They perform all administrative tasks (and usually have the SAP_ALL profile). In case any SAP* user has been removed, after the system was rebooted one can login using standard PASS password and get all the corresponding SAP_ALL privileges.

Threat

Default passwords of SAP* users are well-known (see the table above). With these passwords, an adversary may enter the system using SAP_ALL profile and, consequently, get an unlimited access to any business data stored in the system.

Solution

• First, give superuser rights to a SAP* user in all clients (do not remove it!). To do that, using SU01 transaction, select the SAP* user. After that, click on the Lock/Unlock icon(Ctrl+F5);
• Set login/no_automatic_user_sapstar to 1 (RZ10 and RZ11 transactions). Note that in 3.1G and lower versions, the login/noautomatic_user_sap* parameter is used (for further information, see the SAP Note 68048 [2]);
• Change the SAP* default password (using SU01 transaction);
• Make sure that now the user belongs to the SUPER group in all clients. Go to SU01 transaction, select the SAP* user, click on the Change icon (Shift+F6), then on the Logon Data tab.

EASAI-NA-04 Default password check for the DDIC user

Description

The DDIC user is created in the clients 000 and 001 upon their installation (and copying). This default system user’s purpose is to perform system installation, renewal, configuration and operation. Its purpose can also be implementation of support packages, upgrade and background job runtime of Transport Tool background jobs triggered by the tool. 
In case the client is 000, this user belongs to a dialog type, it has the right to enter the system via SAP GUI and perform any actions.
In all the other clients it is a system type user, it may perform background processing and it can interact with the system. SAP_ALL and SAP_NEW profiles that grant access to all the functions of the SAP are defined for this user.

Threat

The DDIC user default password is well-known (see the table above). With these passwords, an adversary can enter the system using SAP_ALL profile and, consequently, get an unlimited access to any business data stored in the system.

Solution

WARNING! Do not remove the DDIC user or its profile! The DDIC user is necessary for performing certain tasks, such as installation or updating. It can also interact with ABAP dictionary. The DDIC user removal results in a loss of functionality in these areas. But it is acceptable (and highly recommended by some resources) to remove it in all clients except 000.

• In 000 client change the user type to SYSTEM;
• Remove SAP_ALL profile;
• Lock out the DDIC user. Unlock it if needed only. Notice that transport system executes certain programs on behalf of the DDIC user;
• Change the default password for the DDIC user;
• Make sure that the DDIC user belongs to the SUPER group in all clients. Only authorized administrators have the right to modify this account.
• Regularly perform checks of system clients to those illicit ones.

[EASAI-NA-05] Default password check for the SAP user

Description

The SAPCIPIC user is used in transportation system of SAP solutions (in 4.5A and lower versions). It is a communication type user. It is mostly used for EDI (Electronic Data Interchange). It may also transport RFC calls without dialog boxes. 
So, this user does not have dialog type user privileges, though it has the S_A.CPIC profile. As a result, critical are the following authorization objects:

• the S_CPIC (to call for CPIC functions from ABAP/4 programs),
• S_DATASET (with privileges to access files from ABAP/4 programs), and
• S_RFC (authorization check for RFC access to program modules, for example, to a functional group).

(Read more:  How to choose your Security / Penetration Testing Vendor?)

Threat

Default passwords of SAPCPIC user is well-known (see the table above). With these passwords, an adversary can remotely execute RFC requests (e.g. start some OS programs); execute arbitrary OS commands through RFC vulnerabilities (e.g. TH_GREP); create dialog users with any privileges to enter the system and get an unlimited access to the data.

Solution

Remove SAPCPIC user if you do not need it. If the user is still necessary:

• Change the default password for SAPCPIC user;
• Lock out SAPCPIC user. Unlock if necessary only;
• If this user is required for EDI purposes (e.g. by contractor), never transmit this password via a remote session. It is also preferable to use separate communication channel, e.g. e-mail. Change the password immediately after the remote session is over;
• Make sure that this user belongs to SUPER group in all clients, so as to be certain that only authorized administrators have the right to change this user’s account;
• Determine a special user for remote access. Do not use any default users;
• Perform regular checks of your clients to eliminate the risk of illicit access.

[EASAI-NA-06] Default password check for TMSADM user

Description

The TMSADM user is used for transfers through the transport system. It is created automatically upon configuration and changes of Transport Management System (TMS) via the 000 client. 
It is a communication user, in other words, it is often used falsely to transport external RFC calls without dialog boxes. It has the assigned S_A.TMSADM authorization profile enabled to utilize RFC-functions with GUI and to write to a file system. SAP_ALL profile is also often assigned to this user.

Threat

The default password of TMSADM user is well-known. An adversary may remotely start RFC requests to perform critical actions such as deletion and reading files (EPS_DELETE_FILE, EPS_OPEN_FILE2); arbitrary ABAP code execution (through the RFC_ABAP_INSTALL_AND_RUNor TTMS_CI_START_SERVICE function vulnerabilities), and, using BAPI_USER_CREATE1 andSUSR_RFC_USER_INTERFACE requests, to create a dialog user and, consequently, to enter the system and get an unlimited access to business data.

Solution

• Change the default password of TMSADM user; to change this password (according to Note 1414256 [3]) you should:
  • Enter the 000 client under any user with administrative rights.
  • Start the TMS_UPDATE_PWD_OF_TMSADM program with the ABAP editor (the SE38transaction). There are three ways to change the TMSADM password:
    • to enter your own password
    • to set a new standard password (Note 761637, $1Pawd2&), or
    • to set an old standard password (PASSWORD);
  • Select the option "To enter your own password” in the dialog box and enter the new password;
  • Start the program
• Make sure that this user belongs to the SUPER group in all clients. This way you will be certain that only authorized administrators have the right to change this user’s account;
• Determine a special user for the remote access. Do not use any of default users;
• Perform regular checks for your clients to eliminate the risk of illicit access.

Additionally, it is better to apply security notes related to vulnerabilities in the programs which TMSADM user can execute, such as:

• SAP Note 1298160 for vulnerabilities in TTMS_CI_START_SERVICE;
• SAP Note 1330776 for vulnerabilities in EPS_DELETE_FILE and EPS_OPEN_FILE2.

[EASAI-NA-07] Default password check for the EARLYWATCH user

Description

The EarlyWatch user is created in the 066 client upon SAP installation and is related to a dialog type. It can enter via SAP GUI and perform any actions to the system. One can use it for SAP distance remote management and to get access to monitoring data. As a rule, it is used by SAP AG customer support to enter customer's systems. Change the default password forEarlyWatch user, but never delete the user.

Threats

EarlyWatch user’s default password is well-known (see the table above). With this password, an adversary can enter the system using the S_TOOLS_EX_A profile and, consequently, perform various critical actions (for example, access any files, view sensitive tables or display external statistics records via the control tools). In old versions - 6.4 and lower, users could execute critical transactions such as SE37 (function modules execution) and SE38 (running reports). In the new versions, it has fewer privileges, but it can exploit some vulnerabilities, such as theTH_GREP call with the SM51 transaction and, consequently, execute arbitrary OS commands.

Solution

Warning!Do not remove Earlywatch user or its profile!

• Lock out EARLYWATCH user. Unlock if necessary only;
• Change the default password for the EARLYWATCH user;
• Ensure that this user belongs to the SUPER group in all clients so that to be certain that only authorized administrators have the right to change this user’s account;
• Perform regular checks of your clients to eliminate the risk of illicit clients’ access to the system.

By now you should have noticed the ease and clarity with which we tried explain to you some technical subjects. You should also have noticed and wondered how we managed to make the list of critical issues that brief. You may even have marveled at how sometimes we point out what it all means, what it’s good for, and why should you care. It’s completely up to you, but if you like our articles we strongly recommend that you stay with us as in two weaks well come back with the descriprion of the next critical issue.

(Read more: Shellshock Bug: A Quick Primer)

-------------------------------------------------------------------------------------

SAP NetWeaver ABAP Security Configuration Part 1: Patch Management

First critical issue. Patch management flaws

In our previous articles we’ve already introduced you to the list of the 9 most important business application security critical issues. We’ve also had a chance to present to you the skeleton of our guideline with its 33 security assessment steps. As you’ve seen only the skeleton of it, now it’s high time to pay attention to a more detailed explanation of each step to be taken.

In order to insure full-scale system security it is crucial to regularly install security support packages. The number of support packages necessary for a system may be huge. Supporting this idea is the fact that the number of SAP Security Notes grew up to more than 3000 by the mid-2014. As some of you may know, each Sap Security Note serves to fix one or more vulnerability. About 50 Security Notes are issued monthly. Sometimes one can even find a SAP Security Note that was made based on the results of a third-party researcher’s work [1]. Also, when it comes to prompt vulnerability elimination we should take into consideration all the possible consequences implementation of such utilities as Metasploit to get free access to corporate information can lead to. Given the above arguments, it is reasonable to conclude that to develop and establish a patch management process that would ensure the implementation of adequate preventive measures against potential threats is highly necessary at this stage. Let us now focus on the two major checks that must be in place to address the most critical problems.

(Read more:  APT Secrets that Vendors Don't Tell)

Further Steps.

To verify security of SAP components, particularly those of them that are installed separately from the application server you can use such services as SAP Router, SAP Webdispatcher, SAP GUI. Additionally, it’s convenient to use those systems that are linked to the NetWeaver ABAP application server, but operate on the basis of the NetWeaver J2EE or SAP BusinessObjects application servers. Their security is regulated by a separate document included in the EAS-SEC. It’s substantial that, a security patch should be checked for operating systems where SAP services are installed, as well as for DBMS that store SAP solution data.

[EASAI-NA-01] Check for components update (SAP Notes)

Description

The essence of the whole patching procedure is that a patch is designed to substitute outdated and vulnerable objects. There are two ways to fix a vulnerability: one can either implement the correction instructions from an SAP Note in the system, or have a Support Package installed. As a rule, initially a particular SAP Note (with appropriate correction instructions) is issued. After that, a Support Package is applied. The Support Package usually contains changed or new functionality with a set of correction instructions for a certain period of time.
As mentioned above, the number of support packages and SAP Notes required by the system may be huge. That's why the development of patch management process should also involve establishing a priority of patch installation. While determining the right priority one should consider the following factors:

• Threat severity,
• Threat probability,

• Required system privileges,

• Complexity of exploitation, and
• Public exploit availability.

WARNING! Sometimes vulnerability management processes can mix up. That is to say, vulnerabilities may be fixed with either a support package, or with the help of the SAP Notes. The matter is, they won’t synchronize. For instance, a vulnerability fixed with a support package would not be implemented as fixed via the SNOTE transaction to the SAP Notes list.

(Read more:  5 Security Trends from Defcon 2014 - The Largest Hacker Conference)

Threat

As soon as there appears a new security patch, newly identified vulnerabilities rather quickly become publicly available. To put it another way, anyone can gain access to their description. Accordingly, in case security patch was implemented after a long period of time it gives an adversary a chance to exploit those vulnerabilities, to get an unauthorized access to sensitive business data.

Solution

It is imperative to perform regular checks for security patches updates. To do that, one should strictly follow main patch management process steps (data collection, risk assessment, implementing security patch software, result monitoring).
 Using SAP Patch Manager (SPAM)offered by the SAP one can download and implement required support packages from theOnline Server System (OSS). Note that this is only related to versions 3.0 and higher. In order to start the SPAM, you should enter the command “SPAM” in the transaction code field.

Also, it’s possible to use the multi-purpose SAP Software Update Manager (SUM) to implement various system updates. The good news is that a demo version of this product is publicly available at the time [2]

To implement SAP Notes, use the SNOTE transaction to get a list of security notes required for a particular system. As mentioned above, these two mechanisms are not synchronized, so it is preferable to make some changes manually or with some additional third-party tools.

Before proceeding to our next security check let us make a small digression. The thing is we’ve decided to be proactive in terms of information security, thus in addition to major all-purpose checks, each item of our guideline contains a subsection called "Further steps". This subsection gives major instructions on how to further securely configure each particular item.

[EASAI-NA-02] Check for kernel updates

Description

We should keep in mind that in SAP system kernel there are executable files containing SAP Dispatcher, SAP Gateway, SAP Message Server, SAP Router and some other SAP services. For that reason, SAP system kernel has its own update mechanism that is different from other components. Kernel updates are released as service packs for a specific kernel type.

So as to clarify, support packages are cumulative. Therefore they include all the previous updates, even though sometimes releases contain updates for a certain support package only.

Threat

As soon as there appears a new security patch, newly identified vulnerabilities rather quickly become publicly available. To put it another way, anyone can gain access to their description. Accordingly, in case security patch was implemented after a long period of time it gives an adversary a chance to exploit those vulnerabilities, to get an unauthorized access to sensitive business data.

Kernel updates mostly fix highly critical vulnerabilities, as any system has a kernel. So, it’s crucial that kernel update should have highest priority and should be installed before other components.

Solution

It is imperative to perform regular checks for security patches updates. To do that one should strictly follow main patch management process steps (data collection, risk assessment, implementing security patch software, result monitoring).


In case you want to check out the current version of a service pack using SAP GUI you need to open the Status window in System tab and click on the Other kernel info button (Shift+F5 by default). There is always some information on the latest service pack version published on the SAP support portal[3]

The SAP Note is usually downloaded as a system and executable files directory that replaces the previous files. Software Update Manager (SUM) utility is also available to facilitate the manual process a lot (ref. to the operating manual [4]).

That’s it for today’s article, we’ve checked out the first critical issue “patch management flows” and the two steps relating to it. We hope you like our work and share our urge to promote information security to a higher level.

(Read more: Technology/Solution Guide for Single Sign-On)

---------------------------------------------------------------------------------------------

SAP NetWeaver ABAP Security Configuration Part 5: Insecure Settings

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 [1]. 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 [2]). 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[3]). 
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 [4]. 
For the correct reginfo.dat configuration use recommendations from SAP Security Note 1425765 and 1408081. [5][41], [6].

[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 [7]). 
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 [8]). 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[9]). 
For detailed explanation of this syntax check out the SAP Security Note 614971 [10][44]. 
For the correct secinfo.dat configuration refer to SAP Security Notes 1408081, 1525125, 1425765. [11][12][13]

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.

-----------------------------------------------------------------

Error

Why current SAP Security Guides Always Provide So Little Help? - 'click here' not working