Unsichere Deserialisierung = Remote Code Execution

Das Commit Das öffnete eine Hintertür

Eine neue Funktion zur Verarbeitung von benutzerhochgeladenen Objekten wurde integriert. Alle Tests werden erfolgreich abgeschlossen, doch Wochen später zeigt ein Penetrationstest, dass Angreifer Befehle auf dem Server ausführen können. Dies ist das Ergebnis einer unsicheren Deserialisierung, die im Code verborgen ist. Der Abstand zwischen Deserialisierung und Remote-Codeausführung kann gefährlich gering sein, insbesondere wenn serialisierten Daten aus Open-Source-Paketen oder internen Diensten ohne Validierung vertraut wird.

Was ist Deserialisierung im Code, warum ist sie riskant und wo verbirgt sie sich?

Was ist Deserialisierung in Entwicklersprache? Es handelt sich um den Prozess, strukturierte Daten, JSON, XML, Binärformate oder sprachspezifische serialisierte Objekte zu übernehmen und sie wieder in Objekte im Speicher umzuwandeln.

Allein, Deserialisierung ist harmlos und häufig, zum Beispiel:

Javac: Lesen von Objekten mit ObjectInputStream
Python: Laden von Daten mit pickle.load
Node.js: JSON parsen mit JSON.parse

Das Risiko entsteht, wenn die Deserialisierung ohne Validierung auf nicht vertrauenswürdige Daten angewendet wird. Ein Angreifer kann Eingaben erstellen, die eine Gadget-Kette auslösen, vorhandene Codepfade auf unbeabsichtigte Weise verwenden und so zur Remotecodeausführung führen.

Unsicher Deserialisierung wird häufig gefunden in:

Open Source-Pakete mit unsicheren Standardeinstellungen
Benutzerdefinierter Code das setzt voraus, dass serialisierte Eingaben vertrauenswürdig sind
APIs von Drittanbietern geben serialisierte Objekte ohne Überprüfung zurück
Artefakte erstellen Felsen der Yoga-Therapie:
- Javac .ser Dateien, die vorserialisierte Objekte enthalten.
- Python .pkl Modelldateien in Machine-Learning-Workflows.
- Serialisierte Konfigurationsobjekte, eingebettet in Docker-Images oder Bereitstellungscontainer

Prüfvorrichtungen Felsen der Yoga-Therapie:
- Alte serialisierte Testdaten, die aus Produktions-Snapshots kopiert wurden.
- Serialisierte Nutzdaten, die für Leistungs- oder Regressionstests aus externen Repositories heruntergeladen wurden.

Diese Dateien können in ein Repository eingefügt und während Tests oder Bereitstellungen automatisch geladen werden, was zu unsicheren Deserialisierung in CI/CD pipelines, bevor der Code überhaupt die Produktion erreicht.

Von der unsicheren Deserialisierung zur Remotecodeausführung: Der Angriffspfad

Die Ausnutzungskette für unsichere Deserialisierung folgt häufig einem dieser Muster:

Nicht vertrauenswürdige Eingaben gelangen in die Anwendung.
Durch unsichere Deserialisierung werden Objekte ohne Einschränkungen neu erstellt.
Eine Gadget-Kette löst vorhandene Funktionen auf unbeabsichtigte Weise aus.
Der Angreifer erweitert seine Berechtigungen und erreicht eine Remotecodeausführung.

Varianten:

Java-Gadget-Ketten nutzen alte Bibliotheken wie Apache Commons.
Python .pkl Laden von Modellen mit eingebetteten schädlichen Objekten.
Node.js JSON-Parsing mit eval () oder dynamische Importe.

Fließen:

Untrusted Input → Deserialization → Gadget Chain → Remote Code Execution

So erkennen Sie unsichere Deserialisierung vor dem Zusammenführen

Das Erkennen unsicherer Deserialisierungen vor dem Zusammenführen von Code ist deutlich günstiger als die Behebung nach der Bereitstellung. Eine Kombination aus automatisierter Analyse und proaktivem Testen funktioniert am besten:

