This one's a bad habit. Most common causes are:
- Project necessities not better detailed
- Scarse sensibility towards data security
- Scarse knowledge of potential problems of this action
Why should you remove these users, even non-interactive ones, ASAP? Let's see some examples!
Can it really be problematic?
Yes, and here is an example.
Two embedded systems DEV and PRD. An external user, for example, developer (MALLORY, read here to know who he is) accessed to the development system. Since he's a developer, he has a pretty large number of privileges in that system.
In the system the SAP TSM - Transport Management System) was configured. One of the targets from transaction SM59 (RFC destinations) is the one towards the production system (in the example TMSADM@PH8.DOMAIN_AH8).
This destination contains the SYSTEM type user TMSADM.
Wait a minute...an RFC destination from DEV to PRD with a set user? Yes, it's generated during the configuration of the SAP transport management system.
True, but the destination is towards client 000 of production, not the productive one.
Let's see how this situation can be a critical one to find yourself in.
- User MALLORY, formally authorized to access the development system now has access to transaction SM59.
- This allows him to see all RFC destinations present and defined in that system and with access to potentially other systems. Unfortunately, in that system exists an RFC destination that allows one to get to the PRD system, which is coincidentally destination TMSADM@PH8.DOMAIN_AH8
- MALLORY decides to write a program (function module) that, by recalling that RFC destination, makes it possible to reset DDIC user password in that system (or other users that might exist in that system)
- MALLORY can now access client 000 with the user DDIC
- Client 000 is not the productive one. Unfortunately, DDIC has SAP_ALL profile assigned. This makes it very easy to get all information from the productive client also.
How did MALLORY pull it off?
The first weakness is user TMSADM in client 000 with privileged permissions. This system user has SAP_ALL assigned.
As described in OSS note (2086984 - Removal of unnecessary rights from TMSADM and provision of maximal role for TMSADM) user TMSADM should only be authorized to change requests transport.
MALLORY writes an easy function module (using an ambiguous naming in this case - ZPOCREATE_RFC) which calls other user change functions towards the production system while still being in the development one
This allows MALLORY to change user DDIC's password (he could very well carry on other actions). This user also in the production system but still client 000.
Important: here the changes are registered from user TMSADM.
Once the password has been changed, MALLORY is ready to access:
Inside the production system (yet in the default client 000) it's still possible to access data, even from other clients.
With transaction SE16N it's possible to display table data in a cross-client way
See also OSS notes:
- 584434 - CO-OM tools: Special function SE16N
- 561756 - CO-OM tools: Adaptation SE16N to SE16
By exploiting the opportunity of accessing in DEBUG MALLORY manages to access data from the productive system
How do I protect my system from MALLORY?
- Never assign SAP_ALL profile, to any user
- Activate the security audit log on every client of the production system
- Do not define RFC destinations with valid or active users when possible
- Have SAP audits to validate DEBUG actions made in the systems, these are traced via SAP Audit Log
- Perform an authorization trace to understand what every system user needs.
Blog post originally translated from: https://www.aglea.com/blog/utenze-di-sistema-con-sap_all-no-grazie
