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.

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: 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.

2nd topic: The new SAP Security Note Service > See SAP Note 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.

2.1) SAP Gateway => See SAP Note 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 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.

To cut a long story short, if you start an SAP provided or 3rd party external server program directly via the gateway then you can bypass the ABAP system and call the functions provided by that program, thereby bypassing the authentication and any security which the ABAP runtime environment provides natively. Take my word for it that these external RFC server programs do not perform user authentication voluntarily…

To be event blunter, you typically have <sid>adm permissions without authentication… OMG!! But it is not that bad if you understand the gateway and from where the functions in these server programs are intended to be started, namely locally on the Netweaver ABAP Application Server.

So, how to secure it: In the docs and example configurations, you will find a lot of references about a user ID called ‘HUGO’. Forget about HUGO please! If you do not restrict the USER-HOST and HOST profiles in the secinfo ACL file then you can also tell your mother-in-law that you are ‘HUGO’, and not only the SAP system. So concentrate on the USER-HOST and HOST parameters.

You can gain more than 90% security benefit with less than 10% effort by using the following simple entry for the gateway ACL (secinfo file).

If this is the only entry… then it is a “white list” which means that access to the server programs (and the operating system) is forced into a local context. Users on the ABAP system (transactions SM69, SM37, SA38, function module SXPG_COMMAND_EXECUTE, webservices of the same ilk…etc) will request authentication and authorization (primarily objects S_LOG_COM and S_RZL_ADM) from the user. If you are logged on to the localhost as <sid>adm you are also unhindered. All others (including “illegal callers”) are blocked.

This means that you can catch 99,999999999% of “vanilla” use via the ABAP system’s own use of the gateway and control within the local ABAP instance’s granular application authorizations who can perform such tasks. This should normally not produce a loss of functionality, unless a solution is badly designed or someone is misusing the gateway.

Additionally to the user context on the ABAP application server, you can for special exceptions create more specific entries for *known” (KNOWN!!!) external USER-HOST exceptions and restrict them to specific users and programs at the gateway as required. This is strongly recommended, as you don’t have an application security layer anymore to work with.

So much for SOX compliance if you have not done this yet…

In higher releases and patch levels, further features are available to make the gateway control files easier to maintain, such as “blacklisting” certain user-hosts, user names, programs names (this DENY option makes it possible to range more granularly) and define SAProuters which are within the trusted USER-HOSTs (if you trust them within your server network...).

2.2) SAP Security Services… Editor calls and ABAP code injection.

Please see 1167258 and 6 of the patches included in note 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.

