Secure ABAP Development in SAP
Today in 2014, Russian companies that have deployed SAP products have spent a large amount of resources on client-side solutions. However, do these developments introduce additional risks to your business processes? SAP guarantees the quality of the code in its applications through manual auditing of the supplied code and using the most modern mechanisms for static and dynamic analysis of its products for various vulnerabilities. The author of these lines conducted a study at the University of Saarbrucken (Germany), whose goal was to analyze SAP product codes (e-commerce solutions) with the most up-to-date static analysis tools and was convinced of the high quality of this code. The SAP software code passes manual and automated analysis, thousands of special test cases. Client software code can often not be so fully analyzed, especially under the tight deadlines of projects in which it is necessary to work. It is worth thinking about the quality of client code in your systems. It is important to understand that verification of user authorization (a synonym for SAP security for many enterprises) will not help prevent the use of such errors, since a user using code errors is outside the scope of authority defined by the system administrator.
Consider errors that may be present in the client code.
The left possibility of code injection is one of the most common and most dangerous vulnerabilities according to the OWASP classification . Most of the well-known vulnerabilities, including OpenSSL Heartbleed (04/29/2014) and cracking of the Ebay site (05/22/2014) are related to the unintentionally left possibility of injecting user input into the program. The danger of such errors is the almost unpredictable results of the execution of vulnerable programs. The result of the injection of SQL code can be either a password leak or the complete removal of all system data. An additional problem with such vulnerabilities is the difficulty of finding them with automated tools. Search based on rules and patterns will not give a positive result due to the large number of mistakenly formulated assumptions. The only truly effective way to find errors can be a static analysis of the flow of data entering the program (Information Flow Control). Static analysis of the data flow allows us to trace the data that goes to potentially dangerous points and put forward the most accurate assumptions about the presence or absence of code injection vulnerabilities.
')
Another dangerous software code error is the unintentionally left possibility of substitution of input data, which allows directory traversal. An attacker using such a vulnerability can read or write data that is outside of a predefined directory. Thus, critical system settings can be read or configuration files overwritten, which can disable the system for a sufficiently long period of time. There are quite specific options for using this error. For example, calling an OPEN DATASET dset FILTER iv_filter statement that opens a file for reading in a Unix system delivers data from a readable file into a predefined process that can perform unforeseen actions at the operating system level. Thus, incorrect configuration of the OS and vulnerable code that do not have errors separately can lead to critical consequences by working together. You will learn about the problems of 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 denied until the opposite is defined. Unfortunately, in many projects, access control occurs at the transaction level, which makes it possible to combine various existing powers with the purpose of accessing prohibited information. For example, using the CALL TRANSACTION operator (which is massively used by developers) on projects with access control at the transaction level is unsafe. Without WITH AUTHORITY-CHECK, the CALL TRANSACTION statement allows you to navigate through any other transaction. It is also possible that there is an authorization check, but it is done incorrectly. Such cases also need to find and fix.
Prior to this, we considered some instances of vulnerabilities where programmers made unintended errors, causing the code to become vulnerable. However, there are also cases where the programmer intentionally changes the program execution for certain users (“undocumented features”), or even leaves a so-called backdoor, which allows you to bypass all the checks made by the system. A developer can backdoor without malicious purposes, such as obtaining the authority of SAP_ALL for more “efficient” work on an implementation project. Obviously, this does not diminish the risks that the presence of backdoors brings. There are a large number of examples of such backdoors in the network that can be simply copied and transferred to a productive system. To detect the presence of undocumented features and backdoors is very difficult, firstly because of the huge amount of client code, secondly because of the peculiarities of the SAP programming language. ABAP allows you to execute code on the fly and is stored in a DBMS, i.e. can be hidden very, very deep.
There are several different ways to search for vulnerabilities in code, the most advanced of which is static data flow analysis. In SAP Netweaver AS there is 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 now allows you to check client code for potentially dangerous structures, but, unlike Code Inspector, it uses data flow analysis in its work. The most appropriate is the use of CVA from the very first stage of the project - from the development stage (before transferring the development further along the landscape), since Corrections later (for example, in productive operation) are more complex and costly. CVA implementation implies not only finding and fixing errors, but changing the very approach to development standards in the enterprise. The introduction of any new development into a productive system must be authorized by an expert guided in his work by the most advanced development analysis tool.
With this article, we wanted to show that the security issues of SAP products are much broader than our customers often imagine. It is important to clearly understand the whole range of problems that may arise when supporting solutions based on SAP. To do this, you need to be aware of the current state of affairs, and we will tell you about this as part of the article cycle.
The author - Daniel Luzin
Consulting subdivision 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 errors that may be present in the client code.
Code injection
The left possibility of code injection is one of the most common and most dangerous vulnerabilities according to the OWASP classification . Most of the well-known vulnerabilities, including OpenSSL Heartbleed (04/29/2014) and cracking of the Ebay site (05/22/2014) are related to the unintentionally left possibility of injecting user input into the program. The danger of such errors is the almost unpredictable results of the execution of vulnerable programs. The result of the injection of SQL code can be either a password leak or the complete removal of all system data. An additional problem with such vulnerabilities is the difficulty of finding them with automated tools. Search based on rules and patterns will not give a positive result due to the large number of mistakenly formulated assumptions. The only truly effective way to find errors can be a static analysis of the flow of data entering the program (Information Flow Control). Static analysis of the data flow allows us to trace the data that goes to potentially dangerous points and put forward the most accurate assumptions about the presence or absence of code injection vulnerabilities.
')
Catalog traversal
Another dangerous software code error is the unintentionally left possibility of substitution of input data, which allows directory traversal. An attacker using such a vulnerability can read or write data that is outside of a predefined directory. Thus, critical system settings can be read or configuration files overwritten, which can disable the system for a sufficiently long period of time. There are quite specific options for using this error. For example, calling an OPEN DATASET dset FILTER iv_filter statement that opens a file for reading in a Unix system delivers data from a readable file into a predefined process that can perform unforeseen actions at the operating system level. Thus, incorrect configuration of the OS and vulnerable code that do not have errors separately can lead to critical consequences by working together. You will learn about the problems of 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 denied until the opposite is defined. Unfortunately, in many projects, access control occurs at the transaction level, which makes it possible to combine various existing powers with the purpose of accessing prohibited information. For example, using the CALL TRANSACTION operator (which is massively used by developers) on projects with access control at the transaction level is unsafe. Without WITH AUTHORITY-CHECK, the CALL TRANSACTION statement allows you to navigate through any other transaction. It is also possible that there is an authorization check, but it is done incorrectly. Such cases also need to find and fix.
Backdoors
Prior to this, we considered some instances of vulnerabilities where programmers made unintended errors, causing the code to become vulnerable. However, there are also cases where the programmer intentionally changes the program execution for certain users (“undocumented features”), or even leaves a so-called backdoor, which allows you to bypass all the checks made by the system. A developer can backdoor without malicious purposes, such as obtaining the authority of SAP_ALL for more “efficient” work on an implementation project. Obviously, this does not diminish the risks that the presence of backdoors brings. There are a large number of examples of such backdoors in the network that can be simply copied and transferred to a productive system. To detect the presence of undocumented features and backdoors is very difficult, firstly because of the huge amount of client code, secondly because of the peculiarities of the SAP programming language. ABAP allows you to execute code on the fly and is stored in a DBMS, i.e. can be hidden very, very deep.
How to search for errors?
There are several different ways to search for vulnerabilities in code, the most advanced of which is static data flow analysis. In SAP Netweaver AS there is 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 now allows you to check client code for potentially dangerous structures, but, unlike Code Inspector, it uses data flow analysis in its work. The most appropriate is the use of CVA from the very first stage of the project - from the development stage (before transferring the development further along the landscape), since Corrections later (for example, in productive operation) are more complex and costly. CVA implementation implies not only finding and fixing errors, but changing the very approach to development standards in the enterprise. The introduction of any new development into a productive system must be authorized by an expert guided in his work by the most advanced development analysis tool.
Total
With this article, we wanted to show that the security issues of SAP products are much broader than our customers often imagine. It is important to clearly understand the whole range of problems that may arise when supporting solutions based on SAP. To do this, you need to be aware of the current state of affairs, and we will tell you about this as part of the article cycle.
The author - Daniel Luzin
Consulting subdivision 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
Source: https://habr.com/ru/post/243121/
All Articles