General security

SAP NetWeaver J2EE Platform Security

Alexander Polyakov
March 27, 2017 by
Alexander Polyakov

In the previous article, we discussed SAP NetWeaver ABAP Platform and its vulnerabilities. Today's topic is the J2EE platform, its architecture, vulnerabilities, and the latest trends in its cyber security.

SAP NetWeaver J2EE is usually considered an additional platform mainly for applications used by IT department. Although this platform is mostly unknown and underestimated, you will be surprised how many SAP J2EE systems there are in every organization that runs SAP. More importantly how many J2EE systems are open to the Internet. According to the latest SAP Cybersecurity in Figures report, SAP J2EE Platform is the most widespread platform throughout the Internet. A custom scan revealed more than 11000 unique servers with different SAP web servers. The J2EE server remains the most widespread platform having 5000+ installations worldwide. So even if SAP J2EE is not the most common internal platform such as SAP ERP, it is still the most prevalent SAP's web platform, in several times exceeding the number of HANA installations, meaning that regarding remote cyber attacks, it is one of the most important systems to protect.

What should you learn next?

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Application server

Number

%

SAP NetWeaver J2EE

5362

48%

SAP Business Objects

492

4%

SAP HANA

500

4%

SAP NetWeaver ABAP

2696

26%

SAP NetWeaver ICM

1974

18%

Why companies use SAP J2EE platform

SAP J2EE central applications' purpose is mainly an integration of different business systems based on the ABAP engine such as ERP and CRM. Imagine you want to transfer data between SAP ERP and non-SAP system. It usually can be made by Enterprise Service Bus, such as SAP PI, which is based on the J2EE platform. Other applications based on SAP NetWeaver J2EE are as follows:

  • SAP Portal, which is usually a starting point for accessing all SAP and non-SAP applications;
  • SAP Process Integration, a system which simplifies the data transfer between different systems;
  • SAP Solution Manager and other SAP's or custom applications laid on the J2EE engine, which are less discussed than ABAP-based ones but susceptible to critical security issues.

While those systems that are based on J2EE usually do not store business-critical data directly, they keep technical data and can be used to get access to passwords and connections. Also, they transfer this data or provide access to it, thus, once somebody compromises, assume, SAP PI system, he or she can get control over all mission-critical processes. The consequences may be even more deplorable than after attacks on a particular ABAP-based system such as SAP ERP.

Another example is SAP Portal, unauthorized access to which allows cybercriminals to take total control of all business-critical systems of a company.

SAP xMII system is also based on the SAP J2EE engine. It is hard to underestimate its importance since it is a bridge between enterprise applications (i.e. ERP) and Plant floor or ICS. Plant floor is responsible for manufacturing, ICS - for Oil production. It goes without saying that such attacks can lead to devastating results.

Another example is SAP Solution Manager System that is aimed at managing all SAP systems installed in a company. By getting access to Solution Manager, which is like domain controller for SAP systems, an attacker accesses all SAP systems linked to Solution Manager. Put it simply, when the solution manager receives updates from SAP, there should be a way to install them on other SAP Systems. As a rule, it means that solution manager system stores usernames and passwords to connect to satellite SAP systems. Therefore, attacks on systems intended to integrate other systems, storing critical data, and running critical processes, can be more attractive for attackers then the systems itself.

That is why the security of SAP J2EE systems is essential.

SAP J2EE Platform Architecture

SAP J2EE engine consists of different parts that are illustrated in the picture below.

The SAP NetWeaver J2EE is a complex system. It consists of multiple services, some of them such as HTTP and Visual Admin are obligatory while others are not. The Visual Admin service is responsible for the administration of the J2EE engine; HTTP service handles user connections.

HTTP service, which can be accessed from the Internet, and P4 Service accessed locally are main areas that often pique attackers' interest.

The detailed information about architecture can be found in SAP documentation. As we are talking about security, we are interested in basic architecture areas that need to be understood to go further and touch on vulnerabilities and attacks.

SAP NetWeaver J2EE from attackers' point of view

What is SAP NetWeaver J2EE from an attacker's perspective? In fact, it is a dozen of open ports and hundreds of applications installed on Web Application server by default (SAP's applications) or developed by the company.

  • Main services are
    • SAP Visual Admin (P4)
    • SAP NetWeaver HTTP (Web server)
  • Additional services are
    • SAP SDM
    • SAP SDM Admin
    • SAP Log Viewer
    • SAP Log Viewer Standalone
    • SAP J2EE Telnet

The SAP NetWeaver application server is a storage for Java applications. It is similar to any other application servers like Apache Tomcat, BEA WebLogic, IBM WebSphere, or Oracle application server. It is distributed with more than 1000 web applications; all of them are enabled by default.

Our research team only discovered more than 200 vulnerabilities in the SAP J2EE applications. The vendor now fixes most of them. We will show only a couple of the most critical ones. Nevertheless, a lot of vulnerabilities are actually in a patching status, so this article is merely the tip of the iceberg.

SAP J2EE Vulnerabilities

There are about 500 different issues identified in all products based on this platform in total. The number is less than in SAP ABAP Platform but still much more than in any other SAP's platform.

