SAP Security for Beginners Part 15 - SAP Code Security

November 6, 2017 by

Alexander Polyakov

The next topic to deal with after Segregation of Duties is SAP Code Security. It is a relatively new area of SAP Cybersecurity comparing to SoD, for example.

The information about ABAP Security first came to the public eye in 2002 and was devoted to an SAP virus. However, it is not the only problem of the customization brought by the usage of SAP to every client while trying to customize their SAP System to work in specific situations.

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

An ERP system (especially from such vendors as SAP and Oracle) is usually not typical software but more like a framework, on top of which companies develop their own programs and applications. Normally, an ERP system, in particular, by the SAP and Oracle vendors serves as a basement for creating new programs and applications by customers. In the beginning, SAP used ABAP, its proprietary language, to customize SAP Systems. Latter on the vendor added new platforms, such as J2EE and HANA.

Currently, SAP provides a number of languages to extend its functionality: ABAP, Java, and XSJX (for HANA). ABAP remains the most common language even in the latest S/4 HANA applications and presumably contains vulnerabilities (as any other language) unintentionally left by developers. They can also leave backdoors, which can provide malicious functionality, e.g., sending details of every transaction to a 3rd party via email or even posting it on Twitter.

Why development issues are important

A key issue remaining nowadays is the lack of attention to the code security among the developers. Without any changes in their mindset, companies will still stay at risk to fall victims of serious security violations, such as espionage, sabotage, or fraud, and, as a result, suffer great monetary and reputational losses.

The fact that business-oriented programming is an area with a number of its own peculiar features, and that different languages can be used to write the custom code for ERP systems, implies an easy possibility of drawbacks to be left. At the same time, business-oriented programming languages do not have such comprehensive sources where the developers could find information about widespread and critical issues (as OWASP - Open Web Security Application Project) give the developers the insight into the most important critical issues.

Another area that should be taken into account is the security of Enterprise Business software development life cycle. The fact is that 71% of developers do not take into account the security issue in SDLC (Software Development Life Cycle) for their companies that becomes a risk factor for the security of customer organizations. What is more, fixing vulnerabilities on the stage of software development considers easier and less expensive than during post-production.

Percentage of Vulnerability Cost in Stages of SDLC (Source: National Institute of Standards & Technology)

Finally, 80% of attacks can be prevented by simply training the developers in some security development basics.

Unfortunately, this process hardly passes under any control inside the company. It means that nobody can say for sure what is introduced to the system during the programming; there are no control measures at all. The developers can provide insecure code, forget to add checks for the access control in programs, or even send money to their bank accounts so that nobody will be able to find it out without checking the source code. Therefore, the actions of the developers are not limited in any way, and nobody is sure that it is an appropriate way.

What can be done to secure code

The first approach that comes to mind when talking about the code security is analyzing whether source code written by developers contains vulnerabilities. How to analyze custom source code? When we deal with Web Application security, the common practice is to follow the OWASP methodology and to make sure that the top 10 critical issues do not occur in your applications. It does not give you 100% guarantee, but at least you know what steps to take first.

While dealing with enterprise applications, it was not so trivial to understand what issues are to be checked until we founded EAS-SEC, a non-profit organization aimed to increase awareness in the Enterprise Application Security space. EAS-SEC consists of separate projects, and one of them dubbed SAP ABAP Secure Development Guide is focused on code security. The project is dedicated to the description of 9 categories of source code issues for business languages, which are universal and general for most of the business applications (e.g., SAP, Oracle, Microsoft Dynamics, Infor, etc. and their custom languages).

Therefore, below are these 9 categories sorted according to the access needed to exploit a vulnerability, its criticality, and probability of exploitation.

The first three are the most widespread and critical ones. I will do a short review of them later, but first, let's look what else we have here. On the 4th place, there is Directory traversal, a common vulnerability that can be used to get unauthorized access to files. It is followed by Modification of Displayed Content vulnerabilities (including cross-site scripting) since enterprise applications are not only web-based, this category contains all the types of client-side vulnerabilities.

