Sunday, 21 February 2021 16:10

Protecting web methods offered by SAP Instance Agent

Written by Johannes Goerlich
Rate this item
(0 votes)
“© 2020. SAP SE or an SAP affiliate company. All rights reserved.” “Used with permission of SAP SE”

SAP Instance Agent, also known as SAP Start Service or SAPStartSrv, offers web methods as SOAP Web Services to control a SAP instance. By default some of these web methods can be executed without prior authentication.
This means every client with access to the ports of SAPStartSrv may be able to call several web methods without authentication! This may have impact on the availability, integrity of the system and could also be utilized by adversaries to gather information about a target system.

The latest blogpost i could find on the topic of protected webmethods was written by Benjamin Nenninger in 2018:

In the meantime almost all SAP products (SAP NW AS Java seems to be a special case here, see below) leveraging any of the web methods of SAPStartSrv have been updated and there should be no need to allow unauthenticated access for them any longer.
In other words in standard scenarios there should be no need for unprotected web methods anymore and the parameter service/protectedwebmethods = ALL could be set without any side-effects. But now lets go into details…..

I recommend to also take a look at my blogpost Protecting web methods offered by SAP Host Agent.

SAP Instance Agent / SAP Start Service / SAPStartSrv

In the following i will do the question and answer game (as you may recognise from other blogposts of myself) to develop a basic understanding of the SAP Instance Agent and its web methods.

Where do we find the SAP Instance Agent?

Typically we can find it on SAP NetWeaver AS ABAP or AS Java, SAP WebDispatcher, SAP HANA DB, SAP Trex, but also on other SAP products.

SAP Instance Agent also known as SAPStartSrv reads its parameters from the the instance profile or the DEFAULT.PFL. When no values are found it falls back to the Kernel default values.

Which ports are used by SAPStartSrv?

By default it binds 5$$13 (HTTP) and 5$$14 (HTTPS), where $$ is the instance number to the instance the SAP Instance Agent belongs to.

On which ip addresses are these ports accessible?

