La sécurité du ‘SAP Secure Storage’

CERT-DVT Sécurité SAP

English version
dev-light.png

Introduction

  • Qu’est-ce que le SAP Secure Storage ?
    Le SAP Secure Storage est un composant de SAP permettant de stocker des données sensibles que l’application SAP pourra récupérer pour effectuer certaines opérations, comme une connexion distante à un autre SAP, ou bien une connexion à la base de données, etc.
  • Quel type d’information y est stocké ?
    Classiquement, beaucoup de logins/passwords potentiellement à fort privilèges ! Parmi les plus intéressants on retrouve : des services SAP, des connexions distantes, connexions à la base de donnée ou encore au système d’exploitation.
  • Où sont ces données ?
    Cela dépend de la version du SAP et de sa configuration. Elles peuvent être stockées dans la base donnée pour les AS ABAP, ou bien ce sont des fichiers au niveau système d’exploitation pour les AS JAVA ou HANA, et aussi pour les AS ABAP récents.
  • Quelle est la menace ?
    Si un attaquant peut lire le SAP Secure Storage, cela peut conduire à une élévation des privilèges ou encore à la possibilitée de compromettre d’autres systèmes SAP connectés.

dev-logistic.png

SAP Netweaver ABAP – table RSECTAB

Sur les SAP Netweaver ABAP, ces données sensibles sont stockées directement dans une table : RSECTAB. Ces données sont mandant dépendant, et il y-a deux important champs dans cette table RSECTAB :
IDENT – NOT NULL VARCHAR2(189), identification de l’object concerné, par exemple une destination RFC
DATA – RAW(184), les données chiffrées.

Le mécanisme de chiffrement est basé sur du 3DES, et il pourrait être résumé ainsi :

1/ SAP calcule la clé de chiffrement en utilisant du 3DES sur deux clés statiques écrits en dur dans le kernel SAP

La clé de chiffrement.

2/ Puis il déchiffre le contenu du champ DATA de la table avec cette clé, et récupère quelques informations comme le SID et le numéro d’installation du système. Mais la première partie des données reste chiffré après cette première passe.

3/ Utilisant le SID, le numéro d’installation et quelques opérations xor, SAP génère une deuxième clé dérivée de la première.

Une partie de la génération de la deuxième clé.

4/ Finalement, il utilise cette deuxième clé avec, encore une fois, du 3DES pour récupérer le début des données et le mot de passe.

Les administrateurs SAP on la possibilité de changer la clé par défaut… mais cette clé personnalisé sera stockée au niveau système de fichier du système SAP, donc récupérable. Le chemin de cette clé est défini via le paramètre SAP rsec/securestorage/keyfile.

Donc, il est possible de déchiffrer le contenu de cette table :

dev-logistic.png

SAP Netweaver JAVA – fichier SecStore.properties

Sur les SAP Netweaver JAVA le SAP Secure storage est géré par deux fichiers :
Le SecStore.properties, où les données chiffrées sont stockées au format : <paramètre>=<donnée chiffré>

Le SecStore.key, où la clé, chiffrée, est stockée après la version :


Par défaut ces fichiers sont dans le répertoire : /usr/sap/<SID>/SYS/global/security/data/
Le chiffrement de la clé est basé sur un simple xor avec la clé écrite en dur dans le kernel SAP JAVA.

La méthode ‘xor’, avec la clé en dur.

Cette clé est utilisée pour déchiffrer le contenu fichier SecStore.properties, en utilisant le cipher ‘PbeWithSHAAnd3_KeyTripleDES_CBC’ :


Il est donc possible de déchiffrer les données sensibles du JAVA SAP Secure Storage :

dev-logistic.png

SAP HANA & ABAP – fichier SSFS_SID.DAT

SAP HANA, mais aussi les AS ABAP à partir de la version 7.40, utilise les Secure Storage in File System (SSFS). Basé sur le fichier SSFS_SID.DAT, avec en plus le fichier SSFS_SID.key si une clé personnalisée à été configurée.

