The security of ‘SAP Secure Storage’

CERT-DVT Sécurité SAP

Version Française
dev-light.png[x_custom_headline type=”none” level=”h4″ looks_like=”h4″]Introduction[/x_custom_headline]

  • What is SAP Secure Storage ?
    The SAP Secure Store is a SAP component allowing the encrypted storage of sensitive data that SAP application requires for remote login to others systems, database connections, etc.
  • What kind of information are stored in it ?
    Basically it could handle a lot of valuable credentials ! Among the most interesting are login informations about : SAP services, remote SAP system, database and OS.
  • Where do we find it ?
    It depends of SAP version and configuration. It could be a database table for AS ABAP, or a couple of OS files for AS JAVA or HANA, and also for recent AS ABAP versions.
  • What is the threat ?
    If an attacker is able to read the SAP Secure Storage, it could lead to privilege escalation vulnerability as well as horizontal movement activities to others SAP systems.

 

dev-logistic.png[x_custom_headline type=”none” level=”h4″ looks_like=”h4″]SAP Netweaver ABAP – RSECTAB table[/x_custom_headline]

On SAP Netweaver ABAP, sensitive data are stored directly in a table : RSECTAB. Data are client dependant, and there are two important fields in RSECTAB table :
IDENT – NOT NULL VARCHAR2(189), this is object identification, like RFC destination name
DATA – RAW(184), this is the encrypted content

The encryption mechanism is based on 3DES, and can be summarize by the following process :

1/ SAP calculates the encryption key using 3DES on two static keys stored in SAP kernel

The encryption key.

2/ Then it decrypts the DATA content of tables with this key, and retrieves some information like SID and System installation number. But after this first pass, some data are still encrypted.

3/ Using SID, installation number, and some XOR operations, SAP generates a second key derived from the first one.

Part of second key generation.

4/ Finally, it uses this second key on 3DES again with DATA (after the first pass), to retrieve the password.

SAP Administrator could change the default key… but this custom key will be stored in the file system. Its path is defined by parameter rsec/securestorage/keyfile.

Well, we could decrypt it :

 

dev-logistic.png[x_custom_headline type=”none” level=”h4″ looks_like=”h4″]SAP Netweaver JAVA – SecStore.properties file[/x_custom_headline]

On AS JAVA the SAP Secure storage is managed by two files :
The SecStore.properties, where the encrypted contents are stored with format like <parameter>=<encrypted data> :

The SecStore.key, where the key is stored encrypted just after the version :


By default, these files are in /usr/sap/<SID>/SYS/global/security/data/ directory.
The key encryption is based on a simple xor with a hardcoded key stored in SAP JAVA kernel.

The ‘xor’ method, where the hardcoded key is stored.

This key is used to decrypt the SecStore.properties file content using cipher ‘PbeWithSHAAnd3_KeyTripleDES_CBC’ :


Again, we could decrypt it :

 

dev-logistic.png[x_custom_headline type=”none” level=”h4″ looks_like=”h4″]SAP HANA & ABAP – SSFS_SID.DAT file[/x_custom_headline]

SAP HANA, and also AS ABAP from 7.40 version, use Secure Storage in File System (SSFS) as SAP Secure Storage. It’s based on file SSFS_SID.DAT, additionally with a SSFS_SID.key if custom key is set.

The files path could be found in environment variables $RSEC_SSFS_DATAPATH and $RSEC_SSFS_KEYPATH, usually in :
$HOME/.hdb/$HOSTNAME/
/hana/shared/<SID>/global/hdb/security/ssfs/
/hana/shared/<SID>/global/security/rsecssfs/
/usr/sap/<SID>/SYS/global/security/rsecssfs/ (for ABAP system)

Again, the algorithm is based on 3DES with default key hardcoded in the kernel or with the custom key from .key file.

And, yes, we could decrypt it too :

 

dev-target.png[x_custom_headline type=”none” level=”h4″ looks_like=”h4″]Attack scenario using SAP Secure Storage[/x_custom_headline]

In this scenario, an attacker have only a network access to a SAP Netweaver dual stack ABAP & JAVA, like SAP Solution Manager, SAP PI or SAP XI system.

Target’s IP : 192.168.169.172 in our example.

We will demonstrate, that this attacker could use SAP Secure Storage to find credentials, elevate privileges and eventually compromise another SAP System behind the first target.

After scanning the open ports, attacker found that the P4 port 50004 is reachable.

This SAP P4 service is vulnerable to dangerous issues, like information leakage or arbitrary file download. So attacker retrieves the SID, SAP version, etc, from the target.

Then attacker, always through P4 service, can download the JAVA Secure Store files.

Decrypt it, and re-use credential to login back on SAP AS JAVA.

At this point, this is “game over” for the JAVA part of this system. So, J2EE_ADMIN is an administrator user for AS JAVA part. Exists in AS ABAP side, with same password, but as a low privileges user… But it is able to modify user profiles as well…

By adding high privilege ABAP role to J2EE_ADMIN, we now have enough rights to compromise the AS ABAP side too.

Our user could execute OS command, and by this way is able to launch SQL query, and retrieve RSECTAB content, bypassing client restriction.

Attacker learns that the first target is connected to “ANOTHER_SAP_SYSTEM” through RFC, and he/she could get all required information to attack this another_sap_system : IP, System Number, Login…

… and the password

By this way, attacker has compromised :
AS JAVA : 192.168.169.172, port 50000, user J2EE_ADMIN, password QSDjkl123
AS ABAP : 192.168.169.172, SN 00, Client 001, user J2EE_ADMIN, password QSDjkl123
Another SAP : 192.168.169.188, SN 02, Client 456, user RFC_ADMIN, password Hyp3rHyp3r!!
dev-risk-and-security.png

[x_custom_headline type=”none” level=”h4″ looks_like=”h4″]Reference and remediation[/x_custom_headline]

  • References :

All credits to this research go to Dimitry Chastuhin and Vladimir Egorov from ERPScan, who published three good articles on this topic : ABAP, JAVA and HANA
The SAP official help about Secure Storage could be find here : SAP Official help

  • Remediation :

_ Check access to SAP Secure Storage files. Be sure to store them in restricted area.

_ Change the default encryption key (2210637 for HANA, transaction SECSTORE for ABAP, Configtool for JAVA)

_ Clean up the Secure Storage ! Yes sometimes after a System Copy activity, the Secure Storage is not cleaned up, and the refreshed system (QAS, sandbox, …) could store valid production credentials !

_ Perform regularly assessment audit to avoid vulnerabilities or configuration issues allowing attackers accessing to SAP Secure Storage files or tables.

  • SAP Notes :

2210637 – Change the encryption key of hdbuserstore
1894435 – Kernel for the Secure Storage Key Management
1764043 – Support for secure storage in BR*Tools
1622837 – Secure connection of AS ABAP to Oracle via SSFS
2022966 – Increase robustness of secure storage (file system and database) against file system issues
1532825 – Deleting SECSTORE entries during system export/system copy
1639578 – SSFS as password store for primary database connect
1902258 – Secure Storage in the Database Key File Tool
1922423 – SecStoreDB: Drop of System Dependency (Key Generator inside)
1902611 – Potential information disclosure relating to BC-SEC
2183624 – Potential information leakage using default SSFS master key in HANA

 

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.