Pentesting contra aplicaciones en node.js – Parte 2.

En el primer post publicado de ésta serie sobre pentesting contra aplicaciones en node.js simplemente se ha dado un repaso general de las principales vulnerabilidades que se pueden detectar y posteriormente explotar en aplicaciones web basadas en ésta tecnología, la mayoría de las cuales no se encuentran especificadas en el OWASP Top 10, por lo tanto hay que aplicar un enfoque un poco diferente a la hora de realizar un proceso de pentesting contra éste tipo de aplicaciones. No obstante, esto no significa que las vulnerabilidades descritas en el OWASP Top 10 no afecten a las aplicaciones desarrolladas con node.js, todo lo contrario, también son bastante frecuentes cuando se desarrolla una aplicación sin tener en cuenta la seguridad en el proceso de construcción.
En el post anterior también se han mencionado las principales diferencias entre el modelo “event-loop” que implementan las aplicaciones basadas en node.js y el modelo “thread per-request”, por lo tanto en éste post vamos a comenzar a ver ejemplos prácticos de las vulnerabilidades descritas en el primer articulo para que todo quede un poco más claro.

Entorno de pruebas con NodeGoat.

Antes de comenzar y ver ejemplos un poco más centrados en lo que viene a ser el pentesting contra aplicaciones con node.js, es mejor contar con un entorno de pruebas y qué mejor que una aplicación web vulnerable por diseño, por ese motivo a partir de éste punto se procede a explicar la instalación de NodeGoat y su posterior puesta en marcha. Como se verá a continuación es un procedimiento bastante sencillo, solamente es necesario configurar una conexión a una base de datos MongoDB y tener todas las dependencias instaladas en el directorio donde se encuentra la aplicación, algo que se puede conseguir fácilmente utilizando “npm”.

El proyecto se encuentra disponible en GitHub en la siguiente url: https://github.com/OWASP/NodeGoat y tal como se puede ver en el README, la instalación consiste principalmente en la instalación de una base de datos MongoDB (la cual puede encontrarse en un servicio en Internet como https://mlab.com/) y contar con todas las librerías y dependencias obligatorias. El procedimiento se encuentra bastante bien explicado en el repositorio, por lo tanto no tiene mucho sentido replicar lo mismo que aparece en el fichero de README del proyecto, basta simplemente con seguir cada uno de los pasos indicados y será posible tener una instancia de NodeGoat en ejecución, por otro lado, para aquellos que prefieran utilizar Docker, también existe una imagen que cuenta con todo lo necesario para tener el entorno preparado.
Una vez que todas las dependencias se encuentran instaladas y todo está debidamente configurado, se puede ejecutar el “server.js” para levantar el módulo de express que da acceso a la aplicación y desde un navegador web apuntar a la dirección local en el puerto “4000”.

Las credenciales de acceso a la aplicación se encuentran en el README del proyecto, se pueden usar las cuentas: admin/Admin_123, user1/User1_123 o user2/User2_123.

Utilizando cualquiera de las cuentas anteriores, se puede iniciar sesión en la aplicación.

Ahora que ya se cuenta con NodeGoat en ejecución, es posible comenzar a hacer pruebas contra la aplicación, empezando por las más sencillas para ir tomando confianza.

En la aplicación existen varias vulnerabilidades de inyección del tipo XSS, una de ellas se encuentra en el perfil del usuario, en donde es posible editar información básica del usuario que se encuentra autenticado. Dado que algunos de dichos campos no gestionan adecuadamente las entradas y no “escapan” caracteres que son potencialmente peligrosos, es fácil incluir un script que haga cualquier cosa, desde el típico “alert”, cargar un iframe o una de mis favoritas, cargar un hook de BeEF ubicado en un servicio oculto en TOR. Seguramente algunos os diréis, que es necesario que el cliente se encuentre también conectado a dicha red para poder acceder a las direcciones onion, algo que es parcialmente cierto, pero también existen servicios en Internet como por ejemplo “tor2web” que se encarga de servir cómo puente entre usuarios que navegan en la “clear web” sin utilizar TOR y los servicios que se encuentran alojados en la deep web.

