Note 3089413 - Capture-replay vulnerability in SAP NetWeaver AS for ABAP and ABAP Platform

Note 3089413

Overview

Trust relationships can be used to link ABAP based systems and minimize the amount of stored authentication credentials required for remote logons:

If a client system is registered to the remote server system as a calling system, no password is required for the logon. The target server system is known as the called system.

Trust relationships between ABAP based systems have the following benefits:

• A single logon for multiple systems.
• No passwords are stored on the client system or transmitted in the network.
• Timeout mechanisms for the logon data protect against illegal logon attempts.
• User-specific logon data is checked in the trusting system.

The solution described by of the security note changes the method how the calling and the called systems of a trusted/trusting relationship recognize each other. 

Goal

After updating the software, you have migrated all destinations and renewed all trusted relationships in transaction SMT1. You have removed all destinations and trust relationships which are not longer in use. You have activated a profile parameter which prevents any insecure connection. In addition you have reviewed the authorizations for S_RFCACL and S_RFC_TT.  

Here is an example of an intermediate project status concerning transaction SMT1: 

(This example shows too many trust relationships on the left page: A system should only trust few systems like a Fiori Gateway system, a Solution Manager or a central GRC Firefighter.)

How to implement the solution

All systems that use trusted/trusting destinations are affected by the potential replay attack. So especially in these systems the security note has to be implemented. 

Therefore it is required to implement the complete solution (Kernel + ABAP + migration of destinations + update of trust relationships) in both, the calling and the called systems. As long as not all pieces are available you do not get stronger security.

Procedure

1. Update Kernel in all systems
2. Update ABAP in all systems
3. Migrate destinations that use trusted/trusting relationships by executing the migration report RS_MIGRATE_TTDESTS in all systems.
   This step adds information in the destinations about the system ID (necessary) and the installation number (recommended respective necessary if a system is connected to several systems with the same system ID).
   (Run the migration report RS_MIGRATE_TO_NEW_EXT_TICKET in the SAP Solution Manager systems, too)
4. Migrate trusted and trusting relationships in all systems one by one in transaction SMT1.
   This step creates new, individual keys and stores them in the "Secure Store" (and no longer in a database table). This is the crucial action!
5. Set profile parameter rfc/allowoldticket4tt in all systems to block connections that were not updated via step 3. and 4.

Informational notes

FAQ Note 3281854 - FAQ for Security Note 3089413

Consulting note 3224161 - Prerequisites for Note 3089413
The note describes the minimum software levels to implement the solution

Consulting note 3157268 - How-To-Guide: Migration of Trusted/Trusting Relationships

Correction notes for ABAP

Implement required prerequisite notes beforehand (see below).

Security note 3089413 - [CVE-2023-0014] Capture-replay vulnerability in SAP NetWeaver AS for ABAP and ABAP Platform 
Contains (a quite large) TCI and automatic correction instructions for transaction SNOTE
During TCI implementations various short dumps like LOAD_*_VERSION_MISMATCH, CALL_FUNCTION_CONFLICT_* may occur. Just repeat the TCI import in that case.


Correction note 3287611 - Bugfixes in Trusted/Trusting Migration (was: Error in Migration Report RS_MIGRATE_TTDESTS)
Contains automatic correction instructions for transaction SNOTE
Please check for latest version before starting migration. Version 2 of this important correction note was published on 26.01.2023

For the SAP Solution Manager you use 2 additional notes which contains automatic correction instructions for transaction SNOTE:

Correction note 3283990 - Trusted RFC creation in SOLMAN_SETUP after implementing security note 3089413

Correction note 3284618 - Migration Report RS_MIGRATE_TO_NEW_EXT_TICKET for New External Ticket

Related notes

Note 3127135 - Improved RFC ticket handling
Version 1 from 10.01.2023
The note describes the Kernel update

Note 3203082 - Improve TRUSTED RFC generation in the Retrofit process
Version 2 from 16.01.2023
Required if you are using the Retrofit function in Change Control Management

Note 3238586 - RFC_NO_AUTHORITY after implementing note 3127135
Version 3 from 24.08.2022
The note describes potential issues with the user BGRFC_SUPER and the bgRFC scheduler programs in case of using older Kernel versions than the versions listed in the "prerequisite" section.

Note 3246345 - rfc/sendInstNr4tt is not working
Version 2 from 11.01.2023
The note solves further issues in case you are using profile parameter rfc/sendInstNr4tt to deal with non-unique system ids in the system landscape. The note will be updated as soon as the corresponding kernel patches are available.  

Note 3286477 - Empty Destination in sm59
Version 2 from 03.01.2023
New report RS_DELETE_EMPTY_RFCDES deletes the useless empty destination

Note 3288422 - After SAP_BASIS 7.00 SP 40 Syntax error in program "SAPLCRFC"
Version 5 from 11.01.2023
The issue described in this note is solved with the installation of note 3089413

Note 3291426 - Avoid Syntax error in CL_APCRFC_VER_BASE_TEST after applying 3089413
Version 2 from 17.01.2023
Correction on SAP_BASIS 7.52

Consulting note 2187425 - Information about SAP Note Transport based Correction Instructions (TCI)

Prerequisites

Minimum Kernel

The solution works only if both the client systems as well as the server systems of a trusting/trusted connection runs on a suitable Kernel version:
(The grey version numbers are listed in some of notes, however, the complete solution requires the highest versions across all notes.)

7.22       1214
7.49       Not Supported. Use 753 / 754 instead
7.53       (1028) 1036
7.54       18
7.77       (500) 516
7.81       (251) 300
7.85       (116, 130)  214
7.88       21
7.89       10

Minimum SAP_BASIS for SNOTE

You only can implement the notes 3089413 and 3287611 using transaction SNOTE if the system runs on a suitable ABAP version:

SAP_BASIS 700  SP 35 (solved with SP 41)
SAP_BASIS 701  SP 20 (solved with SP 26)
SAP_BASIS 702  SP 20 (solved with SP 26)
SAP_BASIS 731  SP 19 (solved with SP 33)
SAP_BASIS 740  SP 16 (solved with SP 30)
SAP_BASIS 750  SP 12 (solved with SP 26 → 27)
SAP_BASIS 751  SP 7 (solved with SP 16 → 17)
SAP_BASIS 752  SP 1 (solved with SP 12 → 13)
SAP_BASIS 753  (solved with SP 10)
SAP_BASIS 754  (solved with SP 8)
SAP_BASIS 755  (solved with SP 6)
SAP_BASIS 756  (solved with SP 4)
SAP_BASIS 757  (solved with SP 2)

Prerequisite ABAP notes

You only can implement the notes 3089413 and 3287611 if following prerequisite notes are either not required or installed. Take care to implement the notes in the given order! Some of the notes have manual activities, too, which you have to execute before implementing the next notes. You should gather all notes and the changes of the manual activities on the same transport.

Warning: Before you start implementing the correction instructions about OAuth, you must take a backup of the development system as a restore might be required. 
The reason for this is that central ABAP programs get touched and if an error occurs that you cannot rollback the change using transaction SNOTE.
Do not forget to execute the correction reports described in the manual post activities of some of the notes!

[...] 

Note 2270223 - Unnecessary error message in transaction SM59 if router strings are used

Note 2464596 - System PKI: Improvements in test programs
Prerequisite for SAP_BASIS 7.40
SNOTE + manual activity to adjust a GUI status of a program

Note 2820414 - OAuth 2.0 Client - Report for generic use of OAuth 2.0 Client configuration
SNOTE

Note 2927569 - Lock error when deleting several RFC destinations
SNOTE + manual activity to adjust a DDIC object

Note 2942276 - RFC_METADATA_GET support for CDS and INT8
Prerequisite for SAP_BASIS 7.40
SNOTE

Note 3104738 - OA2C: Enhancements for OAuth 2.0 Client interface to CL_HTTP_CLIENT (DDIC Objects generation)
Prerequisite for SAP_BASIS 7.50, 7.51
SNOTE + manual post activity to execute report SOAUTH2_CLIENT_NOTE_3104405 
(The report will generate the DDIC objects required for application of note 3104405.)

Note 3113055 - OA2C: Downport of grant type Client Credentials (DDIC objects generation)
Prerequisite for SAP_BASIS 7.50, 7.51
SNOTE + manual post activity to execute report SOAUTH2_CLIENT_NOTE_3041322
(The report will generate the DDIC objects required for application of note 3041322.)

Note 3105486 - OA2C: Clock Skew Tolerance (DDIC Objects Generation)
Prerequisite for SAP_BASIS 7.50, 7.51, 7.52 – 7.55
SNOTE + manual post activity to execute report SOAUTH2_CLIENT_NOTE_2952190
(The report will generate the DDIC objects required for application of note 2952190.)

Note 2952190 - OA2C: Clock Skew Tolerance
Prerequisite for SAP_BASIS 7.40 – 7.55
SNOTE

Note 3104405 - OA2C: Enhancements for OAuth 2.0 Client interface to CL_HTTP_CLIENT
Prerequisite for SAP_BASIS 7.50, 7.51
SNOTE

Note 3041322 - OAuth 2.0 Client: Downport of grant type Client Credentials
Prerequisite for SAP_BASIS 7.50, 7.51
SNOTE

Note 3120902 - OAuth 2.0 Client: Downport of method SET_TOKEN_AUTOMATIC (DDIC objects generation)
Prerequisite for SAP_BASIS 7.50, 7.51, 7.52 – 7.55
SNOTE + manual post activity to execute report SOAUTH2_CLIENT_NOTE_3120024
(The report will generate the DDIC objects required for application of note 3120024.)

Note 3120024 - OAuth 2.0 Client: Downport of method SET_TOKEN_AUTOMATIC
Prerequisite for SAP_BASIS 7.50, 7.51, 7.52 – 7.55
SNOTE

Note 3146766 - NI_NAME_TO_ADDR and NI_ADDR_TO_(FQ)_NAME are limited to 63 characters
Prerequisite for SAP_BASIS 7.00 – 7.56
On SAP_BASIS release 7.00 up to SP 39, 7.01 up to SP 24, 7.02 up to SP 24, and 7.31 up to SP 30 you have to implement at least version 13 from 21.01.2023 via transaction SNOTE to get the ABAP correction instruction for these releases.
SNOTE + manual activity to create a DDIC object, do not forget to change the length of the new data element to 256 characters. You can ignore the warming about "Output length (256) is greater than maximum output length (255) on dynpros".

Note 3266103 - Empty error message creating new Trusted/Trusting relation
SNOTE

You can copy&paste following list of notes into transaction SNOTE to download and review all potential relevant notes in one step:

2187425
2270223
2464596
2820414
2927569
2942276
3104738
3113055
3105486
2952190
3104405
3041322
3120902
3120024
3146766
3266103
3089413
3283990
3284618
3287611

Here is a typical result:

Depending on the age of the system you could end up with a transport which already contains more than 100 objects. 

Now you can implement the notes 3089413 and 3287611 which add some more hundreds of objects to the transport.

Here is a typical result:

How to identify systems using trusting/trusting connections

Do there exist trusting/trusted relationships?

a) Run new report RS_DISPLAY_TT_INFO to show a list of trusted servers and trusting clients.

(The report does not indicate if a trusted relationship is already migrated.)

b) Check both tabs in transaction SMT1

(The lock icon shows if a relationship is already migrated or not.)

c) Check tables RFCSYSACL (systems whose calls are trusted) and RFCTRUST  (systems that trust current system) in transaction SE16 

Entries in table RFCSYSACL showing an empty field RFCSECKEY and showing version number 3 in field RFCSLOPT indicate migrated trusting relationships.

d) Inspect configuration store RFCSYSACL in the SAP Solution Manager or FRUN to get a cross-system report about trusted systems.

Migrated trusted relationships show the version number 3 as first character in field value RFCSLOPT.

(There does not exists a similar store for trusting systems.)

Example from FRUN:
(Hint: Try both views, the standard view and the table view, to download data to Excel)

A corresponding policy for FRUN could look like this:

<?xml version="1.0" encoding="utf-8"?>
<targetsystem xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" desc="Updated trusted relationships according to note 3089413" id="RFCSYSACL_OPT3" multisql="Yes" version="0001" xsi:schemaLocation="csa_policy.xsd">
  <!-- [p1-CVSS 9.0]  BC-MID-RFC 0003089413 - [CVE-2023-0014] Capture-replay vulnerability in SAP NetWeaver AS for ABAP and ABAP Platform (Version 0011)  -->
  <configstore name="RFCSYSACL">
    <checkitem desc="[p1-CVSS 9.0] Updated trusted relationships according to note 3089413" id="0003089413" not_found="ignore">
      <compliant>
                  RFCSYSID like '%' and 
                  TLICENSE_NR like '%' and
                  RFCTRUSTSY like '%' and
                  RFCDEST like '%' and
                  RFCTCDCHK like '%' and 
                  RFCSNC like '%' and
                  RFCSLOPT like '3%'
      </compliant>
      <noncompliant>
                  RFCSYSID like '%' and 
                  TLICENSE_NR like '%' and
                  RFCTRUSTSY like '%' and
                  RFCDEST like '%' and
                  RFCTCDCHK like '%' and 
                  RFCSNC like '%' and
                  RFCSLOPT not like '3%'
      </noncompliant>
    </checkitem>
  </configstore>
</targetsystem>

A typical result in FRUN using this policy could look like this:

In the SAP Solution Manager you can construct a target system like this:

