CVE-2022-21445-for-12.2.1.3.0-Weblogic

Exploit d'exécution de code à distance avant authentification pour Oracle WebLogic ADF Faces (CVE-2022-21445, CVSS 9.8). Inclut une configuration détaillée de l'environnement, la génération de charges utiles et des instructions de débogage à distance pour les tests d'intrusion.

1. Préparer un dossier pour installer la base de données, créer un chemin comme ci-dessous et décompresser le fichier zip de la base de données téléchargée dans C:\app\oracle\product\19c\db_home1.

2. Exécuter le fichier setup.application avec les droits d'administrateur.

3. Suivre chaque étape comme indiqué dans le Guide d'installation de la base de données.

4. Attention importante : À l'étape 8/17, pensez à cocher Create as Container database pour créer une base de données pluggable nécessaire lors de l'installation de Fusion Middleware.

   À l'étape 9/17, choisir le jeu de caractères Unicode (AL32UTF8).

5. Une fois l'installation terminée, vérifier dans les services Windows que les 4 services principaux (comme sur l'image ci-dessous) sont à l'état RUNNING.

   

6. Créer un nouveau compte oracle database selon les étapes suivantes :

   • Terminal Administrator -> sqlplus / as sysdba
   • Créer l'utilisateur système : alter user system identified by system_password account unlock;
   • Vérifier l'existence de l'utilisateur : select username from dba_users;
   • Configurer l'environnement : alter session set "_oracle_script"=true;
   • Créer un utilisateur standard hr : create user hr identified by user_password;
   • Accorder les privilèges : grant all privileges to hr;
   • Déverrouiller le compte – modifier le mot de passe : alter user hr identified by hr_pass account unlock;
   • Créer un nouveau compte système : alter user sys identified by sys_pass account unlock;

Étape 3 : Installer SQL Developer, version no-jre, lien de téléchargement : SQLDev-NoJRE

• Exécuter le fichier sqldeveloper.application avec les droits d'administrateur.

