<summary><strong>Apprenez le hacking AWS de zéro à héros avec</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Obtenez le [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Partagez vos astuces de hacking en soumettant des PR aux dépôts github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
Comment réagiriez-vous si je vous disais que [GWT, un cadre d'application web open-source assez populaire initialement développé chez Google](https://www.gwtproject.org/) contenait une vulnérabilité de désérialisation Java non authentifiée qui avait été ouvertement discutée en 2015 et 2020, mais qui était encore non corrigée fin 2023 ? Et si je vous disais également que la vulnérabilité était à un niveau tellement bas que sécuriser les applications web vulnérables écrites en utilisant ce cadre nécessiterait probablement des changements architecturaux à ces applications ou au cadre lui-même ?
Si vous êtes comme moi, votre première réaction serait l'incrédulité. Sûrement une vulnérabilité qui pourrait exposer les propriétaires d'applications à l'exécution de code côté serveur par des attaquants non authentifiés aurait été corrigée moins de huit ans après sa découverte. Si aucun correctif n'avait été publié, alors au moins les fonctionnalités de cadre vulnérables auraient été marquées comme obsolètes, et la documentation du cadre fournirait des suggestions pour remplacer le code vulnérable par des alternatives mises à jour. Au minimum, les développeurs du cadre auraient sans aucun doute mis à jour les tutoriels "premiers pas" et autres documentations pour indiquer le danger inhérent à l'utilisation des fonctionnalités vulnérables au lieu de mettre en avant la fonctionnalité.
Aussi surprenant que cela puisse paraître, aucune de ces suppositions n'est vraie. Huit ans plus tard, la vulnérabilité est toujours non corrigée, et les seules indications du danger avant ce billet de blog étaient [un problème GitHub de 2020 avec une réponse de type "WONTFIX"](https://github.com/gwtproject/gwt/issues/9709), [quelques discussions de Google Groups de 2015 qui n'ont jamais conduit à la résolution du problème sous-jacent](https://groups.google.com/g/google-web-toolkit/c/j36D9-11JF4/m/OZwNQgvSAgAJ), et [un billet de blog de 2015 qui suggère correctement que le problème pourrait être résolu en signant les données sérialisées](https://gwtnews.blogspot.com/2015/11/re-java-deserialization-vulnerability_55.html), sauf qu'aucune fonctionnalité de ce type n'a jamais été ajoutée à GWT. Il y a même [un billet de blog de 2020 qui affirme à tort que GWT n'est pas vulnérable](https://gwtnews.blogspot.com/2020/06/re-security-vulnerabilities-with-gwt_52.html), parce qu'il ne transmettrait soi-disant jamais d'objets Java sérialisés sur le réseau.
Dans ce billet de blog, je vais expliquer la vulnérabilité dans GWT (initialement "Google Web Toolkit", parfois appelé "GWT Web Toolkit"), vous montrer comment exploiter une application web GWT vulnérable, vous montrer comment configurer une application web GWT intentionnellement vulnérable pour tester, déterminer si votre propre application basée sur GWT est vulnérable, et discuter des atténuations potentielles.
GWT permet aux développeurs de (entre autres) écrire des applications web en Java qui ont une logique s'exécutant sur le serveur (Tomcat, Jetty, etc.) et une autre dans les navigateurs web des utilisateurs. Le SDK GWT génère tout le code JavaScript côté client nécessaire lorsque le projet Java est compilé. GWT inclut une sorte de mini-JRE écrit en JavaScript à cet effet. Généralement, GWT compile des objets Java personnalisés pour le client et le serveur, et ces objets sont échangés en utilisant un format de sérialisation de texte délimité par des pipes que les deux côtés peuvent analyser. Par exemple, la requête suivante inclut un tableau d'objets `String` et un objet `CustomClass1`, et les propriétés qui décrivent ces objets sont représentées comme des chaînes de caractères ou des chiffres :
Cependant, [GWT a également un concept appelé "classes améliorées"](https://www.gwtproject.org/doc/latest/DevGuideServerCommunication.html#DevGuideSerializableTypes), qui (à un niveau élevé) sont des objets Java qui répondent à certains critères (consultez la documentation liée si vous souhaitez comprendre les spécificités). Ces classes améliorées sont uniquement traitées à l'aide de code côté serveur, mais sont transmises au client et depuis le client dans le cadre de l'état de l'application, bien qu'elles soient opaques pour le client. Vous pouvez considérer cela comme étant analogue au ViewState dans les applications ASP.NET, sauf sans prise en charge pour le chiffrement ou les signatures cryptographiques.
Lorsque les classes améliorées entrent en jeu, elles apparaissent dans les requêtes et réponses GWT codées à l'aide d'une variation non standard de Base64. Par exemple, la valeur `rO0ABXcEAAAAAA==` dans la requête suivante :
Le décodage des données révèle l'utilisation du format de sérialisation d'objet Java (l'en-tête `0xACED` est révélateur, et cela fait que la version encodée commence toujours par `rO0`). Cependant, l'utilisation du format par GWT est légèrement différente de la sérialisation Java standard. Essayer de remplacer la valeur par la sortie de [`ysoserial`](https://github.com/frohoff/ysoserial), par exemple, entraînera le serveur à renvoyer des messages d'erreur au lieu de désérialiser l'objet. Par exemple :
Cela pourrait amener un pentester à croire que GWT effectuait une sorte de validation des données avant de désérialiser l'objet(s), et rejetait les classes inattendues, mais cette supposition serait incorrecte.
La situation est encore pire si le code d'authentification ou d'autorisation d'une application est géré au sein de l'application GWT (au lieu d'un filtre séparé appliqué au niveau du serveur d'application, par exemple), car toute vulnérabilité de désérialisation est exploitable par des appelants non authentifiés ou non autorisés. C'est parce que GWT désérialise les données de la requête avant de les passer à la fonction côté serveur associée.
Si vous avez déjà une application basée sur GWT en direct à tester, vous pouvez utiliser les étapes de cette section pour essayer de l'exploiter. Si vous n'avez pas accès à une application existante, la section "Construire une application vulnérable exemple pour tester contre", ci-dessous, vous guidera à déployer rapidement une pour vous entraîner.
Tout d'abord, vous aurez besoin d'une charge utile de désérialisation. Comme je l'ai mentionné plus tôt dans cet article, la sérialisation de GWT est basée sur le format standard Java, mais elle utilise un motif spécifique qui empêchera la sortie d'outils d'exploitation standard de fonctionner. Au lieu que le flux contienne directement un seul objet, il commence par un entier indiquant le nombre de champs dans le flux. Pour chaque champ, le flux contient une chaîne qui représente le nom du champ, et un objet arbitraire pour la valeur du champ.
Je n'ai pas trouvé de moyen facile de préfixer les informations nécessaires à un objet, et `ysoserial` ne semblait pas être activement maintenu, donc [j'ai créé un fork qui ajoute les fonctionnalités nécessaires](https://github.com/BishopFox/ysoserial-bf) (et intègre également du code supplémentaire que d'autres ont soumis pour inclusion dans `ysoserial`). Il peut générer toutes les charges utiles standard de `ysoserial` (y compris plusieurs qui n'avaient pas été fusionnées dans la branche principale), mais ajoute une option `--gwt` pour créer ces charges utiles formatées pour une utilisation dans une requête GWT-RPC. L'option `--gwt` nécessite un paramètre supplémentaire, qui est le nom du champ à inclure dans le flux d'objets. Le nom de champ spécifique est généralement sans importance, mais une valeur doit être spécifiée pour que GWT reconnaisse la charge utile comme valide. Dans l'exemple ci-dessous, le champ sera nommé bishopfox :
**FIGURE 3** - Génération du payload `URLDNS` au format GWT-RPC
GWT-RPC utilise une version personnalisée de Base64 où le caractère + est remplacé par $, et le caractère / est remplacé par \_, donc l'étape suivante consiste à encoder le payload.
On peut utiliser les opérations standard de Base64, mais remplacer + par $ et / par \_ (ou inversement) dans l'entrée ou la sortie encodée. Par exemple :
```bash
$ base64 -w0 gwt_urldns.bin \
| sed 's/+/\$/g' \
| sed 's./._.g' \
> gwt_urldns.bin.gwt_b64
```
**FIGURE 4** - Exemple d'encodage de payload pour utilisation dans une requête GWT-RPC
Bien sûr, la génération et l'encodage peuvent être combinés en une seule commande :
**FIGURE 5** - Génération et encodage du payload URLDNS
Les objets sérialisés peuvent également être encodés et décodés en Python en incluant l'option `altchars=b'$_'` lors de l'appel à `base64.b64encode` ou `base64.b64decode`. Par exemple :
Comme pour toute autre vulnérabilité de désérialisation Java suspectée, je suggère de commencer avec le payload `ysoserial URLDNS` configuré pour charger une URL basée sur le nom d'hôte actuel de votre Burp Suite Collaborator.
Après avoir généré et encodé le payload, utilisez un outil tel que le module Repeater de Burp Suite pour envoyer une version modifiée de la requête qui contient le payload encodé à la place de la valeur originale. Si cela réussit, vous recevrez très probablement une réponse indiquant que le nom du champ était invalide :
7|0|10|http://127.0.0.1:8888/stockwatcher/|259823D3B8B1029302496D0C7E009509|com.google.gwt.sample.stockwatcher.client.CheckCustomClassService|checkCustomClass1|com.google.gwt.sample.stockwatcher.client.CustomClass1/1972642674|rO0ABXcEAAAAAXQACWJpc2hvcGZveHNyABFqYXZhLnV0aWwuSGFzaFNldLpEhZWWuLc0AwAAeHB3DAAAAAI…omitted for brevity…0AAEueHg=|com.google.gwt.sample.stockwatcher.client.CustomClass2/69504871|java.sql.Date/730999118|1|2|1|2|3|4|1|5|5|6|
Si vous avez commencé par utiliser un payload `URLDNS` pointant vers le nom d'hôte de votre Collaborator, vous devriez pouvoir valider que quelque chose a demandé cette URL, ou au moins résolu le nom DNS. Il _existe_ des environnements tellement restreints qu'ils ne permettent même pas la résolution de noms DNS publics, mais ils sont très rares.
Comme toute autre vulnérabilité de désérialisation Java, une exploitation significative nécessite une chaîne de gadgets basée sur des classes chargées sur le serveur. [La documentation pour notre version personnalisée de `ysoserial` inclut une manière de générer rapidement des payloads pour toutes ses chaînes de gadgets d'exécution de commandes à usage général](https://github.com/BishopFox/ysoserial-bf).
Comme je l'ai mentionné dans la section "GWT et classes améliorées", ci-dessus, GWT désérialise les requêtes avant d'exécuter le code dans les fonctions GWT-RPC associées. Cela signifie souvent qu'une fonction GWT-RPC vulnérable peut être exploitée sans identifiants, ou avec des identifiants peu privilégiés, même si la fonction GWT-RPC nécessite une authentification et une autorisation lorsqu'elle est appelée normalement. Donc, si vous confirmez qu'une fonction est vulnérable, poursuivez en testant pour voir si elle fonctionne sans authentification. Si la fonction GWT-RPC nécessite normalement des identifiants hautement privilégiés, essayez d'envoyer le payload d'exploitation en utilisant des données d'authentification d'un compte peu privilégié, tel que l'inscription à un essai gratuit du produit que vous testez.
Lorsque j'ai commencé à rechercher ce sujet, je n'ai trouvé aucun projet open-source utilisant GWT de manière vulnérable. Le projet d'exemple GWT nécessitait de nombreuses étapes manuelles pour être créé, et le résultat n'utilisait pas le mécanisme de sérialisation vulnérable. Pour faciliter la pratique de l'exploitation d'applications basées sur GWT, [j'ai créé une version du projet d'exemple GWT qui non seulement utilise la sérialisation binaire, mais inclut également des fichiers JAR vulnérables à plusieurs chaînes de gadgets `ysoserial`](https://github.com/BishopFox/VulnerableGWTApp).
Utilisez les instructions "démarrage rapide" pour déployer rapidement une application web GWT vulnérable qui peut être exploitée en utilisant plusieurs des chaînes de gadgets incluses avec la version personnalisée de `ysoserial` discutée ci-dessus.
Si vous voyez des classes Java encodées en Base64 dans tout trafic vers une application basée sur GWT, l'application est presque certainement vulnérable.
Il est également utile de vérifier les fichiers de politique de sérialisation GWT-RPC de l'application pour voir si certains d'entre eux contiennent le décorateur `@ClientFields`. Chaque fichier de politique contenant un ou plusieurs instances du décorateur `@ClientField` indique au moins une méthode GWT-RPC qui devrait être vulnérable.
Les fichiers de politique de sérialisation sont générés pendant le processus de construction GWT. Si vous avez accès au code côté serveur, recherchez des fichiers avec une extension `.gwt.rpc` :
**FIGURE 8** - Recherche de fichiers de politique GWT-RPC sur un serveur
Si la conception de l'application aboutit à une classe que le serveur doit échanger en utilisant la sérialisation binaire Java GWT-RPC, elle aura un `@ClientFields decorator`, comme montré ci-dessous :
Si vous effectuez un test de sécurité à connaissance nulle d'une application web, vous devrez collecter les noms forts GWT-RPC distincts utilisés par l'application, puis utiliser ces noms forts pour accéder aux fichiers de politique. Dans cet exemple de requête, le nom fort est `259823D3B8B1029302496D0C7E009509` :
Il peut être plus efficace de rechercher dans l'historique de votre proxy d'interception pour `strongName =`, ce qui devrait vous donner une liste des fichiers JavaScript générés par GWT qui se réfèrent aux noms forts, même si vos actions au sein de l'application web n'ont pas nécessairement généré de trafic vers les méthodes vulnérables. Par exemple :
var $strongName = '259823D3B8B1029302496D0C7E009509';
…omitted for brevity…
```
**FIGURE 11** - Exemple de référence de nom fort dans un fichier JavaScript d'une application web GWT
Une fois que vous connaissez le(s) nom(s) fort(s) de l'application, les fichiers de politique devraient se trouver dans le même répertoire, nommés en utilisant le(s) nom(s) fort(s) avec une extension `.gwt.rpc`. Par exemple :
**Requête**
```
GET /stockwatcher/259823D3B8B1029302496D0C7E009509.gwt.rpc HTTP/1.1
C'est une excellente manière de construire une liste de contrôle du trafic à surveiller pendant l'utilisation de l'application. Si vous avez testé toutes les fonctionnalités que vous connaissez et que vous n'avez toujours pas vu une ou plusieurs d'entre elles en utilisation, vous devrez soit approfondir le code source, soit envisager de construire manuellement des requêtes pour les méthodes GWT-RPC restantes. Le protocole de sérialisation GWT-RPC est compliqué, donc ce post ne fournira pas d'instructions pour la création manuelle de requêtes, mais [Brian Slesinsky a rédigé un bon guide sur le protocole en 2012](https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit) que vous pouvez consulter si vous souhaitez explorer cette option.
<summary><strong>Apprenez le hacking AWS de zéro à héros avec</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection d'[**NFTs**](https://opensea.io/collection/the-peass-family) exclusifs
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez**-moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Partagez vos astuces de hacking en soumettant des PR aux dépôts github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
