Déchiffrement instantané des mots de passe PSCipher sous Oracle PeopleSoft

Déchiffrement instantané des mots de passe PSCipher sous Oracle PeopleSoft

Le monde des ERP

Dans cet article, nous allons travailler sur un ERP bien connu des entreprises développé par ORACLE nommé PeopleSoft. La sécurité d’un ERP est un élément important dans une entreprise puisque ce dernier  regroupe généralement plusieurs fonctions très sensibles de la société :

  • Gestion RH
  • Gestion recrutement
  • Gestion des stocks
  • ..

De plus en plus de sociétés, nous demande de réaliser des tests d’intrusion sur ce type d’application. SAP et PeopleSoft se partagent la majorité du marché des ERP comme le montre le diagramme suivant datant de Septembre 2010 :

 

SAP a déjà fait l’objet de nombreuses recherches en sécurité et son moteur J2EE a été sérieusement mis à mal dernièrement lors de la dernière présentation d’Alexander Polyakov à la dernière Black Hat USA.

En revanche, les vulnérabilités sur Peoplesoft, bien que nombreuses restent cependant assez floues et très mal documentées sur Internet d’où notre intérêt tout particulier de publier quelques articles sur cette solution.

Il est important de savoir qu’avant la publication de ce papier ORACLE a été contacté plusieurs fois et leur accord nous a été donné pour publier ce document. Vous verrez pourquoi par la suite 😉

Les forces en présence

PeopleSoft possède une architecture complexe bien qu’assez standard dans le monde applicatif. Le schéma ci-dessous résume bien les forces en présence :

On retrouve une architecture 3-tiers classique composée d’un client, d’un serveur d’application contenant plusieurs éléments et d’une base de données ORACLE

Le serveur d’application est subdivisé en 2 parties :

  • Un serveur WEB permettant d’utiliser des servlet. Ce serveur repose la plupart du temps sur la technologie BEA Weblogic.

Les servlet permettent dans un cas de présenter l’application Peoplesoft au client (Portal Servlet), ensuite d’autres servlet viennent se greffer sur le serveur d’application afin d’interagir avec d’autres applications tierces.

Les servlet discutent par l’intermédiaire du protocole JOLT développé par BEA à un service TUXEDO. JOLT est une API Java permettant de s’interfacer simplement avec TUXEDO.

  • TUXEDO va ensuite se charger de communiquer avec les différents éléments externes de PeopleSoft à savoir la BDD, le serveur d’authentification ou encore des applications tierces.

Par exemple l’interaction avec des applications tierces peut se faire par l’intermédiaire de l’Integration Broker. Ce dernier permet d’envoyer des messages People Soft au format XML à d’autres applications (par exemple la gestion de la paie)

 

Sécurité des flux PeopleSoft vers les applications tierces

Nous avons précédemment vu que TUXEDO est le moteur permettant à PeopleSoft d’interagir avec les applications tierces.

C’est le lien entre les données brutes reçues ou envoyées aux applications et le servlet de présentation de PeopleSoft.

Il est donc clair que TUXEDO possède toute les cartes en main pour visualiser les données PeopleSoft mais également pour accéder aux applications tierces 😉

En analysant de plus près, on peut voir que les messages envoyés par TUXEDO à la base de données (Format Oracle ou Net*8) et aux applications tierces (XML) ne sont pas chiffrés.

La seule sécurité mise en place est définie par un couple login/mot de passe.

Ces identifiants sont pour la plupart stockés dans un fichier nommé psappsrv.cfg se trouvant fréquemment à la racine du serveur Weblogic

Ce fichier est utilisé, pour pouvoir administrer les deux composants : TUXEDO et Processus Peoplesoft.

La capture ci-dessous montre un exemple de ce fichier contenant les 2 comptes permettant de se connecter à la base de données PSADMIN et People. Les mots de passe sont bien entendu chiffrés

Pour la partie Integration Broker, les identifiants sont stockés quant à eux dans le fichier integrationGateway.properties se trouvant dans le répertoire PSIGW/WEB-INF du serveur Weblogic

Le login utilisé ici est « broker », le mot de passe est quant à lui chiffré. Nous notons par ailleurs un mystérieux {V1.1} devant ce mot de passe.

L’objectif de se papier est de prouver que le chiffrement de ces comptes est extrêmement simple a casser.

Il est important de noter que ces comptes possèdent pour la plupart des droits extrêmement importants sur l’application PeopleSoft :

  1. PSADMIN a des droits complets sur la base de données PeopleSoft et sur l’application
  2. People possède des droits de lecture sur certaines tables de la base de données PeopleSoft comme par exemple PSOPRDEFN qui contient les mots de passe utilisateurs
  3. Broker possède des droits importants sur les applications tierces et l’application PeopleSoft (il est souvent compte administrateur sur l’application en entreprise)

 

