Skip to Content
Author's profile photo Former Member

Hacker’s Lunch @ SAP TechEd Vienna

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. Standard insert report without a check   *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:Code Inspector variants  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. Standard code insert without checks  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.Customer insert hit list

Assigned Tags

      4 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Amit Gujargoud
      Amit Gujargoud
      Throughout it was Nice reading particularly the section 2.2 and 2.3. And It was good to be on familiar terms with that the “ABAP Editor written it self in ABAP”

      Out of curiosity: "Since ABAP Editor itself written in ABAP, This statement confirms that the “ABAP code for ABAP editor was written in SE38”? Is it?
      So Before the SE38 (ABAP Editor) was released how/where they wrote ABAP code in order to create ABAP Editor?

      May be I’m being some sort of silly ;-). doubtless I will appear with the same question next time in TechED ’10

      Thanks JB for sharing your Session with the Blog!

      Cheers

      "benefiting from the efforts of others who do the same" Be prepare to get whack from Olivier 😉

      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Thanks Amit. Glad you found it interesting and useful.

      Regarding your question: I have taken note of the same and will revert back with "Hackers in the Tandoor" @ SAP TechEd'10 Bangalore 😉

      Cheers,
      Julius

      Author's profile photo Andrea Olivieri
      Andrea Olivieri
      Hello Julius, thanks for sharing this!

      I’m aware about  the "code injection" problem since I encountered  a mismatch problem is in the versioning  of the development objects.
      I always delete  these malicious programs and eliminate transport entries, but I did not know of a standard program that does exactly the same thing ...

      Andrea

      Author's profile photo Former Member
      Former Member
      Blog Post Author
      As you can see SAP have not deactivated the functionality, but rather secured it.

      What many customers do is provide an emergency user procedure to access the authorizations for such eventualities only when they arise. This is faster than transporting, and you can log all the actions of the emergency user ID.

      Cheers,
      Julius