Skip to content

SAP Debugger, powerful yet dangerous! 

SAP Debugger

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? 

What is the SAP Debugger?

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.   

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.

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? 

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 authorization 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.

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. 

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, I recommend trying SecurityBridge Threat Detection. 

Posted by

Ivan Mans
Find recent Security Advisories for SAP©

Looking into securing your SAP landscape? This white-paper tells you the “Top Mistakes to Avoid in SAP Security“. Download it now.

Webinar: SAP Security Baseline: Surviving an SAP Audit

With the recent increase in attention to SAP security from auditors, we decided to investigate SAP baselines. We took a closer look into what SAP baselines are, how they can help you, and how to survive an audit.

Innovator für SAP-Sicherheit: SecurityBridge auf den DSAG-Technologietagen 2023

DSAG-Technologietage, das bedeutet traditionell: Wissensaustausch unter Technologen und Technologiebegeisterten. „Work in progress“ lautet das diesjährige Motto (22.- 23. März 2023, Congress Center Rosengarten, Mannheim). SecurityBridge nimmt die DSAG beim Wort und veranstaltet zusammen mit seinem Partner cbs Corporate Business Solutions Unternehmensberatung GmbH einen zweitägigen Hackathon, bei dem Studierende einen Prototyp für Security entwickeln können, unterstützt durch Coaches führender Beratungsunternehmen.
SAP security by design
Security-by-design is a principle that emphasizes the need to build security measures into software systems from the start rather than as an afterthought. SAP projects need to embed security conciseness to respect this principle and gain a cyber-resilient application. Thus, they should prioritize security when designing and implementing their SAP systems rather than attempting to bolt on security measures afterward. This can help to prevent security breaches and minimize the damage caused by cyberattacks.
Remote Code Execution (RCE) vulnerability in SAP is a type of security issue that allows an attacker to execute arbitrary code on a target system remotely. has gained control of a user's click, they can execute a range of actions, such as transferring funds, changing user settings, or stealing sensitive data.
Management Dashboard
SAP security provider SecurityBridge—now operating in the U.S.—today announced the latest addition to the SecurityBridge Platform—the Management Dashboard for SAP security. The SAP Management Dashboard is a no-cost, additional application for the existing SecurityBridge Platform that combines all SAP data aspects and presents the information through a customizable, single pane of glass security dashboard view.
Hacker mining SAPsecurity
SAP Cybersecurity- SAP Vulnerability
In recent years, cyberattacks against SAP systems have become more common, with attackers gaining network access and then exploring critical applications through port scanning and script-based exploration. Two examples of such attacks that use the SAP RFC SDK are the password lock attack and the password spray attack. In this article, we will outline how to detect these script-based attacks against SAP.