• Configurer les paramètres d'une nouvelle connexion comme sur l'image ci-dessous, en modifiant le nom d'utilisateur et le mot de passe (par exemple hr), le nom d'hôte (par défaut localhost), le port (par défaut 1521), le SID (qui est le nom global de la base de données installée à l'étape 2).

• Si lors du clic sur Test un message indique Success, la connexion est réussie ; cliquer sur Connect.

Étape 4 : Installer Fusion Middleware Infrastructure (FMW) version 12.2.1.3.0, lien de téléchargement : FMW_ver_12.2.1.3.0

• Créer le chemin pour le dossier d'installation de FMW selon le modèle C:\Oracle\Middleware\Oracle_Home.
• Suivre les étapes une à une selon le guide : Guide d'installation de FMW

Étape 5 : Installer Oracle Business Intelligence (OBIEE) version 12.2.1.4.0, lien de téléchargement : OBIEE_ver_12.2.1.4.0

• Exécuter le fichier setup_bi_platform-12.2.1.4.0_win64.exe avec les droits d'administrateur.

• Installer étape par étape selon le Guide d'installation d'OBIEE

• Remarque : Le chemin de BI doit être identique à celui utilisé pour FMW, ici Oracle/Middleware/Oracle_Home.

Étape 6 : Configurer le schéma BI à l'aide de l'utilitaire Repository Creation Utility (RCU)

• Dans le chemin C:\Oracle\Middleware\Oracle_Home\oracle_common\bin, exécuter le fichier rcu.bat avec les droits d'administrateur.

• Suivre les étapes ci-dessous dans l'ordre :

• Enfin, cliquer sur Create pour que le système crée le schéma BI.

Étape 7 : Configurer les variables d'environnement pour OBIEE

• Aller dans Panneau de configuration > Système > Paramètres système avancés > Avancé > Variables d'environnement > Nouvelle variable système.

Étape 8 : Créer le domaine BI

1. Dans le chemin C:\Oracle\Middleware\Oracle_Home\bi\bin, exécuter le fichier config.cmd avec les droits d'administrateur.

2. À l'étape 1 : Cocher les 3 composants, Essbase (serveur OLAP), Business Intelligence Enterprise Edition (BI Analytics) et Business Intelligence Publisher (BI Publisher).

3. À l'étape 3 : Créer un nouveau domaine comme sur l'image ci-dessous, !! NOTEZ LE MOT DE PASSE DU DOMAINE CAR IL SERA DIFFICILE À RÉCUPÉRER. et laisser le domaine nommé bi car c'est la valeur par défaut.

4. À l'étape 4 : Mettre à jour les informations du domaine pour la base de données.

5. À l'étape 8 : Si le processus se déroule correctement, le résultat sera comme sur l'image ci-dessous.

6. Si tout est terminé, enregistrer le fichier d'informations OBIEE pour l'étape suivante, puis se connecter aux URL suivantes :

• http://localhost:9500/console
• http://localhost:9500/em
• http://localhost:9502/xmlpserver
• http://localhost:9502/analytics

7. Erreurs possibles :

• À l'étape 4, si le système indique « Échec de la connexion », vérifier que le mot de passe du domaine est correct.

• À l'étape 8, si une erreur comme sur l'image ci-dessous apparaît, vérifier que Windows est activé et que la version correspond aux conditions décrites.

• Erreur due à l'absence de BI_HOME_PRODUCT, revoir l'Étape 7.
• Mise à jour des erreurs…

Étape 9 : Après la configuration, accéder au domaine BI créé dans le chemin $Oracle_Home\user_projects\domains\bi\servers\AdminServer\tmp_WL_user\adf.oracle.domain.webapp\i83uao.

• Copier tous les fichiers jar de cet emplacement dans un dossier séparé et les partager vers la machine attaquante (dans un environnement de laboratoire, faire ainsi ; en situation réelle d'attaque, la machine attaquante doit également avoir installé les mêmes composants que la machine cible pour obtenir le code source).

• Ajouter également la bibliothèque coherence.jar située dans $Oracle_Home\coherence\lib à ce dossier.

• Ce dossier est crucial pour la réussite de la charge utile (payload), car chaque version de FMW, BI ou environnement peut différer ; il est donc nécessaire d'utiliser les versions exactes pour éviter les risques ou les exceptions lors de la transmission de la charge utile.

Étape 10 (uniquement si un débogage à distance est nécessaire, à noter que dans un environnement réel, on ne peut pas configurer la machine victime librement, donc l'attaquant doit également configurer la machine cible sur sa propre machine pour pouvoir effectuer un débogage à distance et vérifier les erreurs) :

• Installer Mozilla, ajouter le proxy Burp sur le port 8181.

• Activer le débogage à distance sur le serveur BI.

  Accéder à localhost:9500/console.

  Dans Domain Structure -> sélectionner bi -> Environment -> Servers.

Deux serveurs s'affichent : AdminServer de Weblogic et bi_server1 de BI.

Cliquer sur Lock & Edit dans le coin gauche, cocher bi_server1 pour modifier sa configuration. Ensuite, aller dans Configuration -> Server start -> Descendre tout en bas, cliquer sur Advanced (si présent) -> Cliquer sur Arguments et saisir les paramètres de débogage :

-Xdebug -Xnoagent –Xrunjdwp:transport=dt_socket,address=5005,server=y,suspend=n

(on peut essayer avec 0.0.0.0:5005 si une erreur empêche de redémarrer bi_server1 par la suite).

Saisir le mot de passe Weblogic (défini lors de la configuration du domaine BI) -> Apply change & Restart.

Ouvrir un terminal Administrateur -> Naviguer vers $Oracle_Home\user_projects\domains\bi\bitools\bin et exécuter ./stop.cmd puis ./start.cmd pour redémarrer bi_server1. Si aucun message d'erreur n'apparaît pendant le redémarrage, le débogage est activé et écoute sur le port 5005 comme spécifié. En cas d'erreur, vérifier les paramètres de débogage (espaces superflus, adresse incorrecte).

Côté machine attaquante

Étape 1 : Télécharger IntelliJ IDEA Ultimate, l'activer avec un code trouvé sur GitHub.

Étape 2 (uniquement si l'attaque génère des erreurs comme 500 Server Error, ... dues à des exceptions dans la charge utile) :

1. Modifier la version jdk/sdk du projet pour qu'elle corresponde à celle de la machine cible (installation comme à l'Étape 1 côté machine cible).

2. Créer un projet vide pour analyser le code source et effectuer le débogage à distance.

3. Ajouter tous les fichiers jar du dossier reçu de la machine cible à ce projet.

   Project Structure -> Modules -> Cliquer sur + -> 1 JARS or Directories -> Ajouter tout le dossier jar.

4. Configurer le débogage à distance.

   Run -> Edit Configurations -> + -> Remote JVM Debug

Lancer le débogage à distance ; si la console affiche « Connected … », c'est réussi.

Étape 3 :

• Cloner le code de ce dépôt sur la machine, supprimer l'ancien fichier coherence.jar dans le dossier lib et le remplacer par celui reçu de la machine cible à l'étape précédente.

• Ensuite, ajouter le projet dans IntelliJ, ajouter les fichiers jar du dossier lib avec l'option Add as library.

• Vérifier le nom de la classe LambdaIdentity$.... pour qu'il corresponde à la version de Weblogic ; si nécessaire, refactoriser le fichier et modifier son nom.

  Weblogic 12.2.1.3 : LambdaIdentity$E12ECA49F06D0401A9D406B2DCC7463A

  Weblogic 12.2.1.4 : LambdaIdentity$423B02C050017B24DB10DFF759AA56BF

• Modifier le chemin vers le fichier LambdaIdentity$....class dans le fichier Main.java. Pour obtenir le chemin exact, deux méthodes : exécuter javac sur le fichier jar pour générer le fichier .class ; une autre méthode consiste à commenter le code de la fonction main, exécuter le projet normalement, le chemin du fichier class se trouve alors dans le dossier target.

• Vérifier que le jdk et le sdk du projet sont identiques à ceux de la machine cible.

Analyse du code BI et du code générant la charge utile

Analyse du code BI

1. Dans le chemin $Oracle\Middleware\Oracle_Home\user_projects\domains\bi\servers\AdminServer\tmp_WL_user\em\fw8wi5\war\WEB-INF

On trouve le fichier web.xml, qui décrit les correspondances de servlets (servlet-mapping). "resources" est un servlet lié aux ressources système, contenant des données et informations importantes ; c'est pourquoi il est souvent ciblé par les attaquants.

2. En approfondissant la classe ResourceServlet, plus précisément org.apache.myfaces.trinidad.webapp.ResourceServlet, on voit la méthode doGet qui traite les requêtes GET envoyées au serveur.

• Ici, via la méthode _getResourceLoader(), un nouveau loader est créé à partir de la requête entrante. En même temps, un resourcePath est initialisé et reçoit la valeur de servletPath et servletInfo via la méthode getResourcePath avec la requête en paramètre. Ce loader appelle ensuite la fonction getResource(resourcePath), qui tente de charger la ressource depuis la requête et de la trouver via la fonction org.apache.myfaces.trinidad.resource.ResourceLoader.getResource.findResource(). Enfin, la valeur trouvée est transmise à une instance url de la classe URL.class.

• _getResourceLoader maintient une ConcurrentMap pour stocker les correspondances entre servletPath et les loaders. Cette relation est définie explicitement dans oracle.adfinternal.view.resource.rich.RenderKitResourceLoader.

• La méthode _register dans RenderKitResourceLoader() est appelée avec les regex et le loader correspondant, puis retourne super.register, sa fonction parente. Cette fonction ajoute dans concurrentmap_loaders le motif et le loader correspondant. Ainsi, lorsque le loader est initialisé dans la fonction doGet() et reçoit le paramètre de la requête, la valeur servletPath de l'URL de la requête est extraite et transmise à _loader.get() pour récupérer le servlet correspondant.

• L'auteur de la vulnérabilité estime que parmi les classes contenant une méthode override findResource(), oracle.adfinternal.view.resource.rich.RemoteApplicationResourceLoader est celle qui présente un risque de désérialisation. Analysons-la pour en comprendre la raison.

Analyse de la fonction findResource() dans RemoteApplicationResourceLoader.class

Cette fonction retourne une méthode contenant un protocole personnalisé RAStreamHandler(). RAStreamHandler crée un objet URLConnection avec la valeur new RAURLConnection.

La fonction RAURLConnection appelle _getPathBean.

La fonction _getPathBean contient un objet bean créé via l'appel à la fonction getInstanceFromString(), qui traite la chaîne reçue pour en extraire les clés correspondantes (filtre).

La chaîne d'entrée bean est convertie via la classe SerializationUtils d'une forme encodée URL en un objet URLEncoderPathBean. Si tout se passe bien, l'entrée suivante est transmise à la fonction fromURLEncodeString().

En cas d'erreur dans la chaîne d'entrée, une exception est levée. Les exceptions proviennent principalement de la bibliothèque utilisée dans la charge utile, en raison de différences de version ou d'un chemin incorrect vers le fichier Lambda.

Dans la fonction fromURLEncodedString(), une fonction fromString est retournée avec l'URL en paramètre, et son code est le suivant :

Dans la fonction fromString, les données sont lues par readObject() et renvoyées. On voit que l'entrée n'est pas filtrée ; elle passe par plusieurs fonctions et est finalement désérialisée dans fromString(). C'est le point de réception (sink) pour l'exploitation. Une fois le sink identifié, il faut trouver la source.

3. Recherche de la source : comme analysé plus haut, pour trouver la source, il faut déterminer l'URL de la requête entrante. On voit que pour appeler la fonction findResource(), il faut pouvoir atteindre la classe RemoteApplicationResourceLoader. La classe RenderKitResourceLoader définit très clairement les chemins :```bash this._register("/./remote/(.)", new RemoteApplicationResourceLoader());