If you scan Y* , /* name spaces and $tmp package objects in a development system (or even in production…) you are likely to find even more.

In addition to recommending a skilled audit of existing code, you can also try to “stay clean” by following Matt Billingham’s recommendations in his Virtual Community Day session on The ancient and noble art of code reviews.

2.3) Password hashing mechanisms -> See SAP Note 1237762.

Anyone who experiences the hassle of passwords for many systems, or complex password rules, or the combination of both of these together with no budget for single-sign-on… might become tempted to synchronize their passwords.

This is easy to do manually, but you soon loose track of which ones have been subsequently changed and the weakest link (for example an http basic authentication service, or a log file…) gives away the plain text password for all, or the “silos” you use for them - such as ‘<sid>pwd09’ or ‘Summer06’…

Depending on your skills you can work out that SAP’s historic one-way password hashing mechanism (code versions A + B) do not have a client nor system specific attribute to them, and the table containing the hashes is buffered on the application server in lower releases.

While this does at first seem like a cool feature which can be used in a clever way to make administration easier, it is not!! The bugger here is that someone with access to the hashes does not need to know your exact password, but can (depending on the strength of the password) simulate it and compare the hashes in a different system until they produce a clear text value which can reproduce the same hash.

There are lots of booby-traps in this, and you will need to take plenty of camels and water with you if you embark on this journey… but it is possible. You can also take a good night’s rest while a program does it for you, or go on vacation and look forward to your first day at work again… :-)

So, SAP has added these missing attributes now to prevent the problems caused by updating single fields (BCODE and PASSCODE of USR02) of their system tables without understanding the relational model (not to mention missing change documents…) and also to prevent password hash attacks. Giving up the former is a prerequisite to protect the latter!

Please read the note mentioned above carefully. My recommendation is also to strive for code version F (if you are not using CUA to distribute passwords to releases lower than 7.00) or code version H (salted hashes which exclude the user attribute). More information about how to make these settings are included in the above note.

For passwords in RFC connections which require compatibility, please see the SDN Security Wiki How to analyze and secure RFC connections which includes a usefull tip for working around this UPPER-CASE conversion problem. Several questions from the Q&A session can also be answered by information in this wiki, particularly the client side security checks in RFC.

Tip: If you want to delete the object history in SU01, just place your cursor on the password and hit "Delete" on the keyboard.

For standard users required for upgrades (DDIC) and <sid>adm etc etc, I can also recommend taking a look into commercially available password vaults. The better ones give a granular option to make it possible for admins to not even know the password if they choose to use this, as long as they have access to it in the vault.

2.4) What’s next in SAP Security? -> Shortcuts and URL traversals.

Many years ago I found a way to execute transactions under foreign user ID’s without having an account myself in the system. At the time, it seemed easy to fix outside the system as well… but all good security checks are the ones located beyond the boundary of the user’s or the network’s influence, so this is probably not the last time this topic will pop up again. See SAP Note 1397000 for the latest information…

I don’t want to say more about this as SAP is still working on it… but some recommendations and experiences to share with the community when securing these risks are:

a) Strip the file attachments from emails.

The files can enter the SAP network via SMPT protocol as well, and contain router string information in addition to transaction codes, reports, parameters and GUi commands to be executed by the user opening the email. If you block the file extentions .sap using your email gateways, then you can prevent this vector. Also consider .jar and .bex if these have not been stripped already.

Warning: Be carefull of recurring Outlook appointments with the shortcuts in them on the user side. Some accountants don’t use the schedule manager…

b) Restrict access to transaction SUB% in all clients, to protect yourself.

This is the transaction code via which the report parameters are submitted. Take a look at it’s initial screen… no human was ever meant to use that… :-) In contrast to transactions, submitted reports are more likely to not have a selection screen or only one of them if you use the skipscreen option. By restricting authorizations for this transaction, you can also protect yourself against the internet.

SAP_ALL is an allround bad idea, even if you think you are alone in client 000 of a production system....

Warning: WebQueries in BW might request this transaction code, unfortunately. Please check in transaction ST03N whether SUB% or the underlying source code report is being used by any scenarios, and then test it to see whether it is infact submitted from a shortcut.

c)  Internet gateway content filters.

The above mentioned note has been updated after the Q&A session at SAP TechEd Vienna. See the last paragraph of version 3, solution # 5…

“You can reconfigure all proxies through which users access the Internet to drop all content with ".sap" extension and filter mail attachments with extension ".sap" on the mail servers to prevent attacks via mail or from the Internet.”

Conclusion -> Be proactive about security!

If you contribute actively to SAP Security then you can also play a proactive role in securing your own system, benefiting from the efforts of others who do the same and even influence the solution to some extent.

3rd topic: RunSAP methodology for Security…

So, we have had the ASAP methodology for security around for a while now… but even if followed, what happens after the gurus leave the project or the company?

SAP is now developing a security methodology for “normal operations” as part of the RunSAP initiative. This collection of best practices for SAP systems and a methodology around the approach to be taken is available on https://service.sap.com on the Application Lifecycle Management tab and aims at sustainable security implementations, patching and upgrades.

More information is also available in the SIM200 TechEd document.

4th topic: Complexity in Security Concepts

Unfortunately we never got this far in the session, but there is always next year… and the topic is unlikely to go away :-)

Some notes: To my knowledge there are 12 official authorization concepts in SAP (ABAP profiles, PFCG roles, HR structural and context authorizations, P_PERNR mechanisms, CRM business roles, analysis authorizations, Java security roles, UME roles, etc… ). SAP_ALL is the 13th unofficial concept. If you include function calls which don’t react to exceptions or TRY and CATCH tactics or IF SY-UNAME type checks, then you might have way more than just 12 concepts to manage in your systems…

This increase in “diversity” and complexity of administrating security, may be at the expense of security itself for an administrator to have all the skills and (potentially conflicting) concepts under his or her control.

I plan to pick this and other new topics up again next year at SAP TechEd10. Of course I will also follow-up on the topics from TechEd09.