Archivo

Posts Tagged ‘tor2web tor’

Pentesting contra aplicaciones en node.js – Parte 2.

julio 10, 2018 1 comentario

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 SSJI (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 SSJI, 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.

Instalación de un proxy TOR2WEB para acceder a servicios ocultos desde Internet

enero 22, 2015 2 comentarios

Seguramente muchos de los que leéis este blog y os interesan temas relacionados con el anonimato, TOR y cosas similares, conocéis el proyecto “TOR2WEB”, pero para los que no, basta con decir que es una plataforma creada por el equipo de TOR que permite que los servicios ocultos que se publican internamente en la web profunda de TOR se encuentren disponibles desde Internet sin necesidad de que el cliente tenga que arrancar una instancia de TOR en su máquina. Esto quiere decir que cualquier usuario corriente en internet, utilizando cualquier navegador web, podrá acceder a un servicio oculto muy fácilmente.

TOR2WEB está diseñado para funcionar como un proxy reverso, que solamente se encarga de enrutar todas las peticiones entrantes desde la “clear web” a la “deep web” de TOR, con lo cual los servicios ocultos siguen siendo ocultos, incluso para un proxy TOR2WEB. No obstante, el cliente que visita dichos contenidos no lo es, a menos claro, que utilice TOR para acceder a dicho proxy algo que que no tiene mucho sentido, ya que al utilizar TOR ya se tiene acceso a la web profunda de TOR y realmente no seria necesario utilizar TOR2WEB.

“tor2web.org” está conformado por voluntarios en todo el mundo que configuran y exponen un servicio de TOR2WEB para que cualquier usuario en Internet pueda utilizarlo. Dado que se trata de un proxy, no almacena los contenidos de los sitios ocultos, simplemente se encarga de enrutar las peticiones entre la web profunda de TOR y la “web clara”.

Acceder a un servicio oculto en la web profunda de TOR es simple, solamente hace falta sustituir la cadena “.onion” de la dirección del servicio oculto por “.tor2web.org”.

Por ejemplo, si la dirección onion de un servicio oculto es la siguiente: “ajio7mfsscpvgd23.onion” la dirección que se debe utilizar para acceder a dicho servicio utilizando TOR2WEB es: “ajio7mfsscpvgd23.tor2web.org”.

Lo primero que verá el usuario cuando navega hacia dicho sitio es una nota legal que indica que TOR2WEB es solamente un servicio de proxy que tira de la web profunda de TOR y que los contenidos que el usuario visualizará son responsabilidad del creador del servicio oculto al que se intenta acceder. Si el usuario está de acuerdo con los términos expuestos por el proxy, puede continuar y acceder a los contenidos del servicio oculto. La siguiente imagen enseña enseña dicha advertencia.

tor2web1

 

Por otro lado, la plataforma también almacena unas estadísticas básicas sobre el número de accesos que ha tenido el servicio oculto el día anterior, por cuestiones de privacidad y para no generar registros sobre el uso de un servicio oculto, solamente se pueden ver las estadísticas del día anterior y no se almacena nada sobre los datos de otros días. Para acceder a dicha información basta con entrar a la uri “/antanistaticmap/stats/yesterday”. Por ejemplo: “ajio7mfsscpvgd23.tor2web.org/antanistaticmap/stats/yesterday”.
Como se ha mencionado anteriormente, TOR2WEB es un servicio que se encuentra soportado por varios voluntarios en Internet, los cuales configuran una instancia del proxy de TOR2WEB con un dominio propio o con el dominio de TOR2WEB.

Aunque el procedimiento de instalación de un nodo de TOR2WEB es una tarea que se encuentra documentada y bastante bien explicada en la documentación oficial del proyecto, en este artículo explicaré en detalle cómo se puede instalar, configurar y arrancar un nodo de TOR2WEB.

Instalación y configuración de un nodo de TOR2WEB

Antes que nada, el proyecto se encuentra alojado en la siguiente URL: https://github.com/globaleaks/Tor2web-3.0 y se recomienda navegar un poco por cada una de las secciones de la documentación para tener una idea más global del funcionamiento de Tor2Web. En primer lugar es necesario instalar el proyecto y dado que se encuentra pensado principalmente para plataformas basadas en Debian, el mecanismo de instalación consiste adicionar un repositorio a la lista del sistema y posteriormente ejecutar el comando “apt-get” o “aptitute”. Existe un script de instalación que se encarga de realizar todas estas tareas de forma automática y que se recomienda utilizar.

>wget https://raw.githubusercontent.com/globaleaks/Tor2web-3.0/master/scripts/install.sh

>chmod +x install.sh

>./install.sh

Cuando se ejecuta el script pide permisos de administrador para instalar el programa utilizando “apt-get”. Después de realizar la instalación, automáticamente se crea el directorio “/home/tor2web/certs” que es donde se deberán crear los certificados y las claves para el proxy.
Se deben ejecutar los siguientes comandos dentro de dicho directorio.

>openssl genrsa -out tor2web-key.pem 4096

>openssl req -new -key tor2web-key.pem -out tor2web-csr.pem

>openssl x509 -req -days 365 -in tor2web-csr.pem -signkey tor2web-key.pem -out tor2web-intermediate.pem

>openssl dhparam -out tor2web-dh.pem 2048

 

Con los pasos anteriores se encuentra casi terminada la instalación, sin embargo antes de poder arrancar el servicio, es necesario crear un fichero de configuración en “/etc/tor2web.conf”. Dicho fichero no existe por defecto, pero después de instalar Tor2Web, se crea automáticamente un fichero de configuración que sirve de ejemplo en “/etc/tor2web.conf.example”. Las propiedades de configuración que incluye el fichero permiten activar o desactivar varias características interesantes de TOR2WEB, sin embargo, las siguientes son las mínimas que se deben de incluir en el fichero de configuración antes de iniciar el servicio.

nodename: Identificador único del servicio. Es bastante útil para identificar las trazas que se envían a los administradores de TOR2WEB.

datadir: Directorio donde se encuentran los ficheros necesarios para el correcto funcionamiento del programa, incluyendo los certificados creados anteriormente.

processes y requests_per_process: Propiedades que permiten ejecutar el programa utilizando multiproceso. El valor recomendado para la propiedad “processes” es el número de cores del sistema +1.

basehost: Se trata del dominio base donde se ejecutará el proxy. TOR2WEB se puede desplegar en un dominio independiente al de tor2web y en tal caso, es necesario especificar dicho dominio en esta propiedad.

listen_port_http y listen_port_https: Puertos HTTP y HTTPS que serán utilizados por el proxy. Evidentemente los valores por defecto son 80 y 443 respectivamente.

sockshost y socksport: Son probablemente las propiedades más importantes, ya que permiten definir el host y el puerto en el que se encuentra en ejecución un proxy SOCKS de TOR. Es evidente la importancia de dichos valores, ya que TOR2WEB utilizará dicho proxy SOCKS para conectarse con la web profunda de TOR y devolver al usuario final los contenidos del servicio oculto que ha solicitado. En este sentido, para lanzar un nodo de TOR2WEB, es necesario tener una instancia de TOR levantada.

ssl_key, ssl_cert y ssl_dh: Se trata de propiedades que permiten especificar la ruta completa de los certificados y la clave privada que se han creado anteriormente para el servicio.

Con las propiedades anteriores se puede comenzar a utilizar TOR2WEB, sin embargo existen otras propiedades que habilitan características especiales del programa, por ejemplo la posibilidad de bloquear servicios ocultos con contenidos inapropiados, bloquear crawlers, sobre-escribir el fichero “robots.txt” y otras cosas que intentan “alejar” el contenido de servicios ocultos de buscadores como google.

Para conocer en mayor detalle todas las opciones de configuración disponibles, se recomienda revisar la documentación en la siguiente sección. https://github.com/globaleaks/Tor2web-3.0/wiki/Configuration-Guide
Para iniciar un nodo de TOR2WEB con la configuración mínima, se puede utilizar el siguiente fichero

[main]
nodename = AdastraTORY
datadir = /home/tor2web
processes = 5
requests_per_process = 100000
listen_port_http = 80
listen_port_https = 443
basehost = tor2web.org
sockshost = 127.0.0.1
socksport = 9150
ssl_key = /home/tor2web/certs/tor2web-key.pem
ssl_cert = /home/tor2web/certs/tor2web-intermediate.pem
ssl_dh = /home/tor2web/certs/tor2web-dh.pem
cipher_list = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES128-SHA:DES-CBC3-SHA
ssl_tofu_cache_size = 100

 

Con el fichero anterior ubicado en “/etc/tor2web.conf” ahora es posible iniciar el servicio como cualquier otro del sistema

>sudo /etc/init.d/tor2web start
Enabling Tor2web Apparmor Sandboxing
* Starting Tor2web tor2web…
* Starting tor daemon… [ OK ]
>

Con los pasos anteriores, ahora ya contamos con una instancia en ejecución de TOR2WEB en local y disponible para desplegar en algún servidor en Internet.

Saludos y Happy Hack!
Adastra.

A %d blogueros les gusta esto: