www.opel.com

Markus Seibel

SAP SECURITY BEYONDAUTHORIZATIONS

Vulnerability of SAP-Systems using the example of „Remote Function Calls“

AGENDA.

1. Introduction2. Overview – the RFC architecture3. ABAP RFC – Security considerations

1. The Object S_RFC2. Demo: „3 … 2 … 1 … SAP_ALL“3. System configuration and administration4. Approach to restrict S_RFC

4. Gateway Security – often neglected5. Summary – 10 rules for RFC security

Markus Seibel

TABLE OF CONTENTS2

3

Security beyond authorizations

INTRODUCTION

AGENDA.

• SAP systems are often part of heterogeneous system landscapes(many communications interfaces), often even connected to theinternet

• Security in SAP systems must be considered across severallayers (operating system, database, network, SAP application,ABAP/JAVA Stack)

• SAP systems are more and more targets of hacker attacks andindustrial espionage

SAP note 1504652:Secure Configuration of Application Server ABAPSAP_Security_Recommendations_ABAP.pdf

Security beyond authorizations

INTRODUCTION4

AGENDA.

BIZEC ( www.bizec.org ):• SAP security is a complex discipline. It must be addressed holistically• While functional security (e.g. segregation of duties) is highly important, there

are many other threats, which imply higher levels of risk and are not usuallyproperly assessed.

• Several of the presented threats can be exploited by attackers who do noteven have a valid SAP user in the system!

• Because of the technical layer being the foundation of the business logic, asuccessful exploitation of several of these vulnerabilities would usually result ina complete compromise of the business information and processes (SAP_ALLprivileges or equivalent).

• Potential weaknesses around SAP‘s RFC functionality are described in two itemsof the „TEC/11“ and implicitly also part of the „APP/11“

Security beyond authorizations

INTRODUCTION5

6

Overview

THE RFC ARCHITECTURE

AGENDA.7

„Remote Function Calls“ in SAP

THE RFC ARCHITECTURE

Source:Secure Configuration of SAP NetWeaver® Application Server Using ABAP™Version 1.2 - January 2012

1. ABAP RFC- ABAP System is server- Check via S_RFC and login- Client can be SAP or non-SAP

System

2. Registered Server program- Registration at „gateway“- communications interface to

non-SAP systems- Defined target of type „T“

destinations in SM59

3. Start of an external programThe „gateway“ starts a programon the operating system, in orderto manage RFC calls

RFC Client (calling) / RFC Server (is being called)

8

Security considerations

ABAP RFC

AGENDA.9

• During an ABAP RFC call, a user authentication is taking place,afterwards the authorization for the function group of thecalled function module is checked via object S_RFC

• Well, then all seems to be secure… doesn‘t it?

ABAP RFC – Security considerations

THE OBJECT S_RFC

AGENDA.10

• In reality, S_RFC is often granted with „star“ value, even to end users!• S_RFC protects the entire function group1, which may consist of several RFC-

enabled function modules (uncritical and critcal functions)• During development of RFC-enabled modules2 the developer has mostly only

his dedicated usage area in mind; the general external availability (and thusthe higher security demands) are negelected:- No dedicated authority check- Insufficient validation of parameters- The calling program is being trusted blindly!

________________1 Since NetWeaver 7 EHP 2 you can restrict S_RFC also on function module layer2 Some SAP security notes have also fixed vulnerabilities in SAP standard code

ABAP RFC – Security considerations

THE OBJECT S_RFC

AGENDA.11

• RFC-enabled SAP function module without authority check, which directlyexecutes native SQL commands on the SAP database(Vulnerability has been fixed by SAP on 14.12.2010 via SAP note 1456569)

• The RFC SDK (download available in SAPNet) is locally installed on theWindows PC

• A user with „regular“ access rights, without development access, but withwide open S_RFC – authorization logs on to the system

• Then, a „special“ SQL command is submitted via RFC SDK from theWindows-PC, which will result in SAP_ALL privileges

Video provided by VirtualForge GmbH

ABAP RFC – Security considerations

DEMO: „3 … 2 … 1 … SAP_ALL“

Demo "Ich hol'mir mal SAP_ALL"

