ThinkPHP6.0.13 Deserialisierungs-Schwachstellenanalyse

Ich war in letzter Zeit etwas untätig und fühle mich unwohl, wenn ich nichts zu tun finde. Ich habe vor, einige Lücken in TP zu analysieren Im August hat ein Master ein Problem eingereicht, um darauf hinzuweisen, dass TP ein Deserialisierungsproblem hat, aber es gibt viele Haltepunkte und einige Methoden klären ihre Verwendung nicht habe versucht, es im Detail zu analysieren. Geben wir zuerst den POC

Analyse

Erster Blick auf den Ausgangspunkt des POC

Ich habe festgestellt, dass der Ausgangspunkt in der Psr6Cache-Klasse liegt. Wir sind in diese Klasse eingetreten , aber es wurde kein __destruct oder übliche magische Deserialisierungsmethoden wie __wakeup gefunden. Es wird spekuliert, dass sie sich in der abstrakten Klasse der übergeordneten Klasse AbstractCache befinden sollten. Nach der AbstractCache-Klasse

, wie in der Abbildung gezeigt, haben wir erfolgreich die Startklasse dieser Deserialisierungskette gefunden. Hier können wir das Autosave-Attribut auf „false“ setzen, um die Speichermethode aufzurufen.

Gehen Sie zurück zur Psr6Cache-Klasse, um diese Methode anzuzeigen

Sie können feststellen, dass wir sowohl das Pool-Attribut als auch das Schlüsselattribut steuern können. Daher gibt es möglicherweise zwei Routen zum Aufrufen von Methoden mit demselben Namen (getItem) verschiedener Klassen. Oder versuchen Sie, die __call-Methode direkt auszulösen. Schauen wir uns an, wie der POC-Autor den Ablauf der Deserialisierung zulässt.

Der Autor hat exp mithilfe der Konstruktormethode übergeben, und exp instanziiert tatsächlich die Channel-Klasse. Gehen wir in die Channel-Klasse, um zu sehen,

Es gibt eine __call-Methode in der Channel-Klasse, daher entscheidet sich der Autor dafür, __call auszulösen, um die Kette fortzusetzen. Diese Aufrufmethode akzeptiert zwei Parameter (getItem) und die Parameter sind steuerbar (das heißt, die zuvor steuerbaren Schlüsselattribute folgen der Protokollmethode, um sie anzuzeigen). unbrauchbar für nachfolgende Ketten), übergeben Sie die Aufzeichnungsmethode

, gefolgt von der Aufzeichnungsmethode

, und gehen Sie dann zurück, um den POC des Autors zu überprüfen und festzustellen, dass sein Kontrolllazy-Attribut falsch ist. Lassen Sie die Funktion das eingeben zuletzt, wenn Branch die Speichermethode ausführt

Dann sollte die Speichermethode eine kritischere Methode sein. Nach der Speichermethode können drei Punkte ausgenutzt werden.

Laut POC ist es nicht schwer herauszufinden, dass der Autor sich dafür entschieden hat, das Logger-Attribut zu steuern, ihm mithilfe des Konstruktors einen Wert zuzuweisen und es zu einem Objekt der Socket-Klasse zu machen

In dieser Klasse haben wir eine komplexe A-Methode mit demselben Namen gefunden, die eine große Anzahl von Operationen enthält.

Sehen wir uns weiterhin an, wie der Autor es erstellt. Der Autor steuert das Konfigurationsattribut und weist ihm einen Array-Wert zu. Das Array hat den folgenden Inhalt: Der Schlüssel liegt in diesen beiden Schlüsselwerten. Der Autor steuert die Konfiguration und lässt das Programm zu dem Zweig laufen, der die Aufrufmethode aufruft. Gleichzeitig wird die App ausgeführt Das Attribut ist steuerbar. Der Autor macht das App-Attribut der App-Klasse zu einem Objekt. Wir geben die App-Klasse ein

Weiterhin ist hier die einzige Operation, die für die App-Klasse ausgeführt wird und den Wert des Instanzattributs steuert. Der Zweck der Steuerung seines Werts besteht hier darin, die Request-Klasse einzugeben und die URL-Methode auszuführen

Die einzige Manipulation, die der Autor hier an der Request-Klasse vornimmt, besteht darin, den Wert des URL-Attributs zu steuern. Es ist ersichtlich, dass, wenn das URL-Attribut vorhanden ist, der erste Zweig eingegeben wird und sein Wert gleich sich selbst ist.

Gleichzeitig stellten wir fest, dass der vollständige Wert, den wir zuvor eingegeben hatten, wahr war. Daher ist das endgültige zurückgegebene Ergebnis $this->domain().$url. Wir haben die URL kontrolliert, was gibt die Domain-Methode also zurück?

OK, wir müssen uns das nicht ansehen. Nachdem wir so viel analysiert haben, haben wir den endgültigen Wert von $currentUri erhalten, der lautet:

http://localhost/

currentUri wird entsprechend der Länge der Kette beim Erreichen als Array übergeben invoke, unsere Reaktion Die Serialisierungsreise ist fast vorbei

Sehen Sie sich invoke an, die App-Klasse kann diese Methode nicht finden und hat diese Methode in ihrer übergeordneten Klasse gefunden

Sie können sie hier sehen. Es gibt drei Zweige in dieser Funktion. Wohin wird sie also letztendlich führen? Gemäß dem, was wir zuvor in $config['format_head'] übergeben haben, ist das von uns übergebene Objekt zunächst keine Instanz oder Unterklasse von Closure und erfüllt nicht die Bedingungen des zweiten Zweigs

, Also betreten wir die dritten Zweige. Anschließend verwenden wir die Methode invokeMethod(). Das hier übergebene $callabel ist [new thinkviewdriverPhp,'display'] und $vars ist ['http://localhost/']

Beachten Sie, dass die von uns übergebene $method ein Array ist, also geben Sie das ein erste Filialen. Weisen Sie der $class den neuen thinkviewdriverPhp (d. h. das Objekt) und der neuen $method „display“ (d. h. den Methodennamen) zu.

Dann wird unten ein Urteil gefällt, dann ist sein Wert selbst. Da wir ein Objekt übergeben, gibt es hier keine Änderung. Geben Sie dann den kritischsten Code ein

Sie können sehen, dass das Objekt new thinkviewdriverPhp und die Methode display an ReflectionMethod übergeben werden.

Am Ende rufen Sie die invokeArgs-Methode auf, übergeben das neue thinkviewdriverPhp-Objekt und auch $args

Was sind also Argumente?

Nachdem wir es befolgt haben, haben wir festgestellt, dass es sich um eine Verarbeitungsfunktion handelt. Da ich zu diesem Zeitpunkt faul bin und die Analyse fast abgeschlossen habe, werde ich es nicht genau lesen und die Schlussfolgerung direkt ziehen Von uns übergebene Variablen, also [ 'http://localhost/'] Die Schlüsselteile bleiben erhalten und werden in die anschließende Parameterübertragung eingegeben. Schauen Sie weiter auf diese Funktion (invokeArgs). einfach analog zu call_user_func()Daher besteht der letzte Schlüsselcode eigentlich nur aus diesen beiden Zeilen

, also

$reflect = new ReflectionMethod(new \think\view\driver\Php,’display’); return $reflect->invokeArgs(new \think\view\driver\Php,’ ’)

Freunde, die sich oft die TP-Deserialisierung ansehen, werden wissen, dass es vorbei ist! Schließlich wird die Anzeigemethode aufgerufen. Aber was genau ist der obige Vorgang zum Aufrufen der ReflectionMethod-Klasse? Wir können dies anhand des folgenden Beispiels demonstrieren. Dieses Ding ist also call_user_func sehr ähnlich. Schließlich gibt es noch die Anzeigemethode. Es gibt nichts zu sagen, und eval führt den Befehl aus

TPs Kette ist so interessant (und kompliziert) wie eh und je, insbesondere die Verwendung der letzten ReflectionMethod-Klasse. Wenn Sie diese Klasse nicht verstehen und die Kombination von Methoden in der Klasse ähnliche Funktionen wie die Funktion call_user_func erreichen kann, dann ist dies der Fall Es ist leicht, solch ein wunderbares Ereignis zu übersehen.

【Verwandte Tutorial-Empfehlung:Thinkphp Framework】

Das obige ist der detaillierte Inhalt vonThinkPHP6.0.13 Deserialisierungs-Schwachstellenanalyse. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!