Web-Exploit-Detektor

Einführung

Der Web-Exploit-Detektor ist eine Node.js-Anwendung (und ein NPM-Modul), die verwendet wird, um mögliche Infektionen, bösartigen Code und verdächtige Dateien in Webhosting-Umgebungen zu erkennen. Diese Anwendung soll auf Webservern ausgeführt werden, die eine oder mehrere Websites hosten. Beim Ausführen der Anwendung wird eine Liste von Dateien erstellt, die potenziell infiziert sind, zusammen mit einer Beschreibung der Infektion und Verweisen auf zugehörige Online-Ressourcen.

Ab Version 1.1.0 enthält die Anwendung auch Dienstprogramme zum Erstellen und Vergleichen von Snapshots einer Verzeichnisstruktur, sodass Benutzer sehen können, ob Dateien geändert, hinzugefügt oder entfernt wurden.

Die Anwendung wird hier auf GitHub gehostet, damit andere davon profitieren können, und anderen die Möglichkeit geben, eigene Erkennungsregeln beizutragen.

Links

• Meine Website: https://www.polaris64.net/
• Mein Cybersicherheits-Blog, der Artikel enthält, die einige dieser Exploits beschreiben und wie man sie entfernt: https://www.polaris64.net/blog/cyber-security
• Kontaktieren Sie mich
• NPM-Modul

Installation

Normale Benutzer

Der einfachste Weg, den Web-Exploit-Detektor zu installieren, ist als globales NPM-Modul: -

npm install -g web_exploit_detector

Wenn Sie Linux oder ein anderes Unix-basiertes Betriebssystem verwenden, müssen Sie diesen Befehl möglicherweise als root ausführen (z. B. sudo npm install -g web_exploit_detector).

Aktualisierung

Das Modul sollte regelmäßig aktualisiert werden, um sicherzustellen, dass alle neuesten Erkennungsregeln vorhanden sind. Die Ausführung des obigen Befehls lädt immer die neueste stabile (getestete) Version herunter. Um eine bereits installierte Version zu aktualisieren, führen Sie einfach Folgendes aus: -

npm update -g web_exploit_detector

Auch hier müssen Sie möglicherweise den Befehl sudo wie oben verwenden.

Technische Benutzer

Sie können auch das Git-Repository klonen und das Skript wie folgt direkt ausführen: -

1. git clone https://github.com/polaris64/web_exploit_detector
2. cd web_exploit_detector
3. npm install

Ausführung

Vom NPM-Modul

Wenn Sie den Web-Exploit-Detektor als NPM-Modul installiert haben (siehe oben), dann ist das Ausführen des Scanners so einfach wie das Ausführen des folgenden Befehls, wobei Sie den Pfad zu Ihrem Webroot (Speicherort Ihrer Website-Dateien) übergeben: -

wed-scanner --webroot=/var/www/html

Weitere Befehlszeilenoptionen sind verfügbar, führen Sie einfach wed-scanner --help aus, um eine Hilfemeldung mit deren Beschreibung zu sehen.

Wenn Sie das Skript auf diese Weise ausführen, wird eine für Menschen lesbare Ausgabe auf der Konsole erzeugt. Dies ist sehr nützlich, wenn das Skript mit cron ausgeführt wird, da die Ausgabe dann bei jeder Ausführung des Skripts als E-Mail gesendet werden kann.

Das Skript unterstützt auch das Schreiben von Ergebnissen in ein computerfreundlicheres JSON-Format zur späteren Verarbeitung. Aktivieren Sie diese Ausgabe mit dem Befehlszeilenargument --output.

Aus dem geklonten Git-Repository

Rufen Sie das Skript einfach über node auf und übergeben Sie den Pfad zu Ihrem Webroot wie folgt: -

node index.js --webroot=/var/www/html

Rekursive Verzeichnis-Snapshots

Der Web-Exploit-Detektor wird auch mit zwei Dienstprogrammen geliefert, die helfen, Dateien zu identifizieren, die sich unerwartet geändert haben könnten. Ein erfolgreicher Angriff auf eine Website beinhaltet in der Regel das Löschen von Dateien, das Hinzufügen neuer Dateien oder das Ändern vorhandener Dateien auf irgendeine Weise.

Snapshots

