At SAP TechEd09 in Vienna I presented an Expert Lounge session on Security. 57 folks signed up for the "Hacker's Lunch" and a little crowd of innocent bystanders gathered over time as well. It went 40 minutes overtime with the Q&A’s at the end and several people asked me to share the presentation and notes. Here they are. h4. 1st topic: Introduction to Security on SDN…. In this case, if you are reading this and follow the link then you already are on the inside -> so there is nothing left to hack here 😉 For those not yet familiar with SDN (https://sdn.sap.com): Within the Security & Identity Management category you can find a wealth of security related information and usefull tools, such as: • Moderated forums, wikis, blogs, articles, workspaces, partner information in the EcoHub and the SAP Career Center which is a new job board focusing exclusively on SAP related employment. There is a dedicated category for security jobs. • FAQs, memorable discussions and insights from SAP subject matter experts which you won’t find elsewhere in the internet. • Can be used as a benchmark for „in the wild“ security by customers, consultants and SAP as well. A functionality wishlist for developments can be supported too. h4. 2nd topic: The new SAP Security Note Service > See SAP Note 888889 (https://service.sap.com/sap/support/notes/888889) for a general overview. Within the Security and Identity Management stream at SAP TechEd09, the reasoning behind the service and how to use it was presented. In my session, I took a closer look at the trends in these notes and an analysis of selected recent examples and recommendations how to go about securing them. h5. 2.1) SAP Gateway => See SAP Note 1298433 (https://service.sap.com/sap/support/notes/1298433) for the latest entry point into this topic. Many folks believe there is some secret in SAP security. Something basis folks don't talk about. A magic trick in the remote RFC area? This is it! Before you panic: With a relatively small effort it is easy to secure this (particularly if you are not doing it for the first time...), but if you don't take care of this issue then a critical security vulnerability is left open… See the old but release independent SAP Note 110612 (https://service.sap.com/sap/support/notes/110612) for the context. Okay, now the bugger here is that typical security parameters used when starting server programs on an SAP instance via the gateway (so… remotely) cannot be known to SAP when rolling out default settings (e.g. USER, HOST, program name, PASSWORD, etc). So your instances have an RFC gateway control possibility, but the restrictions don’t exist by default (ACL files secinfo and reginfo). Calls to ABAP RFC enabled function modules have historically requested a user to pass an ABAP authorization check (against object S_RFC to *start* the function module) which by implication requests authentication because the ABAP system needs to know which user ID this check should be performed against. This is why you don’t normally notice this risk if you only code in ABAP, calling ABAP RFCs.Please see 1167258 (https://service.sap.com/sap/support/notes/1167258) and 6 of the patches included in note 1394093 (https://service.sap.com/sap/support/notes/1394093) for the context. As the ABAP Editors (SE38 etc) and even the debugger (/h) are themselves written in ABAP, it stands to reason that the ABAP programming language has the capability for a programmer to create their own ABAP Editors. Some programs can even change themselves at runtime by using the same keyword statements which the SAP ABAP Editor use. Now in the case of SE38 for example, the system checks whether you have the required developer authorizations (object S_DEVELOP) and the system’s change settings permit these critical statements to be reached (SCC4 and SE06 changeability settings) and react to them if you are not. Here a developer can be lured into the trap of thinking that the checks are within the ABAP statements themselves (sometimes, ST01 traces might even lead you to believe this…) and assume that authority-checks are not required or standard function modules called do not need to be reacted to by the calling programs. Unfortunately, this is seldom true. If no checks are made, anyone can run the program and use it! Although SAP has quality gates and tools to scan their own code, such errors can still slip through… as was the case with the report RS_REPAIR_SOURCE. 
*Note:* There is no namespace check either, so do not test this on any existing programs! You can seriously damage your system! So, what to do about finding such errors and preventing them? SAP delivers within transaction SCI (the SAP CodeInspector) a variant for security related scans of custom code. The scans are static and do not do the interpretation of the coding context for you, but are a massive improvement compared to doing nothing as they will find such statements. Examples of the checks performed by the CodeInspector are:
Additionally, BADIs are available within the STMS which can check for the presence of a ”code inspection” before the release of the transport request. You can also blacklist certain object types in combination with object names. You can find more information about this in the online SAP Help documentation of the TMS. For more advanced checks against a commercially available pattern database, you can also consider using the CodeProfiler. This also automates the interpretation of the found code further by evaluating an authority-check statement and of course the big question is… where is the inserted code coming from?? If it is unvalidated and the user can define the path or enter it in a field or parameter then your production system and data is toasted. Here is an example of a simple source scan finding the above mentioned SAP standard code in an unpatched system. 
As an experiment, we scanned Z* objects for the same coding pattern in a development system… From experience, these types of vulnerabilities typically originate from migration programs, auditor tools and “utilities” downloaded from the internet during the implementation phase of the system.
*Note:* There is no namespace check either, so do not test this on any existing programs! You can seriously damage your system! So, what to do about finding such errors and preventing them? SAP delivers within transaction SCI (the SAP CodeInspector) a variant for security related scans of custom code. The scans are static and do not do the interpretation of the coding context for you, but are a massive improvement compared to doing nothing as they will find such statements. Examples of the checks performed by the CodeInspector are: Additionally, BADIs are available within the STMS which can check for the presence of a ”code inspection” before the release of the transport request. You can also blacklist certain object types in combination with object names. You can find more information about this in the online SAP Help documentation of the TMS. For more advanced checks against a commercially available pattern database, you can also consider using the CodeProfiler. This also automates the interpretation of the found code further by evaluating an authority-check statement and of course the big question is… where is the inserted code coming from?? If it is unvalidated and the user can define the path or enter it in a field or parameter then your production system and data is toasted. Here is an example of a simple source scan finding the above mentioned SAP standard code in an unpatched system. As an experiment, we scanned Z* objects for the same coding pattern in a development system… From experience, these types of vulnerabilities typically originate from migration programs, auditor tools and “utilities” downloaded from the internet during the implementation phase of the system.- SAP Managed Tags:
4 Comments
| User | Count |
|---|---|
| 5 | |
| 5 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 |
