SAP is undoubtedly the world leader in ERP software. More than 437,000 companies in 180 countries use some form of SAP system (including 98% of the top 100 companies and 92% of the 2000 companies on the Forbes Global list).
Given the varied nature of the systems in the SAP ecosystem (financial, human resources, etc.) It is common to work with very sensitive data from organizations that is very important to safeguard, both from external attackers and internal fraud.
In this post we don’t intend to talk about the latest SAP vulnerabilities (most of them can be identified in the public tool SAP Security Patch Day), but about some of the vulnerabilities that exist since the beginning of SAP and that require a specific configuration by the companies and that, most of the times, is not done. In many cases, organizations are confident that by having the systems on the intranet, with no outside access, the risk is lower, but in addition to possible internal fraud, new mobile applications and portals that are being published on the Internet, can pose vulnerabilities to those systems that are not public. In our experience auditing the security of SAP systems, we have detected the following 4 vulnerabilities on a regular basis:
- Password cracking: at the beginning SAP encrypted passwords using MD5 and the user’s own name to encrypt the password. The problem is that this information (user and hash) is stored in the table containing the user list (USR02) which can be accessed from the system itself or from the database. With a simple dictionary and the John the Ripper program, you can break most system passwords and make use of any of these users. The solution to this problem is to activate a parameter so that MD5 is no longer used.
- Password sniffing: By default, communication between an SAP system and the SAP Logon (tool that allows access to SAP) is not encrypted and this allows sniffing of system access traffic to extract the plain text password of the user who is connecting to the SAP system. The solution is to activate encryption (Secure Network Communication).
- Remote Logon: connections between SAP systems are made using a technology called RFC (Remote Function Call), which requires a technical user with privileges in the system to make the connection. If this connection has not been made correctly, an attacker could jump from one system to another as shown in the following video.
- Code development in production: in SAP systems, the development of custom programs is limited by SAP, and it is necessary to request express authorization from SAP through a Portal to which customers have access. After registering the request, SAP provides code (developer key) that allows you to edit existing programs or create new ones. This restriction can be bypassed by users if they have debugging access (Debug & Replace), since a breakpoint can be entered in the program that requests the developer’s key and enter the variable manually that will allow us to create programs in the system. The solution is to completely restrict access to debug mode in production environments.
As you can see, despite the inherent robustness of a large ERP such as SAP, it is not exempt from potential security cracks that, regardless of whether or not it is connected to the Internet, can put the organization’s information at risk. In these cases, it is always advisable to audit the safety status of the SAP installation, so as not to have any unpleasant surprises.