Ein Snapshot (wie von diesen Dienstprogrammen verwendet) ist eine JSON-Datei, die alle Dateien sowie eine Beschreibung ihres Inhalts zum Zeitpunkt der Erstellung des Snapshots auflistet. Wenn beispielsweise am Montag ein Snapshot erstellt wurde und die Website dann am Dienstag angegriffen wurde, zeigt ein anschließender Vergleich zwischen diesem Snapshot und den aktuellen Website-Dateien, dass eine oder mehrere Dateien hinzugefügt, gelöscht oder geändert wurden. Das Ziel dieser Dienstprogramme ist es daher, das Erstellen dieser Snapshots und das Durchführen der Vergleiche bei Bedarf zu ermöglichen.

Der Snapshot speichert jeden Dateipfad zusammen mit einem SHA-256-Hash des Dateiinhalts. Ein Hash oder Digest ist eine kleine Zusammenfassung einer Nachricht, in diesem Fall des Dateiinhalts. Wenn sich der Dateiinhalt ändert, auch nur geringfügig, wird der Hash völlig anders. Dies bietet eine gute Möglichkeit, Änderungen am Dateiinhalt zu erkennen.

Verwendung

Die folgenden zwei Dienstprogramme werden ebenfalls als Teil des Web-Exploit-Detektors installiert: -

• wed-generate-snapshot: Mit diesem Dienstprogramm kann ein Snapshot für alle Dateien (rekursiv) in einem durch "--webroot" angegebenen Verzeichnis erstellt werden. Der Snapshot wird in einer in der Option "--output" angegebenen Datei gespeichert.
• wed-compare-snapshot: Sobald ein Snapshot erstellt wurde, kann er mit dem aktuellen Inhalt desselben Verzeichnisses verglichen werden. Der zu überprüfende Snapshot wird mit der Option "--snapshot" angegeben. Das Basisverzeichnis, mit dem verglichen werden soll, ist im Snapshot gespeichert. Wenn sich das Basisverzeichnis seit der Erstellung des Snapshots geändert hat, kann die Option --webroot verwendet werden.

Workflow

Snapshots können so oft wie erforderlich erstellt werden, aber als Faustregel sollten sie immer dann erstellt werden, wenn sich eine Site in einem sauberen (nicht infizierten) Zustand befindet und wenn eine legitime Änderung vorgenommen wurde. Bei CMS-basierten Sites wie WordPress sollten regelmäßig Snapshots erstellt werden, da neue Uploads dazu führen, dass sich der neue Zustand vom gespeicherten Snapshot unterscheidet. Bei Sites, deren Dateien sich nie ändern sollten, kann ein einzelner Snapshot erstellt und dann auf unbestimmte Zeit verwendet werden, um sicherzustellen, dass sich tatsächlich nichts ändert.

Verwendung als Modul

Das Skript src/web-exploit-detector.js ist ein ES6-Modul, das die Regelsammlung als rules sowie eine Reihe von Funktionen exportiert: -

• executeTests(settings): Führt den Exploit-Checker basierend auf dem übergebenen settings-Objekt aus. Zur Verwendung konsultieren Sie bitte das Skript index.js.
• formatResult(result): Nimmt ein einzelnes Testergebnis result aus dem von executeTests() zurückgegebenen Array und erzeugt eine Ergebniszeichenfolge, die für die Ausgabe dieses Tests bereit ist.
• getFileList(path): Gibt ein Array von Dateien aus dem Basisverzeichnis path unter Verwendung von readDirRecursive() zurück.
• processRulesOnFile(file, rules): Verarbeitet alle Regeln aus dem Array rules auf einer einzelnen Datei file (String-Pfad).
• readDirRecursive(path): Rekursive Funktion, die ein Promise zurückgibt, das mit einem Array aller Dateien in und Unterverzeichnissen aufgelöst wird.

Das Skript src/cli.js ist eine einfache Befehlszeilenschnittstelle (CLI) zu diesem Modul, die vom Skript wed-scanner verwendet wird. Das Lesen dieses Skripts zeigt eine Möglichkeit, wie dieses Modul verwendet werden kann.

Das Projekt verwendet Babel, um die ES6-Module in "src" in einfache JavaScript-Module in "lib" zu kompilieren. Wenn Sie eine ältere Version von Node.js ausführen, können Module stattdessen aus dem "lib"-Verzeichnis mit require() geladen werden.

