Skip to Content
Technical Articles
Author's profile photo Dmitry Gutsko

How SAP consulters bypass your security restrictions. Part3: Hidden SAP_ALL

Here’s another magic lesson. Today we will focus on the SAP_ALL profile. This profile contains all SAP authorizations (in ABAP systems), meaning that a user with the SAP_ALL profile can perform any action in the system. That’s why SAP doesn’t recommend assigning any of your users this system profile. Everyone knows this rule. Any SAP Security Audit includes such check (identification of users with the SAP_ALL profile). But the SAP_ALL profile is still desired by many including SAP consulters. With such unlimited privileges, anyone will be able to do anything. Now they won’t waste their time on tracking privileges or requesting new changes in roles. They will be able to complete any project on time.

So how can SAP consulters hide the SAP_ALL profile assignment and not be detected by the security team? I ‘ve seen two options in my many years of practice. The easiest way is to copy the SAP_ALL profile authorizations to a role with a simple title. That’s more suitable for the BASIS team because only they have proper authorizations for role modification. You may do it right in the PFCG transaction. Then you just need to transport the role to the production and assign it to any user.

The second option is more powerful. It requires a bit more knowledge about SAP systems. As you know, almost all information in SAP is stored in database tables. Information about what privileges are assigned to a user is no exception, it is also located in the database. To escalate your privileges in SAP you just need to know which table to insert new records into. The USRBF2 table is the right place. Unfortunately, the SAP_ALL profile incorporates a lot of SAP authorizations (more than 1000). And you need to insert each authorization into the USRBF2 table to make it work. You may copy the list of specific SAP_ALL authorizations from other assignments in the USRBF2 table (find a user who has already been assigned the SAP_ALL profile).

Of course there are many ways to correct rows in the table. The easiest option is to write a custom Z ABAP code that will do all the work for you. Also the ABAP code without embedded authority checks can be executed by any user. The backdoor could be written in temporary area ($TMP), no need to insert it into a transport request. The version control is disabled for temporary area (such option will be very interesting for backdoor writers). Thus anyone who has developer rights in SAP system will be able to assign the SAP_ALL profile to any user in the system. So that’s why you need to pay special attention to control in development systems. Actually the backdoor will be able to clean all inserts in 10 minute for instance – be prepared for this scenario. And of course no CUA restrictions will stop you from directly modifying tables in child systems. The USRBF2 modification will be still worked.

This idea can be used in a slightly different way. For instance, a malicious user can insert not SAP_ALL authorizations but authorizations of any powerful role in the system. It will be more difficult to identify such cases.

Another option is to edit the USRBF2 manually and insert only needed SAP_ALL authorizations (like S_TCODE, S_DEVELOP, S_TABU_DIS). For example, using debug mode or SE16N_INTERFACE or SE16_EMERGENCY or another backdoor etc.

Now the most interesting, let’s go to the SUIM transaction (the RSUSR002 report or the S_BCE_68001395 transaction). Looking for users with the SAP_ALL profiles. So, here we don’t find users who used the previously discussed techniques to assign themselves the SAP_ALL profile. The explanation is trivial. In case 1 a user obtains privileges through a role (not through the SAP_ALL profile). In case 2 a user gets authorizations through inserts to the USRBF2 table, but SUIM analyzes completely different tables (the UST04 table).

Now about how not to be deceived.

SUIM USAGE:

Looking for roles which contain critical authorizations in the SUIM transaction (the RSUSR070 report, the S_BCE_68001423 transaction). At least I suggest the following options for searching:

Let me remind you that you can use no more than four filter options here. The fourth option you can set according to your opinion. Anyway we ‘ll find the powerful roles which can used instead of the SAP_ALL profile.

STATIC ABAP CODE ANALYSIS:

Looking for the USRBF2 table modifications in program source codes (by keyword USRBF2). Don’t forget to analyze the $TMP area as well. Identified cases of the system table modification should be properly analyzed. I suggest completely prohibit modifications of system tables USR* in custom ABAP code.

USER BEHAVIOR ANALYSIS:

The Idea is to log and analyze any access to information stored in the USRBF2 table via Security Audit Log. The Access to the table is logged with the following events: Transaction Start – DU9 –Generic table access call to &A with activity &B (auth. check: &C) or Report start – AUW – Report &A Started. Thus you may identify backdoor development process or backdoor usage when writer or user check whether their inserts were successful or not.

Enabling Table Change Logging in your SAP systems may be useful too (to analyze who and what inserted data into the USRBF2 table). The controls discussed in my previous post will also be effective here.

TABLE COMPARISON:

As described above usually backdoors insert data only into the single table ( the USRBF2 table), while classical way via SU01 produces inserts into many more tables (for instance the UST04 table). Therefor to find malicious inserts into the USRBF2 table we can compare values in both tables UST04 and USRBF2. The number of users to whom the SAP_ALL profile is assigned must be the identical.

To identify malicious inserts of role authorizations we should analyze values in the following tables: AGR_USERS, AGR_PROF, UST10S, USRBF2.

Previous post: How SAP consulters bypass your security restrictions. Part2: CALL TRANSACTION

Assigned Tags

      4 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Shahbaz Khan
      Shahbaz Khan

      Hi Dmitry,

      Really liked your article but one question here, if the production environment does not have dev keys enabled and developers from dev instance does not have similar access on production then the risk of this bypassing via ABAP code in tmp is mitigated. Can you confirm this?

      Also other thing, typically auditors are also checking who holds PFCG access and in case if any changes to authorization carried out through this way that will be tracked in RSUSR100N report which is any way be used by the auditor / security personnel to verify the same.

      Regards,

      Shahbaz

      Author's profile photo Dmitry Gutsko
      Dmitry Gutsko
      Blog Post Author

      No, you can transport the malicious code to production from other system in the same landscape. Or the developer key can be removed immediately after code modifications. The RSUSR100N report tracks only classical changes in SU01 or PFCG. The way mentioned in my post can’t be detected via The Change Documents Log.

      Author's profile photo Wilder Latino
      Wilder Latino

      You don't need developer key, you can bypass the developer key process. Also S/4 HANA does not require developer key. There is a misconception that developer key is what restricts a user from creating a program or other developer task. The authorization is the key specifically S_DEVELOP. Developer key is used for license reporting for SAP. You can even use SQ02 to code a little program to add SAP_ALL to the table mention in this topic and you would not even see the SAP_ALL profile in SU01; it would be invisible.

      Restrict S_DEVELOP carefully

      Lock TCODE SQ02, SU02.

      Monitor this table and turn on table change log for it.

      Author's profile photo Dmitry Gutsko
      Dmitry Gutsko
      Blog Post Author

      Thanks for the comment. Completely agree. I’m going to write about SQ02 in one of the following articles.