Exemple d'analyse des événements de traçabilité téléchargés par WebShell

Inspection et mise à mort

Tout d'abord, je comprends que ce que je dois faire n'est pas de trouver où apparaît l'emplacement téléchargé, je dois me connecter au serveur pour effectuer une inspection WebShel. , effectuez une inspection et trouvez Vérifiez s'il a été envahi par d'autres, s'il y a une porte dérobée, etc. Bien que l'adresse IP signalée soit l'adresse IP de notre entreprise, si quelques webshells sont manqués et téléchargés avec succès par d'autres mais ne sont pas détectés, que pouvons-nous faire si le serveur est envahi ? Je suis donc allé inspecter le serveur, j'ai téléchargé cet outil de suppression de webshell, j'ai utilisé netstat -anpt et iptables -L pour déterminer si une porte dérobée avait été établie, j'ai vérifié s'il y avait un programme minier occupant le processeur, etc., je vais n'entre pas dans les détails ici. Heureusement, le serveur n’a pas été compromis et j’ai commencé à réfléchir à ce qui était arrivé à ce point de téléchargement.

File Upload Vulnerability Review

Tout d'abord, j'ai demandé au développeur qui m'a contacté l'adresse de ce serveur ouvert au public. Je l'ai ouvert et j'ai trouvé qu'il me semblait familier. L'avez-vous testé vous-même il n'y a pas longtemps ? À ce moment-là, je me suis senti un peu confus et j'ai confronté le développeur au sujet des informations de rectification. Après le dernier test, j'ai découvert que le lieu de téléchargement utilisait une restriction de liste blanche, qui autorisait uniquement le téléchargement de formats d'image jpeg, png et autres. À ce moment-là, j'ai également découvert que même si le téléchargement était limité par une liste blanche, un nombre aléatoire était ajouté au nom du fichier téléchargé et que les règles de temps correspondaient, j'ai toujours trouvé le chemin de téléchargement et le nom du fichier dans le package de retour. et autres Il a été suggéré d'effectuer une rectification, sinon cela entraînerait des vulnérabilités dans le fichier. Il m'a signalé que la rectification avait bien été effectuée et que le chemin n'était plus renvoyé.

Contournement de l'encodage des suffixes de fichiers

Après avoir discuté et examiné les problèmes de la dernière rectification, j'ai clarifié ma réflexion. Ensuite, je me suis connecté au site Web pour vérifier la raison. Comme le site Web n'a qu'un seul endroit pour télécharger des images, j'ai essayé de capturer le paquet. Après avoir utilisé le répéteur pour relire le package, j'ai constaté que le package renvoyé ne renvoyait pas le téléchargement de fichier. chemin. Ensuite, j'ai essayé divers détours mais le résultat n'est pas bon. En fin de compte, je n'ai pu obtenir aucun résultat après mûre réflexion, puis j'ai demandé à la plate-forme cloud quelle était la raison de l'alarme qui leur avait été fournie. Après avoir lu les résultats des commentaires de la plate-forme cloud, j'ai découvert qu'il y avait un code d'image. Ce n'est pas un gros problème. Le fichier téléchargé n'a pas d'autorisation d'exécution et le chemin du fichier n'est pas renvoyé. Le nom du fichier a été modifié de manière aléatoire. mais pourquoi cette jsp est-elle téléchargée avec succès ? D'accord, cela me rend perplexe.

Quand j'ai examiné attentivement les données webshel ​​​​fournies par la plateforme cloud, j'ai soigneusement observé que le nom du fichier utilise le codage base64. J'étais très confus à ce sujet. Pourquoi dois-je l'encoder quand. J'ai déjà fait une fonction aléatoire ? Il n'y a pas eu de codage lors du dernier test. J'ai soudainement pensé à la clé du problème, puis j'ai utilisé le module de décodage de burpsuite pour encoder en base64 le nom de fichier "1.jsp" en "MS5Kc1A=", puis j'ai envoyé un code d'état de retour réussi de 200, au lieu de ce téléchargement. Code d'état de retour d'échec de 500 erreur.

Donc, le problème est que pendant le processus de rectification, les développeurs ont utilisé l'encodage base64 pour le nom du fichier, ce qui a provoqué le décodage du nom du fichier en base64 pendant le processus de stockage, et lorsque j'ai téléchargé le fichier , je l'ai décodé en base64. Le nom du suffixe .jsp est également codé en base64, et .jsp est également décodé avec succès pendant le processus de stockage. La R&D n'impose pas de restrictions de liste blanche après le décodage. En fait, ce type de changement de codage est inutile. Après tout, le nombre aléatoire a été utilisé pour changer le nom du fichier. C'est pourquoi la modification d'un bug de programme provoque davantage de bugs.

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!