polaris64/web_exploit_detectorThe Web Exploit Detector est une application Node.js utilisée pour détecter d'éventuelles infections, du code malveillant et des fichiers suspects dans les environnements d'hébergement web.
Web Exploit Detector est une application Node.js (et un module NPM) utilisée pour détecter d'éventuelles infections, du code malveillant et des fichiers suspects dans des environnements d'hébergement web. Cette application est destinée à être exécutée sur des serveurs web hébergeant un ou plusieurs sites web. L'exécution de l'application génère une liste de fichiers potentiellement infectés, accompagnée d'une description de l'infection et de références à des ressources en ligne qui y sont liées.
Depuis la version 1.1.0, l'application comprend également des utilitaires pour générer et comparer des instantanés d'une structure de répertoires, permettant aux utilisateurs de voir si des fichiers ont été modifiés, ajoutés ou supprimés.
L'application est hébergée ici sur GitHub afin que d'autres puissent en bénéficier, tout en permettant à d'autres de contribuer leurs propres règles de détection.
La façon la plus simple d'installer Web Exploit Detector est en tant que module NPM global : -
npm install -g web_exploit_detector
Si vous utilisez Linux ou un autre système d'exploitation basé sur Unix, vous devrez peut-être exécuter cette commande en tant que root (par ex. sudo npm install -g web_exploit_detector).
Le module doit être mis à jour régulièrement pour s'assurer que toutes les dernières règles de détection sont présentes. L'exécution de la commande ci-dessus télécharge toujours la dernière version stable (testée). Pour mettre à jour une version déjà installée, exécutez simplement la commande suivante : -
npm update -g web_exploit_detector
Encore une fois, vous devrez peut-être utiliser la commande sudo comme ci-dessus.
Vous pouvez également cloner le dépôt Git et exécuter le script directement comme suit : -
git clone https://github.com/polaris64/web_exploit_detectorcd web_exploit_detectornpm installSi vous avez installé Web Exploit Detector en tant que module NPM (voir ci-dessus), l'exécution du scanneur est aussi simple que d'exécuter la commande suivante en passant le chemin vers votre webroot (emplacement de vos fichiers de site web) : -
wed-scanner --webroot=/var/www/html
D'autres options de ligne de commande sont disponibles, exécutez simplement wed-scanner --help pour voir un message d'aide les décrivant.
Exécuter le script de cette manière produit une sortie lisible par l'homme dans la console. C'est très utile lorsqu'on exécute le script avec cron par exemple, car la sortie peut être envoyée par e-mail à chaque exécution du script.
Le script prend également en charge l'écriture des résultats dans un format JSON plus facile à traiter par la machine. Pour activer cette sortie, voir l'argument de ligne de commande --output.
Appelez simplement le script via node et passez le chemin vers votre webroot comme suit : -
node index.js --webroot=/var/www/html
Web Exploit Detector est également fourni avec deux utilitaires pour aider à identifier les fichiers qui pourraient avoir changé de manière inattendue. Une attaque réussie sur un site implique généralement la suppression de fichiers, l'ajout de nouveaux fichiers ou la modification de fichiers existants d'une manière ou d'une autre.
Un instantané (tel qu'utilisé par ces utilitaires) est un fichier JSON qui liste tous les fichiers ainsi qu'une description de leur contenu au moment de la création de l'instantané. Si un instantané a été généré le lundi, par exemple, et que le site a été attaqué le mardi, alors exécuter une comparaison entre cet instantané et les fichiers actuels du site par la suite montrera qu'un ou plusieurs fichiers ont été ajoutés, supprimés ou modifiés. L'objectif de ces utilitaires est donc de permettre la création de ces instantanés et d'effectuer les comparaisons lorsque cela est nécessaire.
L'instantané stocke chaque chemin de fichier avec un hachage SHA-256 du contenu du fichier. Un hachage, ou digest, est un petit résumé d'un message, qui dans ce cas est le contenu du fichier. Si le contenu du fichier change, même de manière très légère, le hachage deviendra complètement différent. Cela offre un bon moyen de détecter toute modification du contenu des fichiers.
Les deux utilitaires suivants sont également installés dans le cadre de Web Exploit Detector : -
wed-generate-snapshot : cet utilitaire permet de générer un instantané pour tous les fichiers (récursivement) dans un répertoire spécifié par "--webroot". L'instantané sera sauvegardé dans un fichier spécifié dans l'option "--output".wed-compare-snapshot : une fois qu'un instantané a été généré, il peut être comparé au contenu actuel du même répertoire. L'instantané à vérifier est spécifié à l'aide de l'option "--snapshot". Le répertoire de base à vérifier est stocké dans l'instantané, mais si le répertoire de base a changé depuis la génération de l'instantané, l'option --webroot peut être utilisée.Les instantanés peuvent être générés aussi souvent que nécessaire, mais en règle générale, ils devraient être générés chaque fois qu'un site est dans un état propre (non infecté) et chaque fois qu'un changement légitime a été effectué. Pour les sites basés sur un CMS comme WordPress, les instantanés doivent être créés régulièrement car les nouveaux téléversements feront passer le nouvel état par rapport à l'instantané stocké. Pour les sites dont les fichiers ne devraient jamais changer, un seul instantané peut être généré puis utilisé indéfiniment pour s'assurer que rien ne change effectivement.
Le script src/web-exploit-detector.js est un module ES6 qui exporte l'ensemble des règles sous le nom rules ainsi qu'un certain nombre de fonctions : -
executeTests(settings) : exécute le vérificateur d'exploit basé sur l'objet settings passé. Pour l'utilisation, veuillez consulter le script index.js.formatResult(result) : prend un seul result de test du tableau retourné par executeTests() et génère une chaîne de résultats prête à être affichée pour ce test.getFileList(path) : retourne un tableau de fichiers à partir du path de base en utilisant readDirRecursive().processRulesOnFile(file, rules) : traite toutes les règles du tableau rules sur un seul file (chemin sous forme de chaîne).readDirRecursive(path) : fonction récursive qui retourne une Promesse qui sera résolue avec un tableau de tous les fichiers dans path et ses sous-répertoires.Le script src/cli.js est une interface en ligne de commande (CLI) simple pour ce module, utilisée par le script wed-scanner, donc la lecture de ce script montre une façon d'utiliser ce module.
Le projet utilise Babel pour compiler les modules ES6 dans "src" en modules JavaScript simples dans "lib". Si vous utilisez une version plus ancienne de Node.js, les modules peuvent être require()'d depuis le répertoire "lib" à la place.
Le package contient Babel en tant que dépendance de développement et les scripts "build" et "watch:build". Lors de l'exécution du script "build" (npm run build), les modules ES6 dans "./src" seront compilés et sauvegardés dans "./lib", où ils sont inclus par les scripts CLI.
Le répertoire "./lib" est inclus dans le dépôt afin que tout utilisateur puisse cloner le dépôt et exécuter l'application directement sans avoir à installer les dépendances de développement et à construire l'application.
Parfois, certaines règles, en particulier celles étiquetées avec suspicion, identifieront un fichier propre comme une exploitation potentielle. C'est pourquoi un système permettant d'exclure des fichiers de la vérification pour une règle est également inclus.
Le script wed-results-to-exceptions prend un fichier de sortie du script principal de détection (voir l'option --output) et vous donne le choix d'exclure chaque fichier tour à tour pour chaque règle spécifique. Tous les fichiers exclus sont stockés dans un fichier appelé wed-exceptions.json (dans le répertoire personnel de l'utilisateur) qui est lu par le script principal avant d'exécuter l'analyse. Si un fichier est répertorié dans ce fichier, toutes les règles attachées (par ID) seront ignorées lors de la vérification de ce fichier.
Pour les instructions d'utilisation, exécutez simplement wed-results-to-exceptions. Vous devez d'abord disposer d'un fichier JSON de sortie valide provenant d'une exécution précédente du détecteur principal en utilisant l'option --output.
Pour les utilisateurs travaillant directement avec le dépôt Git, exécutez node results_to_exceptions.js dans le répertoire racine du projet.
L'application fonctionne à l'aide d'une collection de "règles" qui sont chargées lors de l'exécution de l'application. Chaque règle se compose d'un ID, d'un nom, d'une description, d'une liste d'URL, de balises, d'un indicateur d'obsolescence et, surtout, d'un ensemble de tests.
Chaque test individuel doit être l'un des suivants : -
Les types de test suivants sont pris en charge : -
Comme les exploits basés sur le web évoluent constamment et que de nouveaux exploits sont créés, l'ensemble des règles doit également être mis à jour. Étant donné que j'héberge un certain nombre de sites web, j'observe constamment de nouveaux types d'exploits, donc j'ajouterai à l'ensemble des règles chaque fois que je le pourrai. J'exécute cet outil sur mes propres serveurs, donc je veux bien sûr qu'il soit aussi fonctionnel que possible !
Cela m'amène aux raisons pour lesquelles j'ai rendu cette application disponible en tant que projet open-source : d'abord pour que vous et d'autres puissiez en bénéficier, et ensuite pour que nous puissions tous collaborer pour contribuer aux règles de détection afin que l'application soit toujours à jour.
Si vous avez découvert un exploit qui n'est pas détecté par cet outil, veuillez soit me contacter pour me le faire savoir, ou mieux encore, écrivez votre propre règle et ajoutez-la à l'ensemble de règles tiers (rules/third-party/index.js), puis envoyez-moi une demande de tirage.
Ne vous inquiétez pas si vous ne savez pas comment écrire vos propres règles ; le plus important est que la règle soit ajoutée, donc n'hésitez pas à m'envoyer autant d'informations que possible sur l'exploit et j'essaierai de créer ma propre règle pour celui-ci.
Les règles sont catégorisées, mais la manière la plus simple d'ajouter votre propre règle est de l'ajouter à l'ensemble de règles tiers mentionné ci-dessus. Les ID de règle sont écrits dans le format suivant : "auteur:type:sous-type(s):id-de-la-règle". Par exemple, une de mes propres règles est "P64:php:cms:wordpress:wso_webshell". "P64" est moi (l'auteur), "php:cms:wordpress" est le regroupement (une règle spécifique à PHP, pour le système de gestion de contenu (CMS) appelé WordPress) et "wso_webshell" est l'ID spécifique de la règle. Lorsque vous écrivez vos propres règles, essayez de suivre ce format et remplacez "P64" par votre propre nom d'utilisateur GitHub ou un autre ID unique.
Le projet contient un ensemble de tests Jasmine qui peuvent être exécutés en utilisant npm test. Il contient également une configuration ESLint, et ESLint peut être exécuté en utilisant npm run lint.
Lors du développement, les tests peuvent également être exécutés à chaque modification d'un fichier source en exécutant npm run watch:test. Pour exécuter les tests et ESLint, le script npm run watch:all peut être utilisé.
Veuillez noter que sauf si vous avez déjà installé Jasmine et/ou nodemon, vous devez exécuter npm install en mode non-production pour vous assurer que les dépendances de développement sont installées.
Merci à l'utilisateur Reddit mayupvoterandomly d'avoir suggéré la fonctionnalité d'instantané de répertoire ajoutée dans la version 1.1.0 et d'avoir suggéré de nouvelles règles qui seront bientôt ajoutées.
Licence ISC
Copyright (c) 2017, Simon Pugnet
Permission est accordée, gratuitement, à toute personne obtenant une copie de ce logiciel et des fichiers de documentation associés (le "Logiciel"), d'utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et/ou vendre des copies du Logiciel, et d'autoriser les personnes à qui le Logiciel est fourni à faire de même, sous réserve des conditions suivantes :
La notice de copyright ci-dessus et cette notice de permission doivent être incluses dans toutes les copies ou parties substantielles du Logiciel.
LE LOGICIEL EST FOURNI "EN L'ÉTAT", SANS GARANTIE D'AUCUNE SORTE, EXPRESSE OU IMPLICITE, Y COMPRIS MAIS SANS S'Y LIMITER LES GARANTIES DE QUALITÉ MARCHANDE, D'ADÉQUATION À UN USAGE PARTICULIER ET DE NON-CONTREFAÇON. EN AUCUN CAS L'AUTEUR NE POURRA ÊTRE TENU RESPONSABLE DE TOUT DOMMAGE DIRECT, INDIRECT, ACCESSOIRE, SPÉCIAL, EXEMPLAIRE OU CONSÉCUTIF (Y COMPRIS MAIS SANS S'Y LIMITER L'ACQUISITION DE BIENS OU DE SERVICES DE REMPLACEMENT, LA PERTE D'UTILISATION, DE DONNÉES OU DE PROFITS, OU L'INTERRUPTION D'ACTIVITÉ) QUELLE QU'EN SOIT LA CAUSE ET QUELLE QUE SOIT LA THÉORIE DE RESPONSABILITÉ, QU'ELLE SOIT CONTRACTUELLE, STRICTE OU DÉLICTUELLE (Y COMPRIS LA NÉGLIGENCE OU AUTRE) DÉCOULANT DE L'UTILISATION OU DE L'INCAPACITÉ À UTILISER LE LOGICIEL, MÊME SI L'AUTEUR A ÉTÉ INFORMÉ DE LA POSSIBILITÉ DE TELS DOMMAGES.