Then there are backdoors. They can be very parlous; however, we rated them only 6 as an attacker needs developer access rights for SAP to be able to inject a backdoor. Backdoors can be very simple such as checking the name of a user who executed a program and then running some background jobs if a particular user runs this program too. Once, we witnessed an occasion when an administrator created a backdoor configured to send a certain amount of money to his bank account.

How to detect these vulnerabilities

Now, let's cover the examples the most severe vulnerabilities starting with Injection vulnerabilities.

This type of vulnerabilities occurs when an application provides no or bad user input validation. An attacker can inject malicious data and perform non-intended actions on a system. Such vulnerability may result in major SAP risks due to the issue's prevalence and the complexity of remediation.

There are various types of injections such as SQL injection, ABAP Code injection, and OS Command injection.

1. Let's look at the ABAP Code injection. "GENERATE SUBROUTINE POOL" statement without the proper sanitizing allows executing arbitrary ABAP code. Another risk is that SAP does not suggest to use it at all, and may disable this functionality in some versions. For mitigation, it is recommended to check user input and sanitize it.
2. Another example of Injection vulnerabilities is an SAP OS Command Injection. If a developer uses the "CALL 'SYSTEM' ID 'COMMAND'" statement, SAP System executes an operating system command, which can be passed as a parameter through the user input. The risk is extremely high as it is possible to run any command on operation system of SAP Server. It gives an attacker even more than an access to SAP itself. To prevent it, we recommend sanitizing the user input or creating a list of allowed OS commands, as well as using the whitelisting approach when executing any command from a user.
3. The last example of Injection vulnerabilities is an SAP SQL Injection. When a developer uses the "SELECT" statement without proper sanitization of all parameters passing through the user input. As a result, unauthorized SQL commands can be executed in the database, and an attacker will be able to read any information from the database. It is recommended to sanitize input or use prepared statements.

The second most critical type of issues is Critical Calls. SAP provides many options to execute critical functionality such as reading files from OS or executing transactions. Some of these functions are potentially dangerous (for example, the dynamic "READ DATASET" statement, which can be executed to read any file from OS). Unauthorized access to any OS file is possible if no access control checks are implemented before running the OPEN DATASET statement. To mitigate, first, ensure that these statements are necessary and you really need to read files from OS. If so, try to provide access control checks.

The third most critical vulnerability is Missing Authorization Checks.

Think about RFC function or transaction, which fulfills a certain critical action in the system. Call it, for example, Z_RFCEXPLOIT (actually, the same applies to reports and transactions). Let's consider that inside this transaction there is a piece of code that can call another possibly critical transaction, for example, an SE16 transaction which can give access to all tables. In practice, it means that if somebody can call Z_RFCEXPLOIT function, he or she can execute the SE16 transaction. To prevent this, developers should manually check if a user has the authorization to execute SE16 before calling it. Otherwise, it means that Authorization Check is missing and it is a critical vulnerability.

Thus, the vulnerabilities connected with Missing Authorization should not be underestimated as they can be easily exploited and do not require special privileges in the system. Taking into account that there are about 2 million RFC functions in SAP, the mentioned vulnerabilities will constantly reappear in SAP products, as well as in self-developed code, the security of which should be thoroughly cared about.

Conclusion

The customization protection is one of the most important areas of SAP Security, which is often overlooked due to its complexity. It is not an easy task to analyze thousands of custom programs, to identify over a hundred of different types of code issues (including not only vulnerabilities but also backdoors, obsolete statements, performance issues, etc.). It is a tough job to detect all these issues and continuously monitor them; nonetheless, it is essential, as hackers can use these loopholes to get access to SAP Systems.

Currently, it is easier to find a vulnerability in SAP rather than to fix it, but only automated tools together with experienced people and relevant actions can beat them.

Resources

• EAS-SEC Articles about ABAP Code Security https://erpscan.com/tag/secure-abap-development-guide/
• Securing SAP from XSS https://erpscan.com/press-center/blog/securing-sap-systems-from-xss-vulnerabilities-part-1-introduction/