Do there exist destinations using a trusting/trusted relationship?

a) Run report RSRFCCHK for the connection types 3, H, and W and activate the checkbox about destinations without explicit passwords. Then use a filter for column "Trusted system". Caution: this column shows misleading information as it does not distinguish between the values Y=Trusted RFC, B=basic authentication or A=no user but shows an active mark in all of these cases.

(The report does not indicate if a trusted destination is already migrated.)

b) Run new report RS_DISPLAY_TT_INFO to show a list of trusted/trusting destinations.

(The report does not indicate if a trusted destination is already migrated.)

c) Check table RFCDES in transaction SE16 for entries with RFCTYPE = 3, W, or H and one of the RFCOPTIONS fields containing *,Q=Y* (this is not 100% reliable as the token could be part of two fields).

d) Open each 3, W, or H destination in transaction SM59 and inspect tab "Logon & Security" for the radio button about the "Trust Relationship". Destinations which already show the correct system id (mandatory) and installation number (recommended) are already migrated.

Example for an RFC destination (not migrated yet):

Example for an http destination (already migrated):

e) Inspect configuration store RFCDES in the SAP Solution Manager or FRUN to get a cross-system report

The field RFCOPIONS shows a string with all RFC options, you have to look for the token Q=Y which indicates trusted/trusting destinations. Therefore, use *Q=Y* as element pattern to find these elements directly in transaction CCDB.  

