Développement d’une chaîne de gadgets personnalisée pour la désérialisation Java

Developing a custom gadget chain for Java deserialization

Objectif du laboratoire

Ce laboratoire repose sur un mécanisme de session utilisant la sérialisation Java. En construisant une chaîne de gadgets personnalisée, il est possible d’exploiter une désérialisation non sécurisée afin de récupérer le mot de passe de l’administrateur, puis de se connecter avec ce compte et supprimer l’utilisateur carlos.

Identifiants fournis :

  • Utilisateur : wiener

  • Mot de passe : peter

Analyse initiale de la session

La cookie de session observée est encodée en Base64 :

Après décodage, on identifie clairement une sérialisation Java, ce qui confirme l’utilisation de ObjectInputStream côté serveur.

Accès au code source

Un commentaire HTML fournit un lien vers une sauvegarde de code Java :

Contenu du fichier AccessTokenUser.java :

  • Classe sérialisable

  • Deux attributs : username et accessToken

  • Aucun comportement dangereux exploitable directement

Dans le dossier /backup, un autre fichier attire l’attention : ProductTemplate.java.

Classe vulnérable : ProductTemplate

La classe ProductTemplate implémente Serializable et redéfinit la méthode readObject().

Points critiques :

  • La méthode readObject() est exécutée automatiquement lors de la désérialisation

  • Une requête SQL est construite dynamiquement avec String.format

  • Le paramètre id est injecté directement dans la requête sans validation

Construction du payload Java

Pour générer un objet sérialisé valide, un projet Java local est créé :

Structure minimale :

Les classes sont volontairement simplifiées afin de permettre uniquement la sérialisation, sans logique interne.

Génération de la cookie malveillante

Dans Main.java, un objet ProductTemplate est instancié avec une valeur contrôlée pour id, puis sérialisé et encodé en Base64.

Premier test avec une simple apostrophe :

Le serveur retourne une erreur SQL, confirmant l’injection.

Exploitation de l’injection SQL

  1. Détermination du nombre de colonnes → 8 colonnes identifiées

Test UNION SELECT → La 4ᵉ colonne est exploitable

  • Enumération des tables

    • Table identifiée : users

Enumération des colonnes

  • username

  • password

  • email

  1. Extraction des identifiants

Payload final injecté dans l’objet sérialisé :

Résultat obtenu

Après envoi de la cookie sérialisée, la réponse du serveur révèle les identifiants :

Mis à jour