Disgracefull SAP notes - code injection powered by SAP Netweaver

[Former Member]

Dear gurus,

I strongly recommend that you double-check your SAP installations for the following optional SAP solution notes or boycott the component products even if they try to implement these approaches.

These are notes you should not implement. You should also scan your own custom implementations for this, as it is increasingly "doing the rounds" and might not only come from SAP...

-

---

[Note 514998: Error in RFC_ABAP_INSTALL_AND_RUN function module|https://service.sap.com/sap/support/notes/514998]

The disgrace:

> Error ??

and

>Modification to the function module RFC_ABAP_INSTALL_AND_RUN on the actual system requirements.

-

---

[Note 1182516: Why are the ABAP jobs submitted by Data Integrator being run by SAP instead of Data Integrator?|https://service.sap.com/sap/support/notes/1182516]

The disgrace (and joke):

> Data Integrator has no control over the job executions.

-

---

[Note 1182244: Two ABAP programs that are submitted at the same time to SAP do not run in parallel|https://service.sap.com/sap/support/notes/1182244 ]

The disgrace:

> Upload the Data Integrator supplied function Z_AW_RFC_ABAP_INSTALL_AND_RUN.

-

---

For those who are less technically versed, these solutions load syntactically correct (or even not) ABAP code as text from the client side into the system remotely, overwrite any existing code with the same name, insert it into the system, load it into the program memory and execute it.

- There is NO security generally, which is appropriate.

- There is NO version management.

- There is NO QA or transport approval

- Anyone who compromises the security (e.g. the file path) on the client side, has remote developer authorizations in SAP.

- Cont... If it is also run as a job then you are (very likely) in deep security troubles...

Also please do yourself the favour of using transaction SCI (SAP Code Inspector) as a usefull way to detect this and other "low brainers" or other code scanner tools which can detect and to some extent interpret the risk from the user input even - IF found within the ABAP system...

There are selective very special cases where it can be appropriate from coding templates which are executed. These should be well documented and well (negative) tested!

Cheers,

Julius

[Former Member]

Hi Julius,

First of all, thanks a lot for all those interesting posts - I usually have a smile on my face when I read your comments...

I'm not quite sure I understand OSS note [514998 - Error in RFC_ABAP_INSTALL_AND_RUN function module|https://service.sap.com/sap/support/notes/514998]. It just talks about an authorization check that was activated. As far as I remember this function module has for the longest time (source code mentions April 2002) a check if the system is modifiable and allows changes to client independent objects. If not, then it ends immediately with an error message.

Thus in a normally configured landscape I'd expect that any application anyhow would just be able to use it in development?! Am I missing something? Are there really external applications out there that do that in production???

Also, in theory overwriting of existing programs is not possible, because if you set mode parameter to F, the program name is fixed to a constant (seems to vary in the different SAP versions I checked). If you choose any other mode, the RFC function basically just executes the existing report, but doesn't change anything.

By the way, it seems to me that your last link was wrong, isn't it KB article [1182244 - Two ABAP programs that are submitted at the same time to SAP do not run in parallel.|https://service.sap.com/sap/support/notes/1182244]? So maybe the new Z-module circumvents all those checks and does all those fun things that nobody can explain later...

Cheers, harald

[Former Member]

Hi Harald,

Thanks. I fixed the link.

> So maybe the new Z-module circumvents all those checks and does all those fun things that nobody can explain later...

Yes, that is what it is.

> Mode F

You could install and run a new ZRFCxxx program which makes an EDITOR-CALL on the existing one.

You can do whatever you want to, without having appropriate authorizations for it and on top of that: you can do it remotely.

This needs to be stopped and customers should react with outrage to such "workaround" solutions.

Cheers,

Julius

[Former Member]

You can now use the attachment to [SAP Note 1427467|https://service.sap.com/sap/support/notes/1427467] which makes the same checks as the standard function module RFC_ABAP_INSTALL_AND_RUN, but is still in the customer Z* namespace.

You can read between the lines for yourself why this is the case, instead of using the standard uncertifiable option...

I can recommend that you implement this note so that the "execute preloaded" option is only available beyond the interface of the function module, always keep ALL your clients closed in PROD as programs are client independent and force the "developed" reports to follow the normal transport and coding checks you do for other programs as well, as they might have the capability of changing themselves (like all self-replicating programs, viruses, trojans, etc tend to achieve).

I am not saying that the Data Services solution intends to achieve this, but offering two SAP solutions without an integration interface for them (bar your own risk via a Z-function) is an enabler for this, unless you have very very tight security.

The solution is in my opinion still a workaround for proper and secure integration components and 9 times out of 10 will not be "lived" in the way they are intended.

There is no standard SAP solution available for checking the change options - so what you can do is schedule a simple job to check T000 for "not equal to" values and alert if found. The screen program of SE16 when displaying T000 will help you further.

Thread closed, but I will update if there are further developments.

Cheers,

Julius

[Former Member]

PS: I also recommend assigning all transported Data Integrator reports to an S_PROGRAM group using RSCSAUTH to be able to isolate them (good luck!) and assigning S_RFC authorizations using RFC_TYPE = 'FUNC' only for the one function module in the group. The value entered is truncated at the 15th character of the function module name...

This way the reports are potentially protected from the SQL statements (that depends on you) , and the reports themselves cannot call any other function modules locally which do make authorization-checks. This is only secure if you protect all RFC destinations in transaction SM59 with a client side authorization group (see documentation in transaction SU21 on object S_ICF, type DEST).

Cheers and good luck!

Julius

[Former Member]

> Thread closed, but I will update if there are further developments.

Take a carefull look at [SAP "Knowledge Base" Note 1401425 |https://service.sap.com/sap/support/notes/1401425] ...

> 1. Install the following transport file K900200.S08 on your sap server based on a unicode environment

There are 28 RFC function modules in this one function group ZAW0.

Take a closer look at them in a sandbox system, and you will also feel the relevance of the transport request number for this "integration technology".

It comes from a sandbox system called S08. It is TP request number 200. I faintly suspect that the DB is not in a "data services" center, let alone having gone through SAP's various other QA systems and code reviews....

This in an ancient security hazard and the consultants seem not to warn customers of the consequences. Please check your systems for this and open SAP customer messages to complain about it if found.

The integration between SAP BOBJ and SAP ABAP systems needs a proper and secure technology and customers should not accept this "permanent workaround" stuff.

Cheers,

Julius

[Former Member]

This problem can now be solved via the correction instructions of SAP Note 1647225.

Many thanks to SAP for fixing the problem and aligning the solution to the existing one of SAP BW.

Cheers,

Julius