Technical Articles
Potential ABAP Command Injection & Dynamic Code Generation
Working with SAP partners over many years to test and certify their ABAP add-ons, I have come to appreciate the Code Vulnerability Analyzer (CVA) tool in the ABAP workbench as a useful safeguard, and also learned to help partners interpret the results of the CVA scan. This blog is to illustrate why you always have Potential ABAP Command Injection in your CVA report, when you implement ABAP Dynamic Code Generation.
ABAP supports generating programs at runtime and execute. In order to do so, below are the major logic steps:
- The source code has to be created at runtime.
- The generated source code, later, is handed over to some ABAP commands for dynamic code generation and execution.
- These ABAP commands generate and execute the program.
Normally, there are two manners to choose for establishing the dynamic code at runtime.
The first one is to generate the code as intermediated program under internal session. Once the internal session is over, the code and program will be deleted without trace.
The second option allows to generate code persistently, which means that even after internal session, the code and program can be kept in the database and they are reusable.
As dynamic code generation is an efficient, yet highly sophisticated programming skill in ABAP, it requires experience and should be a last resort. For instance, in the situation that, it is not possible to determine the data structure until you have the outcome from runtime, then you have to adopt Dynamic Code Generation.
The most important statements in dynamic programming are
- GENERATE SUBROUTINE POOL ( not focus in this blog)
- INSERT REPORT
A typical syntax of Insert Report is code line as below:
INSERT REPORT prog FROM itab
[MAXIMUM WIDTH INTO wid]
{ [KEEPING DIRECTORY ENTRY]
| { [PROGRAM TYPE pt]
[FIXED-POINT ARITHMETIC fp]
[VERSION vs] }
| [DIRECTORY ENTRY dir] }.
The CVA scan, by default, generates a priority 1 message when it detects an “Insert Report” syntax in the ABAP program, as it is not possible for CVA to know if the “Insert Report” syntax is from Dynamic Code Generation as a mandatory syntax, or it is virus planted.
In the situation that SAP CVA tool identifies your code as Potential ABAP Command Injection and a Priority 1 issue, below actions are suggested:
- To investigate the error message and find if the cause is from the detection of “Insert Table” syntax of Dynamic code generation.
- Document the environment in details.
- Partners can also contact the SAP Integration Certification Center(icc-info@sap.com) to analyze the program thoroughly.
There are classes and methods that will allow you create all kind of workbench objects (e.g. classes) on the fly. Are these spotted by the SAP CVA tool as well?
SAP CVA tool will scan all static code base under partner namespace.
And does it scan for uses of the standard SAP classes that allow you to create, e.g. classes and methods containing source code? If not, then it has a gap in functionality that a black hat could exploit.
Using these standard SAP classes is equivalent to GENERATE REPORT - but without using that command.
Hi Matthew Billingham
CVA has introduced to process data flows of execution paths through SAP standard coding but only revealing findings in custom & 3rd party code. The CVA assumption is basically that SAP standard coding is save and the functionality properly protected (e.g. by auth. checks.). I remember a check regarding kind of dangerous functions, but it's unlikely that all security relevant cases are covered. Like Forest mentioned it'll only scan an reveal findings for the statement in the non-SAP namespace. As such it's not covering the scenarios of logic flaws by dependencies with the SAP standard.
In all the responses so far, there seems to be a misunderstanding. I am not talking about the use of INSERT REPORT in SAP standard. I'm talking about the use of function modules and classes that have identical functionality to INSERT REPORT.
If I, third party programmer, use INSERT REPORT, that gets reported.
From the blog:
But if I use in my carefully crafted malicious code ("a virus"), function modules like these
And then call my new created class and method, followed up by using another FM to delete the class/method, CVA assumes because these Function Modules are standard, they're safe to use. So it doesn't raise any alarms.
Even though these function modules require exactly the same authorisations (if not more) as INSERT REPORT, and, like INSERT REPORT ,dynamically generate code.
Seems like a security hole to me.
Hi Matthew Billingham
I'm all with you. Supply chain attacks via third-party add-ons are a huge untreated risk. As a result of the investigation a customer of us ask us to carry out I wrote this blog https://www.no-monkey.com/sap-security-blog/security-meaning-sap-third-party-add-on-certification/index_eng.html
Best,
Marco