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.

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.

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).

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 Security 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.

The post SAP NetWeaver ABAP security configuration part 1: Why do we do these guidelines? appeared first on ERPScan.

In our previous [1],[2] 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 [3]. 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.

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 Security 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 Security Note in the system, or have a Support Package installed. As a rule, initially a particular SAP Security 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 Security 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 Security 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 Security Notes list.

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 the Online 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 [4]

To implement SAP Security 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[5]

The SAP Security 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 [6]).

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.

The post SAP NetWeaver ABAP security configuration part 2: Patch management appeared first on ERPScan.

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:

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 Security 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).

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_RUN or TTMS_CI_START_SERVICE function vulnerabilities), and, using BAPI_USER_CREATE1 and SUSR_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 SE38 transaction). 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 Security Note 1298160 for vulnerabilities in TTMS_CI_START_SERVICE;
• SAP Security 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 for EarlyWatch 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 the TH_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.

The post SAP NetWeaver ABAP security configuration part 3: Default passwords for access to the application appeared first on ERPScan.

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:

• [EASAI-NA-08] Access to the RFC-function via the SOAP interface;
• [EASAI-NA-09] Access to the RFC-function via the form interface Description;
• [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 Server component) 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.

The post SAP NetWeaver ABAP security configuration part 4: Unnecessary functionality appeared first on ERPScan.

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 Security Note 1600846 [3], sapstartsrv settings must be reconfigured. To do this, you need to set the parameter service/protectedwebmethods to DEFAULT in a default system profile (DEFAULT.PFL). To apply the changes, restart all sapstartsrv services in the cluster. Besides, this change of value, also involves implementation of a list of all critical methods by default. Instead, you can use the value ALL (i.e. all methods), though it is considered excessive (the parameter and its values are described in detail in SAP Security Note 927637 [4]).
Implementation of SAP Security 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 the sapstartsrv in a host mode via the local socket that provides high-speed and secure connection (see the picture). It also starts simultaneously with the host.
• DB4STATS and SAPILED are the programs that supply IBM I with the SAP Database Performance Collector and the SAP ILE daemon respectively.
• The SAPHostControl (sapstartsrv in the host mode) is the SAP NetWeaver management agent. It is an executable of sapstartsrv run in the host mode under the sapadm user. It is using remote TCP 1128 port. That is why it is responsible not for the SAP instance, but for any host monitoring, which is controlled centrally.