The percentage of vulnerabilities in SAP J2EE remains almost the same in comparison to the total number of vulnerabilities and ranges between 7 to 20 percent. However, the actual number of vulnerabilities is decreasing after its peak in 2012.

SAP Security Notes sorted by years in NetWeaver J2EE engine

There were many informative presentations about SAP J2EE server security. The most important one[1], which is still relevant, was delivered in 2011. This presentation describes the architecture of this platform and some of the critical authentication bypass vulnerabilities that can be used to gain unauthorized access to the system.

Authentication Bypass attacks on SAP J2EE

In 2011, "Architecture And Program Vulnerabilities In SAP's J2EE Engine", the first detailed research about SAP J2EE Security, saw the release.

Invoker servlet functionality was created for rapid calling servlets by their class name and supposed to be used only for debugging, but it turned out to have become a security problem. Invoker servlet allows calling any servlet from application even if it is not declared in WEB.XML file.

The problem occurs if WEB.XML is configured insecurely.

To call any servlet by Invoker, you can use this URL:

http://server.com/<application name>/servlet/<servlet-name-or-class>

For example, in this WEB.XML, there is servlet that executes actions is stored in /admin/ directory, and access is secured.

However, if you try to call it directly by using /servlet/com.sap.admin.Critical.Action you will still gain access so that authentication bypass will take place.

During our research, we found applications that can be bypassed by direct calling to Invoker servlet and one of them is CTC service that is intended to deal with tasks related to technical configuration.

The other type of Authentication Bypass vulnerability dubbed Verb Tampering is not as well-known as others. However, it can be exploited for various attacks such as WAF bypass. By leveraging Verb Tampering, one may bypass declarative authorization of SAP NetWeaver J2EE engine.

SAP NetWeaver J2EE engine can accept HEAD requests in some circumstances without authentication and manage them as GETs. It means you can use the HEAD method instead of GET for some applications where GET access is restricted by WEB.XML. This type of vulnerability also affects the SAP HANA platform.

This attack makes it possible to access CTC service, create a new user in an SAP system, and assign administrator rights to this user afterward.

The third critical attack is SSRF. All additional information can be found in the "SSRF Vs Business Critical Applications: XXE Tunneling In SAP whitepaper.

In a nutshell, this attack allows gaining access to internally hosted systems such SAP ERP via an external system like SAP Portal. Likewise, SAP Portal has multiple vulnerabilities such as Session Fixation. "SAP: Session (Fixation) Attacks and Protections".

More attacks on SAP Portal are provided in our "Breaking SAP Portal" presentation. [2]

Other Services attacks

As it was mentioned afore, there are SAP J2EE Services, which can be accessed only internally, such as P4, SDM and Log Viewer.

P4 is an administrative service, and it is feasible to access this service by sending an authentication request with no credentials due to the improper access control check. As for SAP Log Viewer, this service does not require authentication and can be used to read any SAP J2EE log remotely. Exploiting a directory traversal vulnerability permits reading any log file and any file from OS as well, including a configuration file with password hashes for SDM service.

SDM Service is responsible for uploading any application on the SAP J2EE platform, and it turns out, one may login into this service having a single password hash without the necessity of decrypting it. Thus, mixing Log Viewer and SDM vulnerabilities allows uploading any application on SAP J2EE system and get full access to this platform.

More details on this attack can be found in our presentation "Injecting Evil Code In Your SAP J2EE Systems".

Conclusion

As you saw, there are many critical vulnerabilities in the SAP J2EE engine that can be exploited to get control over SAP J2EE Systems. We considered only some of them. These vulnerabilities were involved in real attacks on SAP Systems, for example, in the NVidia incident happened in 2014 (the company's SAP Portal was exposed to the Internet with Invoker servlet vulnerability). In 2016, US-CERT published an alert with details of more than 30 enterprises affected by the Invoker servlet issue and allegedly hacked by Chinese hackers.

I am concluding with a piece of advice. Even if the SAP J2EE Platform is not a basis for well-known systems such as ERP, CRM or SRM, it is used in systems that are interconnected with them (e.g. Portal, XI, Solution Manager, and xMII), so their security is vital.

Resources

Alexander Polyakov
Alexander Polyakov

Alexander Polyakov is the founder of ERPScan and President of the EAS-SEC.org project. Recognized as an R&D professional and Entrepreneur of the year, his expertise covers the security of enterprise business-critical software like ERP, CRM, SRM and industry specific solutions for Oil and Gas, Manufacturing, Retail and Banking; as well as other verticals developed by enterprise software companies such as SAP and Oracle. He has received numerous accolades and published over 100 vulnerabilities.

Alexander has also published a book about Oracle Database security, numerous white papers, such the award winning annual "SAP Security in Figures”; plus surveys devoted to information security research in SAP.

Alexander has presented his research on SAP and ERP security at more than 50 conferences and trainings in 20+ countries in all continents. He has also held trainings for the CISOs of Fortune 2000 companies, and for SAP SE itself.

He is the author of numerous whitepapers and surveys devoted to information security research in SAP like "SAP Security in figures." Alexander was invited to speak and train at international conferences such as BlackHat, RSA, HITB and 30 others around globe as well as in internal workshops for SAP and Fortune 500 companies.