SAP - All Articles - CISO Platform2024-03-28T10:45:08Zhttps://www.cisoplatform.com/profiles/blogs/feed/tag/SAPSAP NetWeaver ABAP security configuration part 2: Default passwords for access to the applicationhttps://www.cisoplatform.com/profiles/blogs/sap-netweaver-abap-security-configuration-part-2-default2015-02-02T16:00:00.000Z2015-02-02T16:00:00.000ZAlexander Polyakovhttps://www.cisoplatform.com/members/AlexanderPolyakov743<div><p><b>Second critical category. Default passwords for access to the application<br /> <br /></b> 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.</p><p>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.<br /> In the version 6.10 of SAP Web Application Server, the so-called <i>Master Passwords</i> <a href="http://www.sapsecurityonline.com/password_sap.htm">[1]</a> were first put into practice. <br /> 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:</p><p></p><table><tbody><tr><td>USER</td><td>PASSWORD</td><td>CLIENT</td></tr><tr><td>SAP*</td><td>06071992, PASS</td><td>001, 066, Custom</td></tr><tr><td>DDIC</td><td>19920706</td><td>000, 001, Custom</td></tr><tr><td>TMSADM</td><td>PASSWORD, $1Pawd2& </td><td>000</td></tr><tr><td>SAPCPIC</td><td>ADMIN</td><td>000,001</td></tr><tr><td>EARLYWATCH </td><td>SUPPORT</td><td>066</td></tr></tbody></table><p></p><p><span>(Read more: </span><b><a href="http://www.cisoplatform.com/profiles/blogs/captivating-new-insights-into-hbb-tvs">Can your SMART TV get hacked?</a>)</b></p><p></p><p><u><i>Further steps</i></u></p><p><i>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. <br /> 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. <br /> 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.</i></p><p><b><i>[EASAI-NA-03] Default password check for a SAP user</i></b></p><p><b><i>Description</i></b></p><p>The SAP* users are created in all clients immediately after installation. Those are dialog users who work via SAP GUI (<b>user type = dialog</b>). They perform all administrative tasks (and usually have <b>the SAP_ALL </b>profile). In case any SAP* user has been removed, after the system was rebooted one can login using standard <b>PASS</b> password and get all the corresponding SAP_ALL privileges.</p><p><b><i>Threat</i></b></p><p>Default passwords of <b>SAP*</b> users are well-known (see the table above). With these passwords, an adversary may enter the system using <b>SAP_ALL</b> profile and, consequently, get an unlimited access to any business data stored in the system.</p><p><b><i>Solution</i></b></p><ul><li>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 <i>Lock/Unlock icon</i>(Ctrl+F5);</li><li>Set <b>login/no_automatic_user_sapstar</b> to <b>1</b> (<b>RZ10</b> and <b>RZ11</b> transactions). Note that <i>in 3.1G and lower versions</i>, the <b>login/noautomatic_user_sap*</b> parameter is used;</li><li>Change the SAP* default password (using <b>SU01</b> transaction);</li><li>Make sure that now the user belongs to the <b>SUPER</b> group in all clients. Go to <b>SU01 transaction</b>, select the <b>SAP*</b> user, click on the <i>Change</i> icon (Shift+F6), then on the <i>Logon Data</i> tab.</li></ul><p><b><i>EASAI-NA-04 Default password check for the DDIC user</i></b></p><p><b><i>Description</i></b></p><p>The <b>DDIC</b> 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. <br /> 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.<br /> In all the other clients it is a <i>system</i> type user, it may perform background processing and it can interact with the system. <b>SAP_ALL</b> and <b>SAP_NEW</b> profiles that grant access to all the functions of the SAP are defined for this user.</p><p><b><i>Threat</i></b></p><p>The <b>DDIC</b> 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.</p><p><b><i>Solution</i></b></p><p><i><b>WARNING!</b> 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.</i></p><ul><li>In 000 client change the user type to <b>SYSTEM</b>;</li><li>Remove SAP_ALL profile;</li><li>Lock out the DDIC user. Unlock it if needed only. Notice that transport system executes certain programs on behalf of the DDIC user;</li><li>Change the default password for the DDIC user;</li><li>Make sure that the DDIC user belongs to the <i>SUPER</i> group in all clients. Only authorized administrators have the right to modify this account.</li><li>Regularly perform checks of system clients to those illicit ones.</li></ul><p><b><i>[EASAI-NA-05] Default password check for the SAP user</i></b></p><p><b><i>Description</i></b></p><p>The <b>SAPCIPIC</b> 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. <br /> So, this user does not have dialog type user privileges, though it has the <b>S_A.CPIC</b> profile. As a result, critical are the following authorization objects:</p><ul><li>the <b>S_CPIC</b> (to call for CPIC functions from ABAP/4 programs),</li><li><b>S_DATASET</b> (with privileges to access files from ABAP/4 programs), and</li><li><b>S_RFC</b> (authorization check for RFC access to program modules, for example, to a functional group).</li></ul><p></p><p><b>(Read more: </b><a href="http://www.cisoplatform.com/profiles/blogs/how-to-choose-your-security-penetration-testing-vendor">How to choose your Security / Penetration Testing Vendor?</a>)</p><p></p><p><b><i>Threat</i></b></p><p>Default passwords of <b>SAPCPIC</b> 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. <b>TH_GREP</b>); create dialog users with any privileges to enter the system and get an unlimited access to the data.</p><p><b><i>Solution</i></b></p><p>Remove <b>SAPCPIC</b> user if you do not need it. If the user is still necessary:</p><ul><li>Change the default password for SAPCPIC user;</li><li>Lock out SAPCPIC user. Unlock if necessary only;</li><li>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;</li><li>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;</li><li>Determine a special user for remote access. Do not use any default users;</li><li>Perform regular checks of your clients to eliminate the risk of illicit access.</li></ul><p><b><i>[EASAI-NA-06] Default password check for TMSADM user</i></b></p><p><b><i>Description</i></b></p><p>The <b>TMSADM</b> user is used for transfers through the transport system. It is created automatically upon configuration and changes of <b>Transport Management System (TMS)</b> via the 000 client. <br /> 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 <b>S_A.TMSADM</b> authorization profile enabled to utilize RFC-functions with GUI and to write to a file system. <b>SAP_ALL</b> profile is also often assigned to this user.</p><p><b><i>Threat</i></b></p><p>The default password of <b>TMSADM</b> user is well-known. An adversary may remotely start RFC requests to perform critical actions such as deletion and reading files (<b>EPS_DELETE_FILE, EPS_OPEN_FILE2</b>); arbitrary ABAP code execution (through the <b>RFC_ABAP_INSTALL_AND_RUN</b>or <b>TTMS_CI_START_SERVICE</b> function vulnerabilities), and, using <b>BAPI_USER_CREATE1</b> and<b>SUSR_RFC_USER_INTERFACE</b> requests, to create a dialog user and, consequently, to enter the system and get an unlimited access to business data.</p><p><b><i>Solution</i></b></p><ul><li>Change the default password of <b>TMSADM</b> user; to change this password you should:<ul><li>Enter the 000 client under any user with administrative rights.</li><li>Start the <b>TMS_UPDATE_PWD_OF_TMSADM</b> program with the ABAP editor (the <b>SE38</b>transaction). There are three ways to change the TMSADM password:<ul><li>to enter your own password</li><li>to set a new standard password (Note 761637, <i>$1Pawd2&</i>), or</li><li>to set an old standard password (PASSWORD);</li></ul></li><li>Select the option <i>"To enter your own password”</i> in the dialog box and enter the new password;</li><li>Start the program</li></ul></li><li>Make sure that this user belongs to the <b>SUPER</b> group in all clients. This way you will be certain that only authorized administrators have the right to change this user’s account;</li><li>Determine a special user for the remote access. Do not use any of default users;</li><li>Perform regular checks for your clients to eliminate the risk of illicit access.</li></ul><p>Additionally, it is better to apply security notes related to vulnerabilities in the programs which TMSADM user can execute, such as:</p><ul><li>SAP Note 1298160 for vulnerabilities in TTMS_CI_START_SERVICE;</li><li>SAP Note 1330776 for vulnerabilities in EPS_DELETE_FILE and EPS_OPEN_FILE2.</li></ul><p><b><i>[EASAI-NA-07] Default password check for the EARLYWATCH user</i></b></p><p><b><i>Description</i></b></p><p>The EarlyWatch user is created in the <b>066</b> 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<b>EarlyWatch</b> user, but <b>never delete the user</b>.</p><p><b><i>Threats</i></b></p><p><b>EarlyWatch</b> user’s default password is well-known (see the table above). With this password, an adversary can enter the system using the <b>S_TOOLS_EX_A</b> 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 <b>SE37</b> (function modules execution) and <b>SE38</b> (running reports). In the new versions, it has fewer privileges, but it can exploit some vulnerabilities, such as the<b>TH_GREP</b> call with the <b>SM51</b> transaction and, consequently, execute arbitrary OS commands.</p><p><b><i>Solution</i></b></p><p><b>Warning!</b>Do not remove Earlywatch user or its profile!</p><ul><li>Lock out <b>EARLYWATCH</b> user. Unlock if necessary only;</li><li>Change the default password for the <b>EARLYWATCH</b> user;</li><li>Ensure that this user belongs to the <b>SUPER</b> group in all clients so that to be certain that only authorized administrators have the right to change this user’s account;</li><li>Perform regular checks of your clients to eliminate the risk of illicit clients’ access to the system.</li></ul><p></p><p>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.</p><p></p><p><span>(Read more: </span><b><a href="http://www.cisoplatform.com/profiles/blogs/shellshock-bug-a-quick-primer">Shellshock Bug: A Quick Primer</a>)</b></p></div>SAP NetWeaver ABAP Security Configuration Part 4: Open remote management interfaceshttps://www.cisoplatform.com/profiles/blogs/sap-netweaver-abap-security-configuration-part-5-open-remote2015-03-26T09:30:00.000Z2015-03-26T09:30:00.000ZAlexander Polyakovhttps://www.cisoplatform.com/members/AlexanderPolyakov743<div><p>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. <br /> <span id="more-5362"></span></p><p>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. <br /> 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. <br /> So, this section contains information about the most insecure services. Their settings should by no means be accessible via the corporate intranet.</p><p><b><i><u>Further steps</u></i></b></p><p><i>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 <a href="http://wiki.scn.sap.com/wiki/display/TCPIP/Home+of+TCP-IP+Ports">[1]</a>. The list’s content depends on the installed components of each particular system. <br /> 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.</i></p><p><i><b>[EASAI-NA-11] Unauthorized access to the SAPControl (SAP MMC) service functions</b></i></p><p><i><b>Description</b></i></p><p><i>The SAP Start Service</i> starts on each computer simultaneously with the SAP solution instance. In Windows, this process is executed with <b>sapstartsrv.exe</b>, in UNIX - with <b>sapstartsrv</b>. The SAP Start Service provides the following functions for the SAP solution, instance and process monitoring:</p><ul><li>start and stop;</li><li>monitoring the active state;</li><li>reading logs, trace files and configuration files;</li><li>technical information, for example, on network ports, active sessions, etc.</li></ul><p></p><p>These services are accessible via the <i>SAPControl SOAP Web Service</i> and are used by the SAP monitoring tools (<i>SAP Management Console, NetWeaver Administrator </i>and others). When service starts, it uses the following ports:</p><ul><li>HTTP port <b>5<xx>13</b> (or <b>sapctrl<txx></b> in <b>/etc/services</b>), where <xx> is the instance number;</li><li>HTTPS port <b>5<xx>14</b> (or <b>sapctrls<xx></b> in <b>/etc/services</b>), where <xx> is the instance number.</li></ul><p></p><p>For example, when service starts, either the HTTP port 50013 or the HTTPS port 50014 is used for the instance 00. <a href="http://help.sap.com/saphelp_nw73ehp1/helpdata/en/b3/903925c34a45e28a2861b59c3c5623/content.htm">[2]</a>. 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. <i>Startsrv</i> 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 <b>service/protectedwebmethods</b> parameter.</p><p><b><i>Threat</i></b></p><p>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.</p><p><b><i>Solution</i></b></p><p>In accordance with SAP Note 1600846, <i>sapstartsrv</i> settings must be reconfigured. To do this, you need to set the parameter<b>service/protectedwebmethods</b> to <b><i>DEFAULT</i></b> in a default system profile (<b>DEFAULT.PFL</b>). To apply the changes, restart all <i>sapstartsrv</i>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 <i>ALL</i> (i.e. all methods), though it is considered excessive). <br /> 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 <b>services/http/acl_file</b> and <b>/https/acl_file.</b></p><p><i><b>[EASAI-NA-12] Unauthorized access to the SAPHostControl service functions</b></i></p><p><b><i>Description</i></b></p><p>The <i>SAP Host Agent</i> is a component designated for other components management, their control and monitoring. It consists of the following services and programs:</p><ul><li>The <i>SAPHostExec</i> is a control program that runs under <i>root</i> (UNIX) or <i>LocalSystem</i> (Windows) accounts. It controls all the functions called for by the specific users of this type, such as <b>saposcol</b> and <b>sapacosprep</b> OS collectors. The program is connected with the<i>sapstartsrv</i> 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.</li><li><i>DB4STATS</i> and <i>SAPILED</i> are the programs that supply IBM I with the <i>SAP Database Performance Collector</i> and the <i>SAP ILE daemon</i>respectively.</li><li><i>The SAPHostControl</i> (<i>sapstartsrv</i> in the host mode) is the SAP NetWeaver management agent. It is an executable of <i>sapstartsrv</i> 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.</li></ul><p><br /> <img src="http://erpscan.com/wp-content/uploads/2014/12/for_blog_entry_4.png" alt="for_blog_entry_4.png" /></p><p>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 <b>SAPSystem = 99, SAPSystemName = SAP</b>). <a href="http://help.sap.com/saphelp_nw70ehp3/helpdata/en/a9/02f459814347619d80560e65a7f7d5/content.htm">[6]</a> <br /> For data transmission, the <i>SOAP</i> 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.</p><p><i><b>Threat</b></i></p><p>An authorized adversary can run any random code, caused by the <i>SAPHostControl</i> 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. <br /> 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. This data can be used to implement more critical attacks.</p><p><i><b>Solution</b></i></p><p>Remote execution of random code vulnerability was fixed in May 2012 . <br /> SAP Security Note 1816536 released in April 2012 prevents information disclosure. Resulting from this, it’s sufficient to apply both of these security updates to fix vulnerabilities. <br /> 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.</p><p><i><b>[EASAI-NA-13] Unauthorized access to the Message Server service functions</b></i></p><p><i><b>Description</b></i></p><p>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. <br /> 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. <br /> In order to control the list of addresses one can connect to the Message Server with, you need to activate the <i>Access Control List (ACL)</i>. To do this, use <b>ms/acl_info</b> 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 <b>/usr/sap/<SID>/SYS/global/ms_acl_info</b>.</p><p><b><i>Threat</i></b></p><p>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.</p><p><b><i>Solution</i></b></p><p>It is essential to configure <b>ms/acl_info</b> parameter. It indicates the ACL file that has an authorized access to the Message Server. (default value: <b>/usr/sap/<SID>/SYS/global/ms_acl_info</b>). 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:<br /> <b>HOST = [*| ip | hostname | network mask | domain ] [, ...]</b><br /> Configuration file accepts the "*" wildcard in access control description (e.g., <b>HOST = *.sap.com</b> or <b>HOST = 157.23.45.*</b>). The "*" wildcard should be avoided, especially when in the <b>HOST = *</b> form, as it makes access from any workstation possible. <br /> Access control settings do not affect the retrieval of technical information from the Message Server. It remains always accessible. <br /> As an alternative to ACL file configuration we suggest the following options:</p><ul><li>In 4.5 and lower releases, Message Server port defined by <b>rdisp/mshost</b> and <b>rdisp/msserv</b> parameters should be blocked by the firewall. Only those network segments with SAP servers should be granted access to this port.</li><li>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 (<b>rdisp/msserv</b>), the other one - to access internal connections with the server (<b>rdisp/msserv_internal</b>).</li></ul><p></p><p><i><b>[EASAI-NA-14] Unauthorized access to the Oracle DBMS</b></i></p><p><i><b>Description</b></i></p><p>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 <b>REMOTE_OS_AUTHENT</b> settings. REMOTE_OS_AUTHENT ensures execution of trusted operations between various SAP solutions. <br /> 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.<br /> This setting is implemented by means of the <b>Sqlnet.ora</b> configuration file. In particular, it has to do with <b>tcp.validnode_checking</b>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 <b>TCP.INVITED_NODES</b> or<b>TCP.EXCLUDED_NODE</b>. Note that, the first one is of higher priority. <br /> <b>TCP.INVITED_NODES</b>, in turn, requires each client host to be included in the <b>sqlnet.invited_nodes</b> server list.</p><p><b><i>Threat</i></b></p><p>If restrictions for client nodes are not set, an attacker can connect to the Oracle DBMS without password, using a trusted login<b>$OPS<SID>adm</b>. Thus, the attacker will get almost unlimited access to the DBMS.<br /> Next step is to decrypt <b>SAPR3</b> user password. One can take it from the <b>SAPUSER</b> 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.</p><p><b><i>Solution</i></b></p><p>Set the <b>tcp.validnode_checking</b> parameter in the <b>sqlnet.ora</b> file to “ <b>yes</b>. This way it’s possible to check whether there are inbound connections coming from the permitted nodes listed in <b>sqlnet.invited_nodes</b>.<br /> 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.</p></div>SAP NetWeaver ABAP Security Configuration Part 5: Insecure Settingshttps://www.cisoplatform.com/profiles/blogs/sap-netweaver-abap-security-configuration-part-6-insecure2015-04-02T14:30:00.000Z2015-04-02T14:30:00.000ZAlexander Polyakovhttps://www.cisoplatform.com/members/AlexanderPolyakov743<div><p>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.<br /> <span id="more-7583"></span></p><p><em><strong>[EASAI-NA-15] Minimal password length</strong></em></p><p><em><strong>Description</strong></em></p><p>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, <strong>login/min_password_lng</strong> is the main one. It specifies the allowed minimal password length. This parameter’s default value is <strong>6</strong>, although its acceptable to use values ranging from <strong>3</strong> to <strong>40</strong>.</p><p><em><strong>Threat</strong></em></p><p>In case the minimum password length is set to <strong>less than 8</strong> symbols, an adversary can easily decrypt a password using <strong>USR02</strong> table hash. Alternatively, one can gain access remotely by bruteforcing the password, if the <strong>login/fails_to_user_lock</strong> 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.</p><p><em><strong>Solution</strong></em></p><p>Set the <strong>login/min_password_lng</strong> parameter value for <strong>more than 8</strong>, otherwise choose the value which is in accordance with the company’s security polity. This way, you can lessen the risk of potential attack.</p><p><em><strong>[EASAI-NA-16] Number of invalid logon attempts before the user account lock out</strong></em></p><p><em><strong>Description</strong></em></p><p>The <strong>login/fails_to_user_lock</strong> 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 <strong>login/min_password_lng</strong> parameter. The<strong>login/min_password_lng</strong> parameter, in turn, defines the minimum password length, and thus, prevents remote password bruteforcing. This parameter’s default value is <strong>5</strong>, although it’s acceptable to set values ranging from <strong>1 to 99</strong>.</p><p><em><strong>Threat</strong></em></p><p>If the <strong>login/fails_to_user_lock</strong> 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.</p><p><em><strong>Solution</strong></em></p><p>Set the <strong>login/fails_to_user_lock</strong> parameter value for not <strong>more than 6</strong>. This way, you’ll lessen the risk of potential brute force attack.</p><p><em><strong>[EASAI-NA-17] Password compliance with the security policies in place</strong></em></p><p><em><strong>Description</strong></em></p><p>The <strong>login/password_compliance_to_current_policy</strong> parameter is highly important. If this parameter is absent or or is set to <strong>0</strong>,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.<br /> If this parameter is set to <strong>1</strong>, the settings would affect old users with insecure passwords and force them to choose secure ones upon their logging into the system.</p><p><em><strong>Threat</strong></em></p><p>If the <strong>login/password_compliance_to_current_policy</strong> parameter is set to <strong>0</strong>, 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.</p><p><em><strong>Solution</strong></em></p><p>Set the <strong>login/compliance_to_current_policy</strong> parameter to <strong>1</strong> to apply the password policy requirements for all users, including those newly created.</p><p><em><strong>[EASAI-NA-18] Access control settings for RFC-service (reginfo.dat)</strong></em></p><p><em><strong>Description</strong></em></p><p>The <strong>SAP Gateway</strong> 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 <strong>reginfo</strong> and the<strong>sec_info</strong> files. The <strong>reginfo</strong> file is defined by the <strong>gw/reg_info</strong> parameter and the <strong>sec_info</strong> file is defined by the <strong>gw/sec_info</strong>parameter. <br /> 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: <strong>/usr/sap/<SID>/<INSTANCE>/data/reginfo.</strong> <br /> 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 <strong>gw/acl_mode</strong> instance profile parameter. For further references, see SAP Security Note 1480644 . However, if this file exists but it is empty or has no valid records, it is not allowed to register. <br /> 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 <strong>reginfo</strong> file can be read only ONCE, when a program is being registered. All the further changes and restrictions in the <strong>reginfo</strong> file do not affect successfully registered programs.</p><p><em><strong>Threat</strong></em></p><p>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.</p><p><em><strong>Solution</strong></em></p><p>Unauthorized service registration may be avoided by means of creating a <strong>reginfo.dat</strong> 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. <br /> File records should have the following syntax (note that each line must have TP record, all the other parameters are optional): <br /> <strong>TP=name [NO=<n>] [HOST=<host>] [ACCESS=<host>] [CANCEL=<host>]</strong>, where: <br /> <strong>TP=name</strong> is a registration ID of the external server program. <br /> <strong>NO=n</strong> shows what number of registrations with that ID is allowed. <br /> <strong>HOST=<host></strong> 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. <br /> <strong>ACCESS=<host></strong> 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. <br /> <strong>CANCEL=<host></strong> is(are) (a) host name(s) that allow(s) to log off the registered system server. The same rules are applied as has the<strong>ACCESS</strong> parameter. <br /> 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 <strong>P</strong> and <strong>D</strong> respectively (see SAP Security Note 1105897 ). <strong>P</strong> means that a program is allowed to be registered, (as in the old syntax line); <strong>D</strong> prevents registration. The first line layout in such file is<strong>#VERSION=2</strong>. All the next lines are structured the following way: <strong>P|D TP=name [NO=<n>] [HOST=<host>] [ACCESS=<host>] [CANCEL=<host>]</strong> <br /> <strong>Warning!</strong> The system reads key words only if they are written in upper-case letters. Incorrect specification leads to <strong>HOST=*</strong> wildcard value, which would probably be undesired (there are instructions on how to fix it in SAP Security Note 1473017). <br /> In all the host names’ lists (<strong>HOST, ACCESS</strong> and <strong>CANCEL</strong>), key words must be separated by commas. Any space would indicate the end of host names’ list. <br /> You can find detailed syntax review in SAP Security Note 1069911 . <br /> For the correct <strong>reginfo.dat</strong> configuration use recommendations from SAP Security Note 1425765 and 1408081.</p><p><em><strong>[EASAI-NA-19] Access control settings for RFC-service (secinfo.dat)</strong></em></p><p><em><strong>Description</strong></em></p><p>In the <strong>secinfo</strong> 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<strong>RegInfo</strong> file. In other words, secinfo security file is used to prevent unsanctioned start of an external program. File name is defined by the parameter <strong>gw/sec_info</strong>. Default file path is: <strong>/usr/sap/<SID>/<INSTANCE>/data/secinfo</strong>. <br /> 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. <br /> 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.</p><p><em><strong>Threat</strong></em></p><p>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.</p><p><em><strong>Solution</strong></em></p><p>You should create <strong>secinfo.dat</strong> 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. <br /> File records should have the following syntax ( <strong>USER, HOST</strong> and <strong>TP</strong> lines are obligatory, and other parameters in each line are optional): <br /> <strong>TP=name HOST=<host> USER=<user> [USER-HOST=<user-host>]</strong>, where: <br /> <strong>TP=<program name></strong> is the name of a program, you would like to run (in addition, you can specify a wildcard for program ID, e.g.,<strong>TP=XYZ*</strong>) <br /> <strong>HOST=<host></strong> - name of the host where you would like to run a program. It defines destination address. Note the following difference: in the <strong>reg_info</strong> 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. <br /> <strong>USER=<user></strong> 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. <br /> <strong>USER-HOST=<host> </strong>(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 ). <br /> In 6.40 and lower versions, <strong>PWD=<Password></strong> parameter was supported (ignored in newer systems). <br /> In 6.40, patch 212; 7.00, patch 139; 7.10, patch 80, and higher kernel versions, there appeared additional <strong>permit</strong> and <strong>deny</strong> values indicated by the Latin upper-case <strong>P</strong> and <strong>D</strong> respectively (see SAP Security Note 1105897 ). <strong>P</strong> permits to run the program (the same as the old syntax line); <strong>D</strong> denies it. The syntax of the first line in such file is <strong>#VERSION=2</strong>, and that of all posterior lines is:<br /> <strong>P|D TP=<tp> HOST=<host> USER=<user> [USER-HOST=<userhost>]</strong> <br /> <strong>Warning</strong>: the system reads key words in the upper-case only. Incorrect specification leads to the <strong>HOST=*</strong> wildcard value, which is undesired. (there are guidelines on how to fix it in the SAP Security Note 1473017). <br /> For detailed explanation of this syntax check out the SAP Security Note 614971 . <br /> For the correct <strong>secinfo.dat</strong> configuration refer to SAP Security Notes 1408081, 1525125, 1425765.<a href="https://service.sap.com/sap/support/notes/1425765"><br /></a></p><p><em><strong>Further steps.</strong></em></p><p>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.</p></div>Securing SAP Systems from XSS vulnerabilities Part 2: Defense for SAP NetWeaver ABAPhttps://www.cisoplatform.com/profiles/blogs/securing-sap-systems-from-xss-vulnerabilities-part-2-defense-for2015-08-25T12:16:55.000Z2015-08-25T12:16:55.000ZAlexander Polyakovhttps://www.cisoplatform.com/members/AlexanderPolyakov743<div><p style="text-align:justify;">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.</p><h2>From the developer’s perspective</h2><p style="text-align:justify;">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:</p><ul><li>ABAP built-in function ESCAPE (available as of SAP_BASIS >= 731);</li><li>Class implementation in CL_ABAP_DYN_PRG.</li></ul><p style="text-align:justify;">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.</p><table><tbody><tr><td>HTML / XML</td><td>out = escape(val = val format = cl_abap_format=>e_xss_ml).</td></tr><tr><td>JavaScript</td><td>out = escape(val = val format = cl_abap_format=>e_xss_js)</td></tr><tr><td>URL</td><td>out = escape(val = val format = cl_abap_format=>e_xss_url)</td></tr><tr><td>CSS</td><td>out = escape(val = val format = cl_abap_format=>e_xss_css)</td></tr></tbody></table><p style="text-align:justify;">For lower releases (SAP_BASIS 702, 720 and below), there is an ABAP OO implementation. The implementation is in class CL_ABAP_DYN_PRG.</p><table><tbody><tr><td>Context</td><td>Method</td></tr><tr><td>HTML / XML</td><td>out = CL_ABAP_DYN_PRG=>ESCAPE_XSS_XML_HTML(val)</td></tr><tr><td>JavaScript</td><td>out = CL_ABAP_DYN_PRG=>ESCAPE_XSS_JAVASCRIPT(val)</td></tr><tr><td>URL</td><td>out = CL_ABAP_DYN_PRG=>ESCAPE_XSS_URL(val)</td></tr><tr><td>CSS</td><td>out = CL_ABAP_DYN_PRG=>ESCAPE_XSS_CSS(val)</td></tr></tbody></table><p style="text-align:justify;">For more information about the delivery of these extensions, see SAP Security Note 1582870 [<a href="http://service.sap.com/sap/support/notes/1582870">1</a>].</p><p><strong>For WebDynpro ABAP</strong></p><p style="text-align:justify;">For WebDynpro ABAP, you do not have to care about XSS at all. The security is ensured through the framework itself.</p><p><strong>For Business Server Pages (BSP)</strong></p><p style="text-align:justify;">For BSP, you should use the page directives. For more information, see SAP Security Note 1600317 [<a href="http://service.sap.com/sap/support/notes/1600317">2</a>] and SAP Security Note 1638779 [<a href="http://service.sap.com/sap/support/notes/1638779">3</a>]. These BSP page attributes have the advantage that the BSP framework ensures that the most secure version of encoding is used.</p><p style="text-align:justify;">For BSP, you should use the page directives: <%@page language=“abap“ forceEncode=“html|url|javascript|css“%></p><p style="text-align:justify;">After importing SAP Security Note 1600317 [<a href="http://service.sap.com/sap/support/notes/1600317">4</a>], the existing page directives also use the updated BSP compiler that supports HTML encoding of all print statements on the page.</p><p style="text-align:justify;">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.</p><p style="text-align:justify;">BSP example: <%@page language=“abap“ forceEncode=“html“%><br /> <html><body><form><br /> <% data: inputvalue type string.<br /> inputvalue = request->get_form_field( 'x' ).<br /> %><br /> <input type=text name=x value=“<%=inputvalue%>“><br /> <input type=submit><br /> </form></body></html></p><p style="text-align:justify;">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):</p><ul><li><%html=...%>: HTML encoding</li><li><%url=...%>: URL encoding for parameter names or values of URLs</li><li><%javascript=...%>: JavaScript encoding</li><li><%css=…%> : CSS encoding</li><li><%raw=...%> (no encoding, that is, a global encoding that was set in the page directive is switched off)</li></ul><p style="text-align:justify;">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.</p><p><strong>For BSP Online Text Repository (OTR)</strong></p><p style="text-align:justify;">One aspect that is similar to an XSS attack is a translation-related change that breaks the HTML or JavaScript code.</p><p style="text-align:justify;">Example:<br /> <script><br /> var msg = '<otr>Hello</otr>';<br /> </script><br /> <input name=xyz value=“<otr>Replace 'dog' with<br /> 'cat'</otr>“></p><p style="text-align:justify;">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.</p><p style="text-align:justify;">For BSP ORT, you should use the page directives:<br /> <%@page language=“abap“<br /> forceEncodeOtr=“html|javascript“%></p><p>HTML example<br /> <%@page language=“abap“ forceEncodeOtr=“html“%><br /> <script> var msg =<br /> '<otr>Hello</otr>';<br /> alert(msg);<br /> </script></p><p style="text-align:justify;"></p><p>JavaScript example:<br /> <%@page language=“abap“ forceEncodeOtr=“html“%><br /> <script><br /> var msg = '<%JavaScript=<otr>Hello</otr>%>';<br /> alert(msg);<br /> </script></p><p><strong>For BSP Extensions</strong></p><p style="text-align:justify;">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:<br /> <htmlb:content forceEncode=“ENABLED|BACKWARDS_COMPATIBLE“></p><ul><li>ENABLED: This means to always encode everything. This overwrites all other encode attributes and they no longer have to be set;</li><li>BACKWARDS_COMPATIBLE: This is the default value. The usual encode attributes are active as previously defined.</li></ul><p style="text-align:justify;">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“></p><p style="text-align:justify;">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.</p><p><strong>Mixed BSP page with HTML and HTMLB tags</strong></p><p style="text-align:justify;">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.<br /> <%@page language=“abap“ forceEncode=“html“%><br /> ...<br /> <htmlb:content forceEncode=“ENABLED“><br /> ...<br /> <htmlb:textView text=“<%=param%>“/> (1)<br /> <%=param%> (2)<br /> ...<br /> </htmlb:content></p><p style="text-align:justify;">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.</p><p style="text-align:justify;">The BSP encoding directive <%url|html|javascript=...%> has no effect when passing values to attributes of extension tags and is simply ignored.</p><p style="text-align:justify;">In the following example, the directive to do HTML encoding is ignored, instead of the htmlb tag decides internally which encoding is appropriate.<br /> <htmlb:content forceEncode=“ENABLED“><br /> ...<br /> <htmlb:textView text=“<%html=param%>“/><br /> ...<br /> </htmlb:content></p><p><strong>For Internet Transaction Server (ITS) and HTML Business</strong></p><p style="text-align:justify;">For the Internet Transaction Server (ITS) and HTML Business, the following encoding functions are available:</p><ul><li>xss_url_escape()</li><li>xss_html_escape()</li><li>xss_wml_escape()</li><li>xss_css_escape()</li><li>xss_js_escape()</li></ul><p><strong>HTML Business</strong></p><p style="text-align:justify;">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:</p><ul><li>~auto_html_escaping=1: globally activates encoding</li><li>~new_xss_functions=1: globally activates the use of the updated XSS library</li></ul><p style="text-align:justify;">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.</p><p style="text-align:justify;">Where and how these parameters are specified depends on the SAP_BASIS release:</p><ul><li>For the external ITS (Release <= 6.40), maintain them in the properties of the Internet Service in SE80.</li><li>For the internal ITS (Release >= 6.40), maintain them in the GUI properties in transaction SICF as follows:<ul><li>Release 6.40-7.11: ~auto_html_escaping=1 and</li><li>~new_xss_functions=1 o Release >=7.20: ~auto_html_escaping=1</li></ul></li></ul><p style="text-align:justify;">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.</p><p style="text-align:justify;">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 [<a href="http://service.sap.com/sap/support/notes/1488500">5</a>].</p><p><strong>For Business HTML (BHTML)</strong></p><p style="text-align:justify;">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 [<a href="http://service.sap.com/sap/support/notes/916255">6</a>].</p><p><strong>For Manual Encoding</strong></p><p style="text-align:justify;">You can also manually encode output by using the functions named above. In this case, encode all output.</p><h2>From the administrator’s perspective</h2><p style="text-align:justify;">The administrator has to set the parameters to improve security:</p><ul><li><b>http/security_session_timeout = 900;</b> Enable session timeout to minimize potential attack window.</li><li><b>icf/set_HTTPonly_flag_on_cookies = 0;</b> 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.</li></ul><p style="text-align:justify;">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.</p><h2>From incident response perspective</h2><p style="text-align:justify;">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.</p><ul><li>Configure icm/HTTP/logging_0 parameter<ul><li>set LOGFILE value to path_to_file</li><li>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.</li><li>Set FILEWRAP value to off. Old log files will be saved for future analysis</li></ul></li><li>Configure icm/security_log parameter, o set LOGFILE value to path_to_file<ul><li>set VERBOSITY value to 3. To be able to save all necessary data in</li><li>Set FILEWRAP value to off. Old log files will be saved for future analysis</li></ul></li></ul></div>SAP Security Notes September 2015https://www.cisoplatform.com/profiles/blogs/sap-security-notes-september-20152015-09-29T19:13:48.000Z2015-09-29T19:13:48.000ZAlexander Polyakovhttps://www.cisoplatform.com/members/AlexanderPolyakov743<div><p><a target="_blank" href="http://www.sap.com/">SAP</a> has released the <a target="_blank" href="http://scn.sap.com/community/security/blog/2015/09/08/sap-security-patch-day--september-2015?">monthly critical patch update</a> for September 2015. This patch update closes 20 vulnerabilities and 5 updates in SAP products, 16 of which are high priority, some of them belong to the SAP HANA security area. The most common vulnerability is the Missing authorization check. This month, two critical vulnerabilities found by ERPScan researchers Vahagn Vardanyan, Roman Bejan were closed.</p><h2>About Missing authorization check</h2><p>Missing authorization check enables access to a service without any authorization and use service functionality that has restricted access. This can lead to information disclosure, privilege escalation and other attacks.</p><p>According to a research titled <a target="_blank" href="http://erpscan.com/wp-content/themes/supercms/Publications/3000-SAP-notes-Analysis-by-ERPScan.pdf">Analysis of 3000 vulnerabilities in SAP</a>, missing authorization is the second most common issue in all SAP products and constitutes about 20%. Slightly more than 700 of such vulnerabilities have been closed in different SAP products (662 in SAP NetWeaver ABAP) since 2001.</p><p><img width="700" alt="Most common SAP vulnerabilities" src="http://erpscan.com/wp-content/uploads/2015/09/SAP-vulnerabilities-by-type.png" /></p><h2>Issues that were patched with the help of ERPScan</h2><p>Below are the details of SAP vulnerabilities that were found by <a target="_blank" href="http://www.erpscan.com/">ERPScan</a> researchers.</p><ul><li>An SQL-injection vulnerability in SAP Batch Processing (CVSS Base Score: <font color="#FF0000">4.6</font>). Update is available in SAP Security Note <a target="_blank" href="https://service.sap.com/sap/support/notes/2193389">2193389</a>. An attacker can use SQL-injection vulnerability with a help of specially crafted SQL-queries. He can read and modify sensitive information from a database, execute administration operations on a database, destroy data or make it unavailable. Also in some cases an attacker can access system data or execute OS commands.</li><li>A Cross-site scripting vulnerability in SAP Java Monitoring (CVSS Base Score: <font color="#FF0000">4.3</font>). Update is available in SAP Security Note <a href="https://service.sap.com/sap/support/notes/2176785">2176785</a>. An attacker can use Cross-site scripting vulnerability for injecting a malicious script into a page. Reflected XSS feature is necessity of tricking a user from an attackers' side - he must lead user to a specially crafted link. As for stored XSS, malicious script is injected and permanently stored in a page body, this way user is attacked without performing any actions. The malicious script can access to all cookies, session tokens and other critical information stored by browser and used for interaction with a site. An attacker can gain access to user's session and learn business-critical information, in some cases it is possible to achieve control over this information. Also XSS can be used for unauthorized modification of displayed site content.</li></ul><h2>The most critical issues found by other researchers</h2><p>Some of our readers and clients asked us to categorize the most critical SAP vulnerabilities to patch them first. Companies providing SAP Security Audit, SAP Security Assessment, or SAP Penetration Testing services can include these vulnerabilities in their checklists. The most critical vulnerabilities of this update can be patched by the following SAP Security Notes:</p><ul><li><a target="_blank" href="https://service.sap.com/sap/support/notes/2197397">2197397</a>: SAP HANA Extended Application Services (XS) has a Buffer overflow vulnerability (CVSS Base Score: <font color="#FF0000">9.3</font>). An attacker can use Buffer overflow vulnerability for injecting specially crafted code into a working memory which will be executed by vulnerable application. Executed commands will run with same privileges of a service that executed a command. This can lead to taking complete control of an application, denial of service, command execution and other attacks. In case of command execution, attacker can obtain critical technical and business-related information stored in a vulnerable SAP-system or use it for privilege escalation. Speaking about denial of service, terminating a process of vulnerable component is possible. For this time nobody can use this service, this fact negatively impacts business processes, system downtime and business reputation as result. It is recommended to install this SAP Security Note to prevent risks.</li><li><a target="_blank" href="https://service.sap.com/sap/support/notes/2197100">2197100</a>: SAP function module SCTC_REFRESH_EXPORT_USR_CLNT has an OS command execution vulnerability (CVSS Base Score: <font color="#FF0000">7.1</font>). An attacker can use OS command execution vulnerability for unauthorized execution of operating system commands. Executed commands will run with same privileges of a service that executed a command. An attacker can access arbitrary files and directories located in an SAP-server filesystem including application source code, configuration and critical system files. It allows to obtain critical technical and business-related information stored in a vulnerable SAP-system. It is recommended to install this SAP Security Note to prevent risks.</li><li><a target="_blank" href="https://service.sap.com/sap/support/notes/2200806">2200806</a>:SAP Foreign Trade has a Missing authorization check vulnerability (CVSS Base Score: <font color="#FF0000">6.0</font>). An attacker can use Missing authorization check vulnerability for access a service without any authorization procedures and use service functionality that has restricted access. This can also lead to information disclosure, privilege escalation and other attacks. It is recommended to install this SAP Security Note to prevent risks.</li></ul><p>It is highly recommended to patch all those SAP vulnerabilities to prevent business risks affecting your SAP systems.</p><p>SAP has traditionally thanked the security researchers from ERPScan for found vulnerabilities on their <a target="_blank" href="http://scn.sap.com/docs/DOC-8218">acknowledgment page</a>.</p><p>Advisories for those SAP vulnerabilities with technical details will be available in 3 months on <a>erpscan.com</a>. Exploits for the most critical vulnerabilities are already available in ERPScan Security Monitoring Suite.</p></div>