Applications, sites et API
Particuliers et entreprisesExploitation d’une désérialisation non sûre
Insecure deserialization exploitation
La reconstruction d’un objet à partir de données déclenche un comportement dangereux.
Je pense être concerné : que faire ?
Comprendre et agir
À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.
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
La sérialisation transforme des données en un format transportable ; la désérialisation fait l’inverse. Le danger apparaît quand un programme reconstruit sans précaution des objets complexes à partir d’un contenu non fiable. Selon le format et les bibliothèques, la lecture peut déclencher du code ou consommer trop de ressources. Tous les fichiers JSON ne présentent pas ce risque : la manière de les traiter est déterminante.
- Un paquet doit devenir des objets
Import, message ou état sauvegardé.
- La reconstruction est trop permissive
Le contenu choisit des comportements.
- 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éveloppeurs : acceptez des structures de données définies et limitez taille et profondeur. Vérifiez aussi les traitements différés qui reconstruisent les objets après l’import.
Un message correctement encodé ou compressé n’est pas pour autant digne de confiance.
À 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 ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
Non. Tout dépend de la manière dont l’application le lit : certains traitements peuvent reconstruire des objets actifs ou consommer trop de ressources. Utilisez une application maintenue et signalez un import anormal ; la validation du format relève de son développeur.
Analyser un cas technique
Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.
Étude de cas fictive
Un message de données déclenche un comportement dans le serveur
La désérialisation reconstitue des données à partir d’un message ou d’un fichier. Certains formats permettent aussi de recréer des objets et d’appeler du code associé à leurs classes. Accepter ces formats depuis une source non fiable peut donc provoquer bien plus qu’une simple lecture de 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
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.
- Action
Objet sérialisé
Producteur vers File de jobs
Trace j55
- Action
Livraison ou rejeu
File de jobs vers Désérialiseur
- Action sur place
Résolution dynamique de classes
Désérialiseur
Trace class_policy
- Action
Callback de restauration
Désérialiseur vers Worker
Trace restore_state
- Action sur place
Processus enfant inattendu
Worker
Trace p91
- Action
Après correction : données JSON
File de jobs vers Désérialiseur
- 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.
Éléments à croiser
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é.
Limites de l’interprétation
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
Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.
- Le service doit refuser les types d’objets et champs non prévus.
- Les messages trop volumineux ou trop profonds doivent être rejetés avant d’épuiser les ressources.
- 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 ?
Formulez votre décision et l’élément qui la justifie 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
Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.
Lire les extraits commentés — reconstitution fictive
Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-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
JournalLogs 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=rejectedPréparer une collecte dans votre environnement
Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des secrets.
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.
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.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Des faits réels pour situer ce mécanisme. Les années sont celles des faits ; chaque notice précise qui établit le lien avec le groupe ou la campagne.
- GroupeHAFNIUM
Exchange : enchaîner plusieurs failles pour entrer
Microsoft décrit des intrusions dans des serveurs Exchange installés chez les organisations. Une SSRF permet de contourner une étape d’authentification ; une désérialisation non sûre peut ensuite permettre l’exécution de code avec des droits élevés. Des courriels deviennent accessibles aux attaquants.
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 exploitsMicrosoft · Publié le
Sélection de cas documentés, non exhaustive. Une technique peut être utilisée par de nombreux acteurs. Les cas fictifs de la fiche ne sont attribués à 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
- Suspendez le traitement dangereux et préservez les messages utiles.
- Vérifiez les effets produits avec les droits du service.
- Corrigez le modèle de données et recherchez les autres interfaces utilisant le même mécanisme.
Pour qualifier votre situation et être orienté : 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
- OWASP — Deserialization — cheatsheetseries.owasp.org
- Python — pickle et confiance — docs.python.org
