SAP avec Oracle – Problème d’authentification

CERT-DVT Sécurité SAP

English version

dev-light.png

Introduction

 

Dans les versions antérieures à SAP Netweaver 7.40, pour des raisons de communications, la base de données Oracle est installée avec le paramètre remote_os_authent activé. Cette configuration créée une faille de sécurité importante sur le système SAP, car elle permet de se connecter à la base de données, où sont stockées toutes les données SAP, à distance et anonymement.

Même si ce paramètre est déprécié par Oracle en 2011, et n’est plus supporté à partir de Oracle 12c, il existe encore beaucoup de systèmes SAP possédant cette vulnérabilité.

L’attaque peut se séparer en deux étapes : la connexion à distance sans authentification, puis une élévation de privilège pour passer de l’utilisateur OPS$ à l’utilisateur SAPSR3 (ou SAP<SID> selon les version).

 

dev-logistic.png

Le mécanisme OSP$

 

Afin de comprendre le problème, nous allons décrire en quoi consiste ce mécanisme.

Pour que l’utilisateur SAP au niveau système d’exploitation, le <sid>adm, puisse se connecter à la base de donnée sans qu’une authentification ne lui soit demandée à chaque fois, SAP utilise un mécanisme appelé OPS$ :

  • En premier SAP se connecte à Oracle en utilisant un utilisateur appeler OPS$<sid>adm
  • Puis il se connecte à nouveau avec les informations de connexion de l’utilisateur Oracle SAPSR3 récupérées au préalable.

La seule table appartenant à l’utilisateur Oracle OPS$<sid>adm est une table appelée SAPUSER avec deux colonnes : USERID et PASSWD. Cette table contient le mot de passe chiffré de l’utilisateur Oracle SAPSR3, utilisateur possédant un accès total à l’ensemble des tables SAP.

Voici un exemple de ce mécanisme :

Voyons comment l’utilitaire R3trans est capable de vérifier si la communication entre SAP et la base de données est bien fonctionnelle.

L’outil R3trans :

saptest:bobadm 56> R3trans
This is R3trans version 6.19 (release 720 - 24.08.10 - 14:38:42).
unicode enabled version
usage: R3trans [<options>] <control_file>
The control_file describes what R3trans has to do.
The following options are possible:
-c f1 f2 : Copy file f1 to f2 with character set conversion.
-d : DB connect. Test if SAP database is available.
-i file : Import from file without using a control file.
-l file : List the contents of file to the log file.
-m file : List the contents of file to allow tp to create a cofile.
-t : Test. All database changes are rolled back.
-t4 : Trace level 4. Switch on developer trace.
-u <int> : Unconditional modes. See below.
-v : Verbose. Write more details to the log file.
-w file : Log file. The default log file is 'trans.log'.
-x : DB connect without access on any SAP table.
R3trans finished (0012).

 

Un administrateur SAP lance la commande : R3trans –d

  • Le binaire R3trans essaye de se connecter à la base de donnée avec le compte OPS$
4 ETW000 [dev trc ,00000] charset='', chset='UTF8', UNI_ASC=FALSE/FALSE 12 0.009255
4 ETW000 [dev trc ,00000] Logon as OPS$-user to get SAPSR3's password 14 0.009269
4 ETW000 [dev trc ,00000] Connecting as /@BOB on connection 0 (nls_hdl 0) ... (dbsl 720 140910)
  • R3trans lis le contenu de la table SAPUSER et récupère les informations de connexion du schéma SAP
4 ETW000 [dev trc ,00000] -->oci_prepare_stmt(con=0, len=59, stp=2ff0818); AI=,0,, 115 0.061000
4 ETW000 [dev trc ,00000] SELECT USERID,PASSWD FROM SAPUSER WHERE USERID IN (:A0,:A1)
4 ETW000 21 0.061021
  • Puis il utilise ces informations pour se connecter à nouveau
4 ETW000 [dev trc ,00000] <--oci_execute_stmt(rc=0, iters-errors = 1-0) [dur. 0,001s] 42 0.061780
4 ETW000 [dev trc ,00000] Got SAPSR3's password from OPS$-user 216 0.061996
4 ETW000 [dev trc ,00000] Disconnecting from connection 0 ... 65 0.062061
4 ETW000 [dev trc ,00000] Rolling back transaction ... 18 0.062079
4 ETW000 [dev trc ,00000] Closing user session (con=0, svc=2fdb6b8, usr=300e0e0) 190 0.062269
4 ETW000 [dev trc ,00000] Now I'm disconnected from ORACLE 460 0.062729
4 ETW000 [dev trc ,00000] Connect as 'SAPSR3' with found password from table SAPUSER 21 0.062750
4 ETW000 [dev trc ,00000] Connecting as SAPSR3/<pwd>@BOB on connection 0 (nls_hdl 0) ... (dbsl 720 140910)
4 ETW000 17 0.062767
  • Puis l’outil effectue quelques vérifications, mais la suite ne nous intéresse plus.

