Skip to Content
Author's profile photo Chris Paine

Goodbye Simplicity, Hello Obfuscation – &SAP_EDIT

!! Warning !! I may be endangering your system security

 

Evil Hackers R Us

For quite a few year now, there has been some functionality built into the SE16N table viewing transaction. It allows those with very high access authorizations to make changes to transportable tables without creating a transport, and even to do so in productive systems.

It’s completely against all the rules of careful structured regulated process. Which is fine by me 😉 Joking aside, sometimes it is really useful for making a quick and dirty fix to some configuration/table data that just can’t be done otherwise. The number of times I have fixed data that has been messed up by code errors using this tool is beyond me to count. (Doesn’t say great things about my code does it!)

If the title of this blog, and the descriptions I’ve given haven’t been enough to tell you what I’m talking about, I’m not going to elaborate any further – sorry – but I’m sure I’m already going to be accused of further adding to the problem by writing this blog. Given that there are various threads out there e.g. the Edit function removed from SE16N transaction, reports and interface FM I’m not really opening a can of worms (or at least I hope not.)

Well SAP (or at least one of their customers) picked up on this and now this incredibly useful functionality has gone away. This is the gist of the note 1420281 which comes in a range of recent(ish) (well the note was released in March, that’s kinda recent isn’t it?) support packages. Many of the customers I’m working at are now at these support pack levels and it is becoming more and more frustrating.

Security through obscurity