Statische Anwendungssicherheitstests (SAST):
- Konfigurieren Sie Scanner, um riskante APIs zu erkennen, wie ObjectInputStream, pickle.load und YAML.load ohne sicheren Lader.
- Scannen Sie sowohl den Quellcode als auch die Build-/Test-Artefakte auf unsichere Deserialisierung Muster.
- Ergebnisse direkt anzeigen in pull requests damit Entwickler sie vor dem Zusammenführen beheben können.
CI/CD Integration:

Beispiel-Workflow:

sql

Commit → SAST scan → PR alert → Fix before merge

Blockieren Sie Zusammenführungen bei kritischen, unsicheren Deserialisierungsergebnissen, um zu verhindern, dass unsicherer Code Produktionszweige erreicht.

Unit-Tests mit simulierten bösartigen Eingaben:
- Erschaffung harmlose, kontrollierte Nutzlasten die gängige serialisierte Angriffsobjekte nachahmen.
- Testen Sie, wie die Anwendung damit umgeht. Sie sollte die Eingabe ablehnen, bereinigen oder protokollieren, anstatt sie blind zu verarbeiten.
- Integrieren Sie diese Tests in die automatisierte pipeline Sie werden also bei jedem PR ausgeführt und erkennen unsicheres Deserialisierungsverhalten frühzeitig.
- Stellen Sie sicher, dass die Testnutzdaten nicht ausführbar sind und sicher im Repository gespeichert werden können, und konzentrieren Sie sich ausschließlich auf die Erkennungslogik.

Dieser mehrschichtige Ansatz kombiniert automatisiertes Scannen mit entwicklereigenen Tests und stellt so sicher, dass unsichere Deserialisierungspfade identifiziert und entfernt werden, lange bevor sie zu Sicherheitslücken bei der Remotecodeausführung werden können.

Präventionsstrategien für Entwickler: Verhindern, dass Deserialisierung zur Remotecodeausführung wird

Vertrauensgrenzen: Deserialisieren Sie nur aus authentifizierten, verifizierten Quellen.
Sichere APIs:
- Java: Sichere Bibliotheken mit Validierung.
- Python: Verwenden json.loads() gegenüber pickle.loads() wo möglich.
- Node.js: Vermeiden eval () oder dynamische Codeausführung.
Zulassungslisten und Schemata: Zulässige Objekttypen einschränken. JSON-Schemas erzwingen.
Abhängigkeitshygiene: Überwachen Sie CVEs, die Deserialisierung oder Remotecodeausführung erwähnen.
Code-Bewertungen: Hinzufügen Deserialisierung Sicherheitsüberprüfungen für PR-Überprüfungsvorlagen.

Werkzeughinweis: Werkzeuge wie Xygeni Scannen Sie Code und Abhängigkeiten vor dem Zusammenführen auf unsichere Deserialisierung und identifizieren Sie Hochrisikobereiche, damit Entwickler diese frühzeitig beheben können.

Beispiele für Erkennungsmuster in verschiedenen Sprachen (Sicherer Pseudocode)

Bei allen folgenden Beispielen handelt es sich um bereinigten Pseudocode, der Erkennungsmuster zeigt, nicht um funktionierende Exploits:

Java – Erkennen einer unsicheren API-Nutzung:

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 – Vermeidung unsicherer Deserialisierung:

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 – Dynamische Codeausführung verhindern:

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

Automatisierte Erkennung in DevSecOps Pipelines: Deserialisierung abfangen, bevor sie die Produktion erreicht

Die Automatisierung der Erkennung unsicherer Deserialisierung gewährleistet Schwachstellen werden erkannt und behoben bevor sie zur Remotecodeausführung in der Produktion führen.

Pipeline Scannen

Führen Sie SAST auf Quellcode, Konfigurationsdateien und Build-Artefakte bei jedem commit.
Erkennen Sie unsichere Deserialisierungsmuster sowohl im Anwendungscode als auch Abhängigkeiten.