A profile used while starting executable files also determines whether sapstartsrv will run in an instance operating mode (with an appropriate instance profile) or in a host mode (with the host's own profile that may include parameters SAPSystem = 99, SAPSystemName = SAP). [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 Security 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_checking parameter, which is required to validate host names while they attempt to establish inbound connections. When this parameter is set to yes value, inbound connections are only allowed if they come from the note listed in TCP.INVITED_NODES or TCP.EXCLUDED_NODE. Note that, the first one is of higher priority.
TCP.INVITED_NODES, in turn, requires each client host to be included in the sqlnet.invited_nodes server list.

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.

The post SAP NetWeaver ABAP Security Configuration Part 5: Open remote management interfaces appeared first on ERPScan.

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. The login/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 the sec_info files. The reginfo file is defined by the gw/reg_info parameter and the sec_info file is defined by the gw/sec_info parameter.
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 the ACCESS 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 separate RegInfo 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.

In conclusion we'd like to once again remind you that our core purpose is to make security checks process clear for you. Next time we'll come back with the new critical issue, and the related steps to be taken. If you liked our article, you should definitely check out our new product (demo)

The post SAP NetWeaver ABAP Security Configuration Part 6: Insecure Settings appeared first on ERPScan.

Sixth critical issue. Access control and SOD conflicts. Few would try to argue that the SAP is immune to security system attacks and sensitive business data is well protected from the actions of adversaries. But now you have a chance to get to know about some of the basic operations one can perform to rise the SAP information security to a higher level. The goal of ERPScan team is to help IT personnel make critical decisions when identifying technologies and strategies to increase security in business. ERPScan team publishes a variety of original content, written by IT professionals as a way to increase infosec specialists' productivity around the world. Today, we're going to speak about the sixth critical issue (see the list of critical issues in our first article) and the steps related.

There are a lot of various functions in the SAP system implemented through programs, transactions and reports. It's essential that access to those objects must be restricted by means of setting up various authorization values that would define the types of users and objects allowed to have access as well as the ways to get access. In case users are allowed to perform critical actions, they can attack the SAP system, risen their privileges or steal critical data. Typical example, a user can have access to transaction that changes access rights or access to the transaction that allows a user to read any table.

Segregation of Duties (SoD) is a method of protection that prevents conflict of interests or, in other words, having two or more access rights. The matter is, if they are granted together this can lead to fraud actions. A classic illustration here would be having right to create Payment Order and at the same time having right to approve it. Thus, the SoD helps to segregate incompatible responsibilities.

In this article only 5 security check steps will be given, but those are the main access control checks having to do with the most critical access rights and the related settings. For the reason that Segregation of Rights is based on the business processes of each particular company and as usual it is developed individually, we will not describe relevant to the SoD security checks in the present article.

Further steps

There are at least 100 critical privileges solely in the SAP BASIS that we we'll talk about here, as well as the number of rights in each module is approximately the same. As has been already mentioned, sometimes these privileges overlap each other and it is the SoD matrix that is responsible for that. A standard matrix contains more than 200 different SoD patterns, while each company can additionally use their own ones.
As a further step you can choose to get critical access rights from the the ITAF regulatory document by the ISACA [1] or from the Deutschsprachige SAP Anwendergruppe DSAG standard [2]. Then, you should reconfigure the SoD. The best thing to do here, before starting the analysis of duties segregation, is to find out whether there are wildcards "*" in the access rights' authorizations values.

[EASAI-NA-20] The check for accounts with SAP_ALL profile Description

Description

The SAP_ALL profile is a composite profile. It contains all the privileges for the SAP system including main administering functions and application settings. In accordance with the segregation of duties principle, this profile has no practical use.

Threat

A user that has the SAP_ALL profile privileges can perform any actions within the system. In case authentication data of the SAP_ALL profile user was compromised, an intruder can get an unrestricted access to any business data as well as to the critical business processes.

Solution

• User privileges should be specified according to the least-privileges principle.
• The SAP_ALL profile should be used in case of emergency only.
• You should create only one user with such profile (for emergencies) and keep this user's password in secret. Instead of using the SAP_ALL profile, it's better to distribute this profile's privileges between the appropriate positions. For example, instead of granting a system administrator all the SAP_ALL privileges, you should grant him only the authorizations relevant to system administering, in particular S_*. These authorizations will grant a system administrator enough privileges to administer the entire SAP solution, preventing him from performing tasks in other areas, such as, for instance, HR management.

[EASAI-NA-21] The check for accounts that may start any programs

Description

If additional access control for particular programs was not implemented, a user authorized to run programs can start any program. That, in turn, happens very often, especially in client programs. To control access to programs, authorization groups are created. Each authorization group corresponds to several ABAP programs. Users can start only those programs that are included in the authorization groups assigned to their profiles.
So, users having the following critical access should be checked:

• The SA38 transaction. It is used to execute programs and reports within the system;
• The SE38 transaction. It is used to look through the programs' source code and to develop/debug them;
• The SE37 transaction. It is used to start function modules;
• The SE80 transaction. It is used to edit any objects being under development (i.e. in ABAP editor).

Threat

Those users who are allowed to run any program have an unrestricted access to all system functions and can severely damage the system, as far as there are more than 30K various programs that can perform almost any action, be it user account creation and OS command execution or paying for goods and modification of salaries.
If there is no control, any user having authorization object S_PROGRAM assigned to him and access to SA38 or SE38 can execute any program. Furthermore, with access to SE37 one can start any function module, to SE80 - perform editing of any objects being under development.
Editing and running of some programs can cause a risk that the program will send back inaccurate or incomplete information. Besides, if a user is allowed to start SE38 transaction, it can lead to unauthorized program modification that can impact system integrity.

Solution

• Minimize the number of users with these privileges, roles should be assigned according to the least- privileges principle.
• Its important, to add into the most critical programs additional authorization checks, by means of modification of their source code.
• Besides, you should regularly review the policies, procedures and criteria used to specify authorized groups for the programs that are being created.

[EASAI-NA-22] The check for accounts with the privileges to modify sensitive tables with passwords

Description

USR02, USH02 and USRPWDHISTORY are standard tables for the SAP-system, that contain sensitive user data. Those are, for example, usernames, password hash, user types, client ID, etc.
For access control over these tables, users with the following authorizations should be monitored:

For the SAP NetWeaver version with S_TABU_NAM authorization object support:

• S_TABU_NAM:ACTVT=02;
• S_TABU_NAM:TABLE=USR02 or USH02 or USRPWDHISTORY;

or (for all other versions):

• S_TABU_DIS:ACTVT=02;
• S_TABU_DIS:DICBERCLS=SC.

Threat

Those users that have access to the listed tables have right to change password hash of any user. Thus, they can login the system under any account.

Solution

The number of users with access to USR02, USH02, USRPWDHISTORY tables must be restricted based on the business needs. The roles should be assigned according to the least-privileges principle.

[EASAI-NA-23] The check for accounts that may execute OS commands

Description

For the SAP solution to interact with the host OS, there are specific mechanisms that manage interaction with external OS commands. Those OS commands can be executed by means of transactions defined in the SAP system. Moreover, only the users that have particular privileges can execute them.
The SM49 transaction allows to execute any external command (related to the OS). The SAP solution contains a detailed information for each external command, including the OS commands themselves, preset parameters and the information about whether additional parameters are permitted.
Users executing external commands should have authorization object S_LOG_COM assigned to them. The S_LOGCOM_ALL authorization object (based on S_LOG_COM) allows execution of all commands included in the S_A.SYSTEM and S_A.ADMIN standard authorization profile sets.
To control external commands, the SM69 transaction is used. It allows to modify them and to install additional security controls. The user should be granted with the S_RZL_ADM authorization object with the Activity value set to 01 in authorization profile.

Threat

The users that may execute or modify OS commands potentially can start critical OS commands and may damage the system.
Not being controlled, any user with access to SM49 or SM69 transactions (and access to S_LOG_COM or S_RZL_ADM authorization objects) can execute external OS commands of a SAP solution. There is also a risk that some commands after being edited or run will send back inaccurate or incomplete information. Besides, if user was allowed to start the SM69 transaction, this can lead to unauthorized command modification, which in turn can have a negative effect both on the OS and SAP solution integrity.

Solution

• Minimize the number of users with these privileges, roles should be assigned according to the least- privileges principle.
• Block these transactions and unlock them if necessary during utilization.
• Besides, perform regular review of policies, procedures and criteria associated with authorization group set up for new programs.

[EASAI-NA-24] Check for disabled authorizations

Description

Authorization checks are used each time when it is necessary to verify whether the user has appropriate rights to perform certain actions.
Checks of particular authorization values can be disabled at the system level. The check is not carried out if a system administrator has disabled authorization object check intentionally for the particular transaction (using SU24 and SU25 transactions). This could be useful, as while a transaction is being executed many authorization objects are being checked in a background mode as well.
To make those checks successful a user should have corresponding authorizations. As a matter of fact, some users have more authorizations than necessary. These authorizations along with some others may grant a user additional (extra) privileges and increase the workload. On the other hand, disabling authorization checks is risky as this means that system access defense mechanisms will also be disabled.To enable authorizations implemented by means of SU24/SU25 transactions, set the AUTH/NO_CHECK_IN_SOME_CASES profile parameter to Y (with RZ10 transaction). This setting is used by default in newer version of BASIS. This parameter allows to disable authorization check for individual transactions.

Threat

The absence of critical authorizations check can result in unauthorized critical actions performing to the system. Resulting from this, system efficiency will lower and fraud actions will become possible. Besides, such disabled authorization checks may indicate a backdoor in the system.

Solution

It is recommended to verify necessity of disabling authorization check for system authorization object in a particular program, transaction or RFC-function. Analyse program names, transactions or RFC-functions with system authorization objects where authorization check is disabled. Technically, disabled authorizations are marked in the USOBX_C table (a validation table for the USOBT_C table) with OKFLAG = N field value.
Authorization checks for corresponding authorization objects should be disabled only for the particular transactions and for the period of their execution.

That's it for today's article, we hope you like our work. If you do, check out our new product [link].

The post SAP NetWeaver ABAP Security Configuration Part 7: Access control and SOD conflicts. appeared first on ERPScan.

Seventh critical issue in SAP Security landscape: Unencrypted connections. To protect connections between the SAP NetWeaver system components, especially against the man- in-the-middle (MITM) attacks, it is necessary to ensure SAP security at the transport level. While using the Transport Layer Security (TLS), the data transmission may be protected from eavesdropping not only with encryption, but also with the partner authentication.

TLS provides the following types of protection:

• Authentication: Communication partners may go through authentication. The server is always authenticated, while the client is authenticated depending on the algorithm.
• Data integrity: Message exchange is protected so that any modification is revealed.
• Data confidentiality: The data transmitted between the client and the server is encrypted, thus confidentiality is ensured. Eavesdropper is not able to get access to the data. Protection is available for inbound and outbound connections.

There are two forms of protection, depending on the used connection type. For connections using the Internet protocols such as HTTP, Secure Sockets Layer (SSL) protocol is used. For the SAP protocols such as RFC, Secure Communications Network (SNC) is used.

Further steps

This section contains the detailed encryption settings for various services. However, you should understand that, even if the encryption is enabled, it does not necessarily mean that it is always securely configured. For each type of encryption, in each particular case there are various settings to be fine-tuned. For example, recent BEAST and CRIME attacks on the SSL showed that more SSL fine-tuned settings are necessary [1]. That is why you should be very careful careful while configuring encryption, considering new attack types and peculiarities of the service.

[EASAI-NA-25] The SSL encryption to protect HTTP connections

Description

SSL supports the following protocols:

• HTTPS from HTTP,
• IIOPSEC from the IIOP,
• P4SEC from the P4.

Note that we take into consideration only the HTTP, as IIOP and P4 belong to the JAVA stack. In the ICM service parameter icm/server_port_<xx>, the protocol and the port are specified, where <xx> is the ordinal number of parameter. This parameter is used to specify the service name or port number to be applied to by the protocol. Also, additional service properties can be defined. But one port cannot have more than one service assigned to it. Besides, the service can not start when another program is already using this service or port. Parameter line has the following syntax: PROT = <protocol name>, PORT = <port name> [, TIMEOUT = <timeout>, PROCTIMEOUT = <proctimeout>, EXTBIND = 1, HOST = <host name>, VCLIENT = <client SSL Verification>, SSLCONFIG = ]. Mandatory to be defined are the following parameters: protocol name (PROT) and service name or port number (PORT), other parameters are optional. Default system values for this parameter depend on the system type which is specified by the system/type parameter. The following types are available:

• Double stack: system/type = DS (currently out-of-date). The instance contains AS ABAP and Java AS application servers:
  • icm/server_port_0=PROT=HTTP,PORT=5$(SAPSYSTEM)00,TIMEOUT=60,PROCTIMEOUT=600
  • icm/server_port_1 = PROT=P4,PORT=5$(SAPSYSTEM)04
  • icm/server_port_2 = PROT=IIOP, PORT=5$(SAPSYSTEM)07
  • icm/server_port_3 = PROT=TELNET,PORT=5$(SAPSYSTEM)08,HOST=localhost
  • icm/server_port_4 = PROT=SMTP,PORT=0,TIMEOUT=120,PROCTIMEOUT=120
• Java only: system/type = J2EE (not covered by this document). The instance contains the Java AS application server only.
• ABAP only: system/type = ABAP. The instance contains the ABAP (AS ABAP) application server only.
  • icm/server_port_0 = PROT=HTTP,PORT=0,TIMEOUT=30,PROCTIMEOUT=60
  • icm/server_port_1 = PROT=SMTP,PORT=0,TIMEOUT=120,PROCTIMEOUT=120

Threat

If there is no encryption of network connections, this can lead to unauthorized access to the data being transmitted by means of interception. HTTP protocol transmits all authentication data as a plain text, that allows to intercept it easily using the spoofing type of attack.

Solution

For HTTP connections, you should configure SSL. Detailed step-by-step instructions for this process may be found in the paper SSL Configuration in SAP ABAP AS and JAVA AS – Step-by-step procedure Available: [1].

[EASAI-NA-26] The SNC encryption use to protect the SAP GUI client connections

Description

SNC (Secure Network Communications) is a software layer in the SAP solution architecture. It supplies secure interface for external products. In particular, it is responsible for encryption and authentication. SAP solutions contain basic security controls including password-based user authorization and authentication concepts. With SNC in place, the SAP security can be improved by implementing additional security functions. Those functions are not provided openly by SAP solutions. It is, for example, the use of smart cards for user authentication, additional digital and encryption certificates. There are three security levels that can be applied. snc/data_protection/use parameter is responsible for this (by default it is set to 3 and shows standard connections protection level). Respectively, snc/data_protection/max and snc/data_protection/min show maximum/minimum protection level. So, those values show:

• Authentication only (snc/data_protection/use=1). The system authenticates communication partners. It is the minimum security level provided by the SNC. Data protection is not ensured!
• Integrity protection (snc/data_protection/use=2). The system detects any data modifications (manipulations) that may occur between the two communication endpoints.
• Data confidentiality protection (snc/data_protection/use=3). The message encryption system makes the eavesdropping useless. This level also includes the data integrity protection. It is the maximum security level provided by the SNC.This level also includes data integrity protection.

The snc/enable parameter defines whether the SNC protection is used for connections.

• The default value is: 0 (inactive SNC).
• The secure value: 1 (active SNC)

As soon as the SNC is active (snc/enable = 1), the system starts accepting the SNC-protected connections only. If there is a need to accept a normal connection which is not protected by the SNC, it is necessary to set the appropriate parameters (snc/accept_insecure_gui, snc/accept_insecure_rfc, snc/accept_insecure_cpic) depending on the types of connections to be accepted insecurely.

Threat

If there is no encryption of network connections, this can lead to unauthorized access to the data being transmitted by means of interception. HTTP protocol transmits all authentication data as a plain text, that allows to intercept it easily using the spoofing type of attack. If SNC encryption is not set, this can lead to unauthorized access to data transmitted between the systems using DIAG and RFC protocols. those protocols do not use data and passwords encryption, they use insecure compression algorythms. It is quite easy to decode those algorythms using free tools available on the Internet. This, in turn, allows to intercept passwords and get unauthorized access to system.

Solution

Set the snc/enable parameter to 1 to enable encryption, thus mitigating the risk of unauthorized access. Besides, the SNC User's Guide [2] recommendations may be useful here.

[EASAI-NA-27] The SNC encryption to protect RFC connections between systems

Description

SAP systems can connect to the other SAP systems, or non-SAP systems using two basic methods:

• by the Internet Communication Framework (ICF) that allows to use the HTTP, HTTPS or SMTP, or
• by the Remote Function Call (RFC) which may be called directly in the system.

RFC is the SAP own interface necesary for integration of SAP system and non-SAP system software. RFC calls a function to be executed in a remote system. Other integration technologies, such as web-services, are optional in RFC. Currently, there is a whole range of various RFCs, each of them with various properties and used for specific purposes. To ensure security of RFC connections, a wide range of measures can be implemented, but in this article we describe encryption only.

Threat

RFC-functions called for via RFC protocol may transmit confidential data (e.g., passwords or payment card numbers). When using RFC without encryption, there is a risk that this data will be available as a plain text. If SNC encryption for RFC connections and SSL encryption are not used for HTTP connections between the ABAP-based systems, it makes it possible for an intruder to get access to sensitive data by intercepting it with a spoofing attack.

Solution

It is recommended to carry out an analysis of a list of RFC connections between ABAP-based systems and verify those of them that require the use of SSL and SNC. For protection purposes it's better to prevent connections with ABAP-based systems. Using SM59 transaction to manage RFC and its SNC settings, you can define the following SNC data:

• SNC mode for connection (active or inactive);
• quality of protection (QoP);
• SNC partner name.

Other essential SNC settings (SNC AS name, external library location, maximum and default QoP), as mentioned above, are defined in the application server instance profile (these are profile parameters at the AS ABAP). To enable SNC for RFC adapter and the SAP system, it is necessary to install the certificate to the server. After that, on the RFC control screen (SM59 transaction), select the Change option and go to the Security & Logon tab. There, on this tab go to Edit --> SNC Options. In the appeared dialog window SNC extension: Details make the following changes:

• Enter the quality of protection in the QOP field.
• Enter the SNC communication partner name in the Partners field (if the start of external server program is defined at the application server or at the front end workstation, the SNC partner name will be received automatically from the existing safe route, with no need to specify it).
• Save the SNC settings.
• Return to the initial screen and enable SNC.

For the cases, where SSL is needed, it is recommended to perform the following actions:

• execute the SM59 transaction;
• select connection for which SSL is required;
• in the Logon/Security tab, set the SSL option to Activate;
• save changes.

Well, it's high time we finish the article. We hope you like it. Remember that you can always check out a demo version of our product by the following link.

The post SAP NetWeaver ABAP Security Configuration Part 8: Unencrypted connections appeared first on ERPScan.

Ninth critical issue. Logging of security events. Let us remind you, ERPScan's team core purpose is to take the definition of the SAP security one step further by providing its own guidelines to help SAP users carry out various security checks. This article is no exception. Today, we'll turn our attention to the next critical issue, which is the last one of all but not the least important.

One of the most important aspects to ensure the SAP security (and of any other critical system) is security event logging in place. In case of an incident (which is likely to happen because there are a plenty of settings in such systems and it is quite difficult to control all of them), only the security audit configured correctly will allow the company to discover the fact of an attack in time and, perhaps, to arrange a response to it. Besides, the security audit configured correctly allows to prevent attack in the early stages of collecting system data.

Security event logging system is complicated with a lot of different logs for each SAP subsystem, with each of them able to store sensitive information. Unfortunately, few of these logs may be centrally analysed. This section contains four most critical logs.

Further steps

In total, the SAP system contains about 30 critical and trace logs (for ABAP instance only). After enabling four basic logs described below, implement the fine-tuned settings, e.g., detailed table lists with enabled table logging, details of security event logging in security audit logs, detailed event types in the SAP Gateway log, etc. Also, their central collection and storage implementation should be accompanied with critical events analysis. Only then, you may add and analyse more detailed optional logs for each service.

[EASAI-NA-30] Logging of security events

Description

The SAP security audit log is an addition to the system log, but with a slightly different purpose. In contrast to the system log that must be always active, a security audit log may be enabled and disabled if required. The security audit log is a tool for a detailed overview of all events in a SAP system. The main audit log purpose is to record:

• security-related events in the SAP system neighbourhood (e.g., modifications in primary user accounts);
• information to make system more transparent (e.g., successful and invalid system logon attempts).
• information to reconstruct a chain of events (e.g., successful or failed transaction start).

Filters are used to determine what information should be recorded in the audit log file. In case of event that meets active filter criteria (e.g., start of a transaction), the audit log generates an audit message and writes it to a file. Also, an appropriate notification will be sent to the CCMS Alert Monitor (SAP Computing Center Management System Alert Monitor) used to observe centrally the ABAP and Java components, reveal various categories of system and application errors in different interfaces. A detailed information on events is presented in the auditor's report on the audit log vulnerability assessment. Using filters, you may specify actions needed to be recorded with SM19 transaction. To review the log, SM20 transaction is used. SM18 transaction allows removing old logs. The audit files are located at individual application servers. You may specify the file location and the maximum file size in the following profile parameters. The basic parameter is rsau/enable, which enables the audit log on the application server and by default is set to: 0 (inactive audit);

Threat

If the security event registration is not maintained, there is a risk of delayed response (or its absence) to potential external attacks or internal fraud. An opportunity to carry out the Forensic Investigation after the fact of hacking is almost fully excluded, too.

Solution

It is necessary to set the rsau/enable parameter to "1" (enable) to enable the security event logging. Then, it is necessary to configure filters by specifying exactly what events should be monitored using the SM19 transaction.

[EASAI-NA-31] Logging of HTTP requests

Description

If the ABAP application server is used for web connections by the ICM service, then it is necessary to configure logging of the HTTP requests to the ABAP application server. The icm/HTTP/logging_<xx> parameter is used to manage the HTTP-requests logging in the ICM service (or web dispatcher), if the ICM operates as a server. This parameter defines if HTTP-requests logging is enabled for the ABAP sources. If the ICM acts as a client, you may use the icm/HTTP/logging_client_<xx> parameter for the HTTP logging. The icm/HTTP/* parameter set is valid for the HTTPS as well. The parameter syntax looks the following way: icm/HTTP/logging_<xx>=PREFIX=<URL prefix>, LOGFILE=<log file name> [LOGFORMAT=<format>, FILTER=<filter>, MAXSIZEKB=<size in KBytes>, SWITCHTF=<options>, FILEWRAP=on] The LOGFILE parameter value determines the output file name in the file system. The HTTP-requests logging is not executed if the LOGFILE value is not specified.

Threat

If the security event registration is not maintained, there is a risk of delayed response (or its absence) to potential attacks with the HTTP protocol use. These logs are highly critical, in case the ICM service has the Internet access. Forensic Investigations of an incident related to the Internet attacks is almost impossible with these service logs disabled.

Solution

Specify the OS file name in the icm/HTTP/logging_<xx> parameter in the LOGFILE value to collect all necessary information on potential attacks. It is essential for a Forensic Investigation.

[EASAI-NA-32] Logging of table changes

Description

All SAP data are presented in tables. There are two different table categories:

• Client tables. They contain data used for one client (mandant) only, e.g., the user system logon data in USR02.
• Cross-client or client independent tables. These contain data valid for all the system clients, such as, for example, the T000 table.

The SAP provides table modification logging option to determine what a user has changed, added or removed in the data from tables and when. There are two technical requirements; with both of them in place, you may be sure that table modifications are logged:

• the general logging should be enabled;
• the technical table parameters should be set to "Record data changes".

The data recorded for these modifications is stored in the DBTABLOG table (DBTABPRT in lower versions). For them, the BC_DBLOGS archiving object may be used.

General logging The table changes are not logged by default. Activate the associated settings for the selected clients through the rec/client system parameter. This parameter may have the following values:

• OFF (disabled logging),
• All (logging is enabled for all the system clients),
• <Client number>, (...) (logging for clients with the numbers filled in here).

This parameter covers only those table modifications that result from direct system changes. The modifications occurred as a result of transport activities (for example, import) do not interact with this parameter ("Logging through transports" is used for this).

Warning!: the changes are not recorded when copying client.

Table logging The table logging is controlled by an appropriate value in the technical table configuration (for display, the SE13 transaction is used). To review all the tables logged, the DD09L table is called with the SE16N transaction. It works with the tables where:

• the maximum number of characters in the key field is 250;
• the maximum number of character in the data fields is 3500;

Transport logging To log modifications resulted from transport activities, set up the associated transport parameters. These parameters may be enabled in the Transport Management System (TMS) with the STMS transaction. The desired values for the transport profile (All, <Client number>) are set in the recclient parameter (see SAP Security Note 163694 [1]).

Threat

With no direct table access logging, there is a risk of late or no response to potential unauthorized table data modifications, e.g., an adversary may change the bank account value in the LFBK table and commit fraud actions by money transfer to another account.

Solution

• You should change the rec/client parameter to values corresponding to all production client numbers to collect all required information for a potential Forensic Investigation.
• Automatic logging is not recommended in test systems, as this may lead to a very rapid disk space fill.
• You should log all specific tables with all transaction, system control, setting and other main data, as well as all the data where logging is under question.
• For production system, you should log all clients (rec/client = ALL), at least those of production. But if you set the rec/client parameter to ALL you may seriously affect the system performance.
• For more information, see the following notes: 1916, 112388, 84052. [2] [3] [4]

[EASAI-NA-33] Logging of SAP Gateway activities

Description

Each SAP instance has the SAP Gateway. The gateway ensures interaction between work processes and external programs, and also interaction between the work processes from different instances or SAP systems. The gateway allows to execute RFC services at a SAP system. Higher security requirements are applied to a gateway since it is an application server interface with other systems (other SAP systems, external programs, etc.), one of these requirements is gateway logging activation. The gateway logging is used to control the gateway activity. You may configure what gateway actions exactly will be recorded in the log file. It is possible to configure the log maintenance in the gw/logging parameter or in the gateway monitor (the SMGW transaction). Notice that the gateway monitor is not available if a separate gateway or the Java-only installation are used. The parameter gw/logging contains various indicators that are responsible for logging of certain event types. The S indicator (i.e. Security) in the ACTION field is the most important allowing to record security configuration events and their modifications (e.g., file reloading), with other event types being also important.

Threat

With no security event logging, there is a risk of late or no response to potential attacks on a gateway. The risk of a security breach is considerably increased by this service vulnerabilities known since 2007 and exploits available on the Internet and that enables to get unauthorized access to the service and execute any OS commands.

Solution

• Add S value to the ACTION field for the gw/logging parameter to increase the security level and gain all information required for the potential Forensic Investigation.
• Logging of other security event types is also advisable.

That's it for today and remember, you don't have to let your ERP system fill up with vulnerabilities. With the help of our program you can easily keep your system protected.

The post SAP NetWeaver ABAP Security Configuration Part 9: Security Events Logging appeared first on ERPScan.

We continue our series of posts giving a review of one of the most frequent vulnerability which affects a lot of SAP modules: cross-site scripting, or XSS. Today's post describes how to protect SAP NetWeaver ABAP from XSS.

From the developer's perspective

For all generic Web applications where you accept input parameters, you must use encoding methods provided by the ICF handler. The implementation of the encoding is available as an API in two variants:

• ABAP built-in function ESCAPE (available as of SAP_BASIS >= 731);
• Class implementation in CL_ABAP_DYN_PRG.

In releases higher or equal to SAP NetWeaver Release 7.0 enhancement package 3 (SAP_BASIS >= 731), use the ABAP built-in function ESCAPE(). For more information, see the ABAP keyword documentation for the ESCAPE() function.

For lower releases (SAP_BASIS 702, 720 and below), there is an ABAP OO implementation. The implementation is in class CL_ABAP_DYN_PRG.

For more information about the delivery of these extensions, see SAP Security Note 1582870 [1].

For WebDynpro ABAP, you do not have to care about XSS at all. The security is ensured through the framework itself.

For BSP, you should use the page directives. For more information, see SAP Security Note 1600317 [2] and SAP Security Note 1638779 [3]. These BSP page attributes have the advantage that the BSP framework ensures that the most secure version of encoding is used.

For BSP, you should use the page directives: <%@page language="abap" forceEncode="html|url|javascript|css"%>

After importing SAP Security Note 1600317 [4], the existing page directives also use the updated BSP compiler that supports HTML encoding of all print statements on the page.

In the following example, all print statements use HTML encoding. It only affects print statements on BSP pages and does not have anything to do with tag parameter passing that uses the same syntax, but has different semantics.

BSP example: <%@page language="abap" forceEncode="html"%>
<html><body><form>
<% data: inputvalue type string.
inputvalue = request->get_form_field( 'x' ).
%>
<input type=text name=x value="<%=inputvalue%>">
<input type=submit>
</form></body></html>

The global page attribute defines the default encoding used within the page and all included page fragments. Besides the global page attributes, you can use the following notations for controlling the encoding behavior of a special print event (overriding the global settings):

• <%html=...%>: HTML encoding
• <%url=...%>: URL encoding for parameter names or values of URLs
• <%javascript=...%>: JavaScript encoding
• <%css=…%> : CSS encoding
• <%raw=...%> (no encoding, that is, a global encoding that was set in the page directive is switched off)

Using forceEncode within a page directive in a page fragment has no effect. The encoding within page fragments is always controlled by the including page.

One aspect that is similar to an XSS attack is a translation-related change that breaks the HTML or JavaScript code.

Example:
<script>
var msg = '<otr>Hello</otr>';
</script>
<input name=xyz value="<otr>Replace 'dog' with
'cat'</otr>">

Therefore, there is an extra page attribute that you can set. When this attribute is set, all OTR texts are effectively encoded directly after they have been retrieved in their language-dependent form.

For BSP ORT, you should use the page directives:
<%@page language="abap"
forceEncodeOtr="html|javascript"%>

HTML example
<%@page language="abap" forceEncodeOtr="html"%>
<script> var msg =
'<otr>Hello</otr>';
alert(msg);
</script>

JavaScript example:
<%@page language="abap" forceEncodeOtr="html"%>
<script>
var msg = '<%JavaScript=<otr>Hello</otr>%>';
alert(msg);
</script>

For the BSP HTMLB library, you must set the attribute forceEncode of the <htmlb:content> tag to ENABLED to switch on the internal encoding because it is set to disabled by default. ENABLED means that the extension will use an appropriate encoding depending on the context within a value is used:
<htmlb:content forceEncode="ENABLED|BACKWARDS_COMPATIBLE">

• ENABLED: This means to always encode everything. This overwrites all other encode attributes and they no longer have to be set;
• BACKWARDS_COMPATIBLE: This is the default value. The usual encode attributes are active as previously defined.

In addition, the attribute design of htmlb:content specifies the possible designs as a page supports. Valid values are CLASSIC, DESIGN2002, DESIGN2003, or DESIGN2008, or combinations separated by a plus (+) sign. The older designs CLASSIC and DESIGN2002 are no longer supported (and possibly insecure) and are therefore not to be used anymore: <htmlb:content forceEncode="ENABLED" design="DESIGN2003+DESIGN2008">

If you do not specify a design, then design=CLASSIC is used. Therefore, we recommend overriding this default with one of the supported designs mentioned.

The attribute forceEncode of the BSP page directive @page and the attribute forceEncode of the HTMLB content tag are independent of each other. The first one controls the encoding of variables outside any extension, whereas the last one controls the encoding with the extension HTMLB. Therefore, for a mixed page using HTML in combination with BSP Extensions, you must set both parameters as described in the sections above.
<%@page language="abap" forceEncode="html"%>
...
<htmlb:content forceEncode="ENABLED">
...
<htmlb:textView text="<%=param%>"/> (1)
<%=param%> (2)
...
</htmlb:content>

In this example, the encoding of the variable param in line (1) is controlled by the forceEncode attribute of the htmlb:content tag, and the param in line (2) is controlled by the forceEncode attribute of the page directive.

The BSP encoding directive <%url|html|javascript=...%> has no effect when passing values to attributes of extension tags and is simply ignored.

In the following example, the directive to do HTML encoding is ignored, instead of the htmlb tag decides internally which encoding is appropriate.
<htmlb:content forceEncode="ENABLED">
...
<htmlb:textView text="<%html=param%>"/>
...
</htmlb:content>

For the Internet Transaction Server (ITS) and HTML Business, the following encoding functions are available:

• xss_url_escape()
• xss_html_escape()
• xss_wml_escape()
• xss_css_escape()
• xss_js_escape()

When addressing values of variables using the HTML Business notation: that is, using back quotes (`) or the <server> delimiter, the encoding is controlled by the global parameters:

• ~auto_html_escaping=1: globally activates encoding
• ~new_xss_functions=1: globally activates the use of the updated XSS library

This can be overruled locally in the templates by setting the parameter ~html_escaping_off=1/0 in order to switch off or turn on the escaping.

Where and how these parameters are specified depends on the SAP_BASIS release:

• For the external ITS (Release <= 6.40), maintain them in the properties of the Internet Service in SE80.
• For the internal ITS (Release >= 6.40), maintain them in the GUI properties in transaction SICF as follows:
  • Release 6.40-7.11: ~auto_html_escaping=1 and
  • ~new_xss_functions=1 o Release >=7.20: ~auto_html_escaping=1

As of Release 7.20, there is no need to set the parameter ~new_xss_functions as the updated XSS library is used in all cases.

You must thoroughly test the application when using this approach because there may be cases where the encoding is too generic and can lead to false encoding. In such cases, you can use set the parameter ~html_escaping_off="X" to deactivate the automatic encoding and manually call the functions named. For more information, see SAP Security Note 1488500 [5].

The functions of the HTMLBusiness Template Library (for example SAP_TemplateNonEditableField()) always properly encode and cannot be switched on or off. For more information, see SAP Security Note 916255 [6].

You can also manually encode output by using the functions named above. In this case, encode all output.

From the administrator's perspective

The administrator has to set the parameters to improve security:

• http/security_session_timeout = 900; Enable session timeout to minimize potential attack window.
• icf/set_HTTPonly_flag_on_cookies = 0; Declaring a cookie as HttpOnly increases the security of your system because it eliminates access to this cookie in the Web browser from client-side scripts, applets, plugins, and the like. Set httpOnly flag to secure cookies and Logon Tickets from transmitting them into the malicious host using XSS vulnerability.

To change the parameter activate the RZ10 transaction, select (in the field Profile) necessary profile (for example DEFAULT.PFL if the parameter should be applied globally for the SAP system). To create, change or delete the parameter in a profile select <i>Extended maintenance</i> and press the change button. When changes are made, select the Copy button.

From incident response perspective

To be able to identify the real attack happened because of the XSS vulnerability and also from some other web-based vulnerabilities, it is recommended to configure the following parameters.

• Configure icm/HTTP/logging_0 parameter
  • set LOGFILE value to path_to_file
  • Sеt PREFIX value to "/". If URL prefix="/" (root directory), or empty which means that all HTTP requests will be logged. If prefix value equal "/Directory", the server will log only requests which call "/Directory" directory and subsequent.
  • Set FILEWRAP value to off. Old log files will be saved for future analysis
• Configure icm/security_log parameter, o set LOGFILE value to path_to_file
  • set VERBOSITY value to 3. To be able to save all necessary data in
  • Set FILEWRAP value to off. Old log files will be saved for future analysis

The post Securing SAP Systems from XSS vulnerabilities Part 2: Defense for SAP NetWeaver ABAP appeared first on ERPScan.

in the previous post, we dispelled some SAP Cybersecurity myths.Today we will discuss how SAP cybersecurity differs from traditional IT security. While usually security is security, no matter what one deals with, in SAP area there are some distinctive features. Four main differences between SAP (or any other enterprise business application) and traditional applications can be described by using four Cs.

Complexity

SAP systems are very complex and complexity kills security. Just to give you an idea, demo installation of an SAP System requires 60 gigabytes on a hard drive. The latest version of SAP NetWeaver J2EE engine is shipped with 1200 preconfigured web services, and each has the same functionality as a small website. SAP is much more complex than any other application. Typical SAP system has about 1000 parameters, and most of them can affect security. When you install an SAP System, it goes with 20+ different services, each uses its own proprietary protocol and a set of configurations. Just imagine how many vulnerabilities can be found in such a multipart system. And it’s only for NetWeaver ABAP Application Server, not speaking about that SAP provides at least five other platforms with a completely different set of functions, services, protocols, and even access control systems.

By the way, a few words about access control system. If you are aware of it, I can see it by your reaction even before starting this talk. In a nutshell, authorizations in SAP are like a small set of functionality one can execute. Each authorization has an activity, field, and value. For example, there is a special authorization to get access to tables, and this authorization can be associated with different types of activities such as read or write. Furthermore, there are different types of access, say, an access to a particular number of tables such as system or material tables. When you configure this single small part of access, it will be called authorization, then a set of authorizations is combined into a role, and a role, in its turn, is combined with a composite role. Finally, the role is assigned to a user. And there are thousands of different authorizations. But it is not the only opportunity; roles can be assigned to a profile and profile can be assigned to a user, as well. And above that system, we also have different types of users. For instance, reference users take access rights from real users but don’t store the information about access rights in their profile. Once again, it’s only about ABAP system. For other systems or even modules, there are other role models.

And another fact to prove the idea of SAP complexity. Traditional scanners provide about 40k security checks for all IT systems; in our SAP Security scanner, there are about 10 thousand checks for SAP only. So, you can imagine how complex SAP is and how SAP cybersecurity affects the state of security of a whole company.

Customization

SAP is not a typical software. It resembles a kind of framework. On top of this framework, companies develop applications to accomplish their requirements using ABAP, JAVA, and XSJS languages or some frameworks such as UI5 for HANA.

Our research revealed that in large organizations up to 50% customization are usually implemented. And it’s rather typical; customizations are a part of SAP. You can hardly find any SAP Implementation without customizations and new programs developed to automate one or another part of business. Those customizations may have vulnerabilities as any others applications. Those customizations are usually made by an internal development team, however now the number of companies that outsource this process to 3rd parties is growing. According to our Security Research, we usually find thousands of SAP vulnerabilities per system during the initial assessment. Although not all of them are highly critical, it is a sight that this area is a part of SAP cybersecurity should be considered seriously.

Criticality

All SAP systems provide mission-critical functions. So, if something happens to them, companies are likely to lose millions of dollars. We speak not only about attacks but also about mistakes which can occur because of improper configuration or patching of SAP System. SAP Systems have many configuration parameters for backward compatibility with old and legacy systems. Some or those parameters may be insecure, but it’s not always easy to configure them properly without breaking some connection with a legacy system. Unfortunately, some administrators leave their systems unpatched, because they are simply scared that something goes wrong after updating.

Closeness

Now we can say that this topic is less relevant than it was five years ago, but it remains important. SAP Security is a closed world, only a few people conduct in-depth research in this area and identify new vulnerabilities in SAP software regularly.

For years SAP Security used to be a synonym of Segregation of duties and SAP was like an unbreakable, solid, and secure application developed by Germans. In reality, it turned out that the security was based on the fact that no one had access to these applications and hackers were not interested in examining them. But gradually SAP applications have become more integrated into the infrastructure. At the same time, more researchers began to pay attention to these applications and their security. Nevertheless, any other system (for example, Windows) was on the hackers’ radar for years. All the simple vulnerabilities were identified and closed years ago, and like a human immune system, these became less prone to attacks. As for SAP, these applications have relatively recently become publicly available, so they are plagued with vulnerabilities which were closed in other applications years ago. Figuratively speaking, in terms of cybersecurity, SAP is like a child standing in the heart of Moroccan market crowded with pickpockets, tricksters, and other criminals.

Luckily, the situation is changing, and the level of SAP security awareness has increased significantly. However, security specialists now face another problem. Many guides, books, and documents from SAP are being published, so, it’s hard to choose the most relevant ones and especially ones containing information applicable to your business case.

The post SAP Security for CISO. Part five: 4 Cs of SAP Cybersecurity appeared first on ERPScan.

Application: SAP NetWeaver AS ABAP
Versions Affected: SAP NetWeaver AS ABAP 7.4
Vendor URL: SAP
Bugs: Directory traversal
Reported: 22.04.2016
Vendor response: 23.04.2016
Date of Public Advisory: 08.08.2016
Reference: SAP Security Note 2312966
Author: Daria Prosochkina (ERPScan)

Description

An attacker may be able to read the contents of unexpected files and expose sensitive data. If a targeted file is used as a security mechanism, then the attacker may be able to bypass that mechanism. For example, by reading a password file, the attacker could conduct brute force password guessing attacks in order to break into an account on the system.

Business risk

An attacker can use Directory traversal to access to arbitrary files and directories located in an SAP server filesystem including application source code, configuration and system files. It allows obtaining critical technical and business-related information stored in a vulnerable SAP system.

The post [ERPSCAN-16-031] SAP NetWeaver AS ABAP – directory traversal using READ DATASET appeared first on ERPScan.

On 9th of August 2016, SAP released its monthly critical patch update consisting of 13 SAP Security Notes, plus 17 Notes were released after the second Tuesday of the previous month and before the second Tuesday of this month.

To help everyone who is engaged in SAP patching process, ERPScan research team prepared a detailed review of the released SAP Security notes and guidelines on their implementation. This analysis would also be useful for companies providing SAP Security Audit, SAP Vulnerability Assessment, or SAP Penetration Testing .

SAP Security Notes August 2016

SAP's critical patch update for August 2016 closes 30 vulnerabilities in SAP products in total including 26 SAP Security Patch Day Notes and 4 Support Package Notes. 17 of all the Notes were released after the second Tuesday of the previous month and before the second Tuesday of this month. 14 of all the Notes are updates to previously released Security Notes.

14 of the released SAP Security Notes have a high priority rating and 1 has a Hot News rating. The highest CVSS score of the vulnerabilities is 7.5.

The most common vulnerability type is Cross-site scripting.

Most of the vulnerabilities belong to the Java platform.

Priority vs. Application type distribution

The fact that SAP Systems are complex is a common place. However, then it comes to SAP Security Notes Implementation, one should take it into account. To simplify this process, ERPScan research team created a table showing a distribution between priority and application area.

The most critical SAP Security notes to implement

The most dangerous vulnerabilities of this update can be patched by the following SAP Security Notes:

• 2292714: SAP Memory Snapshot Creation has a Denial of service vulnerability (CVSS Base Score: 7.5). An attacker can use a Denial of service vulnerability to terminate a process of a vulnerable component. For this time, nobody can use this service, this fact negatively affect business processes, system downtime and, as a result, business reputation. Install this SAP Security Note to prevent the risks.
• 2319506: SAP Database Monitors for Oracle has a SQL injection vulnerability (CVSS Base Score: 7.2). An attacker can use an SQL injection vulnerability by specially-crafted SQL queries. It allows reading and modifying sensitive information from a database, executing administration operations on a database, destroying data or making it unavailable. Also in some cases, an attacker can access system data or execute OS commands. Install this SAP Security Note to prevent the risks.
• 2294866: SAP JMS Provider Service has a Missing authorization check vulnerability (CVSS Base Score: 6.4 ). An attacker can use a Missing authorization check vulnerability to access a service without any authorization procedures and use service functionality, which has restricted access. This can lead to an information disclosure, privilege escalation, and other attacks. Install this SAP Security Note to prevent risks.

SAP Java security notes implementation process

SAP Security Notes implementation is not a one-time action but a continuous process, which should be conducted on a regular basis. Unfortunately, this process is not simple and required an in-depth understanding of SAP environment and security, and what’s more important, the security processes in specific to an SAP landscape. Not least because the complexity and interconnection of the software, fixing one problem may in its turn introduce another, causing a knock-on effect across a whole system and the potential downtime of service. ERPScan research team helps to mitigate this issue by introducing its series of SAP Security notes implementation guidelines.

Today we are patching SAP JAVA component BPEM PORTAL CONTENT by using information from SAP Security Note 2296909 released this August. For our tests, we have SAP NetWeaver as JAVA 7.31 with BPEM-PP 7.31 version 18 SP 00 patch.

1) First of all, we need to download a required patch. Log in to the SAP Launchpad using your credential. To find a required component, you can use search functionality.

2) Select “Downloads” and enter “BPEM PORTAL CONTENT 7.31”

3) Choose the required patch. For our system, it’s BPEM PORTAL CONTENT 7.31 SP018 with patch 000001 (file name BPEMPP18P_1-20007114.SCA).

4) Put the downloaded file BPEMPP18P_1-20007114.SCA to C:\usr\sap\trans\EPS\in (Windows) or /usr/sap/trans/EPS/in (Linux)

5) Use a Telnet to connect to a server on port 5NN08 where NN is an instace.

6) Enter the username and password.

7) Use the command “deploy path_to_file” to deploy the patch.

8) As a result of the deploying, you will get a Successful status.

9) Now we can check the version on the web page http(s)://host:5NN00/nwa/sysinfo in “Components Info” tab.

ERPScan highly recommends that SAP customers implement SAP Security notes to prevent business risks affecting your SAP systems as soon as patches are released.

The post SAP Security Notes Implementation process and Review – August 2016 appeared first on ERPScan.

As you may know, implementing SAP Security Notes for ABAP systems sometimes requires manual activities. The recently released Note 2252568 Switchable authorization checks for RFC in Internet Service is an example of such patch. Let’s follow the process of the implementation.

We will use SAP Solution Manager 7.2 with BBPCRM Release 713 level 0009.

1. First, upload the Note into SAP CRM. It can be done in 2 ways:

• Upload a Note manually. Log in to the SAP Launchpad using your credential. To find a required SAP Note, you can use search functionality and then press the “Download for SNOTE” button.

  The ZIP file will be downloaded. Unzip it (txt extension). Log into the SAP system, call for the SNOTE transaction, in the tab GOTO choose “Upload SAP Note”. Then in the window that appears, select the file and give permission to access the file.

  The note is downloaded.

• Download via SNOTE transaction (if Remote Service Connections on SAP Support Portal is configured). To do so, log into SAP system, run the transaction SNOTE, click Download SAP Note on the tab GOTO.

  In the window that appears enter the SAP Note number (2252568 or 0002252568) and press Execute. The Note will be downloaded automatically.

2. The downloaded Note will appear under the NEW category.

Double-clicking allows reading the note content.

To implement the note, press SAP Note Display and choose the “Implement SAP Note” option.

3. Some notes may require implementation of additional notes. If Remote Service Connections on SAP Support Portal is configured in your system, additional notes will be downloaded automatically; otherwise, you should download them (as described above). Such window can appear several times (depending on the number of required Notes).

4. Additional notes can also require manual activity.

After clicking on the “Implement All Instructions Correction Together”, a warning window appears to inform that manual action is required. If manual actions are complete, press ”YES” and go to step 6.

Manual activation

All manual actions are described in the SAP Note or you can find the instruction in the Correction window . Now we will log into the system under the current user or another one.

Step 1.1 To create authorization scenario definition, run the transaction SACF and check if the “CRM_ICSS_1” scenario definition exists. If it doesn’t exist, run SACF_TRANSFER transaction, select radio button “Upload”, select work area “Scenario Definition”, deselect work area “Productive Scenarios”, deselect “Test Mode”, and execute (F8). Then choose the file “CRM_ICSS_1.txt” and confirm upload.

Assign the scenario definition “CRM_ICSS_1.txt” to development package “CRM_ICSS”.

After that, the system will require creating or adding a transport request. You can either create a new transport request or add it to an existing one.

Check If scenario upload has worked.

Step 1.2 To create the authorization scenario definition in older support packages, repeat all the actions described in step 1.1 for CRM_ICSS_CR_1

After all the manual actions are complete, use the SACF transaction to ensure that the scenario is uploaded.

Step 2 To create the productive authorization scenario from the scenario definition, run the transaction SACF, select “Scenario Definition”, select the “Scenario Name” described above (CRM_ICSS_CR_1 and CRM_ICSS_CR_1), and execute (F8).

Double click on the scenario definition and press the button “Scenario” (or press F5) to transfer the scenario definition to a productive scenario.

As the Note allows choosing the scenario status, for CRM_ICSS_1 use the status “Active”, and for CRM_ICSS_CR_1 the status “Logging”. Also, the Transport Request appears here, you can use the one used before.

Using report RSAU_SELECT_EVENTS, identify users that require the authorizations. Analyze messages IDs DUO (Authorization check on object &A in scenario &B successful) and DUP (Authorization check on object &A in scenario &B failed).

After you confirm that the Note is implemented, 2 notification of changes are displayed: the first about changed and inactive objects and the second about changed authorization objects.

Then the window appears, where you should confirm that the manual actions were done. Select Confirmed checkbox and press the check mark button.

Now the Note status is completely implemented.

The post Switchable Authorization Check Security patches – implementation process appeared first on ERPScan.

On 8th of November 2016, SAP released its monthly critical patch update consisting of 16 patches.

To help everyone who is engaged in SAP patching process, ERPScan research team conducted a detailed review of the released SAP Security notes. This analysis would also be useful for companies providing SAP Vulnerability Assessment, SAP Security Audit, or SAP Penetration Testing .

SAP Security Notes November 2016

The critical patch update for November 2016 includes 10 SAP Security Patch Day Notes and 6 Support Package Notes. 5 of all Notes were released after the second Tuesday of the previous month and before the second Tuesday of this month. One Note is an update to a previously released Security Note.

2 of the released SAP Security Notes were assessed as a Hot News. The highest CVSS score of the vulnerabilities is 9.1.

Most of the vulnerabilities belong to the SAP NetWeaver ABAP platform.

The most common vulnerability type is Missing authorization check.

About OS Command execution vulnerability

This month, two the most severe vulnerabilities (CVSS Base Score: 9.1) belong to the Operating System (OS) Command Injection vulnerability type.These are as follows:

• 2357141 SAP Report for Terminology Export component has an OS command execution vulnerability
• 2371726 SAP Text Conversion component has an OS command execution vulnerability

OS command injection occurs when an application accepts untrusted input (forms, cookies, HTTP headers, special characters etc.) to build operating system commands or there is an insufficient sanitizing . Executed commands will run with the privileges of a vulnerable service.

An attacker can use OS command execution vulnerability to execute operating system commands without authentication. As for SAP, an attacker can access arbitrary files and directories located in an SAP server file system including application source code, configuration, and critical system files. The vulnerability allows obtaining critical technical and business-related information stored in a vulnerable system.

OS command execution vulnerability threatens not only applications developed by the vendor, but third-party customizations as well.

Let’s look at the example of vulnerable ABAP code and the ways of vulnerability prevention

Example

In the example below, an attacker can specify the value of command variable, which is used in 'SYSTEM' kernel call. Thus, there is an opportunity to execute OS arbitrary command.

PARAMETERS command(255).

DATA:
      BEGIN OF tabl OCCURS 0,
        line(255),
      END OF tabl.

CALL 'SYSTEM' ID 'COMMAND' FIELD command
              ID 'TAB'     FIELD tabl-line.

How to prevent

1. Avoid user input data in CALL 'SYSTEM' expression.

2. Forbid command calls via SYSTEM by setting the rdisp/call_system parameter value to ‘0’. It can be done by the RZ11 transaction.

Note: The command call barring is applied to the whole system, which can lead to unpredictable consequences, while SAP uses CALL 'SYSTEM' for execution of the OS commands.

3. Implement an authorization check via AUTHORITY_CHECK_C_FUNCTION just before SYSTEM call. It is also possible to use object of authorization 'S_C_FUNCT'. It is necessary to remember that this check defines only the presence of rights to call SYSTEM, not to execute concrete OS command.

4. Ideally, a developer should use existing ABAP best practices.

1. Use of AUTHORITY_CHECK_C_FUNCTION

PARAMETERS command(255).

DATA:
      BEGIN OF tabl OCCURS 0,
        line(255),
      END OF tabl.

CALL FUNCTION 'AUTHORITY_CHECK_C_FUNCTION'
    EXPORTING
        ACTIVITY = 'CALL'
        FUNCTION = 'SYSTEM'
    EXCEPTIONS
        NO_AUTHORITY = 1
        ACTIVITY_UNKNOWN = 2.

IF sy-subrc = 0.
CALL 'SYSTEM' ID 'COMMAND' FIELD command
              ID 'TAB'     FIELD tabl-line.
ENDIF.

2. Use of 'S_C_FUNCT'

PARAMETERS command(255).

DATA:
      BEGIN OF tabl OCCURS 0,
        line(255),
      END OF tabl.

AUTHORITY-CHECK OBJECT 'S_C_FUNCT'
    ID 'PROGRAM' FIELD sy-repid
    ID 'ACTVT' FIELD '16'
    ID 'CFUNCNAME' FIELD 'SYSTEM'.

IF sy-subrc = 0.
CALL 'SYSTEM' ID 'COMMAND' FIELD command
              ID 'TAB'     FIELD tabl-line.
ENDIF.

Priority vs. Application type distribution

The fact that SAP Systems are complex is a common place. However, then it comes to SAP patching, one should take it into account. To simplify this process, ERPScan research team created a table showing a distribution between priority and application area.

The most critical issues closed by SAP Security Notes November 2016

The most dangerous vulnerabilities of this update can be patched by the following SAP Security Notes:

Advisories for those SAP vulnerabilities with technical details will be available in 3 months on erpscan.com. Exploits for the most critical vulnerabilities are already available in ERPScan Security Monitoring Suite.

The post SAP Security Notes November 2016 appeared first on ERPScan.

Application: SAP NetWeaver ABAP
Versions Affected: SAP KERNEL 7.40 64BIT, disp+work.exe (7400.12.21.30308)
Vendor URL: SAP
Bugs: DoS
Reported: 15.12.2016
Vendor response: 16.12.2016
Date of Public Advisory: 14.03.2017
Reference: SAP Security Note 2406841
Author: Vahagn Vardanyan (ERPScan)

VULNERABILITY INFORMATION

Class: DoS
Impact: Denial of Service
Remotely Exploitable: yes
Locally Exploitable: no
CVE: CVE-2017-9843

CVSS Information

CVSS Base Score v3: 2.7 / 10
CVSS Base Vector:

Description

The vulnerability is presented in disp+work.exe in Javascript executing time.

Business risk

An attacker can use a Denial of Service vulnerability for terminating the process of a vulnerable component. For this time nobody can use this service that negatively influences the business processes, system downtime, and business reputation as a result.

VULNERABLE PACKAGES

SAP KERNEL 7.40 64BIT, disp+work.exe (7400.12.21.30308)

SOLUTIONS AND WORKAROUNDS

To correct this vulnerability, install SAP Security Note 2406841

TECHNICAL DESCRIPTION

Proof of Concept

data SOURCE type STRING.
data JS_PROCESSOR type ref to CL_JAVA_SCRIPT.
data RETURN_VALUE type STRING.
JS_PROCESSOR = CL_JAVA_SCRIPT=>CREATE( ).
SOURCE = ' this (1,2,3,4)'. "!!!!!!!!!!!!!!!!!!!!!!! null pointer
JS_PROCESSOR->COMPILE( SCRIPT_NAME = 'tmp.JS'
SCRIPT = SOURCE ).
RETURN_VALUE = JS_PROCESSOR->EXECUTE( 'tmp.JS' ).
This is a windbg log

0:000> r
rax=0000000000000000 rbx=000007df8014b6e0 rcx=000007df800cf8e0
rdx=000007df80149100 rsi=000007df800cf8e0 rdi=0000000000000000
rip=00000001415d6759 rsp=0000000002149ec0 rbp=0000000000000000
r8=000007df8014b6e0 r9=0000000000000000 r10=0000000000000000
r11=0000000002149e80 r12=000007df801496e0 r13=00000001415ed7f0
r14=000007df80149710 r15=000007df80149100
iopl=0 nv up ei ng nz na pe cy
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010283
disp_work!ComputeThis+0x29:
00000001415d6759 4c8b4008 mov r8,qword ptr [rax+8] ds:0000000000000008=????????????????

Call stack

The post [ERPSCAN-17-010] SAP NetWeaver AS ABAP disp+work crash appeared first on ERPScan.

Application: SAP CRM
Versions Affected: SAP CRM 700 – 801
Vendor URL: SAP
Bug: SQL Injection
Reported: 27.02.2017
Vendor response: 28.02.2017
Date of Public Advisory: 08.08.2017
Reference: SAP Security Note 2450979
Author: Vahagn Vardanyan (ERPScan)

VULNERABILITY INFORMATION

Class: SQL Injection
Risk: Medium
Impact: Unauthorized access to critical data
Remotely Exploitable: Yes
Locally Exploitable: No

CVSS Information

CVSS Base Score v3: 6.3 / 10
CVSS Base Vector:

DESCRIPTION

The problem is caused by an SQL Injection vulnerability. The code comprises an SQL statement that contains strings that can be altered by an attacker. The manipulated SQL statement can then be used to retrieve additional data from the database or to modify the data.

BUSINESS RISK

An attacker can use an SQL Injection vulnerability with help of specially crafted SQL queries. He or she can read and modify sensitive information from a database, execute administration operations on a database, destroy data or make it unavailable. In addition, an attacker might access the system data or execute OS commands.

VULNERABLE PACKAGES

SRM_SERVER 701, 702, 713, 714

SOLUTIONS AND WORKAROUNDS

To correct this vulnerability, install SAP Security Note 2450979

TECHNICAL DESCRIPTION

The vulnerability is presented in the CRM_THTMLB_UI_SEARCH ABAP executable program.

This program is used for searching some text in UI components, the program has 4 input parameters.

The vulnerable parameter is APPL2 (an additional BSP application to search in)

After the execution with the malicious charset, disp+word sends an application error.

An exception occurred that is explained in detail below.
The exception, which is assigned to class 'CX_SY_DYNAMIC_OSQL_SYNTAX', was not
caught and
therefore caused a runtime error.
The reason for the exception is:
The current ABAP/4 program attempted to execute an ABAP/4 Open SQL
statement in which the WHERE condition contains an LIKE operator.
The pattern of this LIKE operator
" "
begins with "'", but contains no closing "'".

The post [ERPSCAN-17-046] SAP NetWeaver AS ABAP SQL Injection appeared first on ERPScan.