SAP rétrocompatible et usurpation d’identité !

CERT-DVT Sécurité SAP

English version
dev-light.png

Introduction

Que ce soit sur des vieux SAP R/3 ou des SAP Netweaver récentq, les utilisateurs SAP et leurs mots de passe sont stockés, chiffrés, directement dans la base de données. Heureusement, les algorithmes de hashage ont évolué depuis les années 90 🙂
Cependant, il est possible d’activer tous ces vieux mécanisme, par une simple mauvaise configuration du paramètre SAP : login/password_downwards_compatbility.
Cela pourrait ouvrir des failles dangereuses, comme le cassage rapide des mots de passe, le contournement des politiques de sécurité des mots de passe ou encore l’usurpation d’identité d’un utilisateur SAP.
Dans cet article, j’expliquerai comment les mots de passe SAP sont stockés, puis ce que signifie le paramètre « Password downwards compatibility » et enfin je montrerai quelques problèmes liés à cette configuration.

dev-logistic.png

Les types de hash dans SAP

Il existe différents types de mécanismes de hachage possibles dans un système SAP.
Appelés code version (CODVN) comme dans la table ci-dessous :

Le CODVN actuellement utilisé par défaut est le H : basé sur iSSHA-1, jusqu’à 40 caractères UTF-8, avec un salt aléatoire, et d’une longueur configurable tout comme le nombre d’itération. Se référencer à la note OSS 991968 pour plus d’information sur les deniers algorithmes supportés par le code-H.
Le code-B est le pire possible. Date des années 90, basé sur MD5, avec 8 caractères ASCII tout en majuscule.
Il existe aussi des CODVN particuliers : I et G. Ils permettent d’utiliser plus d’un codvn à la fois. Par exemple, si CODVN est positionné à « I », cela veut dire que les mots de passe utilisateurs seront chiffré en code H, code F et code B.

dev-logistic.png

Stockage des hashs

Les mots de passe utilisateurs sont stockés à plusieurs endroits dans la base de données :

  • USR02

La table, USR02, est la “Master User Table”, c’est la table qui est mise à jour lorsque vous modifiez une utilisateur SAP via la SU01 par exemple. Cette table contient beaucoup d’informations intéressantes, comme :

  • USH02

La table USH02 est la “User changed document”, c’est la table qui contient l’historique des changements effectués sur les utilisateurs. Elle contient une partie des informations de la USR02. Les mots de passe récupérés depuis cette table seront non valides, mais des fois un pattern de mot de passe pour un utilisateur peut-être mise en avant.

  • USRPWDHISTORY

La table USRPWDHISTORY est la table des “Password history information”, elle contient les anciens mots de passe des utilisateurs qui sont utilisés et comparés lorsqu’un utilisateur change son mot de passe. L’historique est paramétrable via login/password_history_size.

dev-logistic.png

La rétrocompatibilité des mots de passe

Quelques fois, après une installation ou un upgrade d’un système SAP, celui-ci doit pouvoir continuer à travailler avec d’autres systèmes qui ne supportent pas les nouveaux types de hash (des SAP plus vieux, ou bien un composant externe, etc).

Activer la rétrocompatibilité des mots de passe dans SAP signifie quelques chose comme çà :

Lorsque la rétrocompatibilité est active, le système essaye d’évaluer un password avec son hash code-H, puis code-F et enfin code-B.

C’est le paramètre login/password_downwards_compatibility qui gère cette rétrocompatibilité.
Ci-dessous un résumé des valeurs possibles :

Valeur | Description
0 | Rétrocompatibilité impossible, aucun hash n’est généré
1 | Rétrocompatibilité impossible, hash sont générés
2 | Rétrocompatibilité impossible, hash sont générés et une entrée dans la syslog est créée lors d’une tentative.
3 | Rétrocompatibilité possible, hash sont générés et une entrée dans la syslog est créée lors d’une tentative.
4 | Rétrocompatibilité possible, hash sont générés et aucune entrée n’est créée dans la syslog.
5 | Utilisation du code B exclusivement. (Comme au siècle dernier !)

dev-target.png

Problème 1 : Rend obsolète la politique de mot de passe

