SAP security research is one of my basic duties in Positive Technologies. Moreover, I had to think of what I would speak about to the participants of our PHDays III forum. Thus, I came to the following subject of research: how to hide a user with the SAP_ALL profile (i.e. all possible authorizations) in the system. If a malicious user manages to log in to the system and get the authorization to create users and assign privileges to them, then his next most probable step is to create a new account for himself, of course with all authorizations in the system. However, this user is listed in the results of internal checks and external audits, and there is zero chance that a user with SAP_ALL authorizations will not arouse any interest.
So, let’s start. I considered two vectors of my research:
- To cheat reports checking user authorizations, that can be done using nested profiles, reference users, roles, profile copies, etc.
- If you ask a SAP specialist how to list users having some particular authorizations, he will advise to use transaction SUIM, Report RSUSR002, which are almost the same. Therefore, we have the following idea: based on analysis of ABAP code of Report RSUSR002 you should create a mechanism to bypass the report algorithm and hide the user.
The first vector is covered in my presentation; the second one will be discussed below.
So, let’s have a look at the logics of the report. It is simple: you take the list of all user accounts and check each user for the given authorizations. If a user does not comply with the search criteria he is deleted from the list. It seems very simple but… the following line attracted our attention in the course of analysis:
A user with mysterious name ‘…………’ (12 dots) is removed from the list. Let’s check our assumption in practice. We will create a user with the name consisting of 12 dots, assign him different roles and profiles, and then check the report results. As we expected, there is no such username in the report results!
It is interesting, why this was implemented by the SAP vendor. Actually, I cannot answer this question. May be this user was created during generation of EARLYWATCH reports and served some particular purpose in the system?..
The following CVSS vector was formed for the vulnerability:
CVSS Base Score: 4.6
CVSS Base Vector: AV:N/AC:H/AU:S/C:P/I:P/A:P
As you can see, the severity level is not high, but it is distressing to know that the vendor of the system, where you store and process all your critical business data, has left such a back door which helps to conceal some specially crafted users. What was in fact the purpose of that?
Actually, the situation is not so bad. The patch fixing this vulnerability was released in June 2013: see SAP Note 1844202. To fix the bug you have to download the patch and implement it in your system.
As you can see from the table below, the correction was released for all existing SAP_BASIS components starting from Release 46B. In other words, if you have not updated your system yet, then this vulnerability will be for sure in your system.
That’s in fact all I wanted to tell. I recommend you to implement the Note which was initiated by your humble servant 🙂
SAP Security note 1844202: https://service.sap.com/sap/support/notes/1844202
Authors: Dmitry Gutsko, Positive Research