Además de la sección de perfil del usuario, ubicado en el extremo superior derecho de la aplicación web, en la opción “memos” es posible escribir un mensaje que quedará almacenado en la base de datos y el cual, admite entre otras cosas, tags HTML que serán renderizadas directamente en el navegador web de cada uno de los usuarios que accedan a la página, lo que nuevamente da como resultado una vulnerabilidad del tipo XSS almacenado.

Otra vulnerabilidad que también es fácil de descubrir se encuentra en la sección “allocations”. La lógica de ésta página es sencilla, cada uno de los usuarios autenticados accede a sus propios “allocations” desde ésta pantalla, sin embargo, la aplicación recibe por parámetro el identificador de cada “allocation” y realiza una búsqueda directa contra la base de datos, sin verificar si el usuario que realiza la petición tiene permiso de acceder al elemento solicitado o dicho de otra manera, nos encontramos con una vulnerabilidad típica de “Insecure direct object reference”, definida en el OWASP Top 10, aunque con la versión más reciente del 2017 ahora tiene otro nombre, pero la filosofía y criticidad de éste tipo de vulnerabilidad sigue siendo la misma. En éste caso, simplemente basta con cambiar la url “/allocations/2” por “/allocations/CUALQUIERNUMERO” y comprobar que en el caso de que la base de datos devuelva resultados, cambia incluso la página de perfil, apareciendo los datos del usuario al que pertenece dicho “allocation”.

En la sección que pone “Learning Resources” hay un parámetro llamado “url” el cual recibe como argumento una url que es utilizada por la aplicación web para realizar una redirección, está es otra vulnerabilidad fácil de descubrir, dado que el parámetro puede ser modificado e incluir un dominio arbitrario, controlando de ésta forma la navegación del usuario. Otra vulnerabilidad que se encuentra definida en el OWASP Top10, aunque en está ocasión, en la versión del 2013: “Insecure Redirects”, vulnerabilidad que ya no se encuentra recogida en la versión actual de OWASP.

Hasta aquí se han visto las vulnerabilidades más sencillas en NodeGoat, sin embargo hay otras más interesantes y que están enfocadas a lo que viene a ser node.js, las cuales se han explicado a grandes rasgos en el artículo anterior. Comenzaremos con una vulnerabilidad de SSJS (Server Side Javascript Injection) la cual como se ha mencionado antes, puede producir la ejecución de código en el lado del servidor y dado su impacto y criticidad, es de las primeras cosas que se tienen que ver en una aplicación desarrollada en node.js. Concretamente, a la hora de realizar una auditoría de código en una aplicación con ésta tecnología, hay que buscar los siguientes patrones:

* Uso de la función “eval” recibiendo entradas por parte del usuario sin validar.

* Uso de la función “setInterval” recibiendo entradas por parte del usuario sin validar.

* Uso de la función “setTimeout” recibiendo entradas por parte del usuario sin validar.

* Creación de una función anónima en node.js partiendo de instrucciones recibidas por parte del usuario y sin validar.

En NodeGoat se encuentra la opción “Contributions” en el menú, la cual tiene tres cajas de texto que reciben valores numéricos cada una, correspondientes a un porcentaje de payroll. Si se ingresa un valor numérico no hay ningún problema, pero si se llega a ingresar una cadena de texto…

Esto simplemente significa que la función “eval” ha fallado en la validación del valor numérico, sin embargo, otra característica interesante de “eval” es que además de validar valores numéricos, también se encarga de la validación y ejecución de instrucciones Javascript. Esto significa, que conociendo la API de Node.js será posible incluir cualquier tipo de instrucción que permita la ejecución arbitraria de código. Unos ejemplos típicos podrían ser “process.exit()”, “while(1)” o incluso, incluir una reverse shell escrita en node.js, algo que se verá en el siguiente post.

Con una vulnerabilidad de SSJS, no solamente es posible producir una condición de denegación de servicio o crear una shell contra el sistema, también es posible, con muy pocas líneas de código, leer directorios y ficheros de forma arbitraria en el sistema de archivos. Simplemente incluyendo una instrucción como: “res.end(require(‘fs’).readdirSync(‘.’).toString())” se podrán ver los ficheros y directorios del directorio raíz de la aplicación web.

Hay muchas más cosas que probar en NodeGoat, las cuales se verán en las próximas entradas de ésta serie.

Un saludo y Happy Hack!
Adastra.