It must have been a few years ago that I participated in a webinar organized by the German-speaking SAP user group (DSAG). In that webinar, the SAP representative explained a recently corrected vulnerability. The correction did not remove the problematic code but only introduced an additional check. Which, in my opinion, is the normal procedure. However, after the explanation by the SAP speaker, an interposed question came from the audience. The question was: How does the fix protect against attackers who use SAP Debugger to skip the check? In response, the spokesperson vehemently emphasized that an SAP system in which users have debugging privileges (coupled with changes to program variables); cannot be protected from compromise.
The combination of the debugger authorization with the said possibility to change the program variables is called, in SAP lingo, Debug & Change. To support the statement of the SAP expert, let’s look at: What is the SAP Debugger? and What can it do to the system?
The SAP Debugger, also known as the ABAP Debugger, is one of the most important development tools offered by SAP. An ABAP developer or a technical SAP consultant uses it to analyze problems or to simulate program flows. Usually, the debugger is simply used to understand a certain behavior in SAP ERP and to identify or understand customizing options. Provided that a user has the appropriate authorizations, the debugger can be called from all ABAP screen-based transactions using function code /h. The SAP ABAP Debugger can also be used in OData, WebDynpro for ABAP, etc.
In addition to the generally known functions such as the step-by-step processing of source code and the analysis of values of program variables, there are still some hidden features not known by everyone.
Did you know that you can start a remote debug session with the SAP Debugger, where you can analyze – or influence – a user’s SAP session? The feature is not new, by the way, as evidenced by this blog from 2013: Remote ABAP Debugging.
Alternatively, you can let the cursor jump from line 1 to n without executing the source code in-between.
So-called breakpoints can also be set dynamically. Breakpoints stop the debugger, or to be more precise, the cursor at a certain point in the program flow.
Additionally, to the ability to view the values of a program variable, there is also the option to change values.SAP offers the possibility to authorize this function granularly. More about this in the section: How can I protect myself?
It was rightly pointed out by the speaker of the SAP webinar mentioned at the beginning of this article that the debugger can be used to compromise the system, provided that the attacker holds or acquires the authorization to do so.
Some examples spotted in the wild:
Now you must know that if an attacker accesses the coveted Debug & Change permission, he typically does not base the attack on the debugger only but uses it in the Reconnaissance phase or in the Gaining Access section. The SAP Debugger can also be a helpful tool in wiping the evidence of the SAP attack since everyone knows the SE16 trick: How to edit SAP tables in Debug Mode using SE16.
This, of course, makes it more important to recognize an anomaly in usage behavior, as described in the recently published article: The easy way to spot anomalies in SAP. It is even better if so-called indicators of compromise are detected at an early stage in order to be able to identify attacks.
Although these functions of the SAP Debugger can be restricted via authorizations, you will quickly notice that developers cannot work without extensive authorizations. Of course, the work of the SAP developer is mainly done in the development system. Therefore, there is no need to allow SAP Debug authorization, especially in combination with change permission of program variables in a system with productive data. So, you should ensure that this critical authorization combination is or will never be assigned in a productive SAP environment.
Use the authorization object “S_DEVELOP” and prevent object type “DEBUG” in combination with activity:
You can achieve additional protection by regularly and promptly analyzing the activities in the associated SAP logs, in this case the SAP Security Audit Log (SAL).
However, this can be very time-consuming. In particular, the reliable detection of anomalies or an indicator of compromise for the SAP system requires additional analyses. If you do not have time to do this manually, I recommend trying SecurityBridge Threat Detection.
Posted by
Looking into securing your SAP landscape? This white-paper tells you the “Top Mistakes to Avoid in SAP Security“. Download it now.
