A popular SAP standard program that poses real security risks
Since as long as I can remember, SAP systems have contained the program RSBDCOS0. Most SAP Basis Administrators use this program regularly to quickly do or check something on the Operating System level of their SAP servers.
However, from a security point of view, SAP should have gotten rid of this program years ago. In fact, according to OSS Note 117657, SAP did try to get rid of it already back in 1999, but because so many customers wanted it back, SAP brought it back with some extra logging and tracing, so you can see in the SAP Syslog (SM21) and even in the OS log (/var/log/messages) which external commands have been executed.
Nevertheless, a minority of SAP customers will inspect the system log and trace files daily to check which operating system commands were executed by whom. To do this, you would ideally need a log analysis tool or a Threat Detection application that detects the execution of these commands in almost real-time.
The program RSBDCOS0 can be used to gain access to the <sid>adm user on the operating system level in various ways, for example by starting an X-term or copying its SSH certificate. Once logged into the OS as <sid>adm, the execution of OS commands would no longer be logged by the application layer. And not so long ago, when the <sid>adm was a trusted database user, you could log in as (Oracle) SYSDBA with it and download the hashes in the USR02 table, of which a large percentage could be cracked within some days.
Basically, when you have <sid>adm, you own the SAP system and can do whatever you want with it.
Cloud and shared responsibility
As SAP customers increasingly start moving their systems from on-premises to the cloud, security now becomes a shared responsibility between the SAP Customer organisation and the cloud service provider.
In this shared security model, the SAP Customer is responsible for the application layer, both parties are responsible for database management and the cloud service provider has responsibility for the operating system.
And in today’s context of ever-increasing cyber threats, new security models like Zero Trust start to appear:
“Zero Trust is a security concept centred on the belief that organizations should not automatically trust anything inside or outside its perimeters and instead must verify anything and everything trying to connect to its systems before granting access.”
Given the need for:
- a stricter security between application and operating system in the cloud context
- no more implicit trust for application users that want to execute commands as <sid>adm
My advice is to delete the SAP standard program RSBDCOS0 right now and again, after the new delivery in every upgrade. If you decide to keep it, be very careful in providing authorisation S_LOG_COM, which controls the right to execute OS commands.
SM49 & SM69
There are also the SM49 and SM69 transactions that facilitate the “controlled” execution of OS commands. Often these commands contain command shells and may facilitate command injection. Do not give away access to SM49 and SM69 lightly. When you don’t use external commands, restrict access to transactions SM49 and SM69 by locking these transactions.
Locking a transaction has been changed by SAP recently: transactions SM01 and S_ALR_87101283 and the report RSAUDITC are now obsolete and are replaced by transactions SM01_DEV and SM01_CUS in dialog mode. (See also: 2234192 – Enhancement for locking application start)
When you must use OS commands, the first step is securing the SAP Gateway to allow only local calls (which is the default setting nowadays) and to use sapxpg.sec and rfcexec.sec ACL files to control access to the kernel programs sapxpg and rfcexec.
See also OSS Notes (SAP user ID needed):
686765 – Security check when you execute external commands (sapxpg)
618516 – Security-related enhancement of RFCEXEC program (rfcexec)
CG3Y & CG3Z
Transactions CG3Y & CG3Z are used for file download and upload between SAP GUI and the application server. They can also be used to download SSH keys and system certificates and acquire OS and SAP access. Again, lock these transactions and make sure to who you assign the authorisation S_DATASET to.
Recommendations
Whether you run your SAP systems on-premise or in the cloud, make sure to restrict access to the OS by application users. These days, SAP Administrators should have an OS account that can be audited.
And delete RSBDCOS0!
