Enterprise Resource Planning (ERP) systems run applications supporting various mission-critical functions in Sales, Purchasing, Finance, and HR modules. Complex in nature, they are also home to large volumes of sensitive data. It is no surprise that criminals bent on committing fraud, sabotage, and corporate espionage are increasingly targeting systems from SAP – the largest ERP vendor. This blog delves into vulnerabilities found in the SAP Authorization concept, the cornerstone of security in SAP systems. SAP applications are developed in Java or Advanced Business Application Programming (ABAP), which is SAP’s proprietary programming language. This research focuses only on the ABAP-based systems.
SAP Authorization Concept
SAP’s Authorization Concept protects transactions, programs, and services in SAP systems from unauthorized access. Security administrators assign roles, or profiles, to users based on job function. A role or profile is a collection of authorization objects, each with a list of permissible values assigned to authorization fields within the object. The authorization fields are building blocks that specify the criteria for evaluating an authorization check and are logically related by AND -- an authorization check is considered a success if, and only if, the user has an authorization assigned that permits all the values specified in the check. For example, a transaction concerned with customer account maintenance can include a check on authorization object ZCUST_ACCNT that has authorization fields ACTION and AREA. Only users with authorizations for ZCUST_ACCNT that permit ‘Change’ and ‘US’ (for the fields ACTION and AREA respectively) can change account data for customers in the U.S. region. Authorization checks can be made at a very granular level, since authorization objects can have up to ten authorization fields. Therefore, the example object ZCUST_ACCNT can be extended, if necessary, to restrict access to users based on eight more parameters, such as business unit and department. Figure 1 illustrates the design and runtime views of the SAP authorization concept with this example.
Figure 1: SAP Authorization Concept: Design and runtime views with an example
An authorization check is coded using the ABAP statement AUTHORITY-CHECK, which upon execution returns a code indicating whether the check is successful. Further processing is restricted based on the return code. The source code for the example transaction discussed earlier will be similar to:
//Check user authorization before proceeding with data update
AUTHORITY-CHECK ‘ZCUST_ACCNT’ ID ‘AREA’ FIELD ‘US’
ID ‘ACTION’ FIELD ‘Change’.
IF sy-subrc <> 0. // Non-zero return code --> error
//throw error and quit the program
//proceed with data update
No good excuses for skipping authorization checks
While most standard SAP functionality is enclosed within authorization checks, the customer developing the programs bears the burden of making these within custom-developed programs. Custom programs can do virtually anything in the SAP system, unless the developers code appropriate checks to keep the unauthorized people from accessing privileged functionality. Unfortunately, authorization checks are forgotten or disregarded, and it is common to skip those checks in scenarios such as:
- Security through obscurity: Large development teams often rely on helpful hacks to avoid lengthy follow-ups with support teams for tasks such as toggling the editor lock on a program. Although these quick-and-dirty programs are intended for internal use within the development team, it is a good idea to code authorization checks -- after all, the existence of and the access to such utilities cannot remain a well-guarded secret indefinitely.
- Purpose-built programs: Underlying assumptions about the target user group often influence what authorization checks, if any, are coded into the program. For instance, assuming that only regional sales managers will use a particular transaction might cause the developer to skip basic authorization checks at a plant or warehouse level. As programs evolve with changing business requirements, assumptions underlying them will also change.
- Cross-system projects: Scalability and performance commonly trump application security in the discussions of any solution that involves interfacing ERP with other systems. As a result, the responsibility of application security in general, and authorization checks in particular, does not rest with a specific team, with each team assuming it is not in scope.
- Interfaces using middleware: Middleware systems interact with the backend system on behalf of the external systems, and often use a generic user ID to connect. Permitting the use of generic user IDs implies that either the authorization checks in the backend are generic (at best) or the privileges assigned to those IDs are too broad.
Vulnerabilities in authorization checks
In an ideal world, the authorization concept offers unmatched flexibility-–the ability to configure security roles based on collections of objects with criteria tailored to any degree of granularity, coarse or fine, as required. This is essential since the security policies adopted by an organization are as unique as its business processes. In practice, however, great flexibility comes with great security risks.
Erroneous implementation of authorization checks allows for exploitation and increases the attack surface (Figure 2). Vulnerabilities are exploitable by the attack surfaces through the corresponding interfaces.
Figure 2: Vulnerabilities due to erroneous authorization checks
Importance of code reviews
In order to mitigate the risks posed by the vulnerabilities discussed in this report, it is essential to have a robust code review process focusing on the security aspects. For some organizations, it is understandably difficult to perform manual security-focused code reviews in a complex system with a constant stream of enhancements and bug fixes introduced into the production environment. Nonetheless, diligent review minimizes the likelihood that errors will survive until production, at which point they can be far harder to correct.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.