Applications, sites et API

Particuliers et entreprises

Exploitation d’une désérialisation non sûre

Insecure deserialization exploitation

Un programme reconstruit des objets à partir de données piégées et déclenche des actions dangereuses.

Révision éditoriale : Comprendre : 2 min · Cas technique et détails : 5 min
Je pense être concerné : que faire ?
Illustration pédagogique : exploitation d’une désérialisation non sûre.

Comprendre et agir

Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.

Une situation concrète

Une application reçoit un paquet décrivant des données à reconstruire. Si elle accepte aussi les indications qui choisissent des objets et leurs comportements, ce paquet peut déclencher des actions pendant sa lecture.

Comment cela fonctionne

Pour stocker ou transmettre des données, un programme peut les convertir dans un format transportable : c’est la sérialisation. La désérialisation les reconstruit à l’arrivée. Si le programme accepte sans précaution des objets complexes provenant d’une source non fiable, cette reconstruction peut exécuter du code ou épuiser ses ressources. Le risque dépend du format, des bibliothèques et du traitement effectué. Il ne concerne donc pas automatiquement tous les fichiers JSON.

Comment le piège fonctionne
  1. Un paquet doit devenir des objets

    Import, message ou état sauvegardé.

  2. La reconstruction est trop permissive

    Le contenu choisit des comportements.

  3. Le service agit pendant la lecture

    Code ou ressources détournés.

Ce que vous pouvez faire

Vos premiers réflexes

Utilisez les versions maintenues de vos applications et signalez les imports anormaux. Vous n’avez pas à inspecter les objets internes ni à corriger le format du service.

Si vous êtes responsable du service ou de l’organisation

Définissez les structures de données acceptées et limitez leur taille ainsi que leur profondeur. Examinez aussi les traitements en arrière-plan qui reconstruisent les objets après l’import.

Un point à vérifierUne idée reçue à corriger

Un message peut être correctement encodé ou compressé et contenir tout de même des données dangereuses.

À vous de décider

Un fichier est présenté comme de simples données. Cela garantit-il que son import ne peut rien déclencher ?

Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.

Voir la réponse expliquée

Non. Le risque dépend de la façon dont l’application lit le fichier. Elle peut reconstruire des objets qui déclenchent du code ou consomment trop de ressources. Utilisez une version maintenue et signalez l’import anormal ; le développeur doit vérifier le format accepté.

Analyser un cas technique

Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».

Étude de cas fictive

Un message de données déclenche un comportement dans le serveur

Lorsqu’un programme désérialise un message ou un fichier, il en reconstitue les données. Avec certains formats, il peut aussi recréer des objets et appeler du code associé à leurs classes. Si la source n’est pas fiable, cette opération peut donc déclencher du code au moment où le programme pense simplement lire des données.

Le danger peut se trouver loin de la requête initiale. Une API enregistre un message dans une file, puis un worker le désérialise avec davantage de droits. Contrôler uniquement l’entrée HTTP laisse ce second traitement exposé. Il faut suivre le message jusqu’au composant qui l’interprète et identifier sa bibliothèque, sa version et ses options.

Un format de données simple réduit la surface d’attaque, mais nécessite encore une validation : champs autorisés, types, tailles et valeurs. Des limites de profondeur et de volume évitent qu’un message provoque une consommation excessive de mémoire ou de calcul. Une signature de message n’est utile que si la clé et l’émetteur sont fiables ; elle ne rend pas sûr un contenu signé par une source compromise.

L’enquête doit relier le message, le worker et les effets observés : processus enfant, fichier créé ou connexion sortante. Une erreur de décodage isolée est moins probante qu’une action inattendue déclenchée au même instant par ce worker.

Le déroulement en schéma

Qui échange avec quiLisez les échanges de haut en bas. Le point marque le départ et la flèche l’arrivée. Les vérifications après correction ne sont pas la suite de l’attaque.

Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.

Étape
ProducteurConfiance externe
File de jobsMessages persistants
DésérialiseurTypes et callbacks
WorkerCapacités système
  1. Action

    Objet sérialisé

    Producteur vers File de jobs

    Trace j55

  2. Action

    Livraison ou rejeu

    File de jobs vers Désérialiseur

  3. Action sur place

    Résolution dynamique de classes

    Désérialiseur

    Trace class_policy

  4. Action

    Callback de restauration

    Désérialiseur vers Worker

    Trace restore_state

  5. Action sur place

    Processus enfant inattendu

    Worker

    Trace p91

  6. Action

    Après correction : données JSON

    File de jobs vers Désérialiseur

  7. Action

    Objet construit explicitement après schéma

    Désérialiseur vers Worker

    Trace report-v2

Comment repérer cette attaque

Indices à rechercher

  • Des objets ou types inattendus sont reçus par une interface.
  • Le traitement d’un message lance des actions sans rapport avec ses données.
  • Des erreurs de reconstruction ou consommations mémoire se répètent.

Repérer les messages rejetés, les types de données inattendus et les comportements inhabituels des workers pendant le traitement d’un message.

Quelles informations comparer

