Post on 27-Dec-2015
description
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
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
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)
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
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
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