Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

S_Develop and Debug Implications and Risks

Former Member
0 Kudos

Can anyone provide some more specific examples of implications/risks of this access?

I have seen lots of comments about how authorization object S_Develop with debug object type is not allowed in production in order to deal with us lovely auditors.  I haven't seen any discussion about the potential implications, how a user could exploit these issues, etc...

I found that users can edit tables via SE16N if they have debug access.  I've also seen that it allows users to bypass standard authorizations.  There has to be some big, easily identifiable implications.  I would just like to understand some other scenarios, if possible.  Thank you.

1 ACCEPTED SOLUTION

Former Member

hi vincent!

you can bypass authorizations if you have debug authorization in production so there's really no limit to the possible exploits.

I for one can think of one implication related to the security audit log (SM18-19-20). with all the authorizations you need you can easily get rid of (some of the) evidence you have left behind.  the kind of thing fraudulent users really like 😉

I hope some others will provide some more examples of why it really is a bad idea to hand out change/debug authorizations in a productive environment.

good luck!

7 REPLIES 7

Former Member

hi vincent!

you can bypass authorizations if you have debug authorization in production so there's really no limit to the possible exploits.

I for one can think of one implication related to the security audit log (SM18-19-20). with all the authorizations you need you can easily get rid of (some of the) evidence you have left behind.  the kind of thing fraudulent users really like 😉

I hope some others will provide some more examples of why it really is a bad idea to hand out change/debug authorizations in a productive environment.

good luck!

martin_voros
Active Contributor
0 Kudos

Hi,

bypassing authorization checks means game over. Think about malicious deleting some business critical data. Or you can execute any OS level commands. From OS level you can usually hop to another systems. Bypassing authorization check is possible only if you give authorization to change values in debugger. But don't be fooled that display only debugger is safe. A user can examine whole memory. So think about viewing data that are not supposed to be displayed to user.

Cheers

0 Kudos

Martin Voros wrote:

Hi,

bypassing authorization checks means game over. Think about malicious deleting some business critical data. Or you can execute any OS level commands. From OS level you can usually hop to another systems. Bypassing authorization check is possible only if you give authorization to change values in debugger. But don't be fooled that display only debugger is safe. A user can examine whole memory. So think about viewing data that are not supposed to be displayed to user.

Cheers

I have to disagree on the OS part as that is completely dependent on the application users' rights on the operating system. In an ideal world those are limited.

Within the SAP application however, you can do just about anything you like with debuggning rights if you also have the change paramater right. I would start by giving myself SAP_ALL 🙂

0 Kudos

Jurjen Heeck wrote:

I have to disagree on the OS part as that is completely dependent on the application users' rights on the operating system. In an ideal world those are limited.

Considering the scope of what <sid>adm needs to be able to do, being able to leverage this just with the auths it needs gives scope to cause complete havoc.

0 Kudos

Hi Jurjen,

even if SAP user is properly restricted it's still easier to find/buy local privilege escalation exploit than remote code execution exploit. Access to OS level SAP user means game over for me.

Cheers

0 Kudos

A powerful user for OS tasks is usually lurking somewhere in any system. For SAP this not only S_DEVELOP must be considered, but also S_DATASET, S_LOG_COM, S_RZL_ADM and parameter rdisp/call_system.

But I was not aware that it is possible to buy an escalation of privileges. What does the debugger for 10 minutes cost now-a-days? 😉

Cheers,

Julius

0 Kudos

Julius von dem Bussche wrote:

But I was not aware that it is possible to buy an escalation of privileges. What does the debugger for 10 minutes cost now-a-days? 😉

Latest prices on the SAP Exchange is 5 Jaffa Cakes / 10 minutes.  The market usually dips on a Monday where a Rich Tea will suffice.