- Travaillez-vous dans une entreprise de **cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
- **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Partagez vos astuces de piratage en soumettant des PR au [repo hacktricks](https://github.com/carlospolop/hacktricks) et au [repo hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
Après avoir examiné les [RCEs à travers les bibliothèques JSON mal configurées](https://www.alphabot.com/security/blog/2017/net/How-to-configure-Json.NET-to-create-a-vulnerable-web-API.html), nous avons commencé à analyser les ViewStates des implémentations JSF. [JavaServer Faces (JSF)](https://en.wikipedia.org/wiki/JavaServer_Faces) est une technologie d'interface utilisateur (UI) pour la création d'interfaces utilisateur Web avec des composants réutilisables. JSF est principalement utilisé pour les applications d'entreprise et une implémentation JSF est généralement utilisée par une application Web qui s'exécute sur un serveur d'applications Java tel que JBoss EAP ou WebLogic Server. Il existe deux implémentations bien connues de la spécification JSF :
Cet article de blog se concentre sur les deux implémentations JSF 2.x : Oracle Mojarra (implémentation de référence) et Apache MyFaces. Les anciennes implémentations (JSF 1.x) sont également susceptibles d'être affectées par les vulnérabilités décrites dans ce post. (JSF 2.0.x a été initialement publié en 2009, la version actuelle est 2.3.x).
Une différence entre JSF et les technologies Web similaires est que JSF utilise des ViewStates (en plus des sessions) pour stocker l'état actuel de la vue (par exemple, quelles parties de la vue doivent être affichées actuellement). Le ViewState peut être stocké sur le `serveur` ou le `client`. Les ViewStates JSF sont généralement automatiquement intégrés dans les formulaires HTML en tant que champ masqué avec le nom `javax.faces.ViewState`. Ils sont renvoyés au serveur si le formulaire est soumis.
Si le ViewState JSF est configuré pour se trouver sur le `serveur`, le champ masqué `javax.faces.ViewState` contient un identifiant qui aide le serveur à récupérer l'état correct. Dans le cas de MyFaces, cet identifiant est un **objet Java sérialisé** !
Si le ViewState JSF est configuré pour se trouver sur le `client`, le champ masqué `javax.faces.ViewState` contient un **objet Java sérialisé** qui est au moins codé en Base64. Vous avez peut-être réalisé à ce stade que c'est une route potentielle vers la catastrophe ! C'est peut-être l'une des raisons pour lesquelles les ViewStates JSF sont aujourd'hui chiffrés et signés avant d'être envoyés au client. Les dangers des objets Java sérialisés
En 2015, lors de la conférence AppSec California, [Gabriel Lawrence](https://twitter.com/gebl) et [Chris Frohoff](https://twitter.com/frohoff) ont présenté un exposé intitulé [Marshalling Pickles (how deserializing objects can ruin your day)](https://frohoff.github.io/appseccali-marshalling-pickles/). Cette présentation a mis en lumière des problèmes oubliés avec la sérialisation d'objets Java et a conduit à la découverte de [plusieurs vulnérabilités graves d'exécution de code à distance (RCE)](https://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/).
Malheureusement, cela a conduit certaines personnes à croire que la vulnérabilité pouvait être atténuée en supprimant/mettant à jour certaines versions de Apache Commons Collections. Une action qui peut en effet aider mais ne résout pas la cause profonde du problème : la désérialisation de données non fiables ([CWE 502](https://cwe.mitre.org/data/definitions/502.html)). En d'autres termes :\
**L'utilisation d'une version de la bibliothèque Apache Commons Collections "vulnérable" ne signifie pas que l'application est vulnérable, et l'absence d'une telle version de bibliothèque ne signifie pas que l'application n'est pas vulnérable.**
Cependant, après qu'un pirate malveillant ait [fermé et crypté les systèmes de la San Francisco Municipal Transportation Agency](https://krebsonsecurity.com/2016/11/san-francisco-rail-system-hacker-hacked/) via une "Mad Gadget"/"Apache Commons Collections Deserialization Vulnerability", Google a lancé [Operation Rosehub](https://opensource.googleblog.com/2017/03/operation-rosehub.html). L'objectif de l'opération Rosehub était de trouver autant de projets open source Java que possible qui utilisaient une version de collections commons "amicale pour les attaquants" en tant que dépendance et de soumettre des demandes de tirage aux propriétaires de projets afin que ces projets cessent d'utiliser des versions problématiques de collections commons dans de nouvelles versions.
Cette page de connexion a un ViewState qui n'est ni chiffré ni signé. Donc, lorsque nous regardons sa source HTML, nous voyons un champ masqué contenant le ViewState : ViewState MyFaces non chiffré :
Si vous décodez le ViewState ci-dessus en utilisant Base64, vous remarquerez qu'il contient un objet Java sérialisé. Ce ViewState est renvoyé au serveur via POST lorsque le formulaire est soumis (par exemple, en cliquant sur Connexion). Maintenant, avant que le ViewState ne soit renvoyé au serveur, l'attaquant remplace le ViewState par son propre ViewState malveillant en utilisant un gadget qui est déjà sur le classpath du serveur (par exemple, `InvokerTransformer` de commons-collections-3.2.1.jar) ou même un gadget qui n'est pas encore connu du public. Avec ledit gadget malveillant placé dans le ViewState, l'attaquant spécifie les commandes qu'il veut exécuter sur le serveur. La flexibilité de ce qu'un attaquant peut faire est limitée par les pouvoirs des gadgets disponibles sur le classpath du serveur. En cas d'utilisation de `InvokerTransformer`, l'attaquant peut spécifier les commandes de ligne de commande qui doivent être exécutées sur le serveur. L'attaquant dans notre exemple a choisi de démarrer une calculatrice sur l'interface utilisateur de notre serveur Linux.
Après que l'attaquant a envoyé son formulaire modifié au serveur, l'implémentation JSF tente de désérialiser le ViewState fourni. Maintenant, même avant que la désérialisation du ViewState ne soit terminée, la commande est exécutée et la calculatrice est démarrée sur le serveur :
Tout s'est passé avant que l'implémentation JSF ne puisse examiner le ViewState et décider qu'il n'était pas bon. Lorsque le ViewState a été jugé invalide, une erreur est généralement renvoyée au client comme "Vue expirée". Mais alors il est déjà trop tard. L'attaquant avait accès au serveur et a exécuté des commandes. (La plupart des attaquants du monde réel ne lancent pas une calculatrice, mais ils déploient généralement un shell distant, qu'ils utilisent ensuite pour accéder au serveur.)
(Le même scénario d'attaque contre JSF tel que décrit ci-dessus a déjà été présenté et démontré dans la présentation de 2015 (pages 65 à 67) : [Marshalling Pickles](https://frohoff.github.io/appseccali-marshalling-pickles/) tenue par Frohoff et Lawrence.)
Comme mentionné précédemment, Oracle Mojarra est l'implémentation de référence JSF (RI) mais peut ne pas être connue sous ce nom. Elle peut être connue sous le nom de Sun JSF RI, reconnue avec le nom de package java `com.sun.faces` ou avec le nom de jar ambigu `jsf-impl.jar`.
Voici la chose : Mojarra n'a pas chiffré et signé le ViewState côté client par défaut dans la plupart des versions de 2.0.x et 2.1.x. Il est important de noter qu'un ViewState côté serveur est la valeur par défaut dans les deux implémentations JSF, mais un développeur pourrait facilement changer la configuration pour utiliser un ViewState côté client en définissant le paramètre `javax.faces.STATE_SAVING_METHOD` sur `client`. Le nom du paramètre ne révèle en aucun cas que le fait de le changer en client introduit de graves vulnérabilités d'exécution de code à distance (par exemple, un ViewState côté client pourrait être utilisé dans des applications Web en cluster).
Bien que le chiffrement du ViewState côté client soit la valeur par défaut dans Mojarra 2.2 et les versions ultérieures, ce n'était pas le cas pour les branches 2.0.x et 2.1.x. Cependant, en mai 2016, les développeurs de Mojarra ont commencé à rétroporter le chiffrement du ViewState côté client par défaut vers [2.0.x](https://github.com/javaserverfaces/mojarra/issues/4142) et [2.1.x](https://github.com/javaserverfaces/mojarra/issues/4141) lorsqu'ils ont réalisé que les ViewStates non chiffrés conduisaient à des vulnérabilités d'exécution de code à distance.
Ainsi, au moins la version [2.1.29-08](https://mvnrepository.com/artifact/com.sun.faces/jsf-impl/2.1.29-08) (publiée en juillet 2016) de la branche 2.1.x et la version [2.0.11-04](https://mvnrepository.com/artifact/com.sun.faces/jsf-impl/2.0.11-04) (également publiée en juillet 2016) de la branche 2.0.x ont le chiffrement activé par défaut.
Lorsque nous avons analysé les bibliothèques Mojarra, nous avons remarqué que Red Hat publie également des versions de Mojarra pour les branches 2.1.x et 2.0.x, la dernière étant [2.1.29-jbossorg-1](https://mvnrepository.com/artifact/com.sun.faces/jsf-impl/2.1.29-jbossorg-1) et [2.0.4-b09-jbossorg-4](https://mvnrepository.com/artifact/com.sun.faces/jsf-impl/2.0.4-b09-jbossorg-4). Comme les deux versions étaient sans chiffrement ViewState par défaut, nous avons contacté Red Hat et ils ont rapidement créé [Bug 1479661 - JSF client side view state saving deserializes data](https://bugzilla.redhat.com/show_bug.cgi?id=1479661) dans leur bugtracker avec les conseils d'atténuation suivants pour la branche 2.1.x :
> Une application Web vulnérable doit avoir défini javax.faces.STATE_SAVING_METHOD sur "client" pour activer l'enregistrement de l'état côté client. La valeur par défaut sur Enterprise Application Platform (EAP) 6.4.x est "serveur".\
> Si javax.faces.STATE_SAVING_METHOD est défini sur "client", une atténuation pour ce problème consiste à chiffrer la vue en définissant com.sun.faces.ClientStateSavingPassword dans le fichier web.xml de l'application :
 est une bibliothèque capable de détecter l'utilisation de clés cryptographiques connues en examinant les produits qu'elles produisent et en les comparant à une liste de clés connues ou faibles. Son module `Jsf_viewstate` est capable de détecter les Java Server Faces ViewStates créés avec des clés connues sur Mojarra et MyFaces, ainsi que les ViewStates non protégés ou compressés.
S'il trouve une correspondance, il listera également la plateforme (Mojarra ou MyFaces), l'algorithme de chiffrement utilisé et si la compression a été utilisée ou non, ce qui est essentiel pour l'exploitation.
Pour rechercher des viewstates vulnérables à grande échelle, en conjonction avec l'énumération des sous-domaines, le module `badsecrets` [**BBOT**]() peut être utilisé :
La plupart des faits sur les JSF ViewStates et leurs dangers présentés dans ce billet de blog ne sont pas exactement nouveaux, mais il semble qu'ils n'aient jamais été présentés de manière aussi condensée. Cela a montré [une fois de plus](https://www.alphabot.com/security/blog/2017/net/How-to-configure-Json.NET-to-create-a-vulnerable-web-API.html) que des changements de configuration apparemment inoffensifs peuvent conduire à des vulnérabilités graves.
\=> L'un des problèmes semble être qu'il n'y a pas assez de transfert de connaissances entre les chercheurs en sécurité et les développeurs qui utilisent et configurent réellement des bibliothèques qui peuvent être dangereuses lorsqu'elles sont configurées de certaines manières.
- Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
- **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Partagez vos astuces de piratage en soumettant des PR au [repo hacktricks](https://github.com/carlospolop/hacktricks) et au [repo hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
