Many factors cause SAP applications to require special measures from a security standpoint, including complexity, criticality, change management, customizations, SAP knowledge, and misconceptions about SAP cyber security. I briefly discuss each of these factors.

Complexity. SAP systems are not standalone applications that run somewhere in your organization and are accessed by a handful of people. Instead, when a company implements an SAP system, many SAP products are usually included as a part of the implementation. These products are all interconnected and are constantly exchanging information.

Criticality. SAP applications are a critical component to any organization as they house mission-critical information and processes. For example, SAP applications are used to process purchase orders, store customer and HR information, and house intellectual property (IP) such as formulas and information necessary for daily operations of every organization.

Change management. Downtime is not an option for SAP applications. To control and prevent downtime, strong change management processes are implemented around SAP applications.

Customizations. SAP applications are heavily customized to map real business processes defined by an organization. This customization adds an extra layer on top of the SAP standard applications, which is commonly referred to as customizations.

SAP knowledge. SAP applications are not traditional web applications. These applications are typically developed using proprietary languages, and their architecture leverages proprietary protocols and concepts that are unique to these systems. Therefore, the knowledge required to understand security risks, vulnerabilities, and misconfigurations around these systems is unique.

Misconceptions about SAP cybersecurity. SAP security teams have existed since the first SAP implementations took place. However, these teams often are focused on managing roles, profiles, and authorizations to ensure that every employee can perform only the activities they are supposed to. This narrow focus on user access has created a gap in security posture, as securing SAP applications should involve much more than segregation of duties.

Because of the previously mentioned factors, organizations are often not properly protecting SAP applications. This lack of proper security leaves them exposed to potential cyber-attacks that can be triggered through unpatched vulnerabilities, or insecure configurations of the SAP system.

The Alert

The U.S. Department of Homeland Security (DHS) released the first-ever US-CERT Alert on cybersecurity risks affecting SAP business applications. This alert forewarns cybersecurity professionals about the significance and implications of a more than five-year-old SAP vulnerability known as the Invoker Servlet (patched by SAP in 2010) that was leveraged to exploit the SAP systems of 36 large-scale global enterprises. The exploitation of these systems was publicly disclosed during 2013-2016 at a digital forum registered in China.

In early 2016, the Onapsis Research Labs became aware of this issue and decided to dig deeper into the topic. Onapsis soon realized that public information about these exploitations had been sitting in the public domain for several years. As the research indicates, cyber-attackers could be actively exploiting global organizations (beyond the original 36 enterprises) to access mission-critical information, and to potentially fully compromise systems. 

The Vulnerability

The SAP Java 2 Platform Enterprise Edition (J2EE) Application Server has a wide set of built-in functionality, providing a comprehensive framework of libraries and services to support the development and deployment of Java applications. One of these functionalities is the Invoker Servlet, which is part of the standard J2EE specification of Sun (now Oracle). It was conceived as a rapid development instrument, allowing developers to test their custom Java applications very quickly.

When enabled, this feature allows anyone to call specific applications without requiring authentication, which implies a security risk. The Invoker Servlet attack (sometimes referred to as the Invoker Servlet Detour) is the vulnerability caused by the previously mentioned feature and allows remote malicious hackers to bypass authentication mechanisms and perform unauthorized business activities via the vulnerable SAP applications. The potential impact of its exploitation is the complete compromise of the SAP system.

Identifying If You Are Vulnerable

As highlighted in the US-CERT Alert, the most critical scenario around this vulnerability is not only when the Invoker Servlet is enabled but also when the Central Technical Configuration (also known as the CTC application, an administration application integrated into the SAP Java Application Server) is enabled and vulnerable. Under these conditions, the SAP system can be compromised by external attackers without any user credentials. You can test this scenario by executing a single HTTP request. To complete this test, access the following URL using any web browser:

https://IP:port/ctc/servlet/com.sap.ctc.util.ConfigServlet?param=com.sap.ctc.util.FileSystemConfig;EXECUTE_CMD;CMDLINE=whoami

Figure 1 shows the execution of the previously detailed test, resulting in arbitrary command execution in the SAP Application Server.