Artefaktinspektion

Scannen .ser, .pkl, und andere serialisierte Dateien auf unsichere Muster, bevor Sie Tests bereitstellen oder sogar ausführen.

Pull Request Blockierung

Blockzusammenführungen, wenn eine unsichere Deserialisierung erkannt wird.
Zeigen Sie in PRs umsetzbares Feedback, um die Behebung zu beschleunigen.

Durchsetzung von Unit-Tests

Integrieren Sie Unit-Tests mit simulierten bösartigen Eingaben in die CI/CD pipeline
Builds schlagen fehl, wenn die Anwendung unsichere serialisierte Daten verarbeitet, anstatt sie abzulehnen.

Vermeidung falscher Positivmeldungen ohne Schwächung der Regeln

Deaktivieren Sie keine Erkennungsregeln, um Warnungen „stummzuschalten“. Dies kann dazu führen, dass eine wirklich unsichere Deserialisierung unentdeckt bleibt.
Verwenden Sie eine kontrollierte Whitelist (Zulassungsliste) für bekannte sichere Muster oder Abhängigkeiten.
Erfordern Sie eine Sicherheitsüberprüfung, bevor Sie Whitelist-Einträge genehmigen.
Behalten Sie die Versionskontrolle für die Whitelist und überprüfen Sie sie regelmäßig, um sicherzustellen, dass alle Ausnahmen gerechtfertigt und sicher bleiben.

Xygenis Rolle

Integriert sich direkt in CI/CD pipelines zum Scannen von Quellcode und zum Erstellen von Artefakten.
Erkennt unsichere Deserialisierungsmuster und riskante Abhängigkeiten frühzeitig im Lebenszyklus.
Unterstützt richtlinienbasierte Whitelists mit obligatorischer Sicherheitsüberprüfung und sorgt so für ein Gleichgewicht zwischen Erkennungsgenauigkeit und Entwicklerproduktivität.

Der Remotecodeausführung durch sichere Deserialisierung immer einen Schritt voraus

Unsichere Deserialisierung kann unbemerkt bleiben, bis sie zu einem direkten Weg zur Remotecodeausführung wird. Um dies zu verhindern, sind folgende Schritte erforderlich:

Verstehen, was Deserialisierung ist und wie sie missbraucht werden kann.
Einbettung der automatisierten Erkennung in den Entwicklungsworkflow.
Regelmäßige Überprüfung von Abhängigkeiten, Build-Artefakten und serialisierten Daten, die in Tests verwendet werden.

Praktische Rolle von Xygeni in diesem Prozess:

Quellcode-Scan: Identifiziert unsichere Deserialisierungsmuster über mehrere Sprachen hinweg, bevor der Code zusammengeführt wird.
Artefakt- und Abhängigkeitsanalyse: Erkennt riskante serialisierte Dateien (.ser, .pkl, eingebettete Konfiguration) und Komponenten von Drittanbietern mit bekannten Schwachstellen.
Richtlinienbasierte Kontrollen: Unterstützt eine kontrollierte Zulassungsliste mit Sicherheitsvalidierung und stellt sicher, dass notwendige Ausnahmen keine echten Risiken mit sich bringen.
Entwickler-Feedback im Kontext: Kennzeichnet den genauen Ort und die Ursache der unsicheren Deserialisierung im Inneren pull requests, sodass Entwickler Probleme sofort beheben und die Schadensbegrenzung durch erneute Scans bestätigen können.

Durch die Integration solcher Prüfungen direkt in CI/CDkönnen Teams unsichere Deserialisierung, bevor es überhaupt zu einer Remotecodeausführung in der Produktion kommen kann.

Wie aus unsicherer Deserialisierung eine Remotecodeausführung wird (und wie man sie vor dem Zusammenführen abfängt)

Inhaltsverzeichnis

Must-Read-Beiträge

Neueste interessante Beiträge