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

[Former Member]

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

[Former Member]

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

[Former Member]

Hi Julius,

I´m not sure whether the next hack could be consider "exceptional, spectacular and funny " since is quite old but when I read it the first time I used those adjectives to describe it.

As I said, is something that I found in the web (...) and the article describes how to gain shell access to your SAP ABAP system when SAP lives in a Unix server. The procedure used is via injection code.

The article is short and very clear so the best for a person that doesn´t know it is read it but roughly the idea is to find a FM that has a weak security and where you can insert code. The candidate is TH_GREP that launchs the unix command grep.

Hack:

Try to see if your user can execute the FM TH_GREP via SE37 or SM51. If so, open x windows and get fun with your sidadm session

Solution:

I think that I SAP created a Support Package in order to solve the problem (the SP restricted the permission needed to execute TH_GREP)

Note: The method is so simple that I tried in my lab systems but I didn´t succeed. Since the method is injection code I tried to insert a `touch file` command but it didn´t work. Hoping is not consider cross-posting I would like to know if someone else managed to make it work.

Best regards,

Félix

Edited by: Frank Koehntopp on Apr 11, 2011 4:01 PM

[mvoros]

Hi,

you can still do command injection. For example if you enter "" || HOSTNAME || "" into string then you will see that command hostname will be executed multiple times. SAP should handle special characters such as quote and escape them.

Cheers

Edited by: Martin Voros on Apr 12, 2011 10:42 AM

[Former Member]

Hi Martin,

I tried with "" || HOSTNAME || "" (and some variations of it) but didn´t manage neither. Since I have also access to OS with sidadm I tried the command grep directly executed by sidadm and the nearest thing that worked was:

#grep `|hostname|` file

OS is HP-UX 11.23 and SHELL of sidadm is /usr/bin/csh. For sure I´m missing something but don´t what.

Best regards,

Félix

[mvoros]

Sorry, that was for Windows. Basically, you need to end quote (I'm not sure but it might be ' in unix) and then start new command. You can use || in unix as well. It works that the first command fails it executes the second command.

Cheers

Martin

[Former Member]

 Solution:
I think that I SAP created a Support Package in order to solve the problem (the SP restricted the permission needed to execute TH_GREP)

