Analyse de vulnérabilité de désérialisation ThinkPHP6.0.13

J'ai été un peu inactif ces derniers temps, et je me sens mal à l'aise si je ne trouve pas quelque chose à faire. J'ai l'intention de trouver des failles à analyser, j'ai donc l'intention de jeter un œil à quelques failles dans TP ThinkPHP6.0.13. la dernière version de TP. En août, un maître a soumis un problème pour souligner que TP a un problème de désérialisation. Certains experts sur Internet l'ont analysé, mais il existe de nombreux points d'arrêt et certaines méthodes ne clarifient pas leurs utilisations, donc je le fais aussi. essayé de l'analyser en détail. Donnons d'abord l'analyse POC

Premier coup d'œil au point de départ du POC

et avons constaté que le point de départ est dans la classe Psr6Cache. , mais aucun __destruct n'a été trouvé. Ou des méthodes magiques de démarrage de désérialisation courantes telles que __wakeup, il est supposé qu'elles devraient être dans la classe abstraite de sa classe parent AbstractCache. En suivant la classe AbstractCache

comme le montre la figure, nous avons réussi à trouver la classe de départ de cette chaîne de désérialisation. Ici, nous pouvons contrôler l'attribut de sauvegarde automatique sur false pour entrer dans la méthode de sauvegarde.

Retournez à la classe Psr6Cache pour voir cette méthode

Vous pouvez constater que nous pouvons contrôler à la fois l'attribut pool et l'attribut clé. Par conséquent, il peut y avoir deux routes pour appeler des méthodes portant le même nom (getItem) de classes différentes. Ou essayez de déclencher directement la méthode __call. Jetons un coup d'œil à la façon dont l'auteur du POC autorise la désérialisation.

L'auteur a transmis exp en utilisant la méthode constructeur, et exp instancie en fait la classe Channel. Allons dans la classe Channel pour voir

Il existe une méthode __call dans la classe Channel, donc l'auteur choisit de déclencher __call pour continuer la chaîne. Cette méthode d'appel accepte deux paramètres. La méthode est codée en dur (getItem) et les paramètres sont contrôlables (c'est-à-dire les attributs clés précédemment contrôlables). Suivez la méthode log pour l'afficher (mais c'est en fait le cas). inutile pour les chaînes suivantes), passez la méthode d'enregistrement

suivie de la méthode d'enregistrement

puis revenez vérifier le POC de l'auteur et constatez que son attribut de contrôle paresseux est faux, laissez la fonction entrer dans le enfin si Branch exécute la méthode de sauvegarde

Alors la méthode de sauvegarde devrait être une méthode plus critique Après la méthode de sauvegarde, il y a trois points qui peuvent être exploités. Lequel l'auteur a-t-il choisi ?

Selon le POC, il n'est pas difficile de constater que l'auteur a choisi de contrôler l'attribut logger, d'utiliser le constructeur pour lui attribuer une valeur et d'en faire un objet de la classe Socket

Dans cette classe, nous avons trouvé une méthode A complexe du même nom, qui contient un grand nombre d'opérations.

Continuons à voir comment l'auteur le construit. L'auteur contrôle l'attribut config et lui attribue une valeur de tableau. Le tableau a le contenu suivant

La clé réside dans ces deux valeurs clés. L'auteur contrôle la configuration et laisse le programme s'exécuter vers la branche qui appelle la méthode d'invocation

En même temps, l'application L'attribut est contrôlable. L'auteur crée l'attribut app de la classe App Object, nous entrons dans la classe App

Ici, nous regardons d'abord la méthode exist de la classe App, et nous avons trouvé cette méthode dans sa classe parent

En continuant, voici la seule opération effectuée sur la classe App, qui contrôle la valeur de l'attribut instances. Le but de contrôler sa valeur ici est d'entrer dans la classe Request et d'exécuter la méthode url

La seule manipulation que l'auteur fait sur la classe Request ici est de contrôler la valeur de l'attribut url. On peut voir que si l'attribut url existe, alors la première branche sera saisie et sa valeur est égale à elle-même.

En même temps, nous avons remarqué que la valeur complète que nous avions transmise auparavant était vraie. Par conséquent, le résultat final renvoyé est $this->domain().$url. Nous avons contrôlé l’URL, alors que renvoie la méthode de domaine ?

OK, nous n'avons pas besoin de regarder ça. Après avoir analysé autant de choses, nous avons obtenu la valeur finale de $currentUri, qui est :

http://localhost/

currentUri est transmise à l'invocation sous forme de tableau en fonction de la longueur de la chaîne, lorsqu'elle atteint. Invoquer, notre réaction Le voyage de sérialisation est presque terminé

Regardez Invoquer, la classe App ne trouve pas cette méthode et a trouvé cette méthode dans sa classe parent

Vous pouvez la voir ici. Il y a trois branches dans cette fonction, alors où ira-t-elle finalement ? D'après ce que nous avons passé dans $config['format_head'] auparavant, tout d'abord, l'objet que nous avons transmis n'est pas une instance ou une sous-classe de Closure, et il ne remplit pas les conditions de la deuxième branche

, nous entrons donc dans les troisièmes branches. Nous poursuivons avec la méthode InvokeMethod(). Le $callabel transmis ici est [new thinkviewdriverPhp,'display'], et $vars est ['http://localhost/']

Notez que la méthode $ que nous avons transmise est un tableau, alors entrez le premières branches. Attribuez le nouveau thinkviewdriverPhp (c'est-à-dire l'objet) à $class et « display » (c'est-à-dire le nom de la méthode) au nouveau $method.

Ensuite, un jugement est fait ci-dessous. Si $class est un objet, alors sa valeur est elle-même. Parce que nous transmettons un objet, il n'y a aucun changement ici. Entrez ensuite le code le plus critique

Vous pouvez voir que l'objet new thinkviewdriverPhp et l'affichage de la méthode sont transmis à ReflectionMethod.

À la fin, appelez la méthode InvokeArgs, en passant le nouvel objet thinkviewdriverPhp, et en passant également $args

Alors, que sont les arguments ?

Après l'avoir suivi, nous avons découvert qu'il s'agissait d'une fonction de traitement. Parce que je suis paresseux et que j'ai presque terminé l'analyse à ce stade, je ne vais pas le lire attentivement et donner la conclusion directement. vars que nous avons transmis, c'est-à-dire [ 'http://localhost/'] Les éléments clés sont conservés et entrés dans le transfert de paramètres ultérieur

Continuez à regarder en arrière Pour cette fonction (invokeArgs), cela peut être. simplement analogique à call_user_func(), Par conséquent, le dernier code clé n'est en fait que ces deux lignes

, qui est

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

Les amis qui regardent souvent la désérialisation tp sauront que c'est terminé ! Après tout, la méthode d'affichage est appelée. Mais quelle est exactement l’opération ci-dessus consistant à appeler la classe ReflectionMethod ? Nous pouvons le démontrer à l’aide de l’exemple suivant. Donc cette chose est très similaire à call_user_func

Enfin, il y a la méthode d'affichage Il n'y a rien à dire Le contenu est passé dans la méthode d'affichage, et eval exécute la commande

Conclusion.

La chaîne de TP est toujours aussi intéressante (et compliquée), en particulier l'utilisation de la dernière classe ReflectionMethod. Si vous ne comprenez pas cette classe et que la combinaison de méthodes dans la classe peut obtenir des fonctions similaires à la fonction call_user_func, alors c'est le cas. facile de rater un événement aussi merveilleux.

【Recommandation de tutoriel connexe : thinkphp framework】

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!