SAP HANA Pentesting. Part 1: Vulnerabilities history

Three years have passed since the day when we published the details of the first vulnerability in SAP HANA. Nowadays more and more HANA systems are used in production environments of enterprises. We decided to start a series of articles on SAP HANA Pentesting to celebrate this event and share noticeable insights about pentesting of this platform. Within this period of time, we have accumulated a lot of knowledge about the organization of SAP HANA security, and now, we want to share it with you.

SAP HANA application history

SAP HANA history dates back to 2010. Since then, several versions of the solution have been released. Here you can find a list of them from the very beginning.

HANA versionSupport Package StacksRelease date
HANA 1.0SPS 00
SPS 01
SPS 02
SPS 03
SPS 04
SPS 05
SPS 06
SPS 07
SPS 08
SPS 09
SPS 10
SPS 11
SPS 12
October 2010
June 2011
July 2011
October 2011
April 2012
October 2012
April 2013
December 2013
April 2014
October 2014
June 2015
December 2015
May 2016
HANA 2.0SPS 00
SPS 01
SPS 02
November 2016
April 2017
July 2017

Among SAP plans for the future, there is to update the releases and maintenance strategy starting with SAP HANA 2.0 SPS 02:

  • SAP HANA 1.0 SPS 12 end of maintenance will be extended until May 2021;
  • SAP HANA will have one SPS release per year starting with SAP HANA 2.0 SPS 03 in Q2 2018.

SAP HANA Security Statistics

Let’s look at vulnerabilities affecting SAP HANA. Over 50 patches had been released in total by December 2017, and the actual number of closed vulnerabilities rises beyond 100. A single patch can fix one or more security issues found by developers or security researchers.

A small number of SAP Security Notes for SAP HANA was released during the period from 2011 to 2013. Still, the popularity of SAP HANA was not high enough yet for security researchers to take notice of the disclosed problems.

A significant increase in vulnerability patching began in 2014. At that time, Security Notes were released 5 times more than the year before.

In 2015, the number of issued Security Notes reached its peak, which forced developers to reconsider the attitude to safety of SAP HANA.

In 2016, the number of issued Security Notes for SAP HANA started to decrease. Presumably, it happened due to the fact that the developers introduced new protection methods against vulnerabilities.

In 2017, 10 SAP Security Notes for SAP HANA were issued. While a tendency of reduction of new SAP HANA Security Notes is traceable, we should not rely on the number of patches to understand the number of actual vulnerabilities. In reality, the number of vulnerabilities is much higher and one patch can serve for closing several issues. Talking about the future, the number of new Security Notes is supposed to increase as SAP implements HANA for different environments and adds new tools for developers. These changes will inevitably lead to the emergence of new vulnerabilities and, consequently, to SAP Security Notes for SAP HANA later.

SAP HANA vulnerabilities by type

Let’s consider the infographics of the vulnerabilities found in the SAP HANA platform for the entire time.

As you can see from the infographic in SAP HANA, the most common loophole type is Information Disclosure. With this type of vulnerability, people that are not supposed to have access to some types of information, get the critical data. It may be the information on company’s employees, clients, partners, competitors or third parties.

The Privilege Escalation is the second common type of vulnerabilities. This type of loopholes allows attackers to increase their privileges to modify critical information.

The third common type of vulnerabilities is SQL Injections that allows attackers to spoof identity, tamper with existing data, and cause repudiation issues, such as voiding transactions or changing balances.

Denial of Service is also a common problem. It involves the impossibility to access the information for the users of the compromised information systems.

SAP HANA vulnerabilities by application

Here you can find our infographics about SAP HANA vulnerabilities classification by application parameter.

The first largest number of vulnerabilities was detected in the main component of SAP HANA Database. This is not surprising as it is also the main component of SAP HANA applications.