It’s not a vuln, it’s a feature !

Maintenant que l’on a bien compris le fonctionnement des différentes couches PeopleSoft et les comptes associés à l’envoi de messages aux applications tierces, nous allons nous amuser à déchiffrer ces mots de passe.

Vous allez me dire, dans un premier temps, comment on obtient les fichiers psappsrv.cfg et integrationGateway.properties sans accès à l’application ?

  • Depuis le NET, je vous laisse faire un peu de Google Hack 🙂

Depuis la découverte et surtout depuis que j’ai prévenu Oracle, le nombre d’occurrence sur le NET de ces fichiers à diminué

 

  • En interne, je vous laisse aller voir du côté du serveur Weblogic ou du serveur FTP, ces fichiers sont souvent laissés en pâture par les admin sys !

Une fois en possession de ces fichiers, il suffit de faire quelques recherches pour comprendre le fonctionnement du chiffrement de mot de passe made in PeopleSoft

Prenons l’exemple du compte broker se trouvant dans le fichier integrationGateway.properties

Après recherche et visualisation de la page suivante :

http://peoplesoft.wikidot.com/peopletools-encryption

On peut voir

  • Que ce mot de passe est chiffré via l’application PSCipher fournie par défaut dans la suite logicielle de PeopleSoft nommée PeopleTools

 

  • Que la chaine de caractère {V1.1}, en préfixe du mot de passe chiffré, montre que la clé de chiffrement utilisée est celle par défaut.

 

Clé qui est la même pour toute installation PeopleSoft (en gros il faut lancer la commande pscipher.sh –buildkey après installation de la solution et avant toute utilisation de la solution, sinon la clé est difficilement modifiable sans coupure de production)

 

  • Que cette clé privée se trouve dans le fichier nommé psvault

 

  • Que cette clé privée peut-être lue par tout le monde par défaut

Les fichiers pscipher.sh et psvault (clé par défaut) sont accessibles directement en téléchargeant le paquet PeopleTools depuis le site ORACLE (suffit de créer un compte utilisateur 🙂 )

Un petit cat sur le fichier pscipher.sh permet de voir que ce dernier fait appel à une classe JAVA

Un cat sur le fichier pvault permet de visualiser la magnifique clé par défaut (je le rappelle c’est la même pour toute installation PeopleSoft) :

Maintenant que nous avons les bonnes informations, il suffit de décompiler la classe PSCipher.class (vu plus haut) avec l’outil CAVAJ, celle-ci est également accessible depuis le paquet PeopleTools.

Après visualisation, on remarque qu’Oracle a bien fait les choses puisqu’une magnifique méthode de déchiffrement de mot de passe est incluse dans le fichier .class. De plus, les clés de génération de la masterkey sont configurées en dur dans le fichier

Il suffit maintenant de modifier la méthode main() de cette classe et d’appeler la méthode decodePassword au lieu d’encodePassword pour pouvoir déchiffrer les mots de passe instantanément

On compile :

Et on déchiffre les pass 🙂

Conclusion

On peut voir que le chiffrement des mots de passe PeopleSoft est facilement réversible.

La faute n’est pas à remettre totalement sur ORACLE même si ces derniers fournissent tous les outils nécessaires au déchiffrement des données publiquement (via l’outil PeopleTools).  Après contact avec eux, c’est une feature largement documentée. Bon je n’ai rien trouvé à ce sujet sur le NET …

Reste néanmoins l’erreur humaine dans laquelle les admin systèmes laissent trainer par un moyen ou un autre des fichiers de configuration sous prétexte que dans ces derniers les mots de passes sont « chiffrés »

Il est également important de savoir que cette méthode ne permet pas de déchiffrer les mots de passes utilisateurs contenus dans la base PSOPRDEFN

 

Une autre méthode existe (non publique également J mais qui fera l’objet d’un paper en 2012) qui consiste à reverser l’outil PeopleTools DataMover en sa version UNIX (nommé psdtmtx). En effet, ce dernier inclut tous les outils permettant de déchiffrer et chiffrer les mots de passe utilisant la clé ACCESSID

 

Références (merci à eux !)

http://whatiserp.net/erp-comparison/sap-vs-oracle/

http://erpscan.com/wp-content/uploads/2011/08/A-crushing-blow-at-the-heart-SAP-J2EE-engine_whitepaper.pdf

http://www.learnpeoplesoft.info/viewpage.php?page_id=6

http://peoplesoft.wikidot.com/peopletools-encryption