AGENDA.12

• The RFC architecture allows ABAP RFC calls from any system, this means alsofrom non-SAP systems (assuming the right level of knowledge and softwareeven from MS Office!)

• Thus, in the case of end users with unlimited S_RFC access, the risk ofuncontrolled Excel based „do-it-yourself mass posting apps“ exists![No „attack“, but potential incident]

• Counter measures:- Object S_RFC access must be restricted- RFC users should in general only have limited access rights- ABAP development guidelines for RFC security- ABAP code reviews to avoid unsecure RFC function modules- System configuration and administration

ABAP RFC – Security considerations

THE OBJECT S_RFC

AGENDA.13

Profile parameter auth/rfc_authority_checkControls, whether and how object S_RFC is checked within „Remote Function Calls“(see also SAP note 931252).The documentation seems to indicate stronger checks when setting values 2 or 9(S_RFC is also checked in the „same user context“).

Difference between values 1 and 2 (or 9):Remote function calls in the same user context1

(ABAP:call function ... destination 'NONE').

Value "1" - no check for S_RFCValue "2" - S_RFC is checked, too

Consequence of setting value “2“ (not recommended!):The above ABAP statement is widely used in SAP, in order to execute functions in aseparate memory area. Therefore you need to grant wide S_RFC access to end usersfor their daily work in the system, although they never perform any remote login!_____________________1 wrongly referred to as „single-sign-on“

SYSTEM CONFIGURATIONABAP RFC – Security considerations

AGENDA.14

ABAP RFC – Security considerations

SYSTEM CONFIGURATION

Internal RFC call (type = F):End user performs a posting, the system is automatically updating CO-PA data by calling a functionmodule in a separate memory area via RFC destination ‘NONE‘. An authority check against S_RFC onlytakes place, if the RFC profile parameter is set to value „2“. In this case you would have to grant S_RFC tothe user, although no remote logon is taking place!

External RFC call with Remote login (type = R):User MAESTRO has logged on as target user of an external RFC call. An authority check against S_RFCalways takes place in this case.

AGENDA.15

SYSTEM ADMINISTRATION

DEV 01 QA 01 PRD 01

DEV 02 QA 02 PRD 01

Calls from systems with lower security classification with „stored“ logon data or „trusted“to those with higher classification must be avoided!

ABAP RFC – Security considerations

AGENDA.16

• On development systems „nearly everybody“ is able to test functionmodules by making use of all existing RFC destinations(Use can be restricted by authority groups and object S_ICF)

• „Powerful“ target users make attacker‘s work even easier• When using „Trusted RFC“, a system with higher security classification

should in general never trust a system with lower classification• If RFC calls to a system with higher classification cannot be avoided,

significant attention must be paid to the access rights of the RFC targetuser

• Never combine independent RFC calls and / or destinations into the sameRFC target user!

• A regular review of the RFC landscape including documentation ofallowed exceptions (e.g. SAP TMS) should become mandatory

ABAP RFC – Security considerations

SYSTEM ADMINISTRATION

AGENDA.17

ABAP RFC – Security considerations

SPECIAL CASE: CALLBACK

System : PR1/001User : JOB_01RFC-Dest. : RF2_200_CALLRFC-User : RFC_01

CALL FUNCTION ‘Z_RF2_EXEC‘DESTINATION ‘RF2_200_CALL‘EXPORTING …

New RFC session with automaticlogin as user JOB_01 withexisting rights ofJOB_01 and call of funktionmodule Z_XYZ, S_RFC ischecked accordingly

System : RF2/200User : RFC_01

FUNCTION ‘Z_RF2_EXEC‘

CALL FUNCTION ‘Z_XYZ‘DESTINATION ‘BACK‘EXPORTING …

ENDFUNCTION.

AGENDA.18

ABAP RFC – Security considerations

SPECIAL CASE: CALLBACK

System : PR1/001User : JOB_01RFC-Dest. : RF2_200_CALLRFC-User : RFC_01

CALL FUNCTION ‘Z_RF2_EXEC‘DESTINATION ‘RF2_200_CALL‘EXPORTING …