The same number of vulnerabilities as in SAP HANA Database was found in SAP HANA Extended Application Services. The SAP HANA Extend Application (XS) was created as a full featured application server, web server, and development environment within the SAP HANA appliance itself. Therefore, this application attracts the attention of security researchers. In the future, the number of disclosed vulnerabilities in SAP HANA XS will decrease in relation to other applications because SAP has introduced SAP HANA XS advanced (XSA). It supersedes SAP HANA XS and provides significant improvements and advantages compared with its predecessor. In the future, security researchers will find vulnerabilities in SAP HANA XSA.

SAP HANA vulnerabilities history

Now that we have considered the general statistics, it is high time to look at the noteworthy vulnerabilities of each year. We will start from 2014 because there were no interesting vulnerabilities in the space from 2011 to 2013 and in most cases, loopholes in the production environment are already patched.

2014

SAP HANA platform was created when SAP became much more aware of vulnerabilities. This solution was a bit more secure by default rather than SAP NetWeaver ABAP Platform. However, multiple vulnerabilities were disclosed in this platform – from program errors to architecture vulnerabilities in the key management process.

18 June 2015, Dmitry Chastukhin, director of security consulting at ERPScan, presented a report on the latest SAP Security trends at the Black Hat Sessions conference in the Netherlands. It covers multiple problems related to encryption algorithms and static keys affecting SAP HANA Security and other SAP products, such as SAP Mobile Platform.

Speaking about the SAP HANA Security, Dmitry explained its encryption weaknesses and issues that make it vulnerable to SQL Injection.

Static encryption keys

SAP HANA database holds the accumulation of its data in memory for the maximum performance, but it still uses persistent disk storage to provide a fallback in case of failure. Data is automatically saved from memory to disk at regular savepoints. The data belonging to a savepoint represents a consistent state of the data on a disk and remains so until the next savepoint operation is completed, according to SAP HANA Security Guide.

SAP HANA uses SAP NetWeaver SSFS to protect the root encryption keys that secure all encryption keys used in the SAP HANA system, such as keys to encrypt savepoints data. So, savepoint keys are encrypted with the same master key for every SAP installation until a user changes it manually. It means that encrypted data is stored in the file system, and an attacker can gain access to these data using default master key.

SAP has provided SAP HANA Security Guidelines stipulating that the master key should be changed, and SAP Security Notes state the same. But, unfortunately, very few customers follow these recommendations. SAP recommends to:

  • Change the SSFS master key using the rsecssfx tool;
  • Change the data volume encryption root key using the hdbnsutil tool;
  • Change the data encryption service root key using the hdbnsutil tool;
  • Restrict access to the key file;
  • Restrict access to the DAT file.

SQL Injection

SQL Injection vulnerability was found in SAP HANA Web-based Development Workbench. To exploit this vulnerability, an attacker needed to inject an SQL query into the post request of the net.xsjs application.

Example 1:

POST /sap/hana/xs/ide/server/net.xsjs HTTP/1.1
X-CSRF-Token:
{"absoluteFunctionName":"sap.hana.xs.ide.server.getTraceFile","inputObject":{"filename":"dev_webdisp' union select version from \"PUBLIC\".\"M_DATABASE\"--","host":"hanacloud"}}

Example 2:

POST /sap/hana/xs/ide/server/net.xsjs HTTP/1.1
X-CSRF-Token:
{"absoluteFunctionName":"sap.hana.xs.ide.server.getTraceFile","inputObject":{"filename":"dev_webdisp","host":"hanacloud' union select version from \"PUBLIC\".\"M_DATABASE\"--"}}

The problem resided in the parameters “filename” and “host”. The data of these parameters was inserted into the SQL query without filtering. This issue allowed an attacker to inject “evil” SQL queries.

This vulnerability was patched in SAP Note 2014881.

2015

SAP HANA Platform includes HANA XS Engine – a built-in application server, which can process HTTP requests from a web browser to the database. HANA XS is yet another application server like Apache Tomcat. All functionality of SAP’s new products is based on web applications, which work on XS engine, obtain data from the SAP HANA database, process this data on XS Engine, and present users the results on web pages. XS Engine uses its own server-side JavaScript engine to process server-side requests.

