Skip to Content

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:

  1. To cheat reports checking user authorizations, that can be done using nested profiles, reference users, roles, profile copies, etc.
  2. 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

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Martin English

    Hi Dmitry,

      I’m a little confused about the timeline and how long this vulnerability has been open. My reading of SAP note 1844202 is that the note was released on 11.06.2013, but the original problem was caused by SAP Security note 694250. Is this correct ?

    If so, SAP note 694250 was released 25.02.2004 which implies the vulnerability has been around for over 9 years !!


    (0) 
  2. Dmitry Gutsko Post author

    Hi,

    No, note 694250 is another probem with RSUSR002. Correction of note 694250 was released in 2004 and not patch new problem with RSUSR002 (note 1844202) discovered in 2013. 

    I think, note 1844202 isn’t last known problem with RSUSR002.

    (0) 

Leave a Reply