Are your System Users Vulnerable to SAP Hacks?
One of the most telling statistics revealed at BlackHat USA earlier this year was the fact that 84 percent of InfoSec professionals regard unmanaged privileged credentials as the biggest cyber security vulnerability within their organizations. For SAP environments, the dangers posed by abusing user accounts with privileged access are well-known and can include shutting down SAP servers to interrupt the availability of services, reading or modifying sensitive information, and performing unauthorized changes to system configurations, programs, users, and other areas. For this reason, privileged access is carefully granted and vigilantly monitored in most systems, especially productive systems. This includes privileges assigned through powerful authorization profiles such as SAP_ALL, SAP_NEW, S_ABAP_ALL and S_A.SYSTEM.
However, countermeasures to prevent abuses of privileged credentials in SAP systems are usually focused upon dialog users since interactive logon is not possible with most other user types. This includes system users that are used for background processing. Therefore, it’s common to find system users with privileged access in productive systems, especially when such users support several cross-system connections and integration scenarios.
The risks posed by system users with privileged credentials should not be overlooked and can be as grave as those posed by dialog users. Attackers are able to modify user types from system to dialog in several ways. The most common method is through the Function Builder used to build, test and manage function modules.
Attackers can access the Function Builder through transaction SE37 in a connecting system to execute the BAPI_USER_CHANGE remote-enabled function module (RFM). This RFM can be used to implement user changes in destination systems. The changes are applied using a privileged system user in the destination system. The credentials for such users are often stored in RFC destinations configured in connecting systems. The relevant RFC destination is entered in the field RFC target sys of the Function Builder (see below). The username of the system user configured for the RFC connection is entered in the USERNAME import parameter. Finally, the values of the LOGONDATA and LOGONDATAX are maintained to specify the dialog user type.
Once executed from the connecting system, BAPI_USER_CHANGE will change the system user to a dialog user type in the destination system through a remote function call. This will enable the attacker to logon to the destination system through methods such as the Remote Logon option in the RFC destination maintained in the connecting system (see below).
Since attackers can bypass the restrictions placed on system users by abusing the privileged credentials provided to such users, it stands to reason that super user privileges should be managed for all user types, not just dialog users. This should include minimizing privileges for technical system and communication users to the minimum required for each scenario. Trace tools such as STAUTHTRACE, STRFCTRACE and STUSOBTRACE can be used to identify the authorization objects required for each user. This should be supported by enabling switchable authorization checks for sensitive function modules such as BAPI_USER_CHANGE, BAPI_USER_CREATE1 and BAPI_USER_PROFILES_ASSIGN, and, in NetWeaver releases 7.4X, enabling Unified Connectivity (UCON) to restrict external access to remote-enabled function modules.
RFC destinations with stored logon credentials can be identified using the config store RFCDES_TYPE_3 in Configuration Validation (ConVal). RFC users with critical profiles such as SAP_ALL can be identified using the store RFCDES_TYPE_3_CHECK. See below.