Migrated destinations show values for the tokens [= for the system id (mandatory), and ^= for the installation number (recommended).

Example from SolMan:

The configuration stores RFCDES_TYPE_3 and RFCDES_TYPE_3_CHECK indicate trusted/trusting destinations in field TRUSTED_SYSTEM but do not show the other tokens mentioned above.

The configuration store RFCDES_TYPE_H seems to show fields like TRUST_SERVERSYSID and TRUST_SERVERINSTNT but it's not yet confirmed that these fields indicate migrated entries.

There does not exist a special store for type W destinations. 

Do there exist not-used trusted destinations?

Destinations which are not in use for a couple of month might be candidates for deletion.

You can use transaction STRFCTRACE to show incoming RFC usage based on the data from the Workload Statistics (see transaction ST03N). You can consolidate the result to show a list of active incoming destinations including how often they have been used. Unfortunately you cannot get a list of not-used inactive destinations this way.

Example:

In addition, you can use the custom report ZRFC_STATRECS_SUMMARY to show a list of outgoing destinations including how often they have been used based on the data from the Workload Statistics (see transaction ST03N). The list could include not-used inactive destinations, too. You can get the report from Github.

Choose a date range for the data from the workload statistics, use the data option CLD (Client Destinations) and activate the checkbox to show unused destinations, too.

Use the ALV functions to hide some columns, filter for ‘RFC type‘ = 3*, H*, W* , filter for ‘Trusted RFC’ = Y and to add subtotals to the target column. 

Save an ALV variant and enter it on the selection screen, too.

You can open the details and navigate into transaction SM59:

How to use the migration report RS_MIGRATE_TTDESTS

The report validates all trusting/trusted destinations and adds the correct system id and installation number if missing.

There is no test mode.

You do not get any result if there do not exist any trusting/trusted destinations.

You can start it either via transaction SA38 or as a generated background job via transaction SMT1 (in this case you would inspect the job log of generated job MIGRATE_DESTINATIONS). Using the job is preferred because it can handle potential timeouts in RFC connections better.

[...]

How to use the migration report RS_MIGRATE_TO_NEW_EXT_TICKET on a SAP Solution Manager system

You can use the test mode first.

[...]

How to migrate trusting relationships in all systems

Use transaction SMT1 to migrate (= re-create) the existing trusted relationships.

Select a system, which shows an old insecure trust relationship (open lock symbol) and use the 'Secure Connection' button.

Enter a valid administrator user (having change authorizations for S_RFC_TT) with password and choose the language and client for the trusted system.

Enter the SNC name of the trusted system if SNC is configured and available between these both systems to encrypt the connection.

Enter the server host and instance number of the trusted system if necessary.

(The current version of the popup shows the language and the client for the trusted system, too.)

The migration uses the predefined destination (which usually has a name like TRUSTED@<sysid><installation>) as a reference to connect to the trusted system into the chosen client. It first verifies if the migration will work on both systems before actually doing it.

The migration actually re-creates the trusted relationship in the server system and the trusting relationship in the client system. Therefore the users require activity 01 (=create) in addition to activity 02 (=change) for authorization object S_RFC_TT.

As the result you will see a locked icon on tab "Systems whose calls are trusted" in SMT1 in the current server system and a locked icon on tab "Systems that trust current system" in SMT1 in the client system.

The table RSCSYSACL now shows an empty field RFCSECKEY and the value in field RFCSLOPT starts with the version number 3. The keys are now stored in the "Secure Store" which you can validate using transaction SECSTORE. You find the corresponding entries in application "Secure Hash Function (HMAC)" with keys like /HMAC_INDEP//ett/<SysId1>/<InstallNumber1>/<SysId2>/<InstallNumber2>

[...]

How to use the profile parameters

Profile parameter rfc/allowoldticket4tt

As soon as you have migrated a system or have finished the migration for a group of connected systems you may want to prohibit any insecure connection which might get implemented later on. You can use profile parameter rfc/allowoldticket4tt to allow or forbid the old (target-system-independent) trusted/trusting method.

You can change the value dynamically in transaction RZ11 without restarting the system (but do not forget to change it in the default profile, too).

Values:

both (default) - old method allowed as client and server
client - old method allowed as client
server - old method allowed as server
no - old method not allowed

After migration of all trusted relationships via transaction SMT1 in one system you can set profile parameter rfc/allowoldticket4tt = client in this system to secure this server system and permit only secured incoming connections.

After migration of all trusted and therefore implicitly also all trusting relationships via transaction SMT1 in the whole system landscape you can set profile parameter rfc/allowoldticket4tt = no in all systems to permit only secured connections.

Profile parameter rfc/sendInstNr4tt

The installation number in the destinations is only mandatory in client systems which have trust relationships to multiple server systems having the same system id. However, it's recommend to use the field in any case. The profile parameter rfc/sendInstNr4tt in server systems allows the report RS_MIGRATE_TTDESTS (which you execute in client systems) to fill this field automatically.

You can change the value dynamically in transaction RZ11 in server systems without restarting these systems. As you need the parameter only during the migration, it might not be necessary to add the parameter to the default profile. You do not need this profile parameter if you enter the installation number manually into the destinations.

Activating the profile parameter allows the installation number to be sent in a logon-free state.
If unknown, the trusted/trusting method determines the system ID and installation number automatically. If the system ID is unique, the installation number is optional. The profile parameter is used to determine whether the sending of the installation number is allowed in a logon-free state.
Values:

0 (default) - installation number cannot be sent
1 - installation number can be sent

What else should I do?

• Verify if existing trusted/trusting relationships are required (Caution: a relationship might be required for RFC as well as for http connections)
• Verify if existing trusted/trusting destinations are still in use (see transaction ST03N)
• Consider to use SNC (respective https) on top of trusted connections
• Consider to activate the setting "use transaction code" for all trusted relationships in transaction SMT1 (which might require to update authorizations for S_RFCACL)
• Verify and reduce authorizations for S_RFCACL, especially in case of the switch-user scenario based on EQUSER = N (respective the access control entries which you might have defined in transaction SMTACL)
• Protect access to table RFCSYSACL by assigning it to the table authorization group TTRL and by using authorization object S_TABU_DIS / S_TABU_NAM
• Verify authorizations for authorization objects S_RFC_TT and S_RFC_ADM

• Verify profile parameter rfc/selftrust = 0

[...]

What about old reports RS_SECURITY_TRUST_RELATIONS and RS_UPDATE_TRUST_RELATIONS?

These reports had been introduced with note 1491645. Do not use these reports.

Report RS_SECURITY_TRUST_RELATIONS lists trust relationships similar to the view in transaction SMT1 and offers to delete superfluous entries. However, it does not  understand the new security method 3, and therefore would show false results.

Report RS_UPDATE_TRUST_RELATIONS is outdated as well as it does not  understand the new security method 3. 

Known issues

The following issues are under investigation and will be solved soon:

• The migration report RS_MIGRATE_TTDESTS shows a wrong name of a profile parameter in some of the messages. The correct name of the profile parameter is rfc/sendInstNr4tt.

Solved:

• Solved with correction note 3287611 version 2 from 26.01.2023:
  • If you execute the migration report RS_MIGRATE_TTDESTS via transaction SA38 online (but not as a background job e.g. via transaction SMT1) then you got a misleading negative result even for already migrated destinations.
  • Transaction SMT1 shows a popup when you migrate a trust relationship. On that popup, the input field about the SNC name was too short (33 instead of 255 characters), therefore you could only renew trust relations with active SNC if the SNC name of the trusting system fits into that field.
  • Transaction SMT1 shows a popup when you migrate a trust relationship. It was unclear which client is used in the trusting system. Now you enter the client into an input field.