By default sapstartsrv binds its ports on all available NICs (indicated by

~> sudo ss -tlpn | grep -e 5..1[34] LISTEN 0 20* users:(("sapstatsrv",pid=13585,fd=10)) LISTEN 0 20* users:(("sapstatsrv",pid=13585,fd=9)) LISTEN 0 20* users:(("sapstatsrv",pid=2118,fd=12)) LISTEN 0 20* users:(("sapstatsrv",pid=2118,fd=9))

This could be adjusted by parameters ‘service/hostname’, ‘service/http/hostname’, ‘service/https/hostname’.

For example ‘service/hostname’ and ‘service/http/hostname could be set to and ‘service/https/hostname’ could be set to $(SAPLOCALHOST) to reduce the attack surface.

~> sudo ss -tlpn | grep -e 5..1[34] LISTEN 0 20* users:(("sapstatsrv",pid=13585,fd=10)) LISTEN 0 20* users:(("sapstatsrv",pid=13585,fd=9)) LISTEN 0 20* users:(("sapstatsrv",pid=2118,fd=12)) LISTEN 0 20* users:(("sapstatsrv",pid=2118,fd=9))

Can access to these ports be secured by any ACLs?

Access to these ports can be controlled individually by an ACL defined in parameter ‘service/http/acl_file’ for http and ‘service/https/acl_file’ for https.

This should be considered if for example no proper network separation is in place.

What clients are accessing these ports?

Typical clients are SAP MMC, SAP MC, sapcontrol, saphostctr. But there may be also custom developed scripts or 3rd party tools, e.g., for monitoring purposes or start/stop of systems. For testing or troubleshooting also postman or SoapUI may be used as a client.

What is served on these ports?

SAPStartSrv offers web methods as SOAP Web Services according to the so called Porttypes configured in profile parameter ‘service/porttypes’.

A WSDL is available at https://<hostname>:5$$14/?wsdl

Which web methods can be accessed without authentication?

This depends on the setting of profile parameter ‘service/protectedwebmethods’.

SAP has grouped some of the web methods in ‘protection groups’ (not an official term). Parameter ‘service/protectedwebmethods’ allows to specify one of the following groups (from least to most protective):

1. ‘NONE’



4. ‘ALL’

In addition to that we can extend or reduce these predefined groups. We can add protection for web methods by appending +<name-of-webmethod> or remove protection by appending -<name-of-webmethod>.

To determine the protected web methods we can do the following:

1. Set the parameter to the desired value.

 2. Restart the Instance Agent for the changes to take effect (!):
sapcontrol -nr <instance number> -function RestartService

3, Export a list of all webmethods:
sapcontrol -nr <instance number> -function GetInstanceProperties | grep -i webmethods | grep -vi protected | tr ',' '\n' | tr -d ' ' | sort > all.txt

 4. Export a list of the protected webmethods:
sapcontrol -nr <instance number> -function GetInstanceProperties | grep -i webmethods | grep -i protected | tr ',' '\n' | tr -d ' ' | sort > protected.txt

5. Compare both lists.

For the settings ‘NONE’ and ‘ALL’ the compare will not work, because the output for protected methods will either be the string ‘NONE’ or ‘ALL’.

With sapcontol 7.53 PL700 for example we get a list of 169 web methods in total, where the setting SDEFAULT will protect 154 and DEFAULT protect 87 of them.

What web methods are not protected with setting SDEFAULT?

With SAPStartSrv 7.53 PL700 the following web methods are not protected with setting SDEFAULT:


Please note: Some of them could be abused for information gathering.

Which authentication methods are supported in general by SAPStartSrv?

OS level authentication using Unix domain sockets or Windows named pipes,

Local Logon ticket (requested by web method RequestLogonFile),

Username and password for OS users,

Client certificate (X.509).

Which users are allowed to authenticate?

SAPStartSrv has no own user store. The authentication relies on users configured for access.

The user <sapsid>adm running the SAPStartSrv proccess is always allowed to authenticate.

Additional OS users may be defined by profile parameter ‘service/admin_users’

OS user groups may also be defined by profile parameter ‘service/admin_groups’.

Besides authentication with OS users it is also possible to allow additional users to authenticate with X.509 client certificates. Therefore, their certificates’ DN has to be configured in profile parameter ‘service/sso_admin_user_<xx>’.

Please note: This parameter also supports wildcards ‘?’ or ‘*’, which have to be used carefully.

What about authorisations?

This is a very valuable question. And this question may undermine the concept of protected web methods to a certain extend!

SAPStartSrv doesn’t have an own user store, nor does it provide any concept to handle authorisations! We will see the possible impact in a few.

How to achieve protecting all web methods without any side-effects?

Simply by making sure every client is properly authenticated.

Why do we may not want to protect all web methods?

As stated before there is no authorisation concept involved. Meaning an authenticated client will be able to call any available web method.

There may be scenarios which involve clients for which we have to follow a risk based approach.

For example, there may be a 3rd party monitoring tool which should be allowed to check certain metrics only, e.g., using a web method providing read only access.
In this case we may not want this 3rd party application to be authenticated and implicit be  able to also execute web methods allowing to exfiltrate (log) data, stop the system or to even make any changes.

Why should we still start with service/protectedwebmethods=ALL?

In any case we should start with setting parameter service/protectedwebmethods = ALL.

For standard scenarios there shouldn’t exist any blocking points to do so.

For custom developed or 3rd party tools we should analyse if these clients should indeed have access to all web methods. If not we have then to make sure they communicate without prior authentication.

Then we have to exclude the relevant web method(s) from protection by adjusting the parameter, e.g., service/protectedwebmethods = ALL -GetAlerts.

Following this approach we have full transparency about web methods which are allowed to be called unauthenticated.

Please note: In such special scenarios we should strongly consider to implement the ACL(s) to protect access to SAPStartSrv in addition to proper network separation.

Authentication for common clients

Authentication by sapcontrol

Sapcontrol by default will use OS level authentication.

If started on the same with user <sapsid>adm no additional credentials are needed.

sapcontrol may also be started with -user "<username>" "password" or -queryuser  to authenticate with any user listed in profile parameter `service/admin_users` and present on OS level.

Please note: The OS user must have set a password. In SSH-key only environments this may not always be the case.

sapcontrol may be started with -prot NI_HTTPS to authenticate with an X.509 client certificate stored in the SAPSSLC.pse. This pse must be trusted by importing the trustchain (or self-signed certificate) into it.

Recent versions of SAPStartSrv will create a so called systemPKI (this is independent from the setting of profile parameter `system/secure_communiation`). SAPStartSrv allows to use this for X.509 based authentication. Even if SAPStartSrv uses by default an existing SAPSSLC.pse, the systemPKI (stored in the sap_system_pki_instance.pse) may be leveraged for authentication. To make sapcontrol use the systemPKI it has to be started as <sapsid>adm with -systempki <profile> (the correct pse will be addressed using SNI).
This can also be used to authenticate at a SAPStartSrv running on a remote host of the same SAP NW AS ABAP system (belonging to the same systemPKI).

Authentication by sapcontrol on Windows

Sapcontrol on windows may also be started with -prot WINHTTPS. This would lead to sending a suitable client certificate – if present in the windows certificate store.

The certificates DN must be maintained in parameter service/sso_admin_user_<xx> to allow logon.

Authentication by SAP MMC

SAP MMC supports X.509 authentication if we activate HTTPS in the “Security” properties of the MMC configuration.
It will send a suitable certificate (depending on the issuer) if present in the windows certificate store.
The certificates DN must be maintained in parameter service/sso_admin_user_<xx>.

Authentication by SAP Host agent (SAPHostControl)

The SAP Host Agent may proxy requests to the SAPStartSrv.

To allow OS level authentication from SAPHostControl we can set the profile parameter service/admin_users = sapadm.

Authentication by Simple Diagnostics Agent

The Simple Diagnostics Agent of FocusedRun uses the SAP Host Agent instance gateway to connect to the SAPStartSrv. SAP Host Agent will proxy requests from SDA to SAPStartSrv.

Authentication by SUM (Software Update Manager)

SUM registers itself to the SAP Host Agent. SAP Host Agent will then be used to start SAPUp process. The SAPUp process will authenticate to SAPStartSrV on OS level by <sapsid>adm or by using the systemPKI.

Authentication by Solution Manager Diagnostics

For SAP Diagnostics Agent to authenticate with user <smd>adm we can configure parameter service/admin_users = daaadm. On Windows systems it would be service/admin_users = <domain>\SAPServiceDAA.

Authentication by Flash component of nwa – System Overview in SAP NetWeaver AS Java

According to SAP note 2544271 both web methods ‘PerfRead’ and ‘MtGetTidByName’ are necessary to display all information in the System Overview of nwa. These both are protected as of setting ‘DEFAULT’ or higher.

Since Flash has finally reached End-of-Life, a replacement for the System Overview in nwa was announced by SAP in SAP note 3013115. At time of writing i had no information if this replacement will then still need to access these both web methods unauthenticated.

Authentication by Log Viewer and Start&Stop in nwa in SAP NetWeaver AS Java

The the Log Viewer tool of SAP NW AS Java uses the Java standalone Web service proxy to communicate with SAPStartSrv.

While SAP note 1631616 (dated to 2013(!)) indicates that authentication issues should be fixed in the Java standalone Web service proxy, other more recent SAP notes still addresses this issue:

According to SAP note 2577844 and 2506964 the web methods ‘GetVersionInfo’, ‘ListLogFiles’, ‘ReadLogFile’, ‘ParameterValue’, ‘J2EEGetProcessList’, ‘PerfRead’, ‘MtGetTidByName’, ‘UtilSnglmsgReadRawdata’, ‘getTidsByName’ are necessary to provide the necessary functionality.

I couldn’t find any final statement from SAP whether these issues are all fixed in the meantime.

In my test environment (SAP NW AS Java 7.5) i couldn’t reproduce the issue with Log Viewer and log files could be displayed with setting ‘SDEFAULT’.

Authentication by SSL Wizard in nwa in SAP NetWeaver AS Java

According to SAP note 2510099 the SSL Wizard needs the web method ‘GetAccessPointList’ to display the correct status of SSL ports.

I hadn’t the change to test if this works in later releases even if the web method is protected. The decision is up to anyone if this functionality is vital.

Read 36 times

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.