The fact that SAP HANA is an in-memory database does not mean that it is more secure. SAP HANA XS web application server, as well as applications based on it, is susceptible to the same vulnerabilities as any other web application server. A number of critical vulnerabilities in SAP HANA XS application server itself was identified by security researchers, for instance, Buffer Overflow vulnerability discovered by Matheu Geli from ERPScan.

Buffer overflow

Buffer Overflow vulnerability exists in SAP HANA interface. If an attacker has a network access to the SQL interface or to the SAP HANA Extended Application Services interface of an SAP HANA system, the vulnerability enables the attacker to inject the code (Remote Command Execution) into the working memory that is subsequently executed by the application. It can also be used to cause a general fault in the product causing its termination.

An anonymous attacker can use a special HTTP request to corrupt the memory of the SAP HANA index server.

curl -v -XPOST http://hana:8000/sap/hana/xs/formLogin/login.xscfunc -H 'Content-type: application/x-www-form-urlencoded; charset=UTF-8' -H 'X-csrf-token: unsafe' -d 'xs-username=AAAAAx800’

The problem resided in the “xs-username” parameter as there was no limit in the user input length and check buffer boundaries in the index server authentication part.

An attacker can use a remote command vulnerability to execute commands without authorization, under the privileges of the service that executes them. The hacker can access arbitrary files and directories located in an SAP server filesystem, including application source code, configuration, and critical system files. It allows obtaining critical technical and business-related information stored in a vulnerable SAP system.

To correct this vulnerability, install SAP Security Note 2197428.

2016

We have told you what critical vulnerabilities exist in SAP HAHA, but it is necessary to note that even an information disclosure vulnerability can make it possible to cause huge harm to a company. In 2016, this loophole was discovered in SAP HANA XS classic user self-service. The CVSS v3 Base Score of this vulnerability is only 5.3 out of 10. Further we will see how this vulnerability works and what an attacker can do with its help.

Information disclosure

A remote unauthenticated attacker can get a list of users in SAP HANA by abusing the password recovery functionality provided by the user self-service application. This application returns detailed messages that are able to reveal the existence of a user.

An anonymous attacker can use a special HTTP request to gain a user list.

POST /sap/hana/xs/selfService/user/selfService.xsjs
{"username":"USER_TO_TEST","action":"forgotPwd"}

If the user exists, the attacker will receive the following error messages:

{"name":"UserError","message":"No e-mail address is set for this user name; contact your system administrator"}
{"status":"success","message":"Request for password reset is accepted; check your e-mail for more instructions"}

If the user doesn’t exist, the attacker will receive the following error message:

{"name":"UserError","message":"Invalid username or configuration; contact your system administrator"}

It might seem that this vulnerability is just the disclosure of information, but if an attacker gets a list of all the users, including administrators, he or she can perform these actions:

  • block user and administrators accounts, which can lead to production disruption because recovering credentials will take a long time;
  • brute-force user passwords and gain access to user’s data;
  • apply social engineering methods in order to fraudulently capture critical information.

To correct this vulnerability, install SAP Security Note 2394445

2017

In 2017, there were many vulnerabilities in SAP HANA and we will talk about them in our next articles.

Resources

Also, you can to get acquainted with other our articles about the SAP HANA:

SAP HANA for Dummies
SAP S/4 HANA Security Guide: Introduction
SAP HANA Security
SAP security for CISO. Part 11: SAP HANA Platform Security
SAP Passwords. Part 2: SAP HANA Security Storage. How it works – security issue is that the default key for encrypting.

The post SAP HANA Pentesting. Part 1: Vulnerabilities history appeared first on ERPScan.

This is a Security Bloggers Network syndicated blog post authored by Michael Medvedev. Read the original post at: Blog – ERPScan