What you are looking for is [SAP Note 1433101 - Misuse of the search function in transaction SM51|https://service.sap.com/sap/support/notes/1433101] which "normalizes" the input for systems on UNIX.

Cheers,

Julius

[Former Member]

BTW you can also bypass the S_ADMI_FCD check, but then this happens:

if use_sxpg = th_true.
      call function 'SXPG_COMMAND_EXECUTE'
        exporting COMMANDNAME = 'SAPGREP'
                  additional_parameters = grep_params
                  operatingsystem = opsys
        importing status = status
                  exitcode = exitcode
        tables exec_protocol = findlist
        exceptions others = 1.

    else.
      perform call_system tables result
                          using grep_params opsys.
    endif.

The "call 'system'" form does not prior check whether this c-call is infact allowed, but the kernel function itself does!

So if you take a closer look at RZ11 param rdisp/call_system then you will see that you can turn it off, and divert well written code to the SXPG application function module (which makes all the S_LOG_COM and S_RZLADM checks beyond the boundary of the function module's interface...).

By default installation value, rdisp/call_system is not disabled and is a dynamic parameter.

If you disable it and set your secinfo gateway controls to "local" or "identical" hosts, then you force the caller to pass via well written application code (such as the SXPG functions) and have a documentable concept to work with.

Cheers,

Julius

PS: Note that before diabling call 'system' you must check your custom Z* and Y* programs for use of this technique. It is quite popular and tempting in some "cowboy coding"...

[mvoros]

Hi,

thanks Julius for additional info. I saw that note and checked that system and it's not patched yet. But I'm still not sure if that fix is enough for Windows. Because that fix is only for Unix and I was able to terminate search string and inject new command (in this case it was harmless hostname command). I am also confused by this line.

 
if use_sxpg = th_true. 

use_sxpg is a local variable and I don't see where it is set. Anyway, it might be some black magic because also debugger does not jump into this FM. Is there any trick how to bypass this protection?

No Julius, you don't have to. You can just turn it off and regularly check ST22 for new dumps

Cheers

[Former Member]

Have you tried setting your breakpoint just ahead of the the RFC call and then switch to "/HS" and F5 the function. You should be able to step into it.

I suspect the variable is (re)set by one of the c-calls in forms executed before the "call 'system'", such as for example when sy-index = 0 in the local "wpinfo".

Via secure config, up-to-date patch levels and correct (and well built) authorizations it can however be contained IMO.

Cheers,

Julius

[Former Member]

I found out why I wasn´t able to inject code. I knew that my system was patched with 1433101 but i didn´t care so much because my user had SAP_ALL and the patch just added extra control with role "S_ADMI_FCD".

What I didn´t realise is that they changed also TH_GREP itself so everything you write in the text box will go between '' so now is sure that just will go text and not possible (as far as I know) to execute commands. I tried in a system not patched and worked perfectly

• if this is UNIX

*

• Avoid bad termination of the search pattern. This could lead to uncontrolled execution

• of any OS command! We enclose the given search pattern with a single quote (').

• - Therefore the shell will not expand this string. As a consequence we don't need a special

• handling for backward quotes >`<.

• - to allow (') as a part of the search pattern and to avoid bad termination of the

• search pattern we expand it to '"'"'. This means we

• - terminate the previous part of the search pattern

• - concatenate this with search pattern "'".

• - open a following part of the search pattern.

replace all occurrences of '''' in local_string with '''"''"'''.

concatenate '''' local_string '''' filename into grep_params

So per above, Julius, what you mention, would it work? I tried to understand it but my background is technical and ABAP skills are between zero and none

Martin: This code won´t affect to Windows and I think is the only piece of code they changed so I guess that if you have permissions or you do what Julius says then you will be able to inject code.

BTW: my next step is to try it thru ICM but that will be after vacations

Best regards,

Félix

[Former Member]

Actually the note mentions S_ADMI_FCD as a "role" although it is an "authorization object".

The note did not add new checks. It is the ALV program behind SM51 which makes a check on this object before calling the TH_GREP command function. Other programs might not. The note mentions that the risk is mitigated as only admins should have roles which contain this object S_ADMI_FCD....

What was done is that the input was "normalized" such that the command passed to the SXPG or the c-function 'SYSTEM' could not include additional (random...) commands in the string.

Actually the code should never reach this c-function call, unless it is performed by another external calling program using the extention IN PROGRAM or variants of it.

There is also a blog about it. Search for "('(".

but that will be after vacations 

You can read about these variants using [ABAP programming security|http://www.sap-press.de/2037]. Make sure you are wearing lots of sun-cream, socks, sandals and a hat with propeller on the top when reading this book on the beach....

Cheers,

Julius

[Former Member]

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?

[Former Member]

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.

[Former Member]

I think you should check your own authorizations and trace them...

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

It did create change documents. Now it also makes authority checks... but as the function is not remote enabled this means you have strong enough auths to do anything anyway in SE37.

This is a backdoor to SE80-functionality. 

There are many such navigation paths. Since a few years now there is an SE80 tcode check in them (except fror the debugger - also in display mode...).

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

End user with authorizations to execute arbitrary function modules?

This is however also a symptom of other problems at times, most notably bad programming... --> It is not only insubordination of the security concept, but sometimes a reaction to it when security admins allow themselves SAP_ALL type of access but the application roles are insufficiently built and attempts are made to restrict developers and basis folks at tcode "type of" level in development systems.

You will crack your scull trying to do this!

If you restrict developers and basis folks in DEV but your roles are crap in PROD (for them to use the available control mechanisms of!), then what other option do they have than hard-coding?

Sure, developers are often the "guilty ones" but I also sympathise with them very often when I see the options they are given to use the implemented authorization concept.

Cheers,

Julius

[Former Member]

Here is another one to watch out for...

Consultants create SoD compliant roles at the object level and all hell breaks loose in GRC when the assignments are made.

So... they create variant and parameter transactions per org. level which call the standard transactions.

I have seen them trying to maintain the org. levels in Su24 as well.....

Personally I would recommend that customers take legal action against such consulting "workarounds" ...

Cheers,

Julius

[Former Member]

If you use the report RSUSUR008_009_NEW with your own rule set, due to the usage of the "OR" operand in the authorization ID, there would be quite a few 'false positives" shown. (this is nothing different from the few tools tested in the market)

to avoid false positive, create different variants for execution (1) for Critical transactions (2) For Critical authorizations.

download both and use VLOOKUP in Excel. This gives a terrific result

Is this a workaround?....Well, I think so

[Former Member]

The "hack" is to use the "Group" field within the Authorization IDs...

[Former Member]

Julius - I've never heard of a variant or parameter transaction before. Is there a way to scan for this "workaround" to see if it has been implemented in our systems? What are these?

[Former Member]

Very good question. I will add it to the list of tricky interview questions (other sticky thread about "some fun to tickle your brain").

Cheers,

Julius

Edited by: Julius Bussche on Sep 30, 2011 11:45 PM

[Former Member]

Ok - I learned about these transactions - basically they are custom tcodes that call a standard tcode using a screen or parameter variant. But what is the connection to Org.fields and SU24?

[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