By Christoph Nagy, CEO of SecurityBridge
It must have been a few years ago that I participated in a webinar where the Service Advertising Protocol (“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?
What is SAP Debugger?
The SAP Debugger, also known as the Advanced Business Application Programming (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.
What can I do in the SAP Debugger?
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 (https://blogs.sap.com/2013/04/29/remote-abap-debugging/)
Alternatively, you can let the cursor jump from line 1 to next 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?
What risks arise from the SAP Debugger?
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 authorizations to do so.
Some examples spotted in the wild:
- Bypass authorization checks by resetting the return code (SY-SUBRC) or setting the cursor.
- Changing values in program variables to infiltrate or manipulate the database
- Modification of the program flow to obtain an abort or a change of the end-result.
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. (https://sapboost.com/how-to-edit-sap-table-in-debug-mode-using-se16 )
This, of course, makes it more important to recognize an anomaly in usage behavior. It is even better if so-called indicators of compromise are detected at an early stage in order to be able to identify attacks.
How can you protect yourself?
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:
- ‘02’ – Changing values of fields and (as of Release 6.10) the function >Goto statement, and
- ‘90’ Debugging of sessions of other users.
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, market solutions can help.
About the Author
Christoph Nagy has 20 years of working experience within the SAP industry. He has utilized this knowledge as a founding member and CEO at SecurityBridge–a global SAP security provider, serving many of the world’s leading brands and now operating in the U.S. Through his efforts, the SecurityBridge Platform for SAP has become renowned as a strategic security solution for automated analysis of SAP security settings, and detection of cyber-attacks in real-time. Prior to SecurityBridge, Nagy applied his skills as a SAP technology consultant at Adidas and Audi. Christoph can be reached online at christoph.nagy@securitybridge.com.
Source: www.cyberdefensemagazine.com