Désérialisation non sécurisée = exécution de code à distance

L' Commit Cela a ouvert une porte dérobée

Une nouvelle fonctionnalité a été intégrée pour gérer les objets téléchargés par les utilisateurs. Tous les tests sont concluants, mais quelques semaines plus tard, un test d'intrusion révèle que des attaquants peuvent exécuter des commandes sur le serveur ; le résultat d'une désérialisation non sécurisée, dissimulée dans le code. L'écart entre la désérialisation et l'exécution de code à distance peut être dangereusement faible, surtout lorsque les données sérialisées provenant de packages open source ou de services internes sont fiables sans validation.

Qu'est-ce que la désérialisation dans le code, pourquoi est-elle risquée et où se cache-t-elle ?

En termes de développement, qu'est-ce que la désérialisation ? Il s'agit du processus consistant à récupérer des données structurées, du JSON, du XML, des formats binaires ou des objets sérialisés spécifiques à un langage, et à les retransformer en objets en mémoire.

Seul, désérialisation est inoffensif et courant, par exemple :

Java: Lire des objets avec ObjetInputStream
Python: Chargement des données avec pickle.load
Node.js: Analyse JSON avec JSON.parse

Le risque apparaît lorsque la désérialisation est appliquée à des données non fiables sans validation. Un attaquant peut créer une entrée qui déclenche une chaîne de gadgets, des chemins de code existants utilisés de manière non intentionnelle, ce qui peut conduire à l'exécution de code à distance.

Peu sûr désérialisation se trouve souvent dans :

Paquets open source avec des valeurs par défaut non sécurisées
Code personnalisé qui suppose que l'entrée sérialisée est digne de confiance
API tierces renvoient des objets sérialisés sans vérification
Construire des artefacts telles que:
- Java .ser fichiers contenant des objets pré-sérialisés.
- Python .pkl fichiers modèles dans les workflows d'apprentissage automatique.
- Objets de configuration sérialisés intégrés dans des images Docker ou des conteneurs de déploiement

Dispositifs d'essai telles que:
- Anciennes données de test sérialisées copiées à partir d'instantanés de production.
- Charges utiles sérialisées téléchargées à partir de référentiels externes pour des tests de performances ou de régression.

Ces fichiers peuvent être introduits dans un référentiel et chargés automatiquement lors de tests ou de déploiements, déclenchant ainsi des actions non sécurisées. désérialisation in CI/CD pipelines avant même que le code n'atteigne la production.

De la désérialisation non sécurisée à l'exécution de code à distance : le chemin d'attaque

La chaîne d’exploitation pour la désérialisation non sécurisée suit souvent l’un de ces modèles :

Une entrée non fiable entre dans l'application.
La désérialisation non sécurisée recrée des objets sans restrictions.
Une chaîne de gadgets déclenche des fonctionnalités existantes de manière inattendue.
L'attaquant élève ses privilèges et parvient à exécuter du code à distance.

Variantes:

Les chaînes de gadgets Java exploitent d’anciennes bibliothèques comme Apache Commons.
Python .pkl chargement de modèle avec des objets malveillants intégrés.
Analyse JSON Node.js avec eval () ou des importations dynamiques.

Couler:

Untrusted Input → Deserialization → Gadget Chain → Remote Code Execution

Comment repérer une désérialisation non sécurisée avant la fusion

Détecter une désérialisation non sécurisée avant la fusion du code est bien moins coûteux que de la corriger après le déploiement. Une combinaison d'analyse automatisée et de tests proactifs est la plus efficace :

Tests de sécurité des applications statiques (SAST):
- Configurer les scanners pour détecter les API à risque comme ObjetInputStream, pickle.load et YAML.load sans chargeur sécurisé.
- Analysez à la fois le code source et les artefacts de build/test pour détecter les éléments non sécurisés désérialisation modèles
- Afficher les résultats directement dans pull requests afin que les développeurs puissent les résoudre avant la fusion.
CI/CD Intégration ::

Exemple de flux de travail :

sql

Commit → SAST scan → PR alert → Fix before merge

Les blocs fusionnent sur les résultats de désérialisation critiques non sécurisées pour empêcher le code non sécurisé d'atteindre les branches de production.

Tests unitaires avec des entrées malveillantes simulées:
- Créer charges utiles inoffensives et contrôlées qui imitent les objets d'attaque sérialisés courants.
- Testez la manière dont l'application les gère ; elle doit rejeter, assainir ou enregistrer l'entrée au lieu de la traiter aveuglément.
- Inclure ces tests dans l'automatisation pipeline ils s'exécutent donc sur chaque PR, détectant très tôt les comportements de désérialisation dangereux.
- Assurez-vous que les charges utiles de test ne sont pas exécutables et peuvent être stockées en toute sécurité dans le référentiel, en vous concentrant uniquement sur la logique de détection.

Cette approche en couches combine une analyse automatisée avec des tests appartenant aux développeurs, garantissant que les chemins de désérialisation non sécurisés sont identifiés et supprimés bien avant qu'ils ne puissent devenir des vulnérabilités d'exécution de code à distance.

Stratégies de prévention pour les développeurs : empêcher la désérialisation de se transformer en exécution de code à distance

Limites de confiance:Désérialisez uniquement à partir de sources authentifiées et vérifiées.
API sécurisées:
- Java : Bibliothèques sécurisées avec validation.
- Python : Utilisation json.loads() plus de pickle.loads() lorsque c'est possible.
- Node.js : à éviter eval () ou l'exécution de code dynamique.
Listes autorisées et schémas: Restreindre les types d'objets autorisés. Appliquer les schémas JSON.
Hygiène de la dépendance: Surveillez les CVE mentionnant la désérialisation ou l'exécution de code à distance.
Revues de code: Ajouter désérialisation contrôles de sécurité pour les modèles d'examen des relations publiques.