Figure 1

Results of executing the whoami command through the Invoker Servlet

However, the aforementioned test is focused on only the most critical scenario. To properly identify if the SAP system is vulnerable to the Invoker Servlet, independently of which application could be abused, a double-check of global and local configurations is required.

For SAP NetWeaver up to 7.0, follow these steps:

1. Use the SAP Config Tool (available in /usr/sap/<SID>/<INSTANCE>/j2ee/configtool/).
2. Go to Cluster-data > Global Server Configuration > Services > servlet_jsp.
3. Check the value of the EnableInvokerServletGlobally property. If it is set to false or not configured, then the system is vulnerable through the global configuration (Figure 2).

Figure 2

Validating the Invoker Servlet global configuration for NetWeaver 7.1 and lower

For SAP NetWeaver from 7.1 upward, follow these steps:

1. Use the SAP NetWeaver Administrator (https://<host>:<port/nwa where host and port are the corresponding SAP System host and http port).
2. Go to Configuration > Infrastructure > Java System Properties > Services.
3. Choose Show Advanced Properties.
4. Type servlet_jsp in the Service Component Name field.
5. Type EnableInvokerServletGlobally in the Property Name field.
6. Check its Default Calculated Value. If it is true, then the system is vulnerable through the global configuration (Figure 3).

Figure 3

Validation of the Invoker Servlet global configuration for NetWeaver 7.1 and higher

Analyzing the Local Configuration

Even if the global configuration for the Invoker Servlet is disabled, it can be overridden by a local setting that is dependent on each application.

To identify if the local configuration of each custom application created in the SAP NetWeaver Java system is properly secured, each web.xml file must be analyzed, looking for the Servlet name Invoker and the parameter InvokerServletLocallyEnabled.

Figure 4 shows an example of a section of a web.xml file that enables the Invoker Servlet locally for that application.

<servlet>
<servlet-name>invoker</servlet-name>
<servlet-
class>com.sap.engine.services.servlets_jsp.server.servlet.InvokerServlet</servlet-class>
<init-param>
<param-name>InvokeByClassName</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>InvokerServletLocallyEnabled</param-name>
<param-value>true</param-value>
</init-param>
</servlet>

If this Servlet is defined locally, and the parameter InvokerServletLocallyEnabled is set to true, then this specific application defined by that web.xml file is also vulnerable, regardless of the global configuration.

Fixing the Vulnerability

If your organization is running a vulnerable SAP application, it could imply a high risk to the complete SAP landscape. Therefore, the vulnerability must be fixed by implementing the proper remediation process.

The remediation of this vulnerability requires a phased approach, which includes several steps.

Step 1. Check if the property EnableInvokerServletGlobally is present in the Java stack. In case it is not, implement SAP Note 1445998. This note creates the property that allows you to disable the Invoker Servlet in SAP NetWeaver 7.00 and lower.

Step 2. After SAP Note 1445998 is implemented, modify the property EnableInvokerServletGlobally to false, as described in the previous section, depending on the SAP NetWeaver version. For versions up to 7.00, save the configuration and restart the instance for this change to take place.

Step 3. Several business applications run on top of the SAP NetWeaver Java Application Server. In case one of the following applications is running on your environment, make sure the mentioned SAP Security Notes are implemented:

•            SAP Enterprise Portal – SAP Note 1467771

•            SAP BillerDirect – SAP Notes 1537663 and 1802092

•            SAP Virus Scan Engine – SAP Note 1900752

•            SAP CRM – SAP Notes 1598246 and 1488846

•            SAP Classified Advertising Management – SAP Note 1535301

Step 4. For each custom application created in the SAP NetWeaver Java Application Server, restrict the use of the Invoker Servlet. These applications should use local specific servlets within their web.xml files. To achieve this, locate the <servlet-name>invoker</servlet-name> configuration in the web.xml file of the application and set its parameter InvokerServletLocallyEnabled to false.

Step 5. To reduce the risk of command execution attacks, implement SAP Security Note 1963100, which disables the features of OS command execution through the CTC application.

Detecting Exploitations

The exploitation of the Invoker Servlet vulnerability is always performed through the execution of HTTP requests, potentially even using a simple web browser. These requests are registered by the SAP NetWeaver Java System in the HTTP responses log, located in the /usr/sap/<SID>/<INSTANCE>/j2ee/cluster/server0/log/system/httpaccess directory.

Access to any Servlet can be detected in that log, and more specifically, the exploitation of the Invoker Servlet through the CTC application can be detected by filtering the responses log file, searching for access to the url /ctc/servlet/com.sap.ctc.util.ConfigServlet.

The extract of the responses log shown in Figure 5 contains evidence of an execution of the Invoker Servlet vulnerability.

[Jun 10, 2016 7:13:47 PM  ] - xxx.xxx.xxx.xxx : POST /logon/logonServlet?redirectURL= 
HTTP/1.1 200 4450
[Jun 10, 2016 7:14:47 PM  ] - xxx.xxx.xxx.xxx : POST /logon/logonServlet?redirectURL= 
HTTP/1.1 200 4450
[Jun 10, 2016 7:25:02 PM  ] - xxx.xxx.xxx.xxx : GET
 /ctc/servlet/com.sap.ctc.util.ConfigServlet?param=com.sap.ctc.util.FileSystemConfig;EXECUTE_
CMD;CMDLINE=ls HTTP/1.1 200 3191

This way, organizations can potentially implement detective controls, which must consider receiving and properly parsing and processing the responses log file of every application server, also considering that logs can rotate and be saved across different files, depending on how the logging capabilities are configured in the SAP Java system.

Mitigation Control

In terms of protection, a basic compensating control could be implemented to avoid the execution of operating system commands via the CTC application, when it is vulnerable to the Invoker Servlet.

To prevent the abuse of this misconfiguration, the SAP Web Dispatcher could be leveraged, but it is effective only if it is the sole entry point to access the SAP Java system. This means that access to the HTTP port of the SAP system needs to be filtered to any source other than the SAP Web Dispatcher.

After the SAP Web Dispatcher is properly deployed in place and the URL filtering is enabled (check https://help.sap.com/saphelp_nw74/helpdata/en/48/9ac19148c673e8e10000000a42189b/content.htm for information on how to set it up), the URI permission table, which defines the URI that should be accepted or denied to go through the Web Dispatcher, should include the following line, preventing access to the CTC application through the Invoker Servlet:

D /ctc/servlet/com.sap.ctc.util.ConfigServlet

After this entry is incorporated in the SAP Web Dispatcher URI permission table, potentially dangerous HTTP requests abusing the Invoker Servlet through the CTC application should be denied, protecting the system against this specific vulnerability.

Fixing the Root Cause

The Invoker Servlet vulnerability is an excellent example of a vulnerability whose exploitation was able to occur due to the combination of security-relevant configuration issues, and the lack of implementing security patches released by SAP. It is also a clear example of how attackers are leveraging an organization’s lack of governance over the security of business applications, as SAP made a security patch available several years ago.

SAP releases patches to fix newly discovered vulnerabilities on the second Tuesday of each month (the same day that Microsoft does). With every new security patch, there could be new configurations with severe security implications on SAP systems if left unpatched. To properly protect SAP systems, it is necessary for organizations to implement a comprehensive SAP cybersecurity program that not only incorporates a patch management process, as well as a configuration change management process, but also brings together all teams within an organization who are responsible for the security of SAP environments. These include SAP security, SAP Basis, IT security, and the internal audit teams. As with any security initiative, it takes the right combination of people, process, and technology to be successful.

It is critical for every organization using an SAP system to close the Invoker Servlet risk by following all the recommendations included in this article. By doing so, the risk of a system compromise through this vulnerability can be eliminated.

Juan Pablo Perez-Etchegoyen

Juan Pablo Perez-Etchegoyen is chief technology officer at Onapsis. He is responsible for the coordination of the development and research activities, focused on SAP and other ERP systems.

Juan will be presenting at the upcoming Cybersecurity for SAP Customers 2017 conference, November 29-December 1, 2017, in Las Vegas. For information on the event click here.

You may contact the author at jppereze@onapsis.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.