Of course, we don’t want to leave you out in the cold after the scenario we described last week and the kind of heavy financial losses that can be occurred as a result. For this reason, in this blog post, we will describe how the SAP ICS can be used to take preventive action, or even better to ensure that weak password hashes do not occur in the first place.
General avoidance of weak password hashes in SAP
The simplest and probably most effective means of prevention is to deactivate the storage of weak password hashes in SAP. However, you should not simply go ahead and alter the following settings without due consideration, but should first clarify in advance whether certain dependencies exist that may require compatibility with legacy systems, meaning that the weak hashes are therefore required. We have already briefly outlined the procedure for doing this in one of our recent articles, so now we will provide some more detailed step-by-step instructions here, illustrated with some nice screenshots:
- After entering the logon information, first call the transaction RZ11 and maintain the profile parameter “login/password_downwards_compatibility”:
- After clicking on “Display”, the settings of the profile parameter are displayed:
A value of “1” is the default setting, which means that the old hash values (with MD5 and SHA1) are also calculated. If you change the value to “0”, the old hash values are no longer calculated and only the hitherto most secure password hash is calculated with the iSSHA1 algorithm. A small note at this point: The changes only take effect after a restart of the instance.
However, changing the profile parameter to “0” does not mean that you are on the safe side yet. The old hash values are still in the SAP system. Rest assured, though. There is also something we can do to remedy this situation. To do this, call the transaction SA38:
- Call SA38 to delete the old password hash (/n ends the current transaction), enter and start the program “CLEANUP_PASSWORD_HASH_VALUES”:
The story of the authorization object “S_TABU_DIS”.
Some of our more experienced readers might initially seek to restrict the authorization to read certain tables in SAP using SE16 using the SAP authorization object “S_TABU_DIS”. However, this is where I have to break the bad news to you, because this measure only addresses the very tip of the iceberg. Andreas Wiegenstein has written a more detailed blog article on the subject entitled “The truth about S_TABU_DIS” and, in it, he describes three different ways of accessing the database using ABAP in SAP:
- Open SQL
- EXECSQL
- ABAP Database Connectivity (ADBC)
If the database is accessed using one of the methods mentioned above, the authorization object “S_TABU_DIS” does not apply to any of the three procedures. Standard accesses via SAP, such as those made via the LogonPad, are excluded from this. It is only in such cases that the authorization object actually takes effect and prevents critical access to, for example, the SAP table USR02, assuming it has been configured correctly, that is.
We will not dive any deeper into the mysterious depths of authorization objects at this point. It is a very extensive area and one which easily justifies an article in its own right. But if you are encountering problems changing / creating authorization objects, stay tuned. We will be posting an appropriate article in due course.
Checking access to the USR02 table
For a variety of reasons, removing old password hashes may not be useful or desirable. In this case, it will be almost impossible to take preventive measures. If you have other experiences, or if you know some tricks from the big wide world of the SAP universe, we would be pleased to hear from you in a comment on this article below.
With the right preparation, you can, however, take some reactive precautions. In this context, though, data protection plays an extremely important role. Business transaction analysis, for example, is a possibility that is subject to the restriction that it only records the last two days in the SAP standard system. This type of analysis lists not only the transactions executed and access to tables, but also the corresponding user. Precisely for this reason, your company’s Works Council / Data Protection Department should also be involved. Transaction analysis can be called up easily using transaction code “STAD”. In addition to specifying the transaction “SE16” and the program for table USR02 “/1BCDWB/DBUSR02”, the read interval should be specified. The default settings of “00:10:00” means, for example, that only 10 minutes before and 10 minutes after the specified time are analyzed.
Read Access Logging can also be activated. The disadvantage of this option is the missing data from the past, because only read accesses are logged if logging is activated. In addition, Read Access Logging (RAL for short) has only been supported since Release 7.40 SP02. The detailed procedure for implementing Read Access Logging can be found using the example of table USR02 in English by clicking on the following link:
How to Configure Read Access Logging in SAP
Setting up the dual control (four-eyes principle) for changes to master data
In the scenario in the last blog article about Pjotr Melnikov entitled “Shockheaded (Hash) Peter: If you play with fire,…”, the accountant was able to take control of a user account with extensive “SAP_ALL” rights to change the master data for a vendor. Assuming that there is no dual control for master data changes in the company, the money could be diverted to the account of his straw man without further ado. The company had therefore failed to implement a functional separation of duties. To prevent this from happening to you, we will show you what you need to set up in SAP, for example, to have a second person approve the changes to bank details in the vendor master data. Of course, we do not want to have to have all amendments approved, so the asymmetric principle of dual control is used here. With the aid of this instrument, you can define individual data fields that require approval. In this scenario, this would be the bank code and account number, for example. For vendors / vendors, these values are in the LFBK table in the fields:
BANKL: Bank keys
BANKN: Bank account number
This would have enabled us to quickly and easily identify the sensitive data fields, enabling us to define the principle of asymmetric dual control for precisely these data fields. To do this, proceed as follows:
- Open Customizing in SAP with the transaction “SPRO” and navigate to:
Financial Accounting > Accounts Receivable and Accounts Payable > Vendor Accounts > Master Data > Preparations for Creating Vendor Master Data > Define Sensitive Fields for Dual Control (Vendors)
- Clicking on the clock with a green check mark takes you to the view: Change View “Sensitive Fields”: Overview
- Via the “New Entries” tab, insert the technical field names mentioned as shown in the screenshot, if they do not already exist.
As soon as you have clicked on the glasses with the pencil at the top of the screen, you have to confirm the transfer. But that’s not yet all. In addition, the roles must be adjusted so that there are users who can also approve changes. Otherwise, the vendors remain blocked after a change, which means that no more payments can be made to the relevant vendor. Using the program “RFKCON00”, which can be called up using transaction “SA38”, you obtain a list of all vendor master data that requires approval.
