November 13, 2014 at 14:09Secure ABAP Development at SAP
Today, in 2014, Russian companies that introduced SAP products spent a lot of resources on client refinement of solutions. However, do these developments bring additional risks to your business processes? SAP guarantees the quality of the code in its applications by manually auditing the delivered code and using the most advanced mechanisms for static and dynamic analysis of its products for various vulnerabilities. The author of these lines conducted a study at the University of Saarbrücken (Germany), the purpose of which was to analyze SAP product codes (e-commerce solutions) with the most modern static analysis tools and was convinced of the high quality of this code. The SAP program code passes manual and automated analysis, thousands of special test cases. Client-side program code often cannot be analyzed so fully, especially in the context of tight deadlines for projects in which you have to work. It is worth considering the quality of client code on your systems. It is important to understand that checking user authorization (a synonym for SAP security for many enterprises) will not help prevent the use of this kind of error, because a user who uses errors in the code goes beyond the authority defined by the system administrator.
Consider the errors that may be present in the client code.
Abandoned code injection is one of the most common and most dangerous OWASP classification vulnerabilities.. Most widely known vulnerabilities, including OpenSSL Heartbleed (04.29.2014) and hacking of the Ebay platform (05.22.2014) are associated with the unintentionally left possibility of injecting user input into the program. The danger of this kind of error lies in the almost unpredictable results of the execution of vulnerable programs. An injection of SQL code can result in a password leak or a complete deletion of all system data. An additional problem associated with such vulnerabilities is the difficulty of finding them by automated means. A search based on rules and patterns will not yield a positive result due to the large number of erroneously formulated assumptions. The only truly effective way to find errors can be a static analysis of the data stream entering the program (Information Flow Control).
Another dangerous programming error is the unintentionally left over option to spoof input data, which allows directory traversal. An attacker using such a vulnerability is able to read or write data located outside a predefined directory. Thus, critical system settings can be read or configuration files can be overwritten, which can disable the system for a sufficiently long period of time. Quite specific use cases for this error are possible. For example, a call to the OPEN DATASET dset FILTER iv_filter statement that opens a file for reading on a Unix system delivers data from a read file to a predefined process that can perform unexpected actions at the operating system level. Therefore, incorrect OS configuration and vulnerable code, without errors individually, can lead to critical consequences when working together. You will learn about problems with incorrect configurations in our next articles.
Are your programmers guided by the concept of authority in developing their applications? In accordance with this concept, access to any functional block of the program should be prohibited until the contrary is determined. Unfortunately, on many projects, access control is done at the transaction level, which makes it possible to combine various existing powers in order to access prohibited information. For example, using the CALL TRANSACTION statement (which is widely used by developers) on projects with access control at the transaction level is unsafe. Without specifying WITH AUTHORITY-CHECK, the CALL TRANSACTION statement allows you to jump through any other transaction. It is also possible that there is an authorization check, but it was done incorrectly. Such cases also need to be found and corrected.
Before that, we examined some cases of vulnerabilities when programmers made unintentional errors, as a result of which the code became vulnerable. However, there may also be cases where the programmer intentionally changes the course of program execution for certain users (“undocumented features”), or even leaves the so-called backdoor, which allows you to bypass all checks set by the system. A developer can make a backdoor without malicious purposes, such as obtaining SAP_ALL authority for more “efficient” work on an implementation project. Obviously, this does not detract from the risks that backdoors bring. There are many examples of such backdoors on the network that can simply be copied and transferred to a productive system. It’s very difficult to catch the presence of undocumented features and backdoors, firstly because of the huge amount of client code, and secondly because of the features of the SAP programming language. ABAP allows you to execute code on the fly and is stored in the DBMS, i.e. can be hidden very, very deep.
There are several different ways to search for vulnerabilities in the code, the most advanced of which is static analysis of the data stream. SAP Netweaver AS has a module that implements data flow analysis for the presence or absence of vulnerabilities (Code Vulnerability Analysis). There are certified partner solutions that allow you to scan application code for vulnerabilities. SAP Code Vulnerability Analysis (CVA) is based on the Code Inspector tool, which for many years allows you to check client code for potentially dangerous structures, but unlike Code Inspector, it uses data flow analysis. The most appropriate is the use of CVA from the first stage of the project - from the development stage (until the development is transferred further along the landscape), because corrections later (e.g. during productive operation) is more complex and costly. Implementation of CVA implies not only the search and correction of errors, but a change in the approach to development standards in the enterprise. The introduction of any new development into a productive system should be authorized by an expert guided in his work by the most modern development analysis tools.
With this article, we wanted to show that the security issues of SAP products are much wider than our customers often imagine. It is important to clearly understand the full range of problems that may arise when supporting SAP-based solutions. To do this, you need to be aware of the current state of affairs, and we will tell you about this as part of a series of articles.
Posted by Daniil Luzin
Consulting Division of SAP CIS LLC
Kosmodamianskaya Emb. 52/7, 113054 Moscow
T. +7 495 755 9800 ext. 3045
M. +7 926 452 0425
F. +7 495 755 98 01
Consider the errors that may be present in the client code.
Code injection
Abandoned code injection is one of the most common and most dangerous OWASP classification vulnerabilities.. Most widely known vulnerabilities, including OpenSSL Heartbleed (04.29.2014) and hacking of the Ebay platform (05.22.2014) are associated with the unintentionally left possibility of injecting user input into the program. The danger of this kind of error lies in the almost unpredictable results of the execution of vulnerable programs. An injection of SQL code can result in a password leak or a complete deletion of all system data. An additional problem associated with such vulnerabilities is the difficulty of finding them by automated means. A search based on rules and patterns will not yield a positive result due to the large number of erroneously formulated assumptions. The only truly effective way to find errors can be a static analysis of the data stream entering the program (Information Flow Control).
Directory Bypass
Another dangerous programming error is the unintentionally left over option to spoof input data, which allows directory traversal. An attacker using such a vulnerability is able to read or write data located outside a predefined directory. Thus, critical system settings can be read or configuration files can be overwritten, which can disable the system for a sufficiently long period of time. Quite specific use cases for this error are possible. For example, a call to the OPEN DATASET dset FILTER iv_filter statement that opens a file for reading on a Unix system delivers data from a read file to a predefined process that can perform unexpected actions at the operating system level. Therefore, incorrect OS configuration and vulnerable code, without errors individually, can lead to critical consequences when working together. You will learn about problems with incorrect configurations in our next articles.
Authorization Errors
Are your programmers guided by the concept of authority in developing their applications? In accordance with this concept, access to any functional block of the program should be prohibited until the contrary is determined. Unfortunately, on many projects, access control is done at the transaction level, which makes it possible to combine various existing powers in order to access prohibited information. For example, using the CALL TRANSACTION statement (which is widely used by developers) on projects with access control at the transaction level is unsafe. Without specifying WITH AUTHORITY-CHECK, the CALL TRANSACTION statement allows you to jump through any other transaction. It is also possible that there is an authorization check, but it was done incorrectly. Such cases also need to be found and corrected.
Backdoors
Before that, we examined some cases of vulnerabilities when programmers made unintentional errors, as a result of which the code became vulnerable. However, there may also be cases where the programmer intentionally changes the course of program execution for certain users (“undocumented features”), or even leaves the so-called backdoor, which allows you to bypass all checks set by the system. A developer can make a backdoor without malicious purposes, such as obtaining SAP_ALL authority for more “efficient” work on an implementation project. Obviously, this does not detract from the risks that backdoors bring. There are many examples of such backdoors on the network that can simply be copied and transferred to a productive system. It’s very difficult to catch the presence of undocumented features and backdoors, firstly because of the huge amount of client code, and secondly because of the features of the SAP programming language. ABAP allows you to execute code on the fly and is stored in the DBMS, i.e. can be hidden very, very deep.
How to look for errors?
There are several different ways to search for vulnerabilities in the code, the most advanced of which is static analysis of the data stream. SAP Netweaver AS has a module that implements data flow analysis for the presence or absence of vulnerabilities (Code Vulnerability Analysis). There are certified partner solutions that allow you to scan application code for vulnerabilities. SAP Code Vulnerability Analysis (CVA) is based on the Code Inspector tool, which for many years allows you to check client code for potentially dangerous structures, but unlike Code Inspector, it uses data flow analysis. The most appropriate is the use of CVA from the first stage of the project - from the development stage (until the development is transferred further along the landscape), because corrections later (e.g. during productive operation) is more complex and costly. Implementation of CVA implies not only the search and correction of errors, but a change in the approach to development standards in the enterprise. The introduction of any new development into a productive system should be authorized by an expert guided in his work by the most modern development analysis tools.
Total
With this article, we wanted to show that the security issues of SAP products are much wider than our customers often imagine. It is important to clearly understand the full range of problems that may arise when supporting SAP-based solutions. To do this, you need to be aware of the current state of affairs, and we will tell you about this as part of a series of articles.
Posted by Daniil Luzin
Consulting Division of SAP CIS LLC
Kosmodamianskaya Emb. 52/7, 113054 Moscow
T. +7 495 755 9800 ext. 3045
M. +7 926 452 0425
F. +7 495 755 98 01