Skip to Content
Author's profile photo Madhumahesh Thorati

Security in SAP


There is a chance to get access to the users account by just making some changes in Table USR02.

i.e if we copy the data of that particular user into internal table from usr02

(working fine in Development Server)

pic 1.JPG

then reset the user password using the following code,

data: t_return type bapiret2 occurs 0 with header line.



        username = ‘TEST4’


        return   = t_return.     ” to Reset user password

loop at t_return.

write:/ t_return-message


  which gives us the password i.e t_return-message.

Then we shall be able to access that particular user’s account i.e ‘TEST4’.

later, the previously copied value i.e is shown in above pic will be added again , so that the user (TEST4) may not know that some one has accessed his account.

For Testing Purpose only.

Kindly share your suggestions.



Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Frank Koehntopp
      Frank Koehntopp

      If you can indeed modify USR02 in your production system something's seriously wrong with your authorization concept.

      Your second step, adding that piece of code, should also not be possible.

      I suggest you rethink your security concept...


      Author's profile photo Graham Robinson
      Graham Robinson

      A very cynical and disingenuous blog post. I suggest you read up on SAP security and authorisation concepts and then post some blogs that show how they work and how to build code that takes advantage of these concepts.


      Graham Robbo

      Author's profile photo Martin English
      Martin English

      I agree with the previous comments, this shouldn't be possible on a properly maintained system (is it possible on a fresh install ?), but It's an interesting piece of code to watch out for, or to keep for penetration testing 🙂

      Author's profile photo Frank Koehntopp
      Frank Koehntopp

      If you don't understand why this should not work I hope you're not running any productive systems right now.

      Even the most basic security configuration will make sure this does not work. And it shouldn't.


      Author's profile photo Frank Koehntopp
      Frank Koehntopp

      If you can manage to get this code into your production landscape something's seriously wrong.

      Author's profile photo Former Member
      Former Member

      Madhumahesh is a classic insider threat. I do believe it would be possible for him to embed his code into some other innocuous report and get it promoted to production at many companies. The downside, for the would-be spy, is that this attack is completely traceable if it is detected. Arrest would surely follow shortly thereafter. There are simpler and less traceable ways to gain unauthorized access to a system, but this is yet another example of how one bad actor can potentially create havok.

      This is a fine argument in favor of including automated code scanning tools into the standard promote to production process. Any code referencing any of a number of critical function modules should be flagged. I'm pretty sure SAP's code inspector functionality could be configured to catch this or similar subterfuge.

      True security professionals are always on guard for insider threats, but the popular press continually trumpets the threat from the mysterious, unnamed outsider hacker attack. While I'm not security expert, I would certainly wager that insider threat dwarfs hacker attack in terms of real damage done on a yearly basis. This also highlights the need for a rigorous pre-hire screening by the HR department!

      I know every organization is different, but I can tell you that unless one of our developers had been specifically requested to explore this area, the mere existence of this code on any server would be grounds for immediate termination!

      Author's profile photo Frank Koehntopp
      Frank Koehntopp

      Two things:

      - a proper development process would detect that code before it gets into production

      - even if you get it on, nobody should have the authorizations to a) run it or b) read/modify USR02


      Author's profile photo Former Member
      Former Member

      You can create ABAP code on a production system which is closed for changes without a developer key and without any changes in debugging mode. I have never seen an audit which was aware on this authorization. (No, I will not post it here.)


      Author's profile photo Frank Koehntopp
      Frank Koehntopp

      Well, the one you told me offline is one our product GRC Access Control would catch as "Critical Basis Activities".

      But that's another good lesson - I had many customers justify bad authorizations with the remark "the auditors never complained!" to which I always responded "If you're ok with your system security depending on the quality of the auditor..." 😉

      Author's profile photo Martin English
      Martin English

      Just catching up on my reading and saw SAP Security in figures – a global survey 2007-2011 (PDF) from ERP Scan

      Obviously, you do need a little cynicism when you read these kinds of reports; After all, they make their living by scaring us and / or the PHBs, but I've followed up on Service Market Place, and the exploits that ERP Scan refer do have SAP notes with workarounds and patches.

      In short, you have more to worry about than just ABAP code accessing USR02 - For example, the publication claims that nearly two thirds of the SAP J2EE systems exposed to the internet have the CTC Service enabled (and also exposed to the internet). CTC is used for functions like User Management, OS Commands, etc. This exposure combined with Verb Tampering allows an attacker to bypass authorization checks for remote access to CTC service - i.e. On an unpatched system, anyone can remotely obtain full unauthorized access to all business-critical data located in the J2EE engine.

      Security is as much about being vigilant, of both your people and your systems, as much as it is about code.


      Author's profile photo Frank Koehntopp
      Frank Koehntopp

      That's exactly the point. I've been working on this with customers since 2005, and it's still something that takes a lot of effort to do right.

      Too many customers are not treating this with the right priority, I think. It's unfortunate that a report like this has to point this out, but maybe that's a psychological issue, like telling kids to brush their teeth 😉


      Author's profile photo Former Member
      Former Member

      This is rather silly as the FM is a wrapper for the BAPI_USER_CHANGE which makes correct authority-checks. So you might as well go to SU01 and just reset the password as you will be authorized to do so via object S_USER_GRP actvt '02' and '05'.

      If you are not authorized for that, then this code is not going to work either!

      One of the blunders of working with SAP_ALL is that you become naiver and naiver about security as you go along....  🙂