Ces fichiers se retrouvent via les variables d’environment $RSEC_SSFS_DATAPATH et $RSEC_SSFS_KEYPATH, habituellement dans :
$HOME/.hdb/$HOSTNAME/
/hana/shared/<SID>/global/hdb/security/ssfs/
/hana/shared/<SID>/global/security/rsecssfs/
/usr/sap/<SID>/SYS/global/security/rsecssfs/ (pour les systèmes ABAP)

Encore une fois, l’algorithme utilisé est du 3DES, avec une clé écrite en dur ou avec la clé personnalisée dans le fichier .key.

Et, oui, il est possible de le déchiffrer :

dev-target.png

Scénario d’attaque utilisant le SAP Secure Storage

Dans ce scenario, un attaquant a seulement un accès réseau à un SAP Netweaver dual stack ABAP & JAVA, comme un SAP Solution Manager, un PI ou un système XI.

IP cible : 192.168.169.172 dans notre exemple.

Nous allons montrer, que cet attaquant peut utiliser les SAP Secure Storage pour trouver des identifiants, faire de l’élévation de privilège mais aussi attaquer d’autres systèmes SAP connecté à la première cible.

Après un scan des ports accessibles, l’attaquant trouve que le service P4, port 5<SN>04 est ouvert.

Le service SAP P4 est vulnérable à des fuites d’information, et aussi à la possibilité de télécharger n’importe quel fichier du système distant. L’attaquant l’utilise donc pour récupérer le SID du système, la version de SAP, etc.

Ensuite, toujours via le service P4, l’attaquant récupère les fichiers du JAVA Secure Storage.

Une fois déchiffrés, l’attaquant ré-utilise les identifiants trouvés pour se connecter en tant qu’administrateur sur le SAP AS JAVA.

A ce moment là, c’est « game over » pour la partie JAVA du système SAP cible. Mais J2EE_ADMIN est l’utilisateur administrateur de la stack JAVA, il existe sur l’AS ABAP, mais avec très peu de droits… Seulement, cet utilisateur a le droit de modifier les profils utilisateurs…

Après avoir ajouter un rôle administrateur de la partie ABAP à J2EE_ADMIN, nous avons maintenant assez de droit pour compromettre aussi la partie AS ABAP du système SAP.

Cet utilisateur peut exécuter des commandes OS, lui permettant d’effectuer des requêtes SQL, et donc de récupérer le contenu de la table RSECTAB, contournant les restrictions liées au mandant.

L’attaquant apprend que ce premier système est connecté à un autre système, via une destination RFC du nom de « ANOTHER_SAP_SYSTEM ». Aussi il est en mesure de récupérer l’ensemble des informations nécessaires pour attaquer ce système : IP, System Number, Login…

… ainsi que le mot de passe.

De cette façon l’attaquant a pu compromettre :
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

Référence et correction

  • Réferences :

Cette article repose sur le résultat des recherches de Dimitry Chastuhin et Vladimir Egorov de chez ERPScan, qui ont publié trois très bons articles sur le sujet : ABAP, JAVA and HANA
Le site officiel de SAP sur les SAP Secure Storage : SAP Official help

  • Ci-après quelques recommandations pour mitiger le risque :

_ Vérifiez les droits d’accès aux fichiers du SAP Secure Storage. Soyez sûr qu’ils ne soient pas accessibles par tous.

_ Changez les clés de chiffrement par défaut : SAP note 2210637 pour HANA, transaction SECSTORE pour ABAP et via Configtool pour JAVA

_ Nettoyez vos SAP Secure Storage ! Oui, parfois après une copie de système, le Secure Storage n’est pas nettoyé et le système rafraichi (QAS, bac à sable, …) peut contenir des identifiants de production valides !

_ Effectuez régulièrement des audits de sécurité SAP pour éviter toutes vulnérabilitées ou configurations permettant à un attaquant d’accéder aux fichiers ou tables du SAP Secure Storage.

  • 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

N’hésitez pas à consulter notre offre SAP Sécurité :
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.