Relier le message consommé à l’instance du worker et à ses processus enfants. Comparer un message rejeté avant désérialisation avec le message suspect réellement traité.

Ce que ces indices ne permettent pas de conclure

Une file interne n’est pas une preuve de confiance dans son contenu. Le journal système ne révèle pas à lui seul la classe désérialisée : cette information vient de l’instrumentation du consommateur.

Comment réagir

Mettre en quarantaine les messages concernés sans les ouvrir avec le mécanisme vulnérable. Corriger le format et les options, traiter les messages déjà en file et examiner les secrets du worker. Reconstruire les environnements dont l’intégrité est incertaine.

Vérifier la correction

L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.

  1. Le service doit refuser les types d’objets et champs non prévus.
  2. Les messages trop volumineux ou trop profonds doivent être rejetés avant d’épuiser les ressources.
  3. Le même contrôle doit s’appliquer aux imports, files et reprises de traitements.

À vous de raisonner

L’API valide la requête, puis un worker privilégié relit le message avec un autre décodeur. Quel périmètre la revue doit-elle couvrir ?

Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.

Comparer avec le raisonnement expliqué

Suivez le message jusqu’au worker, sa bibliothèque et ses options de décodage. Les types, champs et limites de taille doivent être contrôlés aux traitements concernés. La validation HTTP ne suffit pas si le consommateur interprète autrement le contenu ou recrée des objets actifs.

Consulter les détails techniques

Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.

Lire les extraits commentés (reconstitution fictive)

Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-les dans les extraits.

type_resolution
Information pédagogique sur le choix des types par le consommateur ; à collecter dans cette application, pas dans le journal du broker seul.
callback
Fonction de restauration appelée dans le scénario ; son nom n’est pas un indicateur universel de compromission.

Séquence suspecte dans un worker

Journal

Logs synthétiques ; un type demandé et un processus enfant ne sont pas des champs universels de tous les désérialiseurs.

job=j55 producer=partner-7 format=native-object payload_size=824
job=j55 type_resolution=dynamic class_policy=unrestricted
job=j55 worker=w3 callback=restore_state
host=w3 process=p91 parent=worker image=/bin/sh
job=j56 producer=partner-7 format=json schema=report-v2 result=rejected
Préparer une collecte dans votre environnement

Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les secrets.

  1. Service concerné — audit et historique à vérifier

    Où les trouver
    Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
    Quoi relever
    Dans le consommateur de messages, rechercher job, producteur authentifié, format, version de schéma, classes autorisées et résultat de validation. Une erreur de parsing seule n’indique pas si un objet dangereux a été instancié.
    Accès et prérequis
    Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
    Documentation : Service concerné — audit et historique à vérifier

  2. Linux — auditd

    Où les trouver
    Sur le serveur concerné, dans le fichier log_file d’auditd, généralement /var/log/audit/audit.log. Les enregistrements SYSCALL, EXECVE et PATH d’un même événement partagent le numéro dans msg=audit(...).
    Quoi relever
    Sur le worker Linux, rechercher les exécutions anormales après traitement du message : exécutable, parent, identité système et heure. Vérifier que les règles d’audit couvraient les exécutions.
    Accès et prérequis
    Service actif et règles d’audit adaptées avant les faits. Linux n’enregistre pas automatiquement toutes les exécutions et lectures ; les arguments et chemins collectés peuvent être sensibles.
    Documentation : Linux — auditd

Dans l’histoire des cyberattaques

Groupes et campagnes documentés

1 repère

Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.

  1. GroupeHAFNIUM

    Exchange : enchaîner plusieurs failles pour entrer

    Microsoft décrit des intrusions dans des serveurs Exchange hébergés par les organisations. Une SSRF contourne une étape d’authentification ; une désérialisation non sûre peut ensuite faire exécuter du code avec des droits élevés. Les attaquants peuvent alors accéder aux courriels.

    Ce qu’établit la source. Microsoft attribue avec une confiance élevée les premières attaques ciblées à HAFNIUM. L’éditeur signale ensuite l’exploitation de ces mêmes failles par d’autres acteurs.

    Consulter le rapport HAFNIUM targeting Exchange Servers with 0-day exploits

    Microsoft · Publié le

    Également dans ce cas :Falsification de requête côté serveurExploitation de vulnérabilités

Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’aucun de ces groupes.

Si vous pensez être concerné

Si vous utilisez le service

Utilisez les versions maintenues de vos applications et signalez les imports anormaux. Vous n’avez pas à inspecter les objets internes ni à corriger le format du service.

Pour l’équipe qui exploite le service

  1. Suspendez le traitement dangereux et préservez les messages utiles.
  2. Vérifiez les effets produits avec les droits du service.
  3. Corrigez le modèle de données et recherchez les autres interfaces utilisant le même mécanisme.

Pour comprendre votre situation et trouver de l’aide : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.

Sources et repères pour approfondir

Sur des sujets proches

Injection de commandes système ↗Exploitation de vulnérabilités ↗Déni de service, simple ou distribué ↗Toutes les fiches ECRAN →