Le premier problème à propos de cette configuration de paramètre trop haute (> 3), c’est de rentre la politique de mot de passe inutile.
En effet, SAP permet aux administrateurs de créer une politique de mot de passe très fine, à l’aide d’un ensemble de paramètres comme login/min_password_*, login/password_history_size, login/password_charset, etc.
Mais imaginez le scénario suivant :
_ Une bonne politique de mots passe est mise en œuvre sur le système SAP : 10 caractères minimum, 2 chiffres, 2 caractères spécia, etc.
_ Le paramètre login/password_downwards_compatibility est positionné à 3 (car l’équipe précédente l’avait changé, et que l’équipe actuelle ne sait plus trop pourquoi, donc…)
Maintenant, un utilisateur change son mot de passe en : PaSswoRd123!:)kilélongmonmotdepasse^^

Le système hash ce mot de passe en utilisant le code-H, ce qui donne « 7h5Lx8pLzhen2WsLeOcIiuuOn/G34xZfqbqtn7J7D58= » et l’enregistre dans la table USR02 dans la colonne PWDSALTEDHASH.

Seulement voilà, à cause de la rétrocompatibilité, le système essaye aussi de le hasher en utilisant le code-B… mais le code-B est limité à 8 caractères, tout en majuscule vous vous souvenez ?

Donc, le système tronque les 8 premiers caractères, met tout en majuscule, puis chiffre avec le code-B :

PaSswoRd123!:)kilélongmonmotdepasse^^ --> PaSsworRd --> PASSWORD --> code-B --> 8268EEECE2DC6EE0

Finalement, le système enregistre ce hash dans la table USR02 dans la colonne BCODE.

Le deuxième password « PASSWORD » est évidement plus facile à casser que le premier et avoir une politique de complexité des mots de passe ne sert pas à grand chose…

Aussi, toujours à cause de la rétrocompatibilité, si l’utilisateur essaye de se logger à SAP avec YVAN / PASSWORD, cela fonctionne…

dev-target.png

Problème 2 : Usurpation d’identité

Si vous me suivez encore, vous aurez compris qu’un utilisateur unique possède “plusieurs” mots de passe. La plupart du temps ces utilisateurs ne le savent pas.

Ces différents mots de passe sont stockés dans la base de données, comme n’importe quelle autre donnée.

Il est possible d’accéder à ces données et de les modifier…

Il est donc possible de modifier le contenu de la colonne BCODE, de n’importe quel utilisateur, par ce que l’on veut.

update sapsr3.usr02 set BCODE=’2D22DE35F460F464′ where bname=’YVAN’ and mandt=’010′ ;

Où 2D22DE35F460F464 est code-B(‘FOOBAR’).

A partir de là nous pouvons nous logger à SAP, avec le login YVAN/FOOBAR, et utiliser cette utilisateur dans son environnement de travail, avec cses menus personnels, reports, options, droits, etc.

Dans le même temps, le véritable utilisateur continuera à utiliser YVAN/PaSswoRd123!:)kilélongmonmotdepasse^^ sans être alerté.

Bien sûr, avoir les droits suffisants pour modifier la base donnée, signifie que nous avons déjà des droits élevés, mais ceci peut-être utilisé comme une backdoor ou bien comme activité de post-exploitation.

dev-risk-and-security.png

Recommendations

NE MODIFIER PAS le paramètre login/password_downwards_compatibility sans avoir effectué une étude préalable sur les impacts potentiel. En effet, sa modification pourrait engendrer un disfonctionnement des communications entre votre SAP d’autres systèmes, et donc conduire à des problèmes business sérieux.

  • Avant tout, essayer de comprendre quand et pour quoi ce paramètre à été changé (Wow, quel conseil … )
  • Vérifier les entrées dans la syslog correspondant au pattern « Password trunctated » :Cela signifie que quelqu’un ou quelque chose essaye de se connecter avec un mot de passe ne correspond pas au code-H mais au code-B. Ceci pourrait aider à trouver les utilisateurs ou les composants impliqués.
  • Restreindre l’accès à la base de données.
  • Restreindre l’accès aux tables critiques SAP, comme la USR02, USH02 et USRPWDHISTORY, à protéger contre les transactions SE16, SE17, SE11, etc.
  • Utiliser des mots de passe différents dans vos différents systèmes SAP et mandants.
  • Si possible, désactiver la rétrocompatibilité des mots de passe.

Vous voulez le tester vous-même sur votre système ?

Essayez simplement de vous logger avec les 8 premiers caractères de votre mot de passe en majuscule… Ca passe ? Oups :]

Pour plus d’information sur notre offre Sécurité SAP Security :
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.