Skip to content
An ancient SAP backdoor-security risk in SAP landscape

An Ancient SAP Backdoor: A Feature That Could Put Your SAP Landscape at Risk

SecurityBridge
August 27, 2024
4 min read
Chapters

Share Article

SAP Administrators are creatures of habit and often like to reuse passwords. I know, because I have been an SAP Administrator for a long time. 

When ‘easy’ and ‘fast access’ outweigh security, SAP administrators often choose to have the same SAP UID and password in every SAP system they access. This way, the password never has to be looked up and logging in is quick and easy.  

However, because more and more SAP customers are increasingly aware of password weaknesses, they are starting to enforce password policies.  

The policy might contain requirements like: 

  • the validity period of passwords in days (login/password_expiration_time) 
  • the number of historical passwords (chosen by the user, not the administrator) that the system stores and that the user is not permitted to use again (login/password_history_size) 
  • the number of days that a user must wait before changing the password again (login/password_change_waittime) 

SAP parameters like these are meant to prevent the reuse of passwords. Unfortunately, in SAP Managed Service Provider environments, for example, the sharing of SAP super users like DDIC and the reuse of passwords is still common. 

Given the existence of password policies, how is it still possible to circumvent these? 

The Backdoor

An answer is given by the ancient “OSS Note 1942 – How does R3trans work?”. With the transport tool R3trans, it is possible to export and import table data for example, an entry from table USR02 (User Master records).  

The user master record also contains the current password for a given SAP user, so when it is imported into an SAP system, the user master record contains the same password as it had when it was exported. 

When SAP passwords expire, it is easy to re-establish them again because it takes just one R3trans import command. 

The creation of a transport using TP with the relevant R3TR TABU entries will not work here because master data table entries of class A (tables USR02) will not be exported. 

But R3trans works! 

Locations

The possible locations of the files (import and export control files and *.dat files) used are /usr/sap/<SID>, /sapmnt/<SID>, or /usr/sap/trans and any of their subdirectories.  

A particularly good location for these is the /usr/sap/trans/tmp directory because only an SAP Administrator would occasionally look there. 

The other advantage of these *.dat files is that they are valid for most SAP systems. A user-master record exported from system A can be imported into system B, allowing a password reset. 

For the actual R3trans import, an external command or report RSBDCOS0 could be used, assuming the user has the appropriate privileges to execute it. 

New Super Users

It is also possible to create new super users by using an R3trans *.dat file that contains both USR02 (usr master record) and UST04 table entries (roles of a user). 

A malicious actor could prepare these files on their SAP system and, with access to the OS level, can gain quick access to the SAP application layer by creating a new SAP super user using R3trans. 

Advice for Mitigating this Risk

To keep SAP systems safe, SAP Customers need a Vulnerability Management process for hardening SAP environments from the applications layer down to the OS layer, including strict access controls. SecurityBridge offers a Security & Compliance solution that can execute thousands of security checks in complex and large SAP environments, present the findings clearly and offer mitigation and remediation advice based on SAP Best Practices. 

Experience how much easier SAP Platform Security becomes with SecurityBridge and discover how seamless it is to get started and work with it. Give us a tryFor more SAP security-related news, articles, and whitepapers, please follow us on LinkedIn!