ECC6 SE16N vulnerability and logging – UPDATED

October 9th, 2009 Posted in BASIS, Monitoring, Security

Please remove SE16N, or access to SE16N, from your production systems.

UPDATE

UPDATE – This topic was the subject of a blog by Kevin Wilson less than 2 weeks ago, at which time it was discussed extensively.

https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/16008

As long as DEBUG access is very tightly controlled, your system should be protected from the risk of this transaction….

I’ve known for a while that, in some releases of SAP, transaction SE16N can be used to change SAP tables, regardless of authorisations or security settings. It’s not something I’ve been keen to see widely disseminated, as there are major systemic risks in making changes this way. More dangerously, it provides a way to override authorisations by giving your userid (or your accomplice’s userid) the SAP_ALL role.

SE16N, before entering &SAP_EDIT in the command field

Essentially, you run transaction SE16N, then type &SAP_EDIT into the command field and press enter.

SE16N, AFTER entering &SAP_EDIT in the command field

In the example below, I’ve changed the User Group to SUPER.

SE16N, changing User Group to SUPER

Personally, I’d recommend making the transaction unavailable (perhaps even removing it from TSTC ?) in your production system – Your firefighter userid can be given authorisation to allow the appropriate people to add it back in, if necessary.

The reason for mentioning it at all is that SAP Mental Notes and IT-Toolbox SAP on DB2 for z/OS have stated that changes using this method are permanently logged in the tables listed below:
SE16N_CD_KEY : Change Documents – Header
SE16N_CD_DATA : Change Documents – Data

This means, in theory, that you can can query these tables to audit the usage of SE16N to change data. Personally, my attitude is that it’s all well and good knowing Joe Bloggs has broken your system, but I would rather not have to deal with the broken system in the first place. However, there’s a bigger issue…..

When I tested this out on an ECC6 IDES system (DB2 on Windows 2003), the SE16N_CD* tables were not updated.

SE16N, ECC6 IDES, does not appear to update the SE16N_CD* tables

1 – The knowledge of this method of changing data, which is available on production systems to anyone with access to the SE16N transaction is being more widely disseminated.
2 – There appears to be at least one major platform / release that does not support audit of the method of changing data.

This entry was posted on Friday, October 9th, 2009 at 4:10 pm and is filed under BASIS, Monitoring, Security. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
  • leonsteinhardt
    I strongly disagree. SE16N is an essential developer tool, in all systems including production.
    SE16N is not a danger as long as authorization is display only. An attempt to use @SAP_EDIT then results in an authorization failure; the SU53 shows

    Authorization Obj. S_DEVELOP ABAP Workbench
    Object Class BC_C Basis - Development Environment
    Activity 02
    Package <Dummy>
    Object name <Dummy>
    Object type DEBUG
    Authorization group ABAP/4 program <Dummy>

    Properly structuring authorizations is the appropriate response to the potential danger - not removing the tool.
blog comments powered by Disqus