Archive
Hoy vengo a hablar de mi libro: Deep Web: TOR, FreeNET & I2P – Privacidad y Anonimato
El día de hoy ha salido a la venta mi nuevo sobre anonimato y privacidad, el cual ha recibido el nombre de “Deep Web: TOR, FreeNET & I2P – Privacidad y Anonimato“. Se trata de mi tercera obra, la cual nuevamente ha sido publicada por la editorial 0xWORD. Me ha llevado un poco más de 7 meses redactar todo el contenido, tomar capturas de pantalla, realizar las pruebas, aplicar correcciones y ajustes y luego, a la editorial otros pocos meses más en la maquetación e impresión, que por cierto, me ha encantado. El proceso de redactar un libro y esforzarse para que sea lo más claro y ameno posible para el lector lleva tiempo, pero nuevamente ha sido una experiencia muy satisfactoria, especialmente considerando que era un tema sobre el que quería escribir desde hace años y el día de hoy finalmente, he podido ver mi texto publicado. Del mismo modo que con los dos libros de Python que he escrito, mi principal objetivo ha sido intentar incluir todo el contenido práctico posible, me gusta explicar todo por medio de ejemplos y por ese motivo, en el libro se podrán ver varias configuraciones aplicadas a las principales redes anónimas. También cuenta con un capítulo dedicado a la privacidad en Internet, más enfocado a “usuarios finales”, en el que se explica el uso de algunas VPN disponibles actualmente, complementos para navegadores, buenas practicas enfocadas a la privacidad, etc. Luego, hay un capítulo dedicado exclusivamente a redes I2P, Freenet y TOR respectivamente, el último capítulo es bastante más resumido y en él se habla sobre el uso de otras soluciones similares tales como GNUNet, Hyperboria, CJDNS, YaCy, entre otras.Este es mi tercer libro y sigo fomentando el habito de investigar, escribir y compartir, algo que llevo haciendo desde hace mucho tiempo y que personalmente me resulta de lo más entretenido, lo hago simplemente porque me apasiona. Como he comentado y seguramente muchos de vosotros os podéis imaginar, redactar un libro con estas características no es fácil, requiere de mucho tiempo y dedicación constante, pero para mi, hacer este tipo de cosas me resulta alentador y una motivación adicional para seguir adelante, especialmente después de volver del trabajo, a veces muy cansado y con poco animo por “perder” tanto tiempo del día sin hacer aquellas cosas que realmente te gustan, por sentir que estás desperdiciando tiempo valioso que podrías emplear en hacer cosas interesantes y que la mayor parte de tu energía se va en cumplir unos objetivos, que realmente no son los tuyos. En fin, seguramente muchos de vosotros sabéis de lo que hablo, pero francamente creo que lo importante es no desistir y continuar buscando alternativas que te puedan ofrecer esa libertad que cualquier persona con un poco de “espíritu hacker” siempre está anhelando.
Pluggable transports en TOR para la evasión de Deep Packet Inspection
Los puentes (bridges) son una de las formas más “tradicionales” de evadir la censura por parte de países y proveedores del servicio que intentan bloquear las autoridades de directorio y nodos de TOR. Se trata de un mecanismo que funciona bastante bien, ya que los puentes son direcciones que no se encuentran directamente relacionadas con TOR y aunque funcionan exactamente igual que cualquier repetidor, su información no se distribuye públicamente en ninguno de los descriptores emitidos por las autoridades de directorio. Aunque esta medida resulta bastante efectiva para evadir mecanismos de bloqueo simples basados en direcciones o dominios, en los últimos años se ha comenzado a ver que organismos censores implementan técnicas del tipo DPI (Deep Packet Inspection) para analizar el contenido de los paquetes en busca de cualquier indicio o patrón que les permita saber si el paquete en cuestión utiliza el protocolo de TOR. Evidentemente este tipo de técnicas suelen ser muy efectivas y permiten detectar y bloquear cualquier paquete de datos que utilice el protocolo de TOR.
Como siempre, nos encontramos en un constante “tira y afloje”, en el que los mecanismos de censura son mucho más complejos y efectivos, lo cual obliga a implementar técnicas de evasión que puedan ir un paso por delante. Dado que utilizar únicamente los bridges tradicionales ahora no es del todo efectivo (en algunos países), el equipo de TOR lleva unos años mejorando las técnicas de evasión y últimamente se ha venido hablando mucho sobre los Pluggable Transports (PT), cuyo principal objetivo es el de ofuscar el tráfico entre un origen y un bridge por medio de PTs. Dichos PTs se encargan de modificar los paquetes de datos para parezcan peticiones normales, ocultando cualquier indicio que permita descubrir de que se trata de un paquete de datos que hace parte de un flujo de TOR. La siguiente imagen simplifica el funcionamiento del sistema de PTs, el cual como se puede apreciar, no es demasiado complejo.
Funcionamiento de los Pluggable Transports en TOR
Pluggable Transports en TOR con Obsproxy
La especificación de “Pluggable Transports” está diseñada para que sea independiente de TOR u otras soluciones de anonimato e indica los pasos y directrices que debe seguir cualquier implementación de PTs. En el caso de TOR, existen varias implementaciones de PTs que se pueden utilizar, siendo Meek y ObsProxy las más soportadas y por supuesto, recomendadas.
Obsproxy es un framework escrito en Python que permite implementar PTs. Utiliza Twisted para todas las operaciones de red y la librería pyptlib la cual ha sido creada por el equipo de TOR específicamente para soportar las características de los PTs. Esta librería es especialmente interesante para aquellas aplicaciones que se encargan de transformar y ofuscar tráfico TCP y que requieren enviar dichos flujos de paquetes a un destino utilizando TOR.
Para utilizar Obsproxy en el lado del cliente (ver la imagen de arriba) se puede ejecutar TOR Browser Bundle, el cual contiene las implementaciones de los principales PTs soportados en TOR. En este caso concreto, Obsproxy y las otras implementaciones de PTs se encuentran incluidas en el directorio “<TOR_BROWSER/Browser/TorBrowser/Tor/PluggableTransports>”. Dichas implementaciones pueden utilizarse en modo cliente cuando se arranca Tor Browser y su configuración es prácticamente automática por medio de un asistente muy simple, el cual se inicia al abrir la configuración de Tor Browser.
Configuración del cliente de TOR Browser
Como se puede apreciar, existen dos posibles escenarios, o bien el cliente se encuentra “censurado” y sus peticiones se encuentran filtradas por medio de un proxy o el cliente cuenta con una conexión directa a Internet, con lo cual no tendrá mayores inconvenientes a la hora de conectarse a la red de TOR. En el segundo caso, el asistente de Tor Browser le permite al cliente especificar cuál tipo de PT desea utilizar y a continuación, se encarga de configurar al instancia para que utilice el PT adecuado.
Selección de un PT en Tor Browser
Después de seleccionar el tipo de PT la conexión a la red de TOR se hará por medio de los bridges que vienen por defecto en el Tor Browser y además, todas las peticiones se harán a un servidor OBSProxy por medio del cliente obfs3 local que se ha indicado. En el caso de que no sea posible realizar la conexión a la red de TOR utilizando los Bridges OBFS3 por defecto, Tor Browser indicará que hay un “censor” que se encuentra bloqueando las peticiones a dichas máquinas y en tal caso, se debe solicitar un conjunto de Bridges nuevo tal como se ha explicado en un artículo anterior.
El fichero “torrc” utilizado por Tor Browser habrá sufrido algunos cambios después de aplicar la configuración anterior y como se puede ver a continuación, dichos cambios incluyen el uso de Bridges OBFS3.
| Bridge obfs3 169.229.59.74:31493 AF9F66B7B04F8FF6F32D455F05135250A16543C9Bridge obfs3 83.212.101.3:80 A09D536DD1752D542E1FBB3C9CE4449D51298239
Bridge obfs3 169.229.59.75:46328 AF9F66B7B04F8FF6F32D455F05135250A16543C9 Bridge obfs3 109.105.109.163:47779 4C331FA9B3D1D6D8FB0D8FBBF0C259C360D97E6A Bridge obfs3 109.105.109.163:38980 1E05F577A0EC0213F971D81BF4D86A9E4E8229ED DataDirectory /home/adastra/tor-browser_es-ES/Browser/TorBrowser/Data/Tor GeoIPFile /home/adastra/tor-browser_es-ES/Browser/TorBrowser/Data/Tor/geoip GeoIPv6File /home/adastra/tor-browser_es-ES/Browser/TorBrowser/Data/Tor/geoip6 UseBridges 1 |
Por otro lado, en el combo en el que se puede seleccionar un PT, también se puede ver “meek-amazon”, “meek-azure” y “meek-google”. Probablemente el lector se preguntará qué significa eso, pues bien, el PT Meek se basa en HTTPS y se encarga de modificar el tráfico de TOR para que las peticiones parezcan “inocentes” y en este caso concreto, “meek-amazon” se encarga de transformar las peticiones para que parezca que el usuario se encuentra interactuando con la plataforma de Amazon Web Services, “meek-azure” para que parezca que las peticiones se realizan contra la plataforma de servicios web de Microsoft Azure y finalmente “meek-google” modifica los paquetes de datos para que parezca que las peticiones realizadas por el cliente, son simplemente búsquedas en Google. Si bien es un PT muy interesante, actualmente hay varios detalles que se encuentran en estado de desarrollo y la cantidad de PTs del tipo servidor (puentes) es bastante pequeña, por ese motivo siempre se recomienda utilizar el PT de ObsProxy. Sobre Meek se hablará con mayor detalle en un próximo artículo y aunque aquí solamente se ha mencionado la configuración básica del lado del cliente para utilizar un PT con TOR, aun queda haciendo falta explicar la forma en la que se pueden crear Bridges PT que aporten a los usuarios de la red de TOR que se encuentran censurados, esto también lo explicaré en el próximo artículo.
Saludos y Happy Hack!
Adastra.
Generación personalizada de direcciones ONION de TOR con Shallot
Las direcciones ONION en TOR son cadenas con una longitud exacta de 16 caracteres, compuestas por los dígitos entre 2-7 y las letras en minúsculas de a-z. Dichas direcciones generalmente se crean de forma automática por cualquier cliente de TOR, pero en ocasiones, se pueden encontrar sitios en la web profunda de TOR con direcciones ONION que no parecen ser tan aleatorias como la mayoría, en ocasiones tienen patrones fijos que determinan el contenido y/o temática del servicio oculto. Un ejemplo es Facebook, que cuenta con un servicio oculto en la web profunda de TOR para aquellos que quieran acceder a esta popular red social y ya de paso, perder su privacidad y probablemente el anonimato que brinda TOR. La dirección ONION de facebook en la web profunda de TOR es esta: facebookcorewwwi.onion y como se puede apreciar, existe un patrón bastante claro que además, resulta fácil de memorizar. Ahora bien, lo cierto es que personalizar la dirección completa (16 caracteres) con la capacidad de computo que tenemos actualmente resulta imposible, tal como comentaba en un articulo que he escrito hace algún tiempo, calcular y en consecuencia, descubrir un servicio oculto en TOR, puede llevar millones de años, una escala de tiempo que evidentemente no es tolerable. No obstante, si que se puede personalizar una parte de dicha dirección en poco tiempo, todo depende del número de caracteres que se quiera aplicar al patrón. Para hacer esto, existe una herramienta muy fácil de instalar y utilizar, dicha utilidad es Shallot.
INSTALACIÓN Y USO DE SHALLOT
Shallot es una herramienta que permite aplicar un patrón para personalizar una parte de la dirección ONION de un servicio oculto. Los patrones que se pueden aplicar típicamente son expresiones regulares que permiten indicar la forma en la que se debe generar la clave privada del servicio oculto y en consecuencia, la dirección ONION del mismo. Es un programa que se encuentra escrito en lenguaje C y solamente tiene dos dependencias: libssl y libcrypto, librerías que son bastante comunes en sistemas Linux. El proyecto se puede descargar desde GitHub y el proceso de instalación es tan simple como ejecutar “configure” y “make”
| >git clone https://github.com/katmagic/Shallot.git
>./configure |
Las opciones que admite Shallot se pueden ver a continuación
| >./shallot
Usage: shallot [-dmopv] [-f <file>] [-t count] [-x time] [-e limit] pattern -d : Daemonize (requires -f) -m : Monitor mode (incompatible with -f) -o : Optimize RSA key size to improve SHA-1 hashing speed -p : Print ‘pattern’ help and exit -f <file> : Write output to <file> -t count : Forces exactly count threads to be spawned -x secs : Sets a limit on the maximum execution time. Has no effect without -m -e limit : Manually define the limit for e Version: 0.0.3-alpha |
El interruptor “-p” puede ser útil para conocer algunos de los patrones (expresiones regulares) que se pueden aplicar con Shallot.
| ./shallot -p
base32 alphabet allows letters [a-z] and digits [2-7] pattern can be a POSIX-style regular expression, e.g. xxx must contain ‘xxx’ bar$ must end with ‘bar’ ^foo must begin with ‘foo’ b[a4]r may contain leetspeech😉 ^ab|^cd must begin with ‘ab’ or ‘cd’ [a-z]{16} must contain letters only, no digits ^dusk.*dawn$ must begin with ‘dusk’ and end with ‘dawn’ |
Como se puede apreciar, algunas de las expresiones de ejemplo permiten aplicar patrones muy variados, como por ejemplo que la dirección ONION debe comenzar y/o terminar con una cadena determinada, que contenga solamente números o letras o que contenga en cualquier posición de la dirección una cadena determinada.
También existen otras opciones que permiten controlar el tiempo máximo en el que se debe ejecutar la herramienta, si se debe ejecutar como un proceso en “background” y si el resultado (clave privada para el servicio oculto) se debe almacenar en un fichero. Algunos ejemplos del uso de estos interruptores se enseña a continuación
| >./shallot -f /home/adastra/private_key ^hack
>./shallot -m -o ^hacker >./shallot -m -t 15 ^hacker |
En todos los casos, después de procesar y descubrir una clave privada cuya dirección ONION generada contenga el patrón, se pinta por pantalla o se crea un fichero con dicha clave privada para que sea utilizada por un servicio oculto.
Como comentaba antes, el número de caracteres especificados en el patrón es importante y determina si es posible obtener una clave privada que encaje con el patrón y cuánto tiempo puede tardar el calculo de dicha clave. En el proyecto de GitHub de Shallot se enseña la siguiente tabla que nos da una idea del número de caracteres que podemos personalizar en la dirección ONION.
| characters | time to generate (approx.) |
| 1 | less than 1 second |
| 2 | less than 1 second |
| 3 | less than 1 second |
| 4 | 2 seconds |
| 5 | 1 minute |
| 6 | 30 minute |
| 7 | 1 day |
| 8 | 25 days |
| 9 | 2.5 years |
| 10 | 40 years |
| 11 | 640 years |
| 12 | 10 millenia |
| 13 | 160 millenia |
| 14 | 2.6 million years |
Las pruebas anteriores las ha realizado el autor con un ordenador de 1.5Gh de procesador. Si bien es cierto que se puede utilizar ordenadores mucho más potentes, las estimaciones anteriores no sufren cambios considerables con una mayor capacidad de computo, además, solamente se ha llegado a calcular hasta 14 caracteres, la cifra con 15 y 16 caracteres puede llegar a billones de años. Muchísimo más de lo que estamos dispuestos a esperar, por mucho que estemos acostumbrados a utilizar sistemas Windows.
Suponiendo que se utiliza un patrón con pocos caracteres, se puede generar una clave privada en muy poco tiempo, de hecho, las dificultades comienzan a partir de 7 o 8 caracteres, pero cualquier patrón que esté por debajo de dicho valor, puede ser procesado por Shallot en un tiempo bastante razonable.
Uno de los resultados que da la herramienta tras aplicar el patrón “^hack” es el siguiente
| —————————————————————-
Found matching domain after 998147 tries: hacktkeocgipcjvv.onion —————————————————————- —–BEGIN RSA PRIVATE KEY—– MIICWwIBAAKBgQCmZx9BMoG55KOoyAa0T43rNRW4z8m9vjgdXRxX2ZOaFMbrMITC U6zm5CaauB0RYvu0m99/J9YhfXJQor69/YUIWMWGOXdn3CfVPML5kJWdCF68jhyE qmPJAaTuodv7rwlB0KyTzOYUGNLDN/yZey9aG2CKWLfTX/w3Aq7c/6Y20QIDBKSB AoGABFqfSWmx3CIHU40PJCv2ecf61m7LZcAQErvXddYZDCodEYKXDypWJZatQjKm Whl9DGCZIMR3jpfVrKlIVjwT8+ERk35DXdRGzWi0n/y8be5XokYMnTreEbkcsprR H8TeN6cJPwrjgXnd4g9Z2q9luKkDegdGLbsKY9nnh8lf5oUCQQDZi+lDL7S/jEoX k5Xs805cTLPnqdGT0RelivchoGm03U2ggIUycCLv0SM6VaRcKNsBrGBtWg5jznu9 Xm9865xvAkEAw9DuwqkXK+WixHVY+uoT+LUHmBRJiVV+ZHKUzCOvF4yTxqGNCMAM LcuCZtiamFbA4YQnBHAMRpMJt12/OSuAvwJAQjs2GYeqUmYE0MFt99KYhA2HHDny DpSzwriBqAKC/lzk/SnEyYw5nBb/+zLYS3+zNUEAEZ8ktwIF1eFVriczdQJAE6qG q9J5kLbmVuyhkBB0zO5hcCE5EFVren5/XUGrzOz1hJbv4Q+9TkqDO3xaQ/v+iIqt hmu8XPNRhi50Q4vXhwJAQywFaZosVqFLUPJB4AmMeKQ2nPHpSLVVWFVPNNTypDZC LDJgX849UGd0Nu9bCTWFtJaFROGUOa8U2cIsa8N6iQ== —–END RSA PRIVATE KEY—– |
A continuación, solamente es necesario incluir el contenido anterior en un fichero con nombre “private_key” que se deberá ubicar en el directorio que se declara en la propiedad “HiddenServiceDir” del fichero de configuración de TOR (torrc).
| HidenServiceDir /home/adastra/servicioOculto
HiddenServicePort 80 127.0.0.1:80 |
Con las dos directivas anteriores se define un servicio oculto que va a procesar peticiones de los clientes por el puerto 80 en la dirección ONION generada. En este caso, el fichero “private_key” con la clave RSA generada por Shallot debe ubicarse en el directorio “/home/adastra/servicioOculto”. Una vez hecho esto, basta con arrancar la instancia de TOR utilizando el fichero torrc con las directivas anteriores y se podrá ver que en el directorio “/home/adastra/servicioOculto” existe un nuevo fichero llamado “hostname”, con la dirección ONION generada a partir de la clave privada definida en el fichero “private_key”.
Con estos sencillos pasos se puede personalizar una parte de la dirección ONION de un servicio oculto en TOR, algo que en algunos casos viene bien para tener direcciones que sean un poco más fáciles de recordar y compartir.
Saludos y Happy Hack!
Adastra.
Pentesting contra servicios ocultos en TOR – Parte 2
Tal como mencionaba en el artículo anterior sobre pentesting contra servicios ocultos en TOR, es posible que algunos crean que atacar un servicio oculto es una tarea compleja y que requiere de muchos conocimientos para llevarla a cabo, pero lo cierto es que no difiere de un proceso de pentesting convencional. Es importante tener en cuenta que cualquier servicio en la web profunda de TOR puede contener vulnerabilidades criticas que pueden afectar a su desempeño y seguridad, sin embargo, son muchos los usuarios de TOR, I2P o Freenet que creen que por utilizar este tipo de redes ya se encuentran “protegidos” y relajan o descuidan la seguridad de los servicios ocultos que crean y administran. Esto es un error y cualquier servicio que contenga vulnerabilidades puede ser igualmente explotable, aunque se encuentre en la “cyphernet” de TOR o I2P.
En el artículo anterior se explica como utilizar SOCAT para crear un túnel entre la máquina local y el servicio oculto que se desea atacar, utilizando por medio el proxy socks que típicamente se levanta cuando se arranca una instancia de TOR. Este es el mecanismo más sencillo y eficaz que se puede utilizar para realizar pruebas de pentesting contra servicios ocultos, no obstante es necesario mapear en puertos distintos cada una de las direcciones ONION que se desea atacar, no es cómodo pero desde luego resulta sencillo y fácil de implementar. En el post anterior explicaba cómo hacer esto contra un servicio oculto del tipo HTTP, el cual era soportado por una aplicación web vulnerable con Django-moth. En dicho post se explicaba el uso de Nikto y W3AF para comprometer el servicio oculto y ya de paso su anonimato, pero también es posible hacer esto mismo con otros servicios ocultos que no son el típico servidor web, sino también con cualquier servidor que funcione utilizando protocolo TCP. En este artículo se realizarán pruebas sencillas contra servicios ocultos del tipo FTP y SSH
Atacando un servicio oculto en TOR del tipo FTP
Existen muchas implementaciones del protocolo FTP tanto desde el lado del cliente como desde el lado del servidor y también, han sido muchas las vulnerabilidades que se han encontrado y explotado en dichas implementaciones. Si un servidor FTP vulnerable se expone en la web profunda de TOR, es probable que pueda seguir siendo utilizado sin mayores problemas en el caso de que solamente un grupo reducido de usuarios conozca su dirección ONION y no pretendan vulnerarlo, pero si un atacante descubre dicha dirección ONION no tardará demasiado en hacerse con el control de dicho servicio.
Las directivas utilizadas para crear un servicio FTP no son diferentes a las de cualquier otro tipo de servicio oculto, lo único que probablemente cambiará será el puerto y obviamente el directorio.
| HiddenServiceDir /home/adastra/Escritorio/hidden_service_ftp/HiddenServicePort 21 127.0.0.1:21 |
Las líneas anteriores se incluirán en el fichero “torrc” y en la máquina donde se levanta la instancia de TOR, deberá existir un proceso vinculado al puerto 21. La dirección ONION generada, también responderá únicamente a las peticiones entrantes por el puerto 21.
Nuevamente se puede utilizar SOCAT para crear un túnel entre el servicio oculto y la máquina del atacante, pero eso si, es necesario que en la máquina del atacante se arranque una instancia de TOR que tenga la propiedad SOCKSPort establecida (bastante frecuente) para poder utilizar dicho proxy SOCKS y conseguir llegar al servicio oculto.
| >socat TCP4-LISTEN:8000,reuseaddr,fork SOCKS4A:127.0.0.1:ondsyq4v4xcr6ct6.onion:21,socksport=9150 |
El puerto que se abrirá en la máquina del atacante será el 8000 y cualquier petición que llegue a dicho puerto, será automáticamente enrutada al servicio oculto en el puerto 21 cuya dirección ONION es “ondsyq4v4xcr6ct6”, evidentemente para que dicho enrutamiento funcione correctamente se debe establecer el proxy SOCKS, que en este caso es el puerto 9150 (puerto por defecto que utiliza TOR Browser).
Con todos los elementos dispuestos, se puede utilizar cualquier herramienta para realizar pruebas de penetración contra el servicio oculto, no obstante antes de hacer nada, es mejor comprobar que el túnel funciona correctamente y para ello, basta con realizar una petición al servidor FTP utilizando cualquier cliente.
Conexión con el servicio oculto del tipo FTP utilizando SOCAT.
Después de verificar que la conexión se puede establecer, se puede utilizar una herramienta como Metasploit Framework para realizar pruebas automatizadas utilizando los módulos auxiliares que se encuentran incluidos en el framework.
Ejecutando el módulo “auxiliary/scanner/ftp/ftp_login” de MSF contra el servicio oculto FTP
Ejecutando otros módulos auxiliares de MSF contra el servicio oculto FTP
Atacando un servicio oculto en TOR del tipo SSH
SSH es un protocolo bastante conocido y utilizado por prácticamente todos los administradores de sistemas y también es un protocolo muy utilizado en la web profunda de TOR. No es sencillo encontrar direcciones ONION con este tipo de servicios, pero hay bastantes y a veces no se encuentran debidamente configurados. Como mencionaba antes, la principal dificultad a la hora de atacar los servicios ocultos en TOR es que es muy difícil encontrar la dirección ONION de un servicio a atacar y más aun cuando se trata de servicios cuyas funciones son principalmente de administración, como es el caso de cualquier servicio SSH, normalmente son direcciones ONION que solamente las conocen aquellas personas que crean el servicio oculto y que intentan administrar sus servidores de forma remota y anónima. Sin embargo, una vez se descubre la dirección del servicio oculto en cuestión, nuevamente basta con crear un túnel cuyo endpoint será el servicio oculto y a continuación realizar pruebas de pentesting con las herramientas habituales. Suponiendo que la dirección del servicio oculto SSH a atacar es “klebohg2zv4b5j5u”, la siguiente imagen enseña la forma en la que se debe crear el túnel con SOCAT y cómo utilizar el cliente SSH en sistemas Linux para realizar la conexión contra el servicio oculto.
Conexión al servicio oculto del tipo SSH
Después de verificar que el servicio se encuentra activo y que el túnel enruta las peticiones adecuadamente, se puede realizar un proceso de pentesting básico utilizando MSF.
Ejecutando el módulo “ssh_version” de MSF contra el servicio oculto.
Ejecutando el módulo “ssh_enumusers” de MSF contra el servicio oculto.
Ejecutando el módulo “ssh_login” de MSF contra el servicio oculto.
Además de utilizar MSF también se pueden utilizar otras herramientas comunes, como por ejemplo THC Hydra.
Ataque de fuerza bruta contra el servicio oculto utilizando THC Hydra.
Como se puede apreciar, realizar procesos de pentesting contra servicios ocultos en TOR no es una tarea demasiado compleja, aunque si que lo es descubrir las direcciones dichos servicios ocultos. Muchas veces creemos que por utilizar TOR las vulnerabilidades o una mala configuración del sistema es menos evidente o será más difícil de explotar. La realidad es que un servicio oculto en TOR o en cualquier otra red anónima es perfectamente explotable si dicho servicio contiene alguna vulnerabilidad, los vectores de ataque no cambian, solamente cambia el medio utilizado por el atacante.
Si tienes publicado un servicio oculto en cualquier red anónima, presta atención a las vulnerabilidades o malas configuraciones que pueda tener.
Un saludo y Happy Hack!
Adastra.
Pentesting contra servicios ocultos en TOR – Parte 1
El sábado 30 de mayo realice una pequeña charla con los chicos de GR2Dest en la que hablé sobre anonimato con TOR y pentesting contra servicios ocultos. En dicha charla me centre especialmente en actividades de pentesting contra servicios ocultos en la red de TOR y si bien es cierto que no es algo complicado, creo que muchas personas no saben o no entienden como hacerlo. Por ese motivo me he animado a escribir un par de artículos explicando la forma en la que puedes utilizar algunas de las herramientas de pentesting más habituales para atacar los servicios ocultos que se encuentran en la red de TOR. Este es el primero de ellos, espero que sea de tu agrado y te resulte informativo.
Antes de comenzar, intentaré aclarar algunas cuestiones que son importantes sobre TOR. Tal como mencionaba en el artículo ataca un servicio oculto si te atreves los servicios ocultos en TOR se registran en las autoridades de directorio, donde cada registro se incluye en una tabla hash que se compone por la clave pública del servicio y su dirección onion, la cual estará compuesta por letras entre la a y la zeta en minúsculas y los números entre 2 y 7. Este valor se genera al aplicar el algoritmo Base32 sobre el hash SHA de la clave privada del servicio oculto. Suena complejo, pero en realidad es algo de lo que no tenemos que preocuparnos ya que el cliente de TOR se encarga de la generación de la dirección onion de forma automática. No obstante, conocer esa dirección “onion” es otra historia y ahí es donde reside la verdadera dificultad de atacar servicios ocultos en TOR: Su disponibilidad y que en algunos casos, solamente unos pocos usuarios tienen conocimiento de las direcciones que utilizan para transmitir información. Por poner un ejemplo, imaginaros por un segundo a un grupo de islamistas radicales que necesitan transferir documentos e información entre ellos y que se encuentran ubicados en distintos países. Evidentemente, su dios les exige que luchen contra el infiel y se oculten adecuadamente si quieren disfrutar de las 40 mujeres (o cabras) que están reservadas para ellos en el paraíso, por ese motivo el anonimato es una de sus prioridades principales. En este sentido, solamente un grupo reducido de usuarios conocen la dirección del servicio que utilizarán para intercambiar información y adicionalmente, dicho servicio puede estar disponible en una franja horaria determinada y el resto del tiempo puede encontrarse inactivo, con lo cual las probabilidades de que el servicio sea encontrado por cualquier usuario en la red de TOR son realmente bajas. En Tortazo, existe el modo “onion repository” que intenta descubrir direcciones de forma aleatoria o incremental y aunque funciona de un modo similar a otras aplicaciones como Shallot (https://github.com/katmagic/Shallot) el problema del descubrimiento sigue estando latente.
No obstante, si conoces la dirección ONION del servicio que quieres atacar, las cosas cambian muchísimo, ya que puedes utilizar las herramientas de pentesting que utilizas para auditar cualquier servicio en Internet. Puedes usar Metasploit Framework, W3AF, OpenVAS, NeXpose, Nikto, Nmap, etc, etc. Lo único que necesitas es conocer la dirección ONION del servicio que quieres atacar y arrancar una instancia de TOR levantando un proxy SOCKS. El mecanismo es muy sencillo, basta con crear un túnel que permita conectar el servicio oculto con un puerto arbitrario en la máquina local utilizando el proxy SOCKS levantado por la instancia de TOR. A partir de aquí, basta con ejecutar las herramientas anteriormente mencionadas o cualquier otra contra un puerto en la máquina local. Es tan fácil como suena y no requiere de configuraciones especiales. Eso si, todo debe funcionar con protocolo TCP, ya que UDP o ICMP no se encuentran soportados por TOR. En este artículo, explicaré cómo atacar un servicio HTTP utilizando herramientas de pentesting comunes.
Atacando un servicio oculto en TOR del tipo HTTP
Crear un servicio oculto en TOR no tiene ninguna dificultad, basta con especificar las directivas “HiddenServiceDir” y “HiddenServicePort” en el fichero de configuración utilizado para arrancar la instancia de TOR y poco más. Evidentemente, tienes que tener un servidor ejecutándose en el puerto indicado, de lo contrario solamente tendrás una dirección ONION pero nada que responda a las peticiones de los clientes.
Al utilizar las propiedades anteriores, la instancia de TOR se encargará de crear el directorio del servicio oculto y en él incluirá la clave privada del servicio (private_key) y el fichero en el que se incluye la dirección onion del servicio (hostname). En el caso de que el directorio indicado en la propiedad “HiddenServiceDir” ya exista, la instancia de TOR entiende que el servicio ha sido creado previamente y no intenta machacar el directorio, por el contrario, intenta utilizar los ficheros que en él se encuentran incluidos (hostname y private_key). Las siguientes directivas pueden ser utilizadas el fichero de configuración “torrc” que se utilizará para levantar la instancia de TOR.
| HiddenServiceDir /home/adastra/Escritorio/hidden_service_django/HiddenServicePort 80 127.0.0.1:8080 |
Como se puede apreciar, es realmente simple. No requiere ninguna otra opción de configuración adicional, aunque evidentemente en el fichero “torrc” se incluirán muchas más opciones de configuración para personalizar el comportamiento de la instancia, pero esa es otra historia.
En el directorio “/home/adastra/Escritorio/hidden_service_django/ ” se crearán dos ficheros (hostname y private_key) que contienen la dirección ONION del servicio y su clave privada. Por otro lado, cuando un usuario de TOR ingrese a la dirección ONION del servicio por el puerto “80”, la instancia de TOR que recibe dicha petición se encargará de redirigirla al endpoint correspondiente, que en este caso será la máquina local en el puerto “8080”. Evidentemente, es necesario arrancar un servicio en dicho puerto y dicho servicio puede ser de cualquier tipo (SSH, HTTP, SMB, FTP, etc.) Lo que realmente importa es que funcione sobre TCP.
En este caso, para demostrar el uso de algunas herramientas de pentesting contra un servicio oculto vulnerable en la web profunda de TOR, vamos a arrancar una aplicación web con múltiples vulnerabilidades que utiliza el equipo de W3AF para realizar pruebas, dicha aplicación web vulnerable es Django-moth (https://github.com/andresriancho/django-moth)
| >python manage runserver 8080 |
Después de arrancar la aplicación, se podrá acceder al servicio oculto utilizando cualquier otra instancia de TOR que permita el acceso a la web profunda de TOR, como por ejemplo “TOR Browser”.
Django-moth como servicio oculto en la red de TOR
Ahora que el servicio vulnerable se encuentra levantado y es accesible en la web profunda de TOR, lo siguiente es intentar atacar dicho servicio de la misma forma que atacamos cualquier aplicación o servidor web en Internet por medio de herramientas de pentesting comunes. Utilizar herramientas de reconocimiento para aplicaciones web puede ser un buen inicio, como por ejemplo Nikto o algún script NSE de Nmap. No obstante, antes de hacerlo es necesario aplicar algún mecanismo para acceder a cualquier servicio oculto en la web profunda de TOR utilizando dichas herramientas. Para hacer esto, pueden aplicarse 2 enfoques, o bien la herramienta que se va a utilizar soporta el enrutamiento de peticiones por medio de un proxy SOCKS (algo que no todas soportan) o crear un túnel transparente que permita enrutar todas las peticiones al servicio oculto utilizando el proxy SOCKS levantado por una instancia de TOR (siempre y cuando dicha instancia tenga activa la propiedad SOCKSPort). La segunda alternativa resulta ser la más fiable, ya que no hay que aplicar ningún tipo de configuración adicional para que las herramientas funcionen correctamente, todo se hace de forma transparente por medio del proxy SOCKS de la instancia de TOR.
Para montar un túnel de estas características hay varias alternativas, una de ellas es creando un túnel SSH y habilitando el soporte para servidores proxy (algo bastante común en OpenSSH), utilizando un proxy transparente con librerías como Twisted o utilizando directamente SOCAT. Dado que utilizar SOCAT es lo más cómodo, fácil y conveniente, es una de las mejores alternativas.
| >socat TCP4-LISTEN:7000,reuseaddr,fork SOCKS4A:127.0.0.1:fieqd7c2ljyyo54f.onion:80,socksport=9150 |
El comando anterior abrirá el puerto “7000” en la máquina local y utilizará el puerto 9150 (Proxy SOCKS de TOR) para enrutar todas las peticiones entrantes por el puerto “7000” al servicio oculto en el puerto 80. Esto se traduce a que se puede utilizar cualquier herramienta de pentesting web tirando directamente contra la máquina local en el puerto “7000” y SOCAT se encargará de redirigir todas peticiones realizadas desde dicho puerto al servicio oculto definido. Además de enrutar las peticiones desde el cliente hacia el endpoint (servicio oculto) otra de las características que tiene SOCAT es que los túneles creados con esta herramienta son bidireccionales, es decir, que no solamente es capaz de enrutar las peticiones a su correspondiente destino, sino que también es capaz de transmitir las respuestas que emite el servidor. A partir de aquí, realizar un proceso de pentesting contra el servicio oculto es mucho más fácil.
Utilizando Nikto contra un servicio oculto en la red de TOR.
Dado que en este caso concreto el servicio oculto se encuentra soportado por la aplicación web vulnerable Django-moth, qué mejor forma de atacarlo que utilizando W3AF.
|
>./w3af_console w3af>>> plugins audit os_commanding w3af>>> target set target http://localhost:7000/audit/os_commanding/param_osc.py?param=-la w3af>>> start OS Commanding was found at: “http://localhost:7000/audit/os_commanding/param_osc.py”, using HTTP method GET. The sent data was: “param=%7C%2Fbin%2Fcat%20%2Fetc%2Fpasswd” The modified parameter was “param”. This vulnerability was found in the request with id 39. Scan finished in 14 seconds. Stopping the core… |
Como se puede apreciar, se ha encontrado una vulnerabilidad y se ha registrado en la “Knowledge Base” de W3AF. A continuación, se puede intentar explotar dicha vulnerabilidad utilizando el plugin “os_commanding”
Generando una consola contra el servicio oculto vulnerable utilizando W3AF
Como se puede apreciar, se ha generado una consola contra el servicio oculto utilizando W3AF. A partir de aquí, el atacante podrá ejecutar comandos directamente contra el servicio oculto vulnerable y de esta forma, romper su anonimato.
Ejecutando comandos directamente contra el servicio oculto.
En este caso se está atacando a un servicio oculto del tipo HTTP, pero en la web profunda de TOR existen toda clase de servicios vulnerables, los cuales evidentemente también se pueden comprometer. Algunos de ellos los explicaré en el próximo post.
Un saludo y Happy Hack!
Adastra.
Bridges en TOR y una introducción a los “Pluggable transports”
TOR se caracteriza por ser una red centralizada, en la que cada hora, una serie de servidores de confianza llamados “autoridades de directorio” se encargan de generar información sobre los repetidores que conforman la red y algunos datos adicionales sobre el estado general de la misma. Dicha información es pública y se puede consultar fácilmente ejecutando peticiones HTTP contra cualquiera de las autoridades de directorio o sus espejos. Dado que la información sobre los repetidores la puede consultar cualquiera, una de las principales medidas que toman las entidades represoras a la hora instaurar controles y censurar contenidos, consiste simplemente en incluir dichas direcciones IP en una lista negra para impedir que se puedan realizar conexiones contra cualquier repetidor de TOR. Es una medida que se utiliza muchísimo y que según algunos artículos publicados en el blog de TOR (https://blog.torproject.org/) es una de las medidas más utilizadas en países como Cuba, China, Etiopía, Corea del Norte, etc. Con el fin de hacer que la red sea resistente a este tipo de censura, el equipo de TOR ha desarrollado un sistema para que los ciudadanos de países como los anteriores puedan seguir utilizando TOR sin problemas, aunque las direcciones IP de los repetidores incluidos en los consensos o incluso las direcciones IP de las autoridades de directorio se encuentren bloqueadas. Dicho sistema es conocido como “Automatic Bridging” y es un mecanismo en el que se busca eludir la censura por parte de adversarios fuertes, como es el caso del gobierno de un país. Para conseguir esto, las autoridades de directorio utilizan unos repetidores especiales llamados “Bridges” o puentes, los cuales funcionan exactamente igual que cualquier repetidor que hace parte de un circuito en TOR, pero con la diferencia de que no se exponen públicamente en los descriptores emitidos cada hora por las autoridades de TOR. Los bridges pueden ser creados por cualquier usuario de TOR y si estás a favor de la libertad de expresión y te asquea ver como en ciertos países la gente no puede expresar libremente sus ideas sin temor a que sus vidas o las de sus familiares corran peligro, te recomiendo que configures tus instancias de TOR para que también funcionen como puentes y sean utilizadas por aquellas personas que desean reportar los abusos que se comenten en ciertos lugares del mundo.
Para aquellos que desean obtener un listado de bridges de TOR, dado que no se pueden conectar directamente con las autoridades de directorio o con los repetidores que conforman la red, existen dos formas:
1. Consultar los puentes en “BridgeDB”, el proyecto oficial de TOR para acceder a un conjunto reducido de puentes que servirán para eludir la censura. Dicho proyecto se encuentra ubicado en el siguiente enlace: https://bridges.torproject.org. Para obtener los bridges basta con pinchar sobre el botón en el que pone “Get Bridges” u “Obtener puentes” y después de ingresar un captcha, se enseñarán dos puentes que deben ser configurados en la instancia de TOR que no consigue llegar a las autoridades de directorio o a los repetidores de la red.
2. En el caso (bastante frecuente) de que el proyecto “BridgeDB” también se encuentre censurado, la otra alternativa para recibir un par de puentes validos es escribir un correo a la dirección “bridges@torproject.org”. El mensaje no tiene que tener un contenido, es simplemente una dirección de correo que responde de forma automática al remitente con lo que ha solicitado. En el asunto del mensaje se debe especificar un “comando” para obtener información sobre BridgeDB. Si se envía un mensaje a dicha dirección, sin asunto, la respuesta automática contendrá los posibles comandos que puede enviar el comando a la plataforma de BridgeDB.
El contenido del mensaje devuelto, en el caso de no incluir un asunto es el siguiente:
|
” Hey, debiadastra! Welcome to BridgeDB! COMMANDs: (combine COMMANDs to specify multiple options simultaneously) Currently supported transport TYPEs: BridgeDB can provide bridges with several types of Pluggable Transports[0], Some bridges with IPv6 addresses are also available, though some Pluggable Additionally, BridgeDB has plenty of plain-ol’-vanilla bridges – without any [0]: https://www.torproject.org/ |
En el caso de indicar el asunto “get bridges”, lo que se puede ver es lo siguiente:
|
“Hey, debiadastra! [This is an automated message; please do not reply.] Here are your bridges: 83.212.111.114:443 0A6EF34EDF047BFD51319268CD423E To enter bridges into Tor Browser, first go to the Tor Browser download When the ‘Tor Network Settings’ dialogue pops up, click ‘Configure’ and follow > Does your Internet Service Provider (ISP) block or otherwise censor connections Select ‘Yes’ and then click ‘Next’. To configure your new bridges, copy and [0]: https://www.torproject.org/ |
Como se puede ver, ha devuelto tres repetidores con la dirección IP, puerto y fingerprint del puente. Ahora, para que una instancia de TOR pueda utilizar dichos puentes, basta con especificar las siguientes líneas de configuración en el fichero “torrc”.
|
Si estas interesado en crear tu instancia de TOR para que funcione como puente, el procedimiento es bastante sencillo, sin embargo, no se puede configurar una instancia de TOR que funcione como repetidor y puente al mismo tiempo, lo cual es lógico, ya que los repetidores son públicos y los puentes privados y establecer una instancia que actúe como repetidor y puente es equivalente a crear un puente de acceso público y fácil de censurar, lo cual evidentemente no tiene ningún sentido.
Es necesario incluir las siguientes líneas de configuración en el fichero “torrc”:
| SocksPort 0
ORPort 8080 Exitpolicy reject *:* DataDirectory /home/adastra/workspace/bridge/ BridgeRelay 1 |
Como se puede ver, tanto configurar como utilizar un puente es una tarea bastante simple y es una solución que se ajusta bastante bien al problema de la censura. Sin embargo, algunos “rivales fuertes”, tales como los gobiernos de China o Corea del Norte, ahora ya no solamente bloquean las direcciones IP que se encuentren relacionadas con la red de TOR, ahora aplican técnicas de análisis de paquetes que detectan si los paquetes intercambiados utilizan el protocolo de TOR. Ante una medida así, los puentes por si solos pierden efectividad y se hace muy difícil ocultar el trafico. Aquí entra en juego lo que se conoce como “Pluggable Transports”.
Introducción a los Pluggable Transports
Las técnicas DIP (Deep Packet Inspection) se han vuelto cada vez más comunes en aquellos países en los que el nivel de censura es alto. Las rutinas DIP se encargan de analizar un conjunto de paquetes y reensamblarlos para clasificarlos partiendo de patrones conocidos. De esta forma, con DIP es posible determinar que un conjunto de paquetes se encuentran transmitiendo datos en la red de TOR aunque la dirección IP no se encuentre bloqueada.
Ahora bien, la especificación de “Pluggable Transports” define a esta tecnología como la capacidad de convertir flujos de trafico de TOR entre el cliente y un puente, en flujos admitidos y no reconocidos por técnicas de DIP, como por ejemplo, una conversación inocente con cualquier servidor web en Internet. Notar que aunque el rival (censor), pueda monitorizar el trafico y analizar los paquetes en profundidad, no verá ningún patrón conocido que le permita determinar con exactitud que se trata de un paquete que viaja por TOR.
El objetivo de los PT (Pluggable Transports) consiste básicamente en ofuscar el trafico entre el cliente y sus puentes. Para ello, se utiliza un componente de software adicional tanto en el cliente como en la instancia de TOR que funciona como puente. Dichos componentes deben conocer una serie de reglas para poder ofuscar el trafico (cliente) y posteriormente, poder desofuscarlo (servidor). Actualmente existen varias herramientas y frameworks desarrollados siguiendo la especificación de PT ubicada en el siguiente enlace https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt y seguramente la más conocida y popular es OBFSPROXY, un framework implementado en Python del que os hablaré en un próximo articulo.
Un saludo y Happy Hack!
Adastra.
Servicios en TheHackerWay
Deep web: Privacidad y anonimato.
Hacking con Python
Python para Pentesters
Número de Visitas:
Sobre Adastra:
Soy un entusiasta de la tecnología y la seguridad informática, me siento atraído principalmente por la cultura y los fundamentos del Gray Hat Hacking.
Soy una persona afortunada de poder dedicar mi tiempo y energía en hacer lo que me apasiona, aprendiendo y compartiendo lo aprendido. Con bastante frecuencia iré publicando entradas relacionadas con estudios y técnicas que he ido asimilando a lo largo de mis investigaciones, todas enfocadas a las diferentes facetas de la informática con un énfasis especial en la seguridad.
Saludos y Happy Hack!
adastra