If you look up the Wikipedia entry for Security through obscurity you’ll find (probably – – hey this is Wikipedia – it may have changed by the time you read this 😉 :

“Security through (or byobscurity is a pejorative referring to a principle in security engineering, which attempts to use secrecy (of design, implementation, etc.) to provide security. A system relying on security through obscurity may have theoretical or actual security vulnerabilities, but its owners or designers believe that the flaws are not known, and that attackers are unlikely to find them.”

This is exactly what SAP have done in this recent note. 

Come again – what did you say?

Let me take a second to explain. In the code for SE16N there are various checks against the user’s security authorization if they ever try to directly maintain a table. Which I think is perfectly fair. The developers of the solution decided that the most important authorisation to check was the one that allowed you to make changes to values within debug. Arguably if you have access to this (debug change) functionality, you can do anything in the system if you have enough time. I can testify that I’ve used this occasionally to give myself SAP_ALL authorization profile when the system admin has been away sick and we needed to get some work done. Those clever people who wrote the SE16N code decided that if you had those auths, well they weren’t going to be able to stop you – so why not make your life easier! And that’s what they did.

If you look at the code changes in the note all that has been changed is the simple way to alter a couple of global variables in the function group. Which you can easily do using debug.

Applying this note does NOTHING to improve the security of your system from someone with the most basic of SAP knowledge and a search engine.

I find it incredulous that SAP have been pushed (as this is all I can see that has happened) into making a ridiculously simple code change that does very little to actually improve the security of the system. The real issue is not that the SAP code allowed users this functionality, but that security is so lax in many environments that this is a problem in the first place.

Are you happy now Auditors?

Fortunately for me, there are other transactions with almost exactly the same functionality, that haven’t been “patched” – so I’m not going to have to resort to the debugger the next time I’m faced with a data f***-up in production. But you have to ask – “Why, SAP did you release this patch?” Is it not clearly the fault of those in charge of managing system security for giving users far too much access? This is clearly just lip service to the concerns of some SAP customers who haven’t got their house in order. And now my job, working at those SAP customers who do take security seriously, has gotten just a little bit more difficult.

OK – rant over. Time to be happy and smiley and get back to doing some Web Dynpro ABAP and building some more REST services (bit of JSON mixed with Atom Pub anyone 😉 Thanks for bearing with me!

A Final Plea

However Please – if you do know of other ways to circumvent these “attempts” to make SAP more secure – please don’t post them. It’s because people who really haven’t got a clue are messing with live systems that these sort of ridiculous changes occur. If and when I have to do production support – I really don’t need my life made any harder 🙂 Thanks!

 

Disclaimer: you shouldn’t listen to anything I say. It’s likely to be wrong, misleading, confusing and unrepresentative, and in no way reflects the opinions of my employer or any sane person. 😉

Assigned Tags

      13 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Ethan Jewett
      Ethan Jewett
      I'll admit it, I'm mostly posting a comment so that I get notifications of future comments!

      I like your argument and I thought the final plea, which essentially amounts to convenience through obscurity, was pretty funny 🙂

      In my view, legitimate security bugs (unlike this case) should be reported to SAP and fixed as soon as possible. The fact that SAP systems are rife with privilege escalation bugs is not a feature.

      Yes, if these bugs that we use in day-to-day work were all fixed then we would be forced to have professional, repeatable, and sane security practices or suffer through paying consultants to sit around and do nothing while waiting for security clearance. But hey, that's a feature, not a bug 🙂

      Author's profile photo Custodio de Oliveira
      Custodio de Oliveira

      Ethan Jewett wrote:

      In my view, legitimate security bugs (unlike this case) should be reported to SAP and fixed as soon as possible. The fact that SAP systems are rife with privilege escalation bugs is not a feature.

      This is exactly what I think. But "reported to SAP" doesn't mean "Blogged on the ABAP space in SCN so anyone can see and try for themselves to damage their systems".

      Author's profile photo Ethan Jewett
      Ethan Jewett

      Yes, I do believe real, unintended, undocumented security bugs should be disclosed to SAP privately. However, you revived this 3.5 year old comment in the context of a completely different discussion, about instructions for bypassing an authorization check using the debugger. The fact that the debugger allows you access to everything in the system is not a bug and is not (I imagine) going to be changed, so in this case the exact opposite is true.

      Knowledge should be spread so that there are no people ignorant enough to do something like give unsupervised debug access in production systems (for example). Yes, I have seen that in the real world, and yes, I reported it privately along with an explanation of what it allowed to the people in charge of that system and it was fixed.

      Author's profile photo Former Member
      Former Member
      Chris,

      i'm glad you have brought this up. the note has been our for 10 months and this particular hole has been closed. now, how ethical is it to say that you know of others but would not tell what they are? i hope you have communicated them to SAP and i completely agree with you that this should not be public (twittable) information.

      @greg_not_so

      Author's profile photo Chris Paine
      Chris Paine
      Hi Greg, Thanks for the comments,
      I might argue that this really wasn't ever a "hole". You needed to have enough auths to use this functionality that you could have taken control of the whole system had you wanted to anyway. If and when I do find genuine security holes I might mention them to some of my SAP contacts, but going through standard error reporting in SMP is just too painful. It is just not set up to accept this kind of reporting (or perhaps it is and I just don't know how to access it). But that's the start of a completely different blog topic/rant that I'll not start on today 😉
      Author's profile photo Nathan Genez
      Nathan Genez
      Excellent blog Chris.  Very even handed and fair.

      This was blogged about over a year ago (TIP: Editing any table in SAP!!!) but not as responsibly and it was because of that blog (and most likely tons of forums posts which resulted in hundreds of OSS messages to SAP) that the functionality has been removed.  I too am annoyed by that but I understand SAP's position.  Most of these doors originate for SAP's development support purposes and not for anyone else.  But information wants to be free and it eventually spreads out, which in this case, forces SAP to respond.  More trouble for us and for their dev support as well.

      Author's profile photo Chris Paine
      Chris Paine
      Thanks Nathan,

      I've got a picture to put on the dart board now the next time I have to resort to the debugger 😉

      I agree, info will out, which is part of my issue here, as the "fix" isn't really a fix at all. Yes, now using the system log it's going to be slightly more obvious if anyone has been devious - but how many auditor know about that (I'd better shut up right now, before the auditors start learning...)

      Thanks for the comments,

      Chris

      Author's profile photo Martin English
      Martin English
      Just saying 🙂
      Author's profile photo Chris Paine
      Chris Paine
      I should have drawn the evil hacker wearing a bright "Hawaiian" Shirt 😉
      Author's profile photo Chris Paine
      Chris Paine
      For those who don't get the reference, just try to seek out Martin the next time you're at any SAP conference - you're unlikely to miss him 😉
      Author's profile photo Arpan Paik
      Arpan Paik
      I faced the debug (change) issue and one of my developper gave a tough time. He was also very good to gave me smile after doing things whaich he was not supposed to do!!!

      &SAP_EDIT - I am happy as long as rabit do not see the rest of the world before get caught !!!!!

      Author's profile photo Former Member
      Former Member
      If you are interested in obfuscation then take a little look at SAP Note 1473881 ...
      Cheers, Julius
      Author's profile photo Chris Paine
      Chris Paine
      Well at least it gave another two support packs worth of relief from this "security" issue. Not as many people on ECC6 EhP4 SP8 as on SP6... 😉
      Yes, the evil hacker was modelled on me - it has about the same amount of hair anyway 🙂