Security Geeks Introduction to SAP – RFC Destinations

As means of a background, I have been in the security field, specifically the pro-active testing (penetration testing) side of security for over a decade. As part of my role I would present at public and private conferences, helping to educate organizations about the benefits of pen testing or helping to educate pen testing teams about the latest techniques.

I say all of this in order to communicate that I would grade myself as having an above average knowledge of the security space and significant familiarity with commonly used terms in the industry. So when I recently took a product manager roles at Onapsis and was told I would have to learn about SAP and the security and risk implications around SAP in the enterprise I smiled and thought “well, I guess I know what I am doing the first couple of days”. As it turns out SAP is a world unto itself, with a lot of history and complexity.

This blog is the third in a series that documents the self-education that I have been undertaking as I learn about SAP, assessing the security of a SAP system and then implementing secure practices.

This blog builds on a webcast I was fortunate to take part in. My colleague Sergio Abraham has spent a considerable amount of time research RFC Destinations, the common ways they are configured and how various SAP components install RFC Destinations in order to function. I recommend in addition to this blog you view the webcast recording here and the corresponding question and answer session it generated here.

SAP systems do not existing in a vacuum, their function is to process and store data and make decisions based on the data or expose the data in the best possible way to allow humans to make decisions. This data has to come in and out of the SAP systems, and it does so through something called RFC Communications which has two main components: an RFC Function Module that specifies what is going to be performed and an RFC Destination that specifies where it is going to be performed. In my mind I have been comparing RFC Destinations to VPN connections, a RFC Destination will connect two SAP systems or connect a SAP system with an external resource.

These connections allow data to flow around the system, getting to where it is needed to allow the business to run and the correct decisions to be made. The problem is the risk of someone piggybacking on the connection and abuse the connection to gain access to that same data or control of those end points.

To better understand let’s have a look at how you create a RFC Destination. I have simplified the instructions provided by SAP here - to create a new RFC Destination a SAP user (with sufficient rights) would:

  1. Define the IP address of the target system to be connected to
  2. Provide the Instance number of the remote SAP system
  3. Provide the username & password the connection should use to authenticate with (optional)

Step 3 is optional, but when you consider the alternative is providing a username and password each time you access the RFC Destination you can guess how common it is for these credentials to be hard coded.  In addition to that we see two other critical (and compounding) problems.

Use of interactive users for the hardcoded credentials. If you have a connection to a SAP system with a RFC Destination that has an interactive user hardcoded then any user with access to that SAP system is one button click away from SAPGUI access to the endpoint system. They will inherit the rights of that hardcoded user account.

And therein lies the second and compounding problem, we all believe in the concept of least privilege; that is until a critical business process or update fails because the RFC Destination account doesn’t have the full set of rights required. So the account gets a few more rights; then a different issue occurs and the rights increase. Eventually you end up with a hardcoded user with significant rights to the target system; which anyone who gains access to this initial system can inherit.

Oh, and what if that system they have access to also has RFC destinations to even more critical systems…

So, how do I know if I have insecure or risky RFC Destinations configured on my SAP systems? It is a multistep manual process as follows:

  1. Generate a list on a given SAP system of all the RFC Destinations on a system
  2. For each RFC Destination note the account it uses for authentication
  3. On the target system for each RFC Destination review the privileges of the user identified in step 2
  4. On each system that is an endpoint for a RFC Destination; review the RFC Destinations configured on that system to identify any possible chains of attack.

If you will notice above doing this requires you to have access to all SAP systems involved, and manually connect to and review information in each of those systems. Or you could run the RFC Topology Map feature within Onapsis X1 and have it all done in seconds for you – contact me if you are interested in learning more.

So what can we as security professionals do? The problem exists for the typical reasons, human beings took the shortest and quickest parts to get a job that was urgent done. Without the proper knowledge of the real and present danger to the business these configurations create these insecure configurations. As security professionals we need to educate and demonstrate the true risk present, and support the organization as they work to raise their security and practices to an acceptable level.

 

Share Button
This entry was posted in Corporate and tagged , , , , , , , , by Alex Horan. Bookmark the permalink.

About Alex Horan

Alex Horan is a Product Manager at Onapsis Inc. where he is responsible for the development of ERP vulnerability assessment, testing and securing solutions. Alex has over 15 years of experience working within the IT security industry, covering both software and hardware. As a result he brings a deep knowledge and understanding of vulnerability assessment and penetration testing, as well as systems and network administration and auditing to his work at Onapsis. Alex has previously worked for mid- and large-sized companies helping to design and maintain their security posture.

One thought on “Security Geeks Introduction to SAP – RFC Destinations

  1. The analysis of using Trusted Relationships has to be performed against the benefits of Stored Credentials. You can set your destinations using either method and they are equally useful.

    The main advantage of using Stored Credentials is its easy-maintenance. You just need to load the credentials of the remote system and that’s it. But if you are not using SNC these credentials can be read by sniffing the network (remember that RFC is a plain-text protocol).

    Otherwise, Trusted Relationships add a new layer of security. In this case you only need to load a user of the remote system, but you are required to configure specifically the authorization S_RFCACL in the remote system. This object determines who is able to use that Trust Relationship. So here you find two opposites, if you configure this object with wildcards (*) that destination becomes the most insecure, but if you made a good analysis of this object and it is well configured you can be sure it will be quite secure.

    The main disadvantage is the addition of extra effort to configure each destination, and the ongoing maintenance becomes harder.

    Sergio Abraham
    Alex Horan

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>