Erstellung

Das Paket enthält Babel als Dev-Abhängigkeit und die Skripte "build" und "watch:build". Wenn das Skript "build" (npm run build) ausgeführt wird, werden die ES6-Module in "./src" kompiliert und in "./lib" gespeichert, wo sie von den CLI-Skripten eingebunden werden.

Das Verzeichnis "./lib" ist im Repository enthalten, sodass jeder Benutzer das Repository klonen und die Anwendung direkt ausführen kann, ohne Dev-Abhängigkeiten installieren und die Anwendung erstellen zu müssen.

Ausschließen von Ergebnissen pro Regel

Manchmal identifizieren Regeln, insbesondere solche mit dem Tag suspicion, eine saubere Datei als potenziellen Exploit. Aus diesem Grund ist auch ein System enthalten, um Dateien von der Überprüfung durch eine Regel auszuschließen.

Das Skript wed-results-to-exceptions nimmt eine Ausgabedatei vom Hauptdetektorskript (siehe Option --output) und gibt Ihnen die Möglichkeit, jede Datei der Reihe nach für jede spezifische Regel auszuschließen. Alle ausgeschlossenen Dateien werden in einer Datei namens wed-exceptions.json (im Home-Verzeichnis des Benutzers) gespeichert, die vor dem Durchführen des Scans vom Hauptskript gelesen wird. Wenn eine Datei in dieser Datei aufgeführt ist, werden alle zugehörigen Regeln (nach ID) beim Überprüfen dieser Datei übersprungen.

Eine Anleitung zur Verwendung erhalten Sie, indem Sie einfach wed-results-to-exceptions ausführen. Sie müssen zuerst ein gültiges Ausgabe-JSON von einem vorherigen Lauf des Hauptdetektors mit der Option --output haben.

Für Benutzer, die direkt mit dem Git-Repository arbeiten, führen Sie node results_to_exceptions.js im Projektstammverzeichnis aus.

Regel-Engine

Die Anwendung arbeitet mit einer Sammlung von "Regeln", die beim Start der Anwendung geladen werden. Jede Regel besteht aus einer ID, einem Namen, einer Beschreibung, einer Liste von URLs, Tags, einem Deprecation-Flag und am wichtigsten einer Reihe von Tests.

Jeder einzelne Test muss einer der folgenden sein: -

• Ein regulärer Ausdruck: die einfachste Testart. Jeder Wert, der auf den Regex passt, besteht den Test.
• Ein Boolean-Callback: Die Callback-Funktion muss einen Boolean-Wert zurückgeben, der angibt, ob der Wert den Test besteht. Der Callback kann beliebige synchrone Operationen ausführen.
• Ein Promise-Callback: Die Callback-Funktion muss ein Promise zurückgeben, das mit einem Boolean-Wert aufgelöst wird, der angibt, ob der Wert den Test besteht. Dieser Callback-Typ kann beliebige asynchrone Operationen ausführen.

Die folgenden Testtypen werden unterstützt: -

• "path": wird verwendet, um den Dateipfad zu überprüfen. Dieser Test muss vorhanden sein und sollte true ergeben, wenn der Dateipfad als mit der Regel übereinstimmend betrachtet wird.
• "content": wird verwendet, um den Inhalt einer Datei zu überprüfen. Dieser Test ist optional, und Dateiinhalte werden nur gelesen und an Regeln gesendet, die diesen Testtyp implementieren. Wenn dieser Test eine Funktion ist, wird der Inhalt (String) als erstes Argument und der Dateipfad als zweites Argument übergeben, sodass der Test zusätzliche Dateioperationen durchführen kann.

Erweiterung der Regeln

Da webbasierte Exploits sich ständig weiterentwickeln und neue Exploits erstellt werden, müssen auch die Regelsammlungen aktualisiert werden. Da ich eine Reihe von Websites hoste, beobachte ich ständig neue Arten von Exploits, also werde ich die Regelsammlung so oft wie möglich erweitern. Ich führe dieses Tool auf meinen eigenen Servern aus, also möchte ich natürlich, dass es so funktionsfähig wie möglich ist!

Dies bringt mich zu den Gründen, warum ich diese Anwendung als Open-Source-Projekt zur Verfügung gestellt habe: Erstens, damit Sie und andere davon profitieren können, und zweitens, damit wir alle zusammenarbeiten können, um Erkennungsregeln beizutragen, damit die Anwendung immer auf dem neuesten Stand ist.

Beitrag von Regeln

Wenn Sie einen Exploit entdeckt haben, der von diesem Tool nicht erkannt wird, kontaktieren Sie mich bitte entweder, um mich zu informieren, oder noch besser: Schreiben Sie Ihre eigene Regel und fügen Sie sie zum Drittanbieter-Regelsatz hinzu (rules/third-party/index.js) und senden Sie mir dann einen Pull-Request.

Machen Sie sich keine Sorgen, wenn Sie nicht wissen, wie Sie eigene Regeln schreiben; das Wichtigste ist, dass die Regel hinzugefügt wird. Zögern Sie also nicht, mir so viele Informationen wie möglich über den Exploit zu senden, und ich werde versuchen, eine eigene Regel dafür zu erstellen.

Regeln sind kategorisiert, aber der einfachste Weg, Ihre eigene Regel hinzuzufügen, ist, sie zu dem oben genannten Drittanbieter-Regelsatz hinzuzufügen. Regel-IDs werden im folgenden Format geschrieben: "author:type:sub-type(s):rule-id". Zum Beispiel ist eine meiner eigenen Regeln "P64:php:cms:wordpress:wso_webshell". "P64" bin ich (der Autor), "php:cms:wordpress" ist die Gruppierung (eine PHP-spezifische Regel für das Content-Management-System (CMS) namens WordPress) und "wso_webshell" ist die spezifische Regel-ID. Wenn Sie Ihre eigenen Regeln schreiben, versuchen Sie, diesem Format zu folgen, und ersetzen Sie "P64" durch Ihren eigenen GitHub-Benutzernamen oder eine andere eindeutige ID.

Unit-Tests und Linting

Das Projekt enthält eine Reihe von Jasmine-Tests, die mit npm test ausgeführt werden können. Es enthält auch eine ESLint-Konfiguration, und ESLint kann mit npm run lint ausgeführt werden.

Bei der Entwicklung können Tests auch bei jeder Änderung einer Quelldatei durch Ausführen von npm run watch:test ausgeführt werden. Zum Ausführen von Tests und ESLint kann das Skript npm run watch:all verwendet werden.

Bitte beachten Sie, dass Sie, sofern Sie nicht bereits Jasmine und/oder nodemon installiert haben, npm install im Nicht-Produktionsmodus ausführen sollten, um sicherzustellen, dass die Dev-Abhängigkeiten installiert sind.

Danksagungen

Danke an den Reddit-Benutzer mayupvoterandomly für den Vorschlag der Verzeichnis-Snapshot-Funktionalität, die in 1.1.0 hinzugefügt wurde, und für den Vorschlag neuer Regeln, die bald hinzugefügt werden.

Lizenz

ISC-Lizenz

Copyright (c) 2017, Simon Pugnet

Die Erlaubnis, diese Software für jeden Zweck, mit oder ohne Gebühr, zu verwenden, zu kopieren, zu modifizieren und/oder zu verbreiten, wird hiermit erteilt, vorausgesetzt, dass der obige Urheberrechtshinweis und dieser Erlaubnishinweis in allen Kopien erscheinen.

DIE SOFTWARE WIRD "WIE BESEHEN" ZUR VERFÜGUNG GESTELLT, UND DER AUTOR LEHNT ALLE GEWÄHRLEISTUNGEN IN BEZUG AUF DIESE SOFTWARE AB, EINSCHLIESSLICH ALLER STILLSCHWEIGENDEN GEWÄHRLEISTUNGEN DER MARKTGÄNGIGKEIT UND EIGNUNG. IN KEINEM FALL HAFTET DER AUTOR FÜR BESONDERE, DIREKTE, INDIREKTE ODER FOLGESCHÄDEN ODER IRGENDWELCHE SCHÄDEN, DIE AUS NUTZUNGSAUSFALL, DATENVERLUST ODER GEWINNEN RESULTIEREN, SEI ES AUS VERTRAG, FAHRLÄSSIGKEIT ODER EINER ANDEREN UNERLAUBTEN HANDLUNG, DIE AUS DER NUTZUNG ODER LEISTUNG DIESER SOFTWARE ENTSTEHEN ODER DAMIT IN VERBINDUNG STEHEN.