Skip to Content
avatar image
Former Member

Spectacular hacks and workarounds from out there "in the wild"

Dear security gurus,

Right upfront I would like to mention that this thread is not for the purpose of reporting bugs. Please use the "Responsible Security Researcher Guidelines" in the FAQ sticky thread for that.

However there are many threads and tips&tricks out there which users can make use of to avoid security measures or bypass controls - particularly if you only rely on organizational measures (such as training..) and these fail "in the wild".

This thread is for the exceptional, spectacular and funny things which happen in the SAP security world.

Please consider the feelings and reputations of people when posting to this thread. Please anonymize all references (bar SAP standard users... :-). It is meant to help learning about "issues" and forensics to find them, not labelling people with mistakes (which we all make from time to time as we learn).

Cheers,

Julius

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

2 Answers

  • avatar image
    Former Member
    Mar 08, 2011 at 09:07 PM

    This is what happened to me today...

    A user was found to have had more authorizations than needed during a routine check, there was however no problem with the customer roles assigned.

    So what happened was, that the PRGN_CUST setting "ASSIGN_ROLE_AUTH was not set, so the ability to assign some local roles required that the user could also change them.

    The concept did not include roles built via (visible) menus, so the user went searching for SAP standard roles with menus to make the crows nest under the bonnet easier for the user to orientate themselves. These could be assigned in production.

    Of course they click on everything they can see... so missing auths it was.

    Hack : Generate the profiles for the assigned SAP standard roles in production. When auths are missing, go to SU22 and download the proposals for the tcode. Add the missing auths to the file and upload again (until recently an SCC4 changeability check was not performed). Then execute SU25 step 2A and 2B to transfer the data to SU24 (in production) and then regenerate the profiles.

    Voila!

    Solution : You should monitor you changes to Su22 and Su24 in production. I have also seen developers maintaining Su22 in production ⚠️ because their programs did not react to the return code, so they read some urban legend threads and thought it was config.

    You can only meaningfully contain this if you use the authorization concept (in this case too much S_DEVELOP activities) and assign roles system dependently with meaningfull naming conventions for DEV, QAS and PROD.

    Cheers,

    Julius

    Add comment
    10|10000 characters needed characters exceeded

    • Well, back from holidays. Julius, unfortunately the weather in my region wasn´t warm enough and didn´t have a chance to use sun-lotion. Luckly I had your link for enjoying the mornings (just joking, no so crazy)

      As I told you, I´ve continued with ICM approach. Using a web service client (soapUI) , a non-patch SAP system and a user with SAP_ALL rights is easy to get also a unix session of sidadm.

      The last step would be to try to use user EARLYWATCH (with standard roles and profiles) in 066. I read somewhere that it should work too. I checked that with sapgui EARLYWATCH can execute TH_GREP thru SM51 but can´t do it thru SE37. But when I try using the web service client I get error 401 unauthorized.

      So the question is: do you think it should work?

  • avatar image
    Former Member
    May 16, 2011 at 07:45 AM

    There are so many workarounds.

    One of my favorite was the SUPRN function that allowed SAP_ALL to be assigned without a trace.

    We had som users, without access to any user-transaction or any SE-transaction and still they could assign SAP_ALL to themselves.

    Workaround:

    In SAPGui Select Menu item System. Then select Status.

    Double click on program name and you get into the function module. This is a backdoor to SE80-functionality.

    Select Menu item Program - > other object.

    Select Tab Function Group -> Function Module -> SUPRN_INS_OR_DEL_PROFILE

    This function module is a subfunction that is not intended to be directly called, But when used incorreclty it can be used to assign profiles to any user.

    Solution:

    With security note 1406435 SAP have enforced traceability in the function module used. They have also added an extra authorization check to see if the user is allowed to execute the SUPRN.- function group.

    And guess how mad the end user was when he understood we have stopped his backdoor to SAP_ALL.

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      You cannot maintain org. fields in SU24, but you can pass them as parameters to transactions.

      If you do not maintain SU24 for the parameter transaction, it pulls the proposals for the core transaction which the parameters are passed to.

      That is one of the reasons why S_TABU_DIS always pesters you - (until recently).

      Cheers,

      Julius