how - All Articles - CISO Platform2024-03-29T11:41:41Zhttps://www.cisoplatform.com/profiles/blogs/feed/tag/howSAP 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 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>End-to-End Encryption in Bluetooth Low Energy (BLE) IoT Networkshttps://www.cisoplatform.com/profiles/blogs/end-to-end-encryption-in-ble-iot-networks2017-02-18T10:00:00.000Z2017-02-18T10:00:00.000ZAmit Chaharhttps://www.cisoplatform.com/members/AmitChahar<div><p><strong><span class="font-size-4">Overview<br /></span></strong></p><p>With millions of Bluetooth Low Energy (BLE) IoT devices deployed per year, comes the responsibility to secure them. BLE was designed for low power personal area networks. Security was not a focus while designing it. But nowadays, BLE devices are an important part of IoT networks where these can be a matter of life and death.</p><p>There are two types of IoT architecture using BLE:</p><p>1. BLE device sends data to the gateway which is the user's app. The user can see this data and also this data is relayed to the cloud for storage. For example, fit-bit. This architecture can be shown as:</p><p></p><p>public cloud <--------> smartphone/app <-------------> BLE devices</p><p>|____________| |___________________|</p><p> Public network Private network</p><p></p><p>2. BLE device sends data to the gateway which in turn sends this data to the cloud. The user can access this information via an application. For e.g. home automation, medical components etc. A typical route from a BLE device to the user for this type of architecture can be shown like this:</p><p></p><p>app <----------> public cloud <--------> gateway <-------------> BLE devices</p><p> |_________________| |___________________|</p><p> Public network Private network</p><p> </p><p><strong><span class="font-size-4">Security</span></strong></p><p>Security has been a great concern for BLE devices in IoT networks because they are connected to public networks via gateways. The data to and from these devices can be modified and disrupted by hackers present in both public network and personal network. Even the devices itself can be controlled by hackers if security is not implemented properly. </p><p>With the introduction of new BLE 4.2, security is enhanced between the gateway and the BLE device using stronger encryption algorithms like Elliptic Curve Diffie-Hellman but the other components of the network can still be insecure. So, an end-to-end security approach is needed for this kind of IoT networks.</p><p><strong><span class="font-size-4">Vulnerabilities</span></strong></p><p>There are vulnerabilities on the private side of the network i.e. BLE sensors network. Even if the connection between the BLE device and the gateway is encrypted using LE secure connections available in BLE 4.2, the data is decrypted by the Bluetooth stack link layer on the gateway before sending it to the upper layers for processing. This decryption can be a point of vulnerability.</p><p>Also, the cloud is on public network which is exposed to hackers. There are many vulnerabilities in this type of structure. Hackers can get access into the cloud itself as evident by the Apple iCloud hack. If the data is sent to cloud via a unencrypted medium, it can be modified in between.</p><p><strong><span class="font-size-4">Protecting Data on Gateway</span></strong></p><p>The data sent from the BLE device, should not be decrypted on the gateway side because every decryption is a vulnerability. Unlike IP-based IoT networks, the data sent from the BLE device to the gateway is very small amount of data for e.g. various sensors in smart home systems. The data is sent from these sensors periodically in some KBs only. This data can be sent directly to cloud without any type of aggregation on the gateway.</p><p>In BLE 4.2, LE secure connections can be used to transfer packets securely from BLE device to the gateway. But when the gateway receives these packets, they are first decrypted at the link layer and then forwarded to upper layers. Now, these decrypted packets which have user data in plain text is a vulnerability too. If someone hacks into the gateway, then he can see all the sensor data in plaintext and can modify it before sending it to the cloud.</p><p>To counter this problem, one option can be to encrypt the user data on BLE device, send it to the gateway, gateway publishes this data directly to cloud and cloud has the key to decrypt this data. But this whole architecture needs a key management mechanism to be implemented by the application itself on the BLE device. Doing these kinds of operations on BLE device are difficult due to low processing, low storage, limited power etc..</p><p>This problem can be tackled by doing modifications in the Bluetooth stack on gateway side. Why not directly transfer the data from the physical layer of the Bluetooth stack directly to the cloud? Since the data coming from BLE devices is not a large amount of data, it can be transferred directly. The link layer and rest of the upper layers can be emulated on the cloud which processes the data coming from the gateway side. The data received from the gateway side is raw physical layer data. This solution can be called as a remote Bluetooth stack.</p><p>For this solution, customized Bluetooth chipset because vendors ship both physical layer and link layer along with the hardware.</p><p><strong><span class="font-size-4">Protecting Data on Cloud</span></strong></p><p>To protect the data on the cloud, the public cloud has to be replaced by a private cloud. But the problem comes is how this cloud would communicate securely with the gateway and the user? </p><p>To send data to and from the gateway and the cloud, a publish/subscribe service with end-to-end encryption can be used for e.g. Pubnub. This service will publish the data to the cloud. This service uses end-to-end encryption and also the data inside the encrypted message is also encrypted with Bluetooth LE security, thus providing a two-layer security.</p><p>Also, the user can access this data using same publish/subscribe service having end-to-end encryption. Thus, the cloud is not exposed to the public network. The new end-to-end encrypted secure architecture can be shown as:</p><p></p><p>User/app <----------> public cloud <--------> gateway <-------------> BLE devices</p><p> |______________________| |_______________________|</p><p> Private network Private network</p><p> </p><p> Secure BLE IoT network architecture</p><p></p><p><strong><span class="font-size-4">One step further</span></strong></p><p>One more step can be to keep all the key information on the user side instead of a cloud. Thus, mitigating any vulnerability on cloud side too. Only two entities will have the keys: BLE device and the user application. Thus, providing a complete end-to-end encryption architecture. </p><p><em><strong>Disclaimer: The material explained in this blog is patented by Wispero Networks Inc. which is working on IoT Security Management.</strong></em></p><p><em><strong>Author: Amit Chahar</strong></em></p><p><em><strong>Organization: Wispero Networks Inc. (<a href="http://wispero.com/">http://wispero.com/</a>)</strong></em></p><p><em><strong>Linkedin: <a href="https://in.linkedin.com/in/amit-chahar-15661689">https://in.linkedin.com/in/amit-chahar-15661689</a></strong></em></p></div>