SAP HANA : Pentest through TREXNet

CERT-DVT Sécurité SAP

Version Française

dev-light.png

Introduction

In 2016 an important security vulnerability was corrected on the new SAP platform : SAP HANA.
An anonymous ‘Remote command Execution’ was possible. The exploitability is more or less easy, depending on versions, but even with the last up to date SAP HANA version, currently SPS12, attack are still possible if the SAP System isn’t well configured.

SAP HANA

Because it’s not the goal of this article, I will not describe the HANA infrastructure or detailed workload of S/4 HANA. To summarize, this is the ‘in memory’ database, presented by SAP like the next big thing :

(c) SAP AG

SAP encourage customers to migrate on SAP HANA, and position itself as Oracle concurrent in performance and high availability aspects.
On security side, our goal, even if the product is relatively new, the number of SAP security notes isn’t negligible.

Notice, than 2/3 of these SAP Notes are tagged in high priority.

dev-network.png

SAP HANA TREXNet : the issue

For internal communication between different servers of a SAP HANA system, the system uses the TREXNet protocol : a proprietary and undocumented protocol. TREXNet isn’t the official name, but by mistakenly, there are many references of it by this name.
Because this protocol wasn’t design to be used by end-users, it was created without special security notions : no authentication, no encryption, etc.
Threrefore, if a malicious user manages to communicate with these internal services through the TREXNet protocol, it may compromise the full SAP system.

Extract of ‘SAP HANA Security Guide‘ (c) SAP AG

Impacted services are the follow (where xy is the SAP system number) :

Default port – Service name
3xy00 – HDB Deamon
3xy01 – HDB Nameserver
3xy02 – HDB Preprocessor
3xy03 – HDB Indexserver
3xy04 – HDB Scriptserver
3xy05 – HDB Statisticserver
3xy07 – Xengine
3xy10 – HDB Compileserver

Access to any of these services allows attacker to perform operations at the OS level as an SAP administrator privileges without being authenticated.

From SPS06, these services are no longer accessible externally by default. However, they are still necessary in ‘Multi-host’ scenario.
For versions below the SPS10, the attack is easy due to the access to function like ‘pexec’.
Since SPS11, several unsafe functions are no longer accessible, also, SAP provides a method for isolate and protect these internal communications. The attack is still possible in the case of a mis-configured SAP System, exposing one of these internal services.

dev-target.png

Attack scenario against SAP HANA

Below an example of a SAP HANA pentest, using this vulnerability. We only know the IP address of the target SAP System. This is the last SAP HANA platform 1 version available, SPS12, where the only mistake made by administrator is to expose services using TREXNet.

  • SAP system port scanning
  • Checking if the attack is possible
  • From now, it’s possible to read, write and delete any data of the SAP system.
  • DDos attack, remotly without authentication is also possible, including web service on port 8000

SAP HANA services are no longer accessible.

  • Finally it’s possible to modify files. To add, for example, a reverse shell in environment file. Then wait for an administrator login.

dev-network.png

Remediation & Conclusion

The SAP HANA internal communications are critical points in term of security. It is imperative to isolate, in dedicated network, these types of communications, like described in the OSS Note 2183363 and in the ‘SAP HANA Security Guide’.

It also important to audit, during the project phase, to identify if potential risk will exist in the future infrastructure and the exposure of internal SAP HANA services.

Check out our SAP Security offer :

http://www.devoteam.fr/en/offers/risk-security/expert-articles/secure-your-sap-against-new-threats

  • SAP Audit Assessment
  • SAP Penetration Testing
  • Remediation Process
  • Training
  • etc.