During their penetration tests (pentests), our security analysts at usd HeroLab repeatedly uncover vulnerabilities that pose significant risks to corporate security. They increasingly encounter the same vulnerabilities. Our blog series "Top 3 Vulnerabilities" presents them and provides tips on how to avoid them - for #moresecurity across all IT assets.
Today we look at the three most common security-critical vulnerabilities that our analysts have identified in SAP Pentests in recent years.
Why SAP Pentests?
A company's own SAP systems are a critical area for the IT security of a company, as sensitive and critical business processes are performed there. Exploiting a vulnerability in this environment can therefore have serious consequences, such as operational or financial damage for the entire company.
We therefore recommend regular pentests to identify potential vulnerabilities in your SAP infrastructures. However, many people are unaware of the fact: A pentest as carried out for other systems or applications, is not sufficient here. The complexity of SAP system landscapes requires in-depth expertise and a profound understanding of SAP environments. This expertise, coupled with a special approach to the comprehensive investigation of SAP systems and FIORI web applications, characterizes our SAP Pentests and enables our analysts to identify particularly critical, specific gateways for attackers.
Misconfiguration of the SAP Router
The SAP Router is an important component in a SAP system that serves as a secure communication channel between SAP systems and external networks, such as the internet or other company networks. The primary purpose is to enable SAP-(application-)servers to be accessed only via this channel and not to be exposed in the network.
Attackers can exploit incorrect configurations in SAP Routers, for example to execute port scans on systems behind the firewall. Therefore an attacker can use this vulnerability to enumerate information from the internal network and the SAP landscape. This can also allow attackers to bypass firewall restrictions and directly access systems within the SAP landscape. This bypassing of network security measures can lead to unauthorized access to sensitive data and critical resources.
The SAP Router is recognized as a popular attack vector as a gateway between the external and internal network as it provides a route to potentially sensitive systems and data behind the firewall. There is also a publicly available tool for carrying out port scans via an SAP Router. As can be seen in the following example, an internal system behind the firewall can be enumerated with this tool via the SAP Router.
Security tip:
To minimize the attack vector, strict access controls should be defined. In this way, access to the SAP Router can be restricted and unauthorized connections from external networks can be prevented. A password should be enforced for all connections, which is set in the route permission table. In addition, encryption should be activated for communication between SAP systems and the SAP Router in order to protect the confidentiality and integrity of the data.
Appropriate network segmentation can isolate critical systems and restrict direct access to sensitive areas within the SAP landscape. To identify and prevent attacks, appropriate systems can be used to monitor network traffic for suspicious activity and implement proactive measures.
Incorrect permissions for transactions
SAP systems provide functional modules in the form of transactions. In authorization audits and penetration tests, we repeatedly discover that regular users, e.g. in a department, have access to transactions that enable hazardous functionality.
A common example is access to any data tables with the data browser transaction SE16. In general, access to certain table contents within the SAP system is often necessary for the daily work of regular users. However, if the accessible tables are not sufficiently restricted, it is possible to view the password hashes of all users in the SAP system in table USR02:
Overall, the SAP authorization concept is complex. Often a large number of authorizations and roles exist within a company, making it complex to maintain and keep track of the authorizations used. In many cases, the assigned roles also contain several individual authorizations, meaning that fine-grained assignment results in a high level of effort. Furthermore, it is not immediately apparent for each transaction whether it represents a threat to the security objectives and how serious this threat may be. Some transactions such as SM49 allow attacks on the underlying operating system of the SAP application, for example.
Security tip:
To minimize attack vectors, a concept for the necessary authorizations of business processes should be established that is as fine-grained as possible. The roles used should be as detailed as possible and only contain authorizations that are absolutely necessary for the business processes (least privilege principle). Particularly critical authorizations, for example table access, should be further restricted to ensure that only defined accesses within the transaction are permitted.
Access control in the SAP Management Console
The so-called SAP Management Console allows various management functions for the SAP system. These accesses are enabled via a SOAP API interface. Recurring administration tasks can be mapped using the SAP Management Console and various monitoring solutions obtain information via this interface.
In the event of an incorrect configuration, it is for example possible to read log files, password guidelines or parameter values of the system configuration via this interface without authentication. The security objectives are compromised if sensitive access is possible without authentication. Attackers can easily enumerate and use provided accesses with publicly available tools, as can be seen in this example:
Security tip:
To minimize the attack surface, access to SAP Management Console functions without authentication should be restricted to the extent feasible. SAP provides a standard configuration for this purpose. The system parameter service/protectedwebmethods should be set to the value SDEFAULT.
If other functions are required without authentication in order to depict business processes, exceptions can be specified in the system parameter. However, SDEFAULT should be used as the basis here. For example, to enable the additional functionality for listing J2EE processes without authentication, the parameter value SDEFAULT -J2EEGetProcessList can be used.
Are you interested in gaining a detailed overview of the current security level of your SAP system landscape and identifying potential for improvement? A SAP-specific pentest can help. Contact us, we will be happy to help you.
.