Si un attaquant arrive à reproduire ce processus, alors il aura un accès total aux données SAP, et donc sur le système SAP.

dev-network.png

Connexion à distance sans authentification

 

Pour se connecter à une base de données Oracle paramétrée comme ci-dessus, il suffit de créer un utilisateur <sid>adm en local sur la machine attaquante, puis d’utiliser le client Oracle (sqlplus) pour établir une connexion. Oracle faisant “confiance” au système d’exploitation pour l’authentification, cela fonctionne.


L’utilisateur ne peut rien faire sur les tables SAP :


Cependant il a accès à la table “SAPUSER”, contenant le hash du mot de passe de SAPSR3 :

dev-calculator.png

Etude du chiffrement

 

Ce hash, généré par SAP, n’a pas l’air d’être aussi aléatoire que cela :

plain : < mot de passe fourni >
hash : < contenu de la table sapuser >
hexa : < base64 -d | xxd –p >
plain : A
hash : V01/0020ZctvSB67Wv2dyQ==
hexa : 574d7fd34db465cb6f481ebb5afd9dc9

plain : B
hash : V01/0020ZctvSB67Wv2dyg==
hexa : 574d7fd34db465cb6f481ebb5afd9dca

plain : AA
hash : V01/0020ZctvSB67Wv2dyfy+
hexa : 574d7fd34db465cb6f481ebb5afd9dc9fcbe

plain : BB
hash : V01/0020ZctvSB67Wv2dyvy9
hexa : 574d7fd34db465cb6f481ebb5afd9dcafcbd

plain : AAA
hash : V01/0028ZctvSB67Wv2dyfy+7hc=
hexa : 574d7fd34dbc65cb6f481ebb5afd9dc9fcbeee17

plain : AAAA
hash : V01/0030ZctvSB67Wv2oVYRzDVDk8A==
hexa : 574d7fd34df465cb6f481ebb5afda85584730d50e4f0

plain : AAAAA
hash : V01/0030ZctvSB67Wv2oVYRzDVDk8FZh
hexa : 574d7fd34df465cb6f481ebb5afda85584730d50e4f05661

Après quelques recherches il est facile de comprendre pourquoi ce mécanisme n’est plus supporté.

En effet le chiffrement est réversible, bien que basé sur du 3DES, le salt et la clé sont statiques et les mêmes pour tous les systèmes SAP :

Salt en dur.


Le début de la clé.


 

Le claire.


dev-target.png

Elévation de privilège vers SAPSR3

 

Il suffit donc de casser le chiffrement récupéré depuis la table SAPUSER et de se connecter avec l’utilisateur SAPSR3.

Maintenant il est possible de lire, écrire, modifier et effacer l’ensemble des données du système SAP hébergé sur cette base de données.

Par exemple, il est possible de créer un utilisateur SAP avec des droits d’administration (SAP_ALL), puis d’utiliser le SAPGui pour se connecter à SAP avec cet utilisateur.

dev-risk-and-security.png

Correction & Conclusion

 

En réponse à ce problème, SAP fourni un nouveau mécanisme, le ‘SAP Secure Storage’ (SSFS), disponible depuis la version 7.20 du kernel. Aussi, les versions à partir de SAP Netweaver 7.40, par défaut, utilisent ces SSFS et ne sont plus vulnérables.

Ci-dessous quelques notes sur le sujet :

1622837 - Secure connection of AS ABAP to Oracle via SSFS
1860519 - SAP fails to connect to the database
1905775 - SSFS connection is not working
1639578 - SSFS as password storage for primary database connect
1764716 - Memory leak when using the secure storage in the file system
1764043 - Support for secure storage in BR*Tools
1638280 - Data records in table DBCON

La mise en place de ce nouveau mécanisme n’impacte que très peu le business. Ce n’est pas une montée de version, il n’y a pas de modification fonctionnelle à apporter. De plus l’opération est relativement rapide et le risque limité.

Si vous utilisez encore les OPS$, nous vous conseillons de migrer vers le ‘SAP Secure Storage’ au plus vite.

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.