polaris64/web_exploit_detectorWeb Exploit Detector è un'applicazione Node.js utilizzata per rilevare possibili infezioni, codice malevolo e file sospetti in ambienti di web hosting.
Il Rilevatore di Exploit Web è un'applicazione Node.js (e modulo NPM) utilizzata per rilevare possibili infezioni, codice malevolo e file sospetti in ambienti di hosting web. Questa applicazione è pensata per essere eseguita su server web che ospitano uno o più siti. Eseguendo l'applicazione si genera un elenco di file potenzialmente infetti, insieme a una descrizione dell'infezione e riferimenti a risorse online correlate.
A partire dalla versione 1.1.0, l'applicazione include anche utilità per generare e confrontare snapshot di una struttura di directory, consentendo agli utenti di vedere se alcuni file sono stati modificati, aggiunti o rimossi.
L'applicazione è ospitata qui su GitHub in modo che altri possano trarne beneficio, oltre a permettere ad altri di contribuire con le proprie regole di rilevamento.
Il modo più semplice per installare Web Exploit Detector è come modulo NPM globale: -
npm install -g web_exploit_detector
Se stai utilizzando Linux o un altro sistema operativo basato su Unix, potresti dover eseguire questo comando come root (ad esempio sudo npm install -g web_exploit_detector).
Il modulo dovrebbe essere aggiornato regolarmente per assicurarsi che tutte le ultime regole di rilevamento siano presenti. Eseguendo il comando sopra si scaricherà sempre l'ultima versione stabile (testata). Per aggiornare una versione già installata, basta eseguire il seguente comando: -
npm update -g web_exploit_detector
Ancora, potresti dover usare il comando sudo come sopra.
Puoi anche clonare il repository Git ed eseguire lo script direttamente in questo modo: -
git clone https://github.com/polaris64/web_exploit_detectorcd web_exploit_detectornpm installSe hai installato Web Exploit Detector come modulo NPM (vedi sopra), eseguire lo scanner è semplice come eseguire il seguente comando, passando il percorso della tua webroot (posizione dei file del tuo sito): -
wed-scanner --webroot=/var/www/html
Sono disponibili altre opzioni da riga di comando; basta eseguire wed-scanner --help per vedere un messaggio di aiuto che le descrive.
Eseguire lo script in questo modo produrrà output leggibile dall'uomo sulla console. Questo è molto utile quando si esegue lo script con cron, ad esempio, poiché l'output può essere inviato come email ogni volta che lo script viene eseguito.
Lo script supporta anche la scrittura dei risultati in un formato JSON più adatto ai computer per un'elaborazione successiva. Per attivare questo output, vedere l'argomento da riga di comando --output.
Basta chiamare lo script tramite node e passare il percorso della tua webroot come segue: -
node index.js --webroot=/var/www/html
Web Exploit Detector include anche due utilità per aiutare a identificare file che potrebbero essere cambiati inaspettatamente. Un attacco riuscito a un sito di solito comporta l'eliminazione di file, l'aggiunta di nuovi file o la modifica di file esistenti in qualche modo.
Uno snapshot (come usato da queste utilità) è un file JSON che elenca tutti i file insieme a una descrizione del loro contenuto nel momento in cui lo snapshot è stato creato. Se uno snapshot è stato generato lunedì, ad esempio, e poi il sito è stato attaccato martedì, eseguire un confronto tra questo snapshot e i file attuali del sito mostrerà che uno o più file sono stati aggiunti, eliminati o modificati. L'obiettivo di queste utilità è quindi quello di permettere la creazione di questi snapshot e l'esecuzione dei confronti quando necessario.
Lo snapshot memorizza ogni percorso file insieme a un hash SHA-256 del contenuto del file. Un hash, o digest, è un piccolo riepilogo di un messaggio, che in questo caso è il contenuto del file. Se il contenuto del file cambia, anche in modo molto piccolo, l'hash diventerà completamente diverso. Ciò fornisce un buon modo per rilevare qualsiasi modifica al contenuto dei file.
Le seguenti due utilità sono anch'esse installate come parte di Web Exploit Detector: -
wed-generate-snapshot: questa utilità permette di generare uno snapshot per tutti i file (ricorsivamente) in una directory specificata tramite "--webroot". Lo snapshot verrà salvato in un file specificato nell'opzione "--output".wed-compare-snapshot: una volta generato uno snapshot, può essere confrontato con il contenuto corrente della stessa directory. Lo snapshot da controllare viene specificato tramite l'opzione "--snapshot". La directory di base da confrontare è memorizzata all'interno dello snapshot, ma se la directory di base è cambiata da quando lo snapshot è stato generato, è possibile usare l'opzione --webroot.Gli snapshot possono essere generati con la frequenza desiderata, ma come regola generale dovrebbero essere generati ogni volta che un sito è in uno stato pulito (non infetto) e ogni volta che è stata apportata una modifica legittima. Per i siti basati su CMS come WordPress, gli snapshot dovrebbero essere creati regolarmente poiché nuovi caricamenti faranno sì che il nuovo stato differisca dallo snapshot memorizzato. Per i siti i cui file non dovrebbero mai cambiare, è possibile generare un singolo snapshot e poi usarlo a tempo indeterminato per assicurarsi che nulla cambi effettivamente.
Lo script src/web-exploit-detector.js è un modulo ES6 che esporta l'insieme di regole come rules oltre a una serie di funzioni: -
executeTests(settings): esegue il controllo degli exploit basandosi sull'oggetto settings passato. Per l'utilizzo, consultare lo script index.js.formatResult(result): prende un singolo result di test dall'array restituito da executeTests() e genera una stringa di risultati pronta per l'output per quel test.getFileList(path): restituisce un array di file dal path di base usando readDirRecursive().processRulesOnFile(file, rules): processa tutte le regole dell'array rules su un singolo file (percorso stringa).readDirRecursive(path): funzione ricorsiva che restituisce una Promise che verrà risolta con un array di tutti i file in e sottodirectory.Lo script src/cli.js è una semplice interfaccia a riga di comando (CLI) per questo modulo, utilizzata dallo script wed-scanner, quindi leggere questo script mostra un modo in cui questo modulo può essere utilizzato.
Il progetto utilizza Babel per compilare i moduli ES6 in "src" in moduli JavaScript semplici in "lib". Se stai utilizzando una versione obsoleta di Node.js, i moduli possono essere require()'d dalla directory "lib" invece.
Il pacchetto contiene Babel come dev-dependency e gli script "build" e "watch:build". Quando si esegue lo script "build" (npm run build), i moduli ES6 in "./src" verranno compilati e salvati in "./lib", dove vengono inclusi dagli script CLI.
La directory "./lib" è inclusa nel repository in modo che qualsiasi utente possa clonare il repository ed eseguire l'applicazione direttamente senza dover installare dev-dependency e compilare l'applicazione.
A volte le regole, specialmente quelle etichettate con suspicion, identificheranno un file pulito come potenziale exploit. Per questo motivo, è incluso anche un sistema per consentire l'esclusione di file da controllare per una regola.
Lo script wed-results-to-exceptions prende un file di output dallo script principale di rilevamento (vedi l'opzione --output) e ti dà la possibilità di escludere ogni file a turno per ogni regola specifica. Tutti i file esclusi vengono memorizzati in un file chiamato wed-exceptions.json (nella home directory dell'utente) che viene letto dallo script principale prima di eseguire la scansione. Se un file è elencato in questo file, tutte le regole allegate (per ID) verranno saltate quando si controlla questo file.
Per istruzioni sull'utilizzo, basta eseguire wed-results-to-exceptions. Dovrai prima avere un JSON di output valido da un'esecuzione precedente del rilevatore principale utilizzando l'opzione --output.
Per gli utenti che lavorano direttamente con il repository Git, esegui node results_to_exceptions.js nella directory principale del progetto.
L'applicazione opera utilizzando una collezione di "regole" che vengono caricate quando l'applicazione viene eseguita. Ogni regola consiste in un ID, nome, descrizione, elenco di URL, tag, flag di obsolescenza e, soprattutto, un insieme di test.
Ogni singolo test deve essere uno dei seguenti: -
Sono supportati i seguenti tipi di test: -
Poiché gli exploit basati sul web sono in continua evoluzione e vengono creati nuovi exploit, anche l'insieme di regole deve essere aggiornato. Poiché ospito diversi siti web, osservo costantemente nuovi tipi di exploit, quindi aggiungerò all'insieme di regole ogni volta che posso. Eseguo questo strumento sui miei server, quindi ovviamente voglio che sia il più funzionale possibile!
Questo mi porta alle ragioni per cui ho reso questa applicazione disponibile come progetto open-source: primo, affinché tu e altri possiate trarne beneficio, e secondo, affinché possiamo tutti collaborare per contribuire con regole di rilevamento in modo che l'applicazione sia sempre aggiornata.
Se hai scoperto un exploit che non viene rilevato da questo strumento, per favore contattami per farmelo sapere o, ancora meglio, scrivi la tua regola e aggiungila all'insieme di regole di terze parti (rules/third-party/index.js), quindi inviami una pull request.
Non preoccuparti se non sai come scrivere le tue regole; la cosa più importante è che la regola venga aggiunta, quindi sentiti libero di inviarmi quante più informazioni possibile sull'exploit e cercherò di creare una mia regola.
Le regole sono categorizzate, ma il modo più semplice per aggiungere la tua regola è aggiungerla all'insieme di regole di terze parti menzionato sopra. Gli ID delle regole sono scritti nel seguente formato: "autore:tipo:sotto-tipo(i):id-regola". Ad esempio, una delle mie regole è "P64:php:cms:wordpress:wso_webshell". "P64" sono io (l'autore), "php:cms:wordpress" è il raggruppamento (una regola specifica per PHP, per il Sistema di Gestione dei Contenuti (CMS) chiamato WordPress) e "wso_webshell" è l'ID specifico della regola. Quando scrivi le tue regole, cerca di seguire questo formato e sostituisci "P64" con il tuo nome utente GitHub o un altro identificativo univoco.
Il progetto contiene un insieme di test Jasmine che possono essere eseguiti usando npm test. Contiene anche una configurazione ESLint, ed ESLint può essere eseguito usando npm run lint.
Durante lo sviluppo, i test possono anche essere eseguiti quando un file sorgente cambia eseguendo npm run watch:test. Per eseguire test ed ESLint, si può usare lo script npm run watch:all.
Tieni presente che, a meno che tu non abbia già Jasmine e/o nodemon installati, dovresti eseguire npm install in modalità non di produzione per garantire che le dev-dependency siano installate.
Grazie all'utente Reddit mayupvoterandomly per aver suggerito la funzionalità di snapshot delle directory aggiunta nella versione 1.1.0 e per aver suggerito nuove regole che verranno aggiunte presto.
Licenza ISC
Copyright (c) 2017, Simon Pugnet
Con la presente viene concessa l'autorizzazione, a titolo gratuito, a chiunque ottenga una copia di questo software e dei relativi file di documentazione (il "Software"), di utilizzare il Software senza restrizioni, inclusi, senza limitazione, i diritti di utilizzo, copia, modifica, fusione, pubblicazione, distribuzione, sottolicenza e/o vendita di copie del Software, e di consentire alle persone a cui il Software è fornito di fare altrettanto, alle seguenti condizioni:
Il suddetto avviso di copyright e questo avviso di autorizzazione devono essere inclusi in tutte le copie o parti sostanziali del Software.
IL SOFTWARE VIENE FORNITO "COSÌ COM'È", SENZA GARANZIA DI ALCUN TIPO, ESPRESSA O IMPLICITA, INCLUSE, MA NON LIMITATE A, LE GARANZIE DI COMMERCIABILITÀ, IDONEITÀ PER UNO SCOPO PARTICOLARE E NON VIOLAZIONE. IN NESSUN CASO L'AUTORE SARÀ RESPONSABILE PER QUALSIASI RECLAMO, DANNO O ALTRA RESPONSABILITÀ, DERIVANTE DA O IN CONNESSIONE CON IL SOFTWARE O L'USO O ALTRE OPERAZIONI NEL SOFTWARE.
path