Note sur l'outillage : Des outils comme Xygéni analyser le code et les dépendances pour détecter toute désérialisation non sécurisée avant la fusion, en identifiant les zones à haut risque afin que les développeurs puissent les corriger rapidement.

Exemples de modèles de détection dans différentes langues (Pseudo-code sécurisé)

Tous les exemples ci-dessous sont des pseudo-codes nettoyés montrant des modèles de détection et non des exploits fonctionnels :

Java – Détection d'une utilisation non sécurisée des API:

java
// BAD: Accepting untrusted input without validation
ObjectInputStream in = new ObjectInputStream(userInputStream);
Object obj = in.readObject(); // Unsafe - no class type checks

// GOOD: Validate allowed classes before processing
if (allowedClasses.contains(obj.getClass().getName())) {
    process(obj); // Safe processing of approved classes
}

Python – Éviter la désérialisation dangereuse:

python
import pickle

# BAD: Loading untrusted serialized data directly
data = pickle.loads(untrusted_input)  # Unsafe - arbitrary object execution risk

# GOOD: Use JSON with schema validation
import json
data = json.loads(untrusted_input)  # Safe when validated against schema

Node.js – Empêcher l'exécution de code dynamique:

javascript
// BAD: Executing code from parsed data
let obj = JSON.parse(untrustedInput);
eval(obj.code); // Unsafe - allows arbitrary code execution

// GOOD: Use fixed logic without dynamic execution
let safeObj = JSON.parse(untrustedInput);
process(safeObj); // Handle only expected properties and values

Automatisation de la détection dans DevSecOps Pipelines : Détecter la désérialisation avant qu'elle n'atteigne la production

L'automatisation de la détection de désérialisation non sécurisée garantit les vulnérabilités sont détectées et corrigées avant qu'ils ne conduisent à l'exécution de code à distance en production.

Pipeline Balayage

Courir SAST sur le code source, les fichiers de configuration et les artefacts de construction à chaque commit.
Détecter les modèles de désérialisation non sécurisés dans le code d'application et dépendances.

Inspection des artefacts

Scanner .ser, .pkl, et d'autres fichiers sérialisés pour les modèles non sécurisés avant de déployer ou même d'exécuter des tests.

Pull Request Blocage

Les blocs sont fusionnés si une désérialisation non sécurisée est détectée.
Affichez des commentaires exploitables dans les PR pour accélérer la correction.

Application des tests unitaires

Inclure des tests unitaires avec des entrées malveillantes simulées dans le CI/CD pipeline
Les builds échouent si l'application traite des données sérialisées non sécurisées au lieu de les rejeter.

Éviter les faux positifs sans affaiblir les règles

Ne désactivez pas les règles de détection pour « faire taire » les alertes ; cela peut permettre à une désérialisation non sécurisée réelle de passer inaperçue.
Utilisez une liste blanche contrôlée (liste blanche) pour les modèles ou dépendances sûrs connus.
Exiger une validation de sécurité avant d’approuver les entrées de la liste blanche.
Conservez la liste blanche sous contrôle de version et révisez-la périodiquement pour vous assurer que toutes les exceptions restent justifiées et sûres.

Le rôle de Xygeni

S'intègre directement dans CI/CD pipelines pour analyser à la fois le code source et les artefacts de construction.
Détecte les modèles de désérialisation non sécurisés et les dépendances risquées au début du cycle de vie.
Prend en charge la liste blanche basée sur des politiques avec un examen de sécurité obligatoire, équilibrant la précision de la détection avec la productivité des développeurs.

Garder une longueur d'avance sur l'exécution de code à distance grâce à la désérialisation sécurisée

Une désérialisation non sécurisée peut passer inaperçue jusqu'à ce qu'elle devienne un chemin direct vers l'exécution de code à distance. Pour l'empêcher, il faut :

Comprendre ce qu’est la désérialisation et comment elle peut être abusée.
Intégration de la détection automatisée dans le flux de travail de développement.
Révision régulière des dépendances, des artefacts de build et des données sérialisées utilisées dans les tests.

Rôle pratique de Xygeni dans ce processus:

Analyse du code source: Identifie les modèles de désérialisation non sécurisés dans plusieurs langages avant la fusion du code.
Analyse des artefacts et des dépendances: Détecte les fichiers sérialisés à risque (.ser, .pkl, configuration intégrée) et des composants tiers présentant des vulnérabilités connues.
Contrôles basés sur des politiques: Prend en charge une liste d'autorisation contrôlée avec validation de sécurité, garantissant que les exceptions nécessaires n'introduisent pas de risques réels.
Commentaires des développeurs en contexte: Indique l'emplacement exact et la cause de la désérialisation non sécurisée à l'intérieur pull requests, permettant aux développeurs de résoudre les problèmes immédiatement et de confirmer l'atténuation par le biais de nouvelles analyses.

En intégrant des contrôles comme ceux-ci directement dans CI/CD, les équipes peuvent détecter et corriger les problèmes non sécurisés désérialisation avant qu'elle n'ait la possibilité de dégénérer en exécution de code à distance en production.

Comment la désérialisation non sécurisée devient une exécution de code à distance (et comment la détecter avant la fusion)

Table des Matières

Articles à lire absolument

Derniers articles d'intérêt