New RFC session with automaticlogin as user JOB_01 withexisting rights ofJOB_01 and call of funktionmodule Z_XYZ, S_RFC ischecked accordingly

System : RF2/200User : RFC_01

FUNCTION ‘Z_RF2_EXEC‘

CALL FUNCTION ‘Z_XYZ‘DESTINATION ‘BACK‘EXPORTING …

ENDFUNCTION.

With a modification or enhancement of a function module, which is knownto be called via RFC, a callback can be inserted:

CALL FUNCTION ‘___<use your imagination>___‘DESTINATION ‘BACK‘ ...

The callback will be sucessful, if the calling user has the respective S_RFCaccess and the needed application permissions.

AGENDA.19

ABAP RFC – Security considerations

SPECIAL CASE: CALLBACK

Counter measures against RFC Callback:• Restrict S_RFC of calling user on RFC client-side• Use Function module RFC_CALLBACK_REJECTED in

own customer development; see SAP Note 1515925:“Preventing RFC callbacks during synchronous RFC”

• Parameter rfc/reject_callback in higher releases (7.31)• Parameter rfc/callback_security_method (7.41 kernel)

and callback whitelists in SM59

AGENDA.20

• End user: Only function group SLST for all(Few further cases in individual roles)

• Support staff: Needed function groups for RFC comparisons ofcustomizing entries in SM30, ABAP versions, roles/authorizations- Individual trace via transaction ST01 (or STAUTHTRACE – note 1603756)

• Non-Dialog RFC users:Security Audit Log (or transaction STAUTHTRACE)

ABAP RFC – Security considerations

APPROACH TO RESTRICT S_RFC

21

Often neglected

GATEWAY SECURITY

AGENDA.22

Often neglected

GATEWAY SECURITY

1. ABAP RFC- Authentication at SAP system

via login as SAP user- Authority checks against S_RFC

2. Registered server program &3. Start of an external program

- NO authentication as SAP user- Optional (!) Checks through„Access Control Lists“ (ACL):

> REGINFO for reg. server> SECINFO for start of ext. prog.

By default, the validation using theACL files is inactive!> Significant vulnerability

AGENDA.23

• Risks:- Uncontrolled execution of operating system commands- Registration of „fake“ RFC servers at the gateway

• Problem can NOT be solved through firewalls(Respective 33xx TCP Ports must be open!)

• Within most SAP implementations, the gateway is not secured by ACL files(default setting by SAP in lower basis releases)!

• Protection:- Profile parameter gw/reg_no_conn_info, gw/reg_info, gw/sec_info- Maintainance of ACL files (sec_info und reg_info)- Systems with 720 kernel: Set parameter gw/acl_mode = 1

• Underlying concept:Only own application server(s) may start programs or register servers;Exceptions need to be known and explicitly allowed in ACL files

Often neglected

GATEWAY SECURITY

24

Summary

10 RULES FOR RFC SECURITY

www.opel.com

Summary

10 RULES FOR RFC SECURITYThe most important first:

Regularly and timely implementthe relevant SAP security notes

AGENDA.

ABAP development1. Only make dedicated function modules RFC-enabled2. Always implement authority checks in RFC-enabled FM and validate all

passed parameters (never trust the caller)3. „Dangerous" ABAP statements in RFC FM exponentiate the risk!

User administration4. Restrict object S_RFC for all users (dialogue and system)5. Per RFC destination a dedicated target user, because…6. …target users of RFC calls should only get authorizations (S_RFC and other

objects), which are really needed

Summary

10 RULES FOR RFC SECURITY26

AGENDA.

System administration7. Set parameter auth/rfc_authority_check to value 1 (not 0, 2 or 9)

(If available: Make use of rfc/reject_callback: value 1)8. Secure the RFC gateway (ACL files sec_info and reg_info)

RFC system landscape9. Systems with lower security classification (e.g. development systems)

should never perform RFC calls to systems with higher securityclassification using „stored“ logon credentials or via „Trusted RFC“

Management support10. Higher Security means higher maintenance, test and correction efforts!

Summary

10 RULES FOR RFC SECURITY27

Markus Seibel

THANK YOU

28