polaris64/web_exploit_detectorEl Web Exploit Detector es una aplicación Node.js utilizada para detectar posibles infecciones, código malicioso y archivos sospechosos en entornos de alojamiento web.
Web Exploit Detector es una aplicación Node.js (y un módulo NPM) utilizada para detectar posibles infecciones, código malicioso y archivos sospechosos en entornos de alojamiento web. Esta aplicación está pensada para ejecutarse en servidores web que alojen uno o más sitios web. Al ejecutar la aplicación se generará una lista de archivos potencialmente infectados, junto con una descripción de la infección y referencias a recursos en línea relacionados.
A partir de la versión 1.1.0, la aplicación también incluye utilidades para generar y comparar instantáneas (snapshots) de una estructura de directorios, lo que permite a los usuarios saber si se han modificado, añadido o eliminado archivos.
La aplicación está alojada aquí en GitHub para que otros puedan beneficiarse de ella, así como para que otros puedan contribuir con sus propias reglas de detección.
La forma más sencilla de instalar Web Exploit Detector es como módulo NPM global: -
npm install -g web_exploit_detector
Si estás usando Linux u otro sistema operativo basado en Unix, puede que necesites ejecutar este comando como root (p. ej. sudo npm install -g web_exploit_detector).
El módulo debe actualizarse periódicamente para asegurarse de que todas las reglas de detección más recientes estén presentes. Ejecutar el comando anterior siempre descargará la última versión estable (probada). Para actualizar una versión ya instalada, simplemente ejecuta lo siguiente: -
npm update -g web_exploit_detector
De nuevo, puede que tengas que usar el comando sudo como antes.
También puedes clonar el repositorio Git y ejecutar el script directamente de la siguiente manera: -
git clone https://github.com/polaris64/web_exploit_detectorcd web_exploit_detectornpm installSi has instalado Web Exploit Detector como módulo NPM (ver arriba), ejecutar el escáner es tan simple como ejecutar el siguiente comando, pasando la ruta a tu webroot (ubicación de los archivos de tu sitio web): -
wed-scanner --webroot=/var/www/html
Hay otras opciones de línea de comandos disponibles; simplemente ejecuta wed-scanner --help para ver un mensaje de ayuda que las describe.
Ejecutar el script de esta manera producirá una salida legible para humanos en la consola. Esto es muy útil cuando se ejecuta el script con cron, por ejemplo, ya que la salida se puede enviar como correo electrónico cada vez que se ejecuta.
El script también admite la escritura de resultados en un formato JSON más amigable para computadoras para su posterior procesamiento. Para habilitar esta salida, consulta el argumento de línea de comandos --output.
Simplemente llama al script a través de node y pasa la ruta a tu webroot de la siguiente manera: -
node index.js --webroot=/var/www/html
Web Exploit Detector también incluye dos utilidades para ayudar a identificar archivos que podrían haber cambiado inesperadamente. Un ataque exitoso a un sitio generalmente implica eliminar archivos, añadir archivos nuevos o modificar archivos existentes de alguna manera.
Una instantánea (tal como se usa en estas utilidades) es un archivo JSON que enumera todos los archivos, así como una descripción de su contenido en el momento en que se creó la instantánea. Si se generó una instantánea el lunes, por ejemplo, y luego el sitio fue atacado el martes, al realizar una comparación entre esta instantánea y los archivos actuales del sitio se mostrará que uno o más archivos fueron añadidos, eliminados o modificados. El objetivo de estas utilidades es, por lo tanto, permitir que estas instantáneas se creen y que las comparaciones se realicen cuando sea necesario.
La instantánea almacena cada ruta de archivo junto con un hash SHA-256 del contenido del archivo. Un hash, o resumen, es un pequeño resumen de un mensaje, que en este caso es el contenido del archivo. Si el contenido del archivo cambia, incluso de manera muy pequeña, el hash se volverá completamente diferente. Esto proporciona una buena manera de detectar cualquier cambio en el contenido de los archivos.
Las dos utilidades siguientes también se instalan como parte de Web Exploit Detector: -
wed-generate-snapshot: esta utilidad permite generar una instantánea de todos los archivos (de forma recursiva) en un directorio especificado por "--webroot". La instantánea se guardará en un archivo especificado en la opción "--output".wed-compare-snapshot: una vez que se ha generado una instantánea, se puede comparar con el contenido actual del mismo directorio. La instantánea a verificar se especifica mediante la opción "--snapshot". El directorio base contra el que verificar se almacena dentro de la instantánea, pero si el directorio base ha cambiado desde que se generó la instantánea, se puede usar la opción --webroot.Las instantáneas se pueden generar con la frecuencia que se desee, pero como regla general, deben generarse siempre que un sitio esté en un estado limpio (no infectado) y siempre que se haya realizado un cambio legítimo. Para sitios basados en CMS como WordPress, las instantáneas deben crearse regularmente, ya que las nuevas subidas harán que el nuevo estado difiera de la instantánea almacenada. Para sitios cuyos archivos nunca deberían cambiar, se puede generar una única instantánea y luego usarla indefinidamente para asegurarse de que nada cambie.
El script src/web-exploit-detector.js es un módulo ES6 que exporta el conjunto de reglas como rules así como varias funciones: -
executeTests(settings): ejecuta el verificador de exploits basado en el objeto settings pasado. Para su uso, consulta el script index.js.formatResult(result): toma un único result de test del array devuelto por executeTests() y genera una cadena de resultados lista para la salida de ese test.getFileList(path): devuelve un array de archivos desde la path base usando readDirRecursive().processRulesOnFile(file, rules): procesa todas las reglas del array rules en un único file (ruta de cadena).readDirRecursive(path): función recursiva que devuelve una Promesa que se resolverá con un array de todos los archivos en y subdirectorios.El script src/cli.js es una interfaz de línea de comandos (CLI) simple para este módulo, utilizada por el script wed-scanner, por lo que leer este script muestra una forma en que se puede usar este módulo.
El proyecto utiliza Babel para compilar los módulos ES6 en "src" a módulos JavaScript simples en "lib". Si estás ejecutando una versión antigua de Node.js, los módulos se pueden require() desde el directorio "lib".
El paquete contiene Babel como dependencia de desarrollo y los scripts "build" y "watch:build". Al ejecutar el script "build" (npm run build), los módulos ES6 en "./src" se compilarán y guardarán en "./lib", donde son incluidos por los scripts de CLI.
El directorio "./lib" está incluido en el repositorio para que cualquier usuario pueda clonar el repositorio y ejecutar la aplicación directamente sin tener que instalar dependencias de desarrollo y compilar la aplicación.
A veces, las reglas, especialmente las etiquetadas con suspicion, identificarán un archivo limpio como un exploit potencial. Debido a esto, se incluye un sistema para permitir que los archivos sean excluidos de ser verificados para una regla.
El script wed-results-to-exceptions toma un archivo de salida del script detector principal (ver la opción --output) y te da la opción de excluir cada archivo por turno para cada regla específica. Todos los archivos excluidos se almacenan en un archivo llamado wed-exceptions.json (en el directorio home del usuario) que es leído por el script principal antes de ejecutar el escaneo. Si un archivo está listado en este archivo, entonces todas las reglas adjuntas (por ID) se omitirán al verificar este archivo.
Para instrucciones de uso, simplemente ejecuta wed-results-to-exceptions. Necesitarás tener un JSON de salida válido de una ejecución anterior del detector principal, usando primero la opción --output.
Para usuarios que trabajan directamente con el repositorio Git, ejecuta node results_to_exceptions.js en el directorio raíz del proyecto.
La aplicación opera utilizando una colección de "reglas" que se cargan cuando se ejecuta la aplicación. Cada regla consiste en un ID, nombre, descripción, lista de URLs, etiquetas, un indicador de obsolecencia y, lo más importante, un conjunto de tests.
Cada test individual debe ser uno de los siguientes: -
Los siguientes tipos de test están soportados: -
Como los exploits basados en web están en constante evolución y se crean nuevos exploits, el conjunto de reglas también debe actualizarse. Como alojo varios sitios web, estoy constantemente observando nuevos tipos de exploits, por lo que iré añadiendo reglas siempre que pueda. Ejecuto esta herramienta en mis propios servidores, por lo que, por supuesto, quiero que sea lo más funcional posible.
Esto me lleva a las razones por las que he puesto esta aplicación a disposición como proyecto de código abierto: en primer lugar, para que tú y otros puedan beneficiarse de ella y, en segundo lugar, para que todos podamos colaborar para contribuir con reglas de detección y que la aplicación esté siempre actualizada.
Si has descubierto un exploit que no es detectado por esta herramienta, por favor, contáctame para informarme o, mejor aún, escribe tu propia regla y añádela al conjunto de reglas de terceros (rules/third-party/index.js) y luego envíame un pull request.
No te preocupes si no sabes cómo escribir tus propias reglas; lo más importante es que la regla se añada, así que siéntete libre de enviarme toda la información que puedas sobre el exploit y yo intentaré crear mi propia regla para él.
Las reglas están categorizadas, pero la forma más sencilla de añadir tu propia regla es añadirla al conjunto de reglas de terceros mencionado anteriormente. Los IDs de las reglas se escriben en el siguiente formato: "autor:tipo:sub-tipo(s):id-regla". Por ejemplo, una de mis reglas es "P64:php:cms:wordpress:wso_webshell". "P64" soy yo (el autor), "php:cms:wordpress" es la agrupación (una regla específica de PHP, para el Sistema de Gestión de Contenidos (CMS) llamado WordPress) y "wso_webshell" es el ID de regla específico. Al escribir tus propias reglas, intenta seguir este formato y reemplaza "P64" con tu propio nombre de usuario de GitHub u otro identificador único.
El proyecto contiene un conjunto de pruebas Jasmine que se pueden ejecutar usando npm test. También contiene una configuración de ESLint, y ESLint se puede ejecutar usando npm run lint.
Durante el desarrollo, las pruebas también se pueden ejecutar cada vez que cambia un archivo fuente, ejecutando npm run watch:test. Para ejecutar las pruebas y ESLint, se puede usar el script npm run watch:all.
Ten en cuenta que, a menos que ya tengas Jasmine y/o nodemon instalados, debes ejecutar npm install en modo no producción para asegurarte de que las dependencias de desarrollo estén instaladas.
Gracias al usuario de Reddit mayupvoterandomly por sugerir la funcionalidad de instantáneas de directorios que se añadió en la versión 1.1.0 y por sugerir nuevas reglas que se añadirán pronto.
Licencia ISC
Copyright (c) 2017, Simon Pugnet
Se concede permiso para usar, copiar, modificar y/o distribuir este software para cualquier propósito, con o sin cargo, siempre que el aviso de copyright anterior y este aviso de permiso aparezcan en todas las copias.
EL SOFTWARE SE PROPORCIONA "TAL CUAL" Y EL AUTOR RENUNCIA A TODAS LAS GARANTÍAS CON RESPECTO A ESTE SOFTWARE, INCLUYENDO TODAS LAS GARANTÍAS IMPLÍCITAS DE COMERCIABILIDAD Y APTITUD. EN NINGÚN CASO EL AUTOR SERÁ RESPONSABLE DE NINGÚN DAÑO ESPECIAL, DIRECTO, INDIRECTO O CONSECUENTE, NI DE NINGÚN OTRO DAÑO QUE SURJA DEL USO O RENDIMIENTO DE ESTE SOFTWARE, YA SEA POR CONTRATO, NEGLIGENCIA O CUALQUIER OTRA ACCIÓN LEGAL.
path