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
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
- SAP Managed Tags:
6 Comments
