Wie oben gezeigt, gibt der Code einen Fehler „Ausnahme im Thread „Haupt“ Java.lang.Classcastexception-Fehler: testserialization.ExploitDeser kann nicht in Testserialisierung umgewandelt werden.Employee “ was bedeutet, dass das Typ-Casting nicht korrekt ist, der Code jedoch immer noch ausgeführt wird. Die readObject-Funktion der DeserializeDemo-Klasse kann die benutzerdefinierte Implementierung des readObject der ExploitDeser-Klasse ausführen.,
Dies ist, was hier die unsichere Deserialisierung ist, dass, obwohl es immer noch einen Typ-Casting-Fehler gibt, wenn serialisierte Daten einer benutzerdefinierten Klasse mit einer benutzerdefinierten Implementierung von readObject als Eingabe bereitgestellt werden, wie oben gezeigt ausgeführt wird.
Dies geschieht durch die Gadget-Ketten, die von ysoserial und anderen Java-Deserialisierungs-Exploitationstools verwendet werden, wo sie nach Verkettung von Klassen suchen, um schließlich in eine benutzerdefinierte Implementierung von readObject zu gelangen, die Code auf Systemebene ausführen kann, der als Teil der Benutzereingabe bereitgestellt wird.,
Sanierung
Nun, da wir uns angesehen haben, was Deserialisierung ist und wie sie ausgenutzt wird, schauen wir uns die Sanierung an.
Die Sanierung, die wir hier besprechen werden, heißt „Look-ahead class validation“, in der wir die Liste der Klassen, die deserialisiert werden sollen, auf die Whitelist setzen können. Beispielsweise. in unserem Szenario würden wir erwarten, dass nur Objektdaten der Mitarbeiterklasse deserialisiert werden, und für den Rest sollte die Deserialisierung nicht zulässig sein.,
Im Grunde überschreibt diese Methode die Funktion „resolveClass“, die Teil der Klasse“ObjectInputStream“ (die während der Deserialisierung verwendet wird) ist, und führt eine weiße Liste der Liste der Klassen aus, die deserialisiert werden müssen.
Nun, da wir mit der Theorie fertig sind, können wir zur Implementierung springen.,
Lässt eine neue Klasse erstellen „LookAheadObjectInputStream“ erweitern Sie es auf ObjectInputSteam Klasse, so dass wir die Member-Funktion resolveClass überschreiben können:
Im obigen Code die Zeile:
if (!desc.getName().equals(Employee.class.getName())) {
sucht im Grunde, ob serialisierter Inhalt Objekt der Employee-Klasse enthält sonst bietet es Fehler“ Unautorisierter Deserialisierungsversuch “ und verhindert dessen Ausführung.,
Der zuletzt geänderte Code für „DeserializedDemo“ ist nun wie folgt dargestellt:
Beachten Sie im obigen Code den hervorgehobenen Code, in dem anstelle des Aufrufs der ObjectInputStream-Klasse die LookAheadObjectInputStream-Klasse aufgerufen wird, die die resolveClass-Methode zur Laufzeit überschreibt und entsprechend ausführt.
Nun, lasst uns die böswillige übergeben.,ser-Datei, die zuvor als Eingabe für die Deserialisierung erstellt wurde, und beachten Sie die Ausgabe:
Wie oben zu sehen ist, wird diesmal die benutzerdefinierte Implementierung von readObject aus der benutzerdefinierten Klasse „ExploitDeser“ während der Deserialisierung nicht ausgeführt., Stattdessen erhalten wir die benutzerdefinierte Fehlermeldung „Nicht autorisierter Deserialisierungsversuch“, die in der überschriebenen resolveClass-Funktion unter der LookAheadObjectInputStream-Klasse festgelegt wurde.
Dies ist ein sehr einfaches Beispiel für die Verwendung der Look-Ahead-Klassenvalidierungsmethode, um eine unsichere Deserialisierung zu verhindern. Eine umfangreiche Implementierung um diese Idee herum ist die“ serialKiller “ – Bibliothek. Link kann unten gefunden werden:
Daher kann dies als eine der Lösungen angesehen werden, um unsichere Deserialisierung in Java zu mildern.,
Ich suche immer noch nach anderen Methoden der Milderung, über die ich später bloggen werde.
Bitte geben Sie Ihr wertvolles Feedback. Bis dahin weiter hacken und lernen….
