Analyse des instances GetShell de décompression dangereuses découvertes grâce à la traçabilité

Récemment, alors que nous aidions un client à retracer un incident d'intrusion, nous avons découvert que le pirate informatique utilisait la « fonction de décompression ZIP » du site Web pour télécharger un Webshell avant d'accéder au serveur. Parce que cette méthode d'exploitation des fuites est relativement représentative en termes de « structure de charge utile d'attaque » et de « chemin de décompression réel », et que l'industrie n'accorde toujours pas suffisamment d'attention à la vulnérabilité de « décompression dangereuse ». Par conséquent, nous avons rédigé ce rapport, dans lequel nous expliquons le processus de traçage des intrusions et de découverte de vulnérabilités, et proposons quelques suggestions de sécurité dans les deux dimensions du développement de la sécurité et des solutions de protection des produits pour chiens de sécurité, dans l'espoir de bénéficier à l'industrie.

Il est à noter que bien que le CMS ait effectué les configurations de défense pertinentes, si vous écrivez directement le fichier JSP dans le répertoire racine du CMS, il ne sera pas exécuté et une erreur 403 sera signalée. L'attaquant a profité de la fonctionnalité de déploiement automatique du package war et a utilisé l'idée de "traversée de répertoire" pour faire sortir le package war du répertoire racine du CMS.

1. Traçabilité des intrusions

Le personnel d'exploitation et de maintenance d'une entreprise a découvert certaines anomalies dans le système alors qu'il était en service tard dans la nuit Afin d'enquêter sur le problème dans les plus brefs délais, le client a contacté notre entreprise, puis le laboratoire Haiqing. est intervenu pour effectuer la traçabilité et l’analyse et fournir des plans d’élimination ultérieurs.

En vérifiant le fichier journal Tomcat /logs/localhost_access_log.yyyy-MM-dd.txt, nous pouvons constater que l'attaquant a fait exploser l'interface de connexion du site Web ("POST /cmscp/login.do"). La fréquence d'accès de l'interface est très élevée), comme le montre la figure.

Remarque : Le code d'état HTTP lorsque l'explosion réussit est 302, et le code d'état HTTP lorsque l'explosion échoue est 303.

Afin de déterminer si l'attaquant a téléchargé un cheval de Troie de site Web, utilisez le moteur de détection Webshell AI de Website Security Dog pour analyser le répertoire webapps de Tomcat. Vous constaterez que le fichier nommé "/admin/login.jsp" est. reconnu comme Webshell (le pirate informatique l'a fait. La dénomination d'un Webshell prête quelque peu à confusion), comme le montre la figure.

Après une nouvelle confirmation manuelle, il peut être déterminé que le fichier jsp est bien un Webshell. Et cela est lié au déploiement automatique du fichier admin.war, comme le montre la figure.

Alors, comment ce package de guerre est-il téléchargé sur le serveur ? Continuez à analyser les fichiers journaux et concentrez-vous sur « l'interface qui peut être une fonction de téléchargement de fichiers » pendant l'analyse. Il peut être déterminé à titre préliminaire que le pirate informatique a utilisé les fonctions Téléchargement ZIP et Décompression ZIP avant d'utiliser ce webshell, comme le montre l'image.

Recherchez le fichier test5.zip appelé par l'interface de décompression de fichiers sur le serveur. Après l'avoir analysé, vous constaterez que le chemin où se trouve admin.war est "test5.zip...". Par conséquent, le fichier ZIP est un fichier malveillant soigneusement construit par des pirates. Il fera du chemin de décompression du package war non plus le répertoire par défaut "/uploads/1", mais le répertoire "webapps" de Tomcat, comme le montre la figure.

Remarque : Comment générer le fichier zip malveillant dans cet article

(1) Exécutez le script python suivant pour générer test5.zip :

import zipfile if __name__ == "__main__": try:binary = b'<script>alert("helloworld")</script>'zipFile = zipfile.ZipFile("test5.zip", "a", zipfile.ZIP_DEFLATED) info = zipfile.ZipInfo("test5.zip")zipFile.writestr("../../../safedog.html", binary)zipFile.close()except IOError as e: raise e

(2) Faites glisser le package war contenant Webshell vers "test5.zip », comme le montre la figure.

2. Audit de code

Grâce à l'analyse précédente de traçabilité des intrusions, on peut conclure à titre préliminaire que cette attaque est liée à "l'interface de décompression ZIP" du CMS (GET /cmscp/core/web_file_2/unzip .do?ids= {ids}&parentId={parentId}) sont étroitement liés. Cette interface correspond à la méthode unzip de WebFileUploadsController.java, comme le montre la figure.

Suivez la méthode unzip et constatez que son implémentation spécifique se trouve dans WebFileControllerAbtractor.java. On constate que lors de la décompression du fichier zip, la méthode unzip de la classe AntZipUtil est appelée, comme le montre la figure.

En suivant la méthode unzip de la classe AntZipUtil, nous pouvons constater que

cette méthode n'effectue pas de vérification des paramètres

sur le nom du fichier dans le package compressé ZIP avant d'écrire le fichier. Une telle écriture de code entraînera une vulnérabilité de traversée de répertoire, comme le montre la figure.

Actuellement, Haiqing Lab a soumis la vulnérabilité au CNVD et a informé le fabricant de la corriger.

3. Résumé

Grâce à cet exemple, nous pouvons constater que la sécurité de la fonction de décompression peut causer de graves dommages à la sécurité du site Web (prenons comme exemple le composant de développement Spring Integration Zip, qui a également été exposé à CVE-2018. -1261 "Vulnérabilité de décompression non sécurisée"). Si l'activité du site Web implique des fonctions de décompression, il est recommandé d'accorder plus d'attention à la dimension du développement de la sécurité. De plus, Safe Dog propose également des solutions de défense de produits correspondantes.

En termes de développement de la sécurité, il est recommandé aux développeurs de procéder à un auto-examen et à des restrictions sur les aspects suivants lors de la mise en œuvre de l'algorithme de décompression :

(1) Limiter ou non l'extension des fichiers dans le package compressé

Par exemple : .war, .jsp, jspx, .jsp::$DATA (affecte uniquement les hôtes Windows)

(2) S'il faut limiter le chemin de décompression réel des fichiers dans le package compressé

(3) S'il faut limiter le total taille des fichiers dans le package compressé (en cas de packages compressés **Attaque de déni de service provoquée par)

(4) S'il faut accorder des autorisations raisonnables au répertoire de l'application Web

De plus, nous recommandons également aux utilisateurs de choisir des fichiers fiables et des produits de sécurité professionnels, tels que les utilisateurs qui ont installé des produits pour chiens de sécurité. Une fois qu'un incident de sécurité se produit, vous recevrez automatiquement un message texte d'alarme du système pour intervenir dans les plus brefs délais afin d'éviter des pertes plus importantes.

En termes de "Safe Dog Product Defense", il est recommandé aux utilisateurs d'utiliser la protection d'arrière-plan du site Web de "Website Security Dog" et "Yunyu" et les fonctions de protection du répertoire de fichiers de Server Dog, ainsi que le backend Web. de Yunyu et Website Safety Dog La fonction de protection du chemin peut protéger contre les comportements de force brute en arrière-plan du site Web.

La fonction de protection d'arrière-plan de Yunyu est comme indiqué dans l'image :

La fonction de protection d'arrière-plan du chien de sécurité du site Web est comme indiqué dans l'image :

Fonction de protection du répertoire du dossier du serveur :

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!