SAP RFC Security

Posted by Andrea Mazzolani on Dec 2, 2022 8:15:00 AM
Andrea Mazzolani

RFC means Remote Function Call and it's the SAP standard interface that make the systems communicate between eachother.

RFC

 

Failing to configure this aspect can expose the system to a series of security problems. There are multiple aspects to keep in mind. In this article we will talk about how to protect the system from RFC calls made from third party systems or from other SAP systems.

What are the most common problems?

  • Usage of the RFC destinations to connect to less critical to most critical systems
  • RFC destinations without active encryption mechanisms
  • RFC destinations without controls on call back
  • RFC destinations accessible from outside

 

Today we're going to talk specifically about the latter aspect, in fact there are functions that SAP exposes in which there's no need for credentials in the system to obtain informations. But they could be useful for OSINT (Open-source intelligence) purposes.

 

By default, the RFC functions (remote enabled) are recalled from outside. Clearly some of these have the need for a specific user to be able to be executed (with their own authorizations). But generally speaking, they can be recalled. In the below image you can see, for example, that the RFCPING function module is recallable from outside. See the "Remote-Enable Module" active check box.

 

      RFC SAP

 

To avoid this behavior, and therefore do so that by default everything is "closed" and only the one explicitly allowed one remains open, it's necessary to activate a component called UCON Unified Connectivity.

 

In this video you can see the malevolent behavior of recalling the function module from the outside.

 

 

By using the UCON you can verify and discover if there are analog active cases in your system too. Particularly useful also for SAP FIORI.

 

What is SAP UCON and what is it used for?

SAP Unified Connectivity (UCON) is a framework present in SAP (ABAP) since the 7.40 version, and it's scope is to protect the SAP systems from RFC accesses reducing to the bare minimum necessary the number of executable modules in that mode, using the "whitelist" (Communication Assembly - CA).

 

This means that only the Function Modules, that are actually used in the system after an adequate observatory period, will be inserted in the CA and therefore accessible showing all the others instead as blocked (in SAP there are many tens of thousands of these objects compared to the real usage per type of system of a couple of hundred or rarely thousands).

 

One of the most common threats is to modify these configurations. What happens if we shut down or deactivate the services? What repercussions could happen? Let's see what could be the typical path of adoption of this tool.

 

What is the typical activation path?

The typically executed path is made up by two system analysis phases and one final phase. The first two are:

  • Logging
  • Evaluation

that last a couple of months and anyway the sum of the duration of the two phases should cover a significant period of time for a typical system usage (six-monthly, annual, etc. closures etc.).

 

Only at the end of the two analysis phases you can go to the final phase, in which the protection is activated after having adequately valorized the content of the CA (Communication Assembly).

 

The result of the Logging and Evaluation phases consists in a list that sums the calls per single Function Module, divided based on different criteria, like:

  • The user/system that executed them result therefore useful also in the case you don't want to complete the whole activation process and therefore take advantage of only the logging potential offered from the framework
  • The program used
  • The registered IP
  • And other useful informations

 

    UCON Result

 

The whole process is managed through a single transaction (UCONCOCKPIT) of which we show its main panel as an example

    UCON Fasi

 

The described path can be imagined as a chimney, from top to bottom rather than what shown above, based on the completion of the different phases.

 

Typically the two analysis phases are executed in productive environment, instead the CA configurations are executed in development environment and transported through the standard SAP transport mechanism.

 

Ask us how we can help you to activate this function the correct way!

 

 

Topics: rfc, rfc security, UCON

Yes Subscribe!

Blog Aglea, what you could find out?

Every Friday a new post, interview or content related to SAP Security.

  • Tips on how to design SAP Security
  • How to
  • Checklist
  • Common error and pitfall on security SAP
  • Interview with experts
  • Who we are and Aglea vision on SAP Security

Recent Posts

Post By Topic

See all