Over the past few weeks, we have looked at weak password hashes in SAP in quite some detail. Having previously already presented a conceivable scenario for exploiting such a vulnerability, as well as a guide to hacking weak password hashes and the measures to be taken to protect against it, in this blog post, we will be showing you how to use data analyses to detect potential fraud.
A combination of data analyses as the key to success
If you take a look at the scenario from the blog article “Shockheaded (Hash) Peter: If you play with fire,…” the experienced reader will notice a chain of unfortunate circumstances. On a case-by-case basis, the results of each data analysis may not seem so critical at first glance, but the combination of them put together should make you sit up and pay attention as an auditor. But let’s take things one step at a time. Before we really get to heart of the issue, let us first show you in detail what data analysis possibilities there are, in order to be able to illustrate the connection between them more clearly afterwards.
In the scenario described, Pjotr Melnikov takes advantage of the insufficient security of read accesses to SAP table USR02. Unfortunately, this fact is not reflected in any SAP table, since read-only accesses are documented in a log instead of a table. Log analysis is not, however, something that we are going to go into in great detail in this article. The use of the “SAP_ALL” profile thus serves as the first usable starting point. A list of all users with an SAP_ALL profile can be found in the SAP table “UST04”, or alternatively via the report “RSUSR002”. Either you filter directly to the critical profiles “SAP_ALL” or “SAP_NEW”, or, alternatively, you can also use the SQL Editor, e.g. using transaction “DB50” or “DBACOCKPIT”. You can then enter the following SQL command in the navigation menu on the left under “Diagnostics -> SQL Editor”:
SELECT * FROM UST04 WHERE PROFILE=’ SAP_ALL’ OR PROFILE=’ SAP_NEW’;
That’s all you need to do for the profiles with all rights for now. With the list, you can already go to your IT department and raise some critical questions about it. In this context, the audit guidelines for SAP ERP 6.0 from the German-speaking SAP user group, the DSAG, clearly state that you should completely avoid such profiles. In addition to the profiles mentioned above, there may also be other profiles with very extensive rights. However, this kind of analysis would be too far-reaching at this point.
Subsequently, Pjotr used a hacked SAP user to change vendor master data in SAP. In this context, two data analyses are useful for the purposes of detection. On the one hand, there is the avoidance of segregation of duty conflicts, which we have already described in the last article: setting up dual control (the four-eyes principle) for changes to master data and, on the other hand, there is the critical change to the vendor bank details. You can also just analyze changes to vendor master data, for example, without taking the segregation of duties into consideration.
However, it wouldn’t be SAP if we could write a blog post without a single catch. Changes are saved in the table “CDHDR” (change document header) with a few exceptions. Associated items can be found in the SAP table “CDPOS” (change document item). Up to a certain point, it is not even that difficult to evaluate the data manually.
Call transaction “SE16N” or “SE16” by specifying table “CDPOS”. For the table name fields, we use the SAP table “LFBK” (vendor master data – bank details) and the field name “KEY”. The corresponding settings will then look like this:
The field name “Key” may appear somewhat confusing at first. For readers with at least some rudimentary knowledge of database basics, it should, however, quickly become clear why this has to be the case: If a value is changed in SAP that is used in the corresponding table as a primary key or part of the primary key, only a change to the primary key is stored in the “CDPOS”. In short, a primary key is a value or a combination of values that are used to uniquely identify a data record (or more simply: a table row). In the figure above, the primary key of table “CDPOS” is marked in blue (blue letters). Accordingly, the primary key of “CDPOS” is made up of the following: client, change document object, object value, document number, table name, table key, field name and change indicator.
Unfortunately, the table “CDPOS” does not contain the user which made the change. You can find this by querying the identified document number from “CDPOS” in the table “CDHDR”. By following this approach, you can at least manually determine when and which user has changed bank data in the vendor master data. However, one-time changes can occur frequently, depending on the SAP system and the number of postings. For this reason, it is not advisable to examine each individual case one-by-one, as we have found a large number of false positives in various analysis projects. Several changes to the vendor bank details of a single vendor are particularly worth looking out for. These should be evaluated carefully and examined in further detail. Under certain circumstances, however, you may not find any particular abnormalities by following this approach. We will explain why this might happen in the next section.
Putting the puzzle together
Perhaps you will come to the conclusion that each examination should be assessed critically in its own right on an average basis and that every such audit is also very time-consuming and uses up resources. However, it is only when you put the findings and the respective context together in combination that the picture really starts to become clear. In order to be able to determine the context correctly, we use process mining methods. We use them for the automatic reconstruction of actual business processes and use the balancing mechanism in SAP for the fully automated generation of process sequences. On this basis, the findings made can take on a completely different meaning. Imagine that during the purchase order for steel, shortly before the receipt of goods for the purchase order, the vendor’s bank account details are changed and shortly after the settlement of the invoice, they are changed again – all within the same process sequence. What would you think about a process sequence like this in purchasing? And then, what’s more, you realize that a segregation of duties is missing in the sequence too and has been marked as a finding. Are the alarm bells starting to ring yet?
Notice the combination of findings and their context is a very good way to evaluate really critical process sequences / processes that never work as planned, either in real life, or in SAP. Forget the comparison of target and actual processes. These only match and result in a smooth process in perhaps 5% of cases.
The data indicators from zap Audit for the critical findings would therefore be:
| Name of the indicator | Description |
|---|---|
| Vendors with multiple bank account changes | FI document marked because it was processed between two changes to the bank account of a vendor used in the document. The two changes to the bank account were made within a time period of 7 days` maximum. |
| Segregation of Duties | Document marked due to a segregation of duties conflict with another document. |
| Operations done by super users | Document marked if it was booked by a user possessing standard SAP privileged access rights. |
With the beta update to the new version of zap Audit on 08/12/2017, we have also extended the indicator to the activities of superusers. In future, in addition to the pseudonymized user name, a reference to the password hash will be provided. This is divided into three levels ranging from weak (md5 hash) to medium (SHA-1 hash) and strong (iSSHA-1 hash). In this way, extremely critical superusers who also have very weak password hashes can be identified and checked even faster and more effectively.
