As you may know there are some basic rules in SAP Security. One of them is to prohibit direct modifications in production systems. All changes in SAP system have to be first implemented in the development system and then could be promoted through the SAP landscape to the SAP production system. That’s why SAP recommends to setup SAP system landscape (typically comprising of Development, Quality Assurance, Pre-Production and Production systems). Only approved and tested changes should be deployed into the production environment.
What you may not know is that all mentioned above restriction could be bypassed. How? SAP consultants and SAP developers know some ABAP statements which allow to modify or invoke arbitrary code (In the article I will be only talking about ABAP code changes). It works in the production environment too even SAP systems are closed via transaction SCC4/SE06. Thus someone may create a small inconspicuous program with one of dynamic ABAP statement, transmit it to production and get limitless possibilities. This type of backdoor is multipurpose. With its help anyone can modify any source code, execute any program, change any table entry and assign any privileges to anyone on the system.
Below some examples of dangerous ABAP statements:
This statement passes the content of itab to the ABAP program specified in prog in the repository as source code. If a program with the specified name already exists, its source code is overwritten. Otherwise a new program with the name specified in prog and the source code from itab is created in the repository.
GENERATE SUBROUTINE POOL itab NAME prog [error_handling]
This statement generates a temporary subroutine pool. The source code of the subroutine pool is taken from the internal table itab. The generated subroutine pool is stored internally in the current internal session. The eight-character name of the temporary subroutine pool is assigned to the variable prog.
Function Module RFC_ABAP_INSTALL_AND_RUN (takes the source code and installs it on a remote system). By the way, the global SAP support likes to invoke this FM.
In my practice, I have seen many versions of backdoor programs with such statements, some are written using minimum number of lines of code, others are written with an excellent graphical interface and rich features (loading, exporting, launching programs). These programs have one thing in common – the ability to run arbitrary ABAP code directly in production systems.
The authors of such software are often ordinary SAP developers and SAP consulters involved in the project. Why does this happen? Each project has its own timeline. The processes within the company for obtaining new privileges or changing production code can be slow. To close projects on time SAP consulters sometimes need to fast change code in production, quickly fix bugs or test something using production data. It is extremely convenient for them to have such tool in production. They usually do it with good intentions.
On the other hand, what to do if such ABAP code falls into the wrong hands? The backdoor is equivalent SAP_ALL privileges. You can do absolutely everything! No restrictions. No segregation of duties matrix. For instance, you can read any data, can change any bank account, can raise your salary, can stop SAP system etc. Usually in such cases the authors of the software don’t insert into program any authorization checks. So, the code can be executed by almost everyone.
Of course, the presence of such programs is not acceptable from IS point of view. Let’s discuss how to detect such backdoors in your environment.
STATIC ABAP CODE ANALYSIS:
We can launch the report to search for keywords in the source code of SAP programs. I usually use one of the following programs – RSABAPSC, RS_ABAP_SOURCE_SCAN, CODE_SCANNER. What to look for? For example, the calls of ABAP functions described above – INSERT REPORT, GENERATE SUBROUTINE POOL. Usually there are not many results (dynamic ABAP coding are not often used in fact). Then we analyze the results in manual mode. The most common feature of such programs we are looking for is loading ABAP source code from a text file or editing the code directly in a text edit box.
Just one remark: Backdoors can be written not only in Z* or Y* customer namespaces. But in the namespace for Partner ABAP Code which starts with “/” (surprise?).
DYNAMIC ABAP CODE ANALYSIS:
There is a possibility of monitoring program behavior through the SAP Security Audit (SM20). SAP Security Audit can track not only user activity but also program activity. After the program has run interesting for us information about what the program was doing remains in the SAP logs. The advantage of this method is that you can once specify the triggering rules. And then all suspicious events automatically will come to you in passive mode.
To detect dynamic ABAP code usage, we should analyze appearance of BU4 events in SAP Security Audit (Other events – BU4 – Dynamic ABAP code: Event &A, event type &B, check total &C). At first we get a lot of false positives. Suggest to filter dynamic calls from SAP standard code and consequently eliminate false positives by adding programs to exclusion list. Adhering to this approach you will always receive the most actual information about dynamic code usage in ABAP code.
To identify RFC_RUN_AND _INSTALL calls we need to analyze AUK events in SAP Security Audit (RFC Function Call – AUK – Successful RFC Call &C (Function Group = &A)). In this scenario we can only analyze external RFC calls for example.
