Archive

Posts Tagged ‘hacking tor’

Pluggable transports en TOR para la evasión de Deep Packet Inspection

julio 30, 2015 2 comentarios

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.

PTFuncionamiento 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.

pt1Configuració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.

pt2Selecció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

junio 16, 2015 2 comentarios

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
>make

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

junio 9, 2015 Deja un comentario

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.

pentestingserviciosocultos-II-1Conexió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.

pentestingserviciosocultos-II-2Ejecutando el módulo “auxiliary/scanner/ftp/ftp_login” de MSF contra el servicio oculto FTP

pentestingserviciosocultos-II-3Ejecutando 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.

pentestingserviciosocultos-II-4Conexió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.

pentestingserviciosocultos-II-5Ejecutando el módulo “ssh_version” de MSF contra el servicio oculto.

pentestingserviciosocultos-II-6Ejecutando el módulo “ssh_enumusers” de MSF contra el servicio oculto.

pentestingserviciosocultos-II-7Ejecutando 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.

pentestingserviciosocultos-II-8Ataque 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

junio 2, 2015 3 comentarios

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”.

pentestingserviciosocultos-1Django-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.

pentestingserviciosocultos-2Utilizando 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&#8221;, 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”

pentestingserviciosocultos-3Generando 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.

pentestingserviciosocultos-4Ejecutando 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”

abril 28, 2015 2 comentarios

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)
get bridges Request vanilla bridges.
get transport [TYPE] Request a Pluggable Transport by TYPE.
get help Displays this message.
get key Get a copy of BridgeDB’s public GnuPG key.
get ipv6 Request IPv6 bridges.

Currently supported transport TYPEs:
obfs2
obfs3
obfs4
scramblesuit
fte

BridgeDB can provide bridges with several types of Pluggable Transports[0],
which can help obfuscate your connections to the Tor Network, making it more
difficult for anyone watching your internet traffic to determine that you are
using Tor.

Some bridges with IPv6 addresses are also available, though some Pluggable
Transports aren’t IPv6 compatible.

Additionally, BridgeDB has plenty of plain-ol’-vanilla bridges – without any
Pluggable Transports – which maybe doesn’t sound as cool, but they can still
help to circumvent internet censorship in many cases.

[0]: https://www.torproject.org/

<3 BridgeDB

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
194.132.208.140:1418 E6F48300BB17180451522069F16BD5
192.36.31.74:22656 FEB63CA5EBD805C42DC0E5FBDDE82F

To enter bridges into Tor Browser, first go to the  Tor Browser download
page [0] and then follow the instructions there for downloading and starting
Tor Browser.

When the ‘Tor Network Settings’ dialogue pops up, click ‘Configure’ and follow
the wizard until it asks:

> Does your Internet Service Provider (ISP) block or otherwise censor connections
> to the Tor network?

Select ‘Yes’ and then click ‘Next’. To configure your new bridges, copy and
paste the bridge lines into the text input box. Finally, click ‘Connect’, and
you should be good to go! If you experience trouble, try clicking the ‘Help’
button in the ‘Tor Network Settings’ wizard for further assistance.

[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”.

Bridge 83.212.111.114:443
Bridge 194.132.208.140:1418
Bridge 192.36.31.74:22656
UseBridges 1

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.

2015, año en el que deberías comenzar a pensar en I2P.

febrero 3, 2015 2 comentarios

TOR es la red anónima más extendida, conocida (y atacada) del mundo y sin duda gran parte de su éxito se debe a que es una red que provee unos buenos niveles de anonimato y privacidad para cualquier usuario en Internet. Sin embargo, para nadie es un secreto que se trata de una red que se ha convertido en el principal objetivo de varios gobiernos y agencias en todo el mundo. Son muchos los que constantemente intentan realizar ataques contra la infraestructura de TOR, la cual se basa principalmente en la gente que “desinteresadamente” decide exponer su máquina como un repetidor y así, hacer que la red sea más grande y difícil de atacar. 2014 ha sido un año complicado para TOR, ya que se han descubierto varios ataques exitosos que han sido admitidos por el equipo del proyecto de los cuales aun no se conoce su impacto real, por este motivo, cuando hablamos de TOR, desafortunadamente ya no podemos hablar de un anonimato fuerte. Hay varias cosas que personalmente me gustan del proyecto, es muy interesante y cuenta con una comunidad de desarrolladores/contribuidores enorme, sin embargo hay otras que las considero no solamente mejorables, sino claro un fallo de diseño que ahora le esta pasando factura al proyecto. No pretendo criticar la arquitectura y diseño de TOR, aun así creo que hoy en día, con la cantidad de “rivales” y entidades con intenciones de romper el anonimato de los usuarios que usan esta red, ya es una cuestión de tiempo que su arquitectura y diseño se vuelvan indefendibles. Mis razones para afirmar esto son las siguientes:

– Red centralizada: Las autoridades de directorio son servidores que se encargan de mantener viva la red, de gestionar y verificar el estado de cada repetidor participante, emitir los ficheros de consenso que son utilizados por los clientes para componer sus circuitos, mantener un registro de “Introduction Points”, “Rendezvous Points” y las tablas de servicios ocultos registrados en la red, entre muchas otras labores de administración que son completamente transparentes para los usuarios. Esto es mucho, pero que mucho poder para ser manejado únicamente 10 ordenadores. Esta claro que un ataque dirigido contra algunos de estos ordenadores (o todos) puede generar un caos en la red y esto es algo que ya ha pasado entre los meses de octubre y diciembre del 2014, en los que se llevaron acabo ataques de DoS distribuidos contra algunas de las autoridades de directorio de TOR. El resultado: Gran parte de la red se mantuvo saturada durante varias horas y era prácticamente imposible acceder a la web profunda de TOR. Ahora bien, no tengo constancia de que existan campañas de APT contra dichos servidores, pero no me extrañaría, es más, hoy en día nadie puede garantizar con un 100% de certeza que todas las autoridades de directorio de TOR están siendo controladas única y exclusivamente por el equipo de TOR.

Red basada en las buenas intenciones: Cuando un cliente de TOR registra su instancia como un repetidor en la red, las autoridades de directorio se encargan de verificar varios parámetros relacionados con el rendimiento óptimo del repetidor y si se trata de una instancia maliciosa basándose principalmente en un mecanismo de listas negras. Sin embargo sino hay ningún problema, el repetidor es incluido en el consenso que emiten las autoridades de directorio cada hora y ahora, alguien que efectivamente no conoces pasa a ser el repetidor de salida del circuito que te permite conectarte con la web profunda de TOR. Tal como lo han demostrado la inmensa cantidad de ataques que se han llevado a cabo en el 2014, las autoridades de directorio de TOR no pueden saber si un repetidor concreto es malicioso hasta que es detectado y reportado, algo que puede tardar meses. Este es un problema que tiene difícil solución, pero que se convierte en una situación particularmente problemática dado que los circuitos en TOR son bidireccionales.

– Circuitos bidireccionales: Cuando un cliente de TOR se conecta a la red, utiliza un circuito compuesto por 3 repetidores, uno de entrada, uno intermedio y uno de salida. Dicho circuito es bidireccional, lo que quiere decir que funciona tanto para enviar como para recibir paquetes de datos para y desde un destino determinado. Este modelo seria desastroso para una red anónima pequeña, pero ese no es el caso de TOR, ya que la cantidad de voluntarios en todo el mundo es enorme, pero tal como comentaba anteriormente cualquiera puede exponer su ordenador como un repetidor en la red y aunque las autoridades de directorio cuentan con rutinas para la detección de repetidores maliciosos, al final se basan en una relación de confianza y si no hay indicios que demuestren lo contrario, las autoridades de TOR se fían de los clientes que registran sus instancias como repetidores de cualquier tipo. Si hablamos de un adversario con suficientes recursos, puede registrar una gran cantidad de repetidores en la red de TOR y controlar gran parte del trafico de los usuarios y dado que los circuitos en TOR son bidireccionales, realizar ataques basados en los tiempos de las peticiones/repuestas, correlacionales y análisis de trafico para identificar a un usuario, es mucho más sencillo de implementar. Imaginaros por un segundo, ¿Qué pasaría si los circuitos fueran unidireccionales? Pues que este tipo de ataques dejarían de ser viables, dado que teóricamente no habría forma de correlaccionar el trafico de un circuito con otro basándose únicamente en las estadísticas, eso sin contar con que para el adversario seria necesario contar con el doble de recursos para controlar dos circuitos distintos. – ¿Únicamente TCP? La red de TOR únicamente soporta protocolos de red basados en TCP, como por ejemplo HTTP, FTP, SSH, etc. Sin embargo, si se utiliza cualquier otro servicio basado en un protocolo de red distinto, como es el caso de DNS, puede existir una fuga de información que posiblemente revelará la identidad del usuario, ya que es trafico que no pasará por medio de TOR. Dicho en otras palabras, si una de tus aplicaciones ejecuta peticiones DNS para resolver una dirección IP o un nombre de dominio, dichas peticiones producirán una fuga de información, es más, si simplemente haces un “ping” contra otra máquina, también se producirá una fuga de información. TOR solamente soporta TCP, y peticiones DNS (UDP) o un simple “ping” (ICMP) pueden arruinar tu anonimato. Si bien es cierto que existen aplicaciones como “torsocks” que permiten hacer un “torify” de de las aplicaciones para que todo pase por medio de TOR, la realidad es que las fugas de información siguen siendo un problema bastante común.

– Servicios ocultos. ¿Cuándo va a terminar de cargar mi página?!

En TOR no solamente existen servicios ocultos del tipo HTTP, los hay de todo tipo (siempre y cuando se basen en TCP), pero independiente del tipo de servicio que usemos siempre hay una característica que es común a todos: Son LENTOS. Alguna vez te has preguntado ¿por qué demonios los servicios ocultos en TOR son tan lentos? Probablemente alguien te habrá dicho que es porque el trafico se replica entre varios nodos, por esos son lentos. Eso es FALSO, los servicios ocultos son lentos no solamente porque existan repetidores de por medio, son lentos porque cada servicio oculto se encuentra registrado en una base de datos (hash) que comparten las autoridades de directorio para mantener un registro de las direcciones onion de cada servicio con su correspondiente “Introduction Point”. Dado que dicho proceso es centralizado y el número de direcciones onion es gigantesco, es perfectamente normal presenciar una demora cuando se solicita acceso a un servicio onion, eso sin contar que para preservar el anonimato en ambas partes (tanto para el cliente como para el proveedor del servicio) existen dos circuitos independientes que se conectan entre si para la transferencia de datos entre cliente y servidor. Todo esto ya os lo contaba en un articulo anterior Ahora bien, es un problema que no tendrá una solución a corto plazo, ya que el tamaño de la red es tan grande que no es de extrañar que las autoridades de directorio se vean colapsadas por la cantidad de peticiones que reciben en picos puntuales del día, así que lo mejor que podéis hacer si navegáis por la web profunda de TOR es respirar profundo y llenaros de mucha paciencia.

Sin embargo no todo en TOR son problemas, eso está claro, ya que sino tuviera las virtudes que tiene nadie la usaría. Una de esas virtudes es la cantidad de usuarios que aportan a la red y el número de personas que crean herramientas, librerías, sitios con documentación, etc. Son aportes que ayudan a todo el ecosistema de la red y que desde luego le han permitido estar en la posición en la que está actualmente. No obstante, existen otras redes anónimas que si bien llevan prácticamente el mismo tiempo de desarrollo que TOR (entre los años 2003 y 2005) no han tenido las repercusiones ni el impacto que ha tenido TOR. Tal es el caso de redes como I2P y FreeNet, siendo la primera la que desde mi punto de vista puede aportar una solución elegante y eficiente a los problemas que he descrito anteriormente en TOR. Seguramente te preguntaras ¿Y por qué I2P no es tan conocido si es tan bueno? Francamente no me lo explico, pero desde mi punto de vista es una cuestión de propaganda y moda, algo que desafortunadamente mueve muchas cosas en la industria de la seguridad y en la informática en general. Creo que I2P no ha llegado a recibir el reconocimiento que se merece porque en los medios solamente se habla de TOR, es el referente de anonimato por excelencia a cualquiera que se lo preguntes! lo cual es una pena. Por ese motivo me he animado a escribir este articulo, hablando de las desventajas que tiene TOR y como una red como I2P puede aportar una solución real.

– Red descentralizada. Ya no hablamos de autoridades de directorio, hablamos de máquinas que se conectan a una red privada en la que todos “hablan el mismo idioma” y no existen entidades que gobiernen el funcionamiento general de la red. Tu te conectas y automáticamente ya eres parte de la red, no necesitas descargarte ficheros con información sobre la red o cosas similares, todos los usuarios son repetidores potenciales y están ahí para construir tus propios túneles de comunicación con otros usuarios. Se acabo eso de depender de 1 o 10 ordenadores para poder navegar en la web profunda o para construir circuitos.

– ¿Buenas intenciones? De eso nada, todos juegan con las mismas reglas. A diferencia de TOR, en I2P no se ruega a nadie que por favor aporte un poco de su ancho de banda y que convierta su instancia de I2P en un repetidor para los circuitos de los usuarios. No, en I2P todos los usuarios que se conectan actúan como repetidores. Esto quiere decir que si te conectas a I2P, una parte de tu ancho de banda será utilizada por otros usuarios en la red, eso si, tu puedes decidir cuanto puedes o quieres aportar. Esto es una característica que en mi opinión es de las más acertadas, ya que hace que los ataques “sybil” sean prácticamente inviables.

– Circuitos en doble sentido y túneles unidireccionales En TOR los túneles que construyen los clientes están compuestos por tres máquinas y dichas máquinas se utilizan para enviar y recibir información. En I2P esto también cambia, ya que no existen los circuitos como tal, en su lugar se crean túneles de comunicación en un solo sentido. Si un emisor quiere enviar un mensaje a un destinatario contará con un túnel compuesto por “x” repetidores que se encargarán de enviar el mensaje y por otro lado, si el emisor quiere recibir mensajes provenientes de la red, contará con otro túnel compuesto por “z” repetidores que se encargarán de recibir el mensaje y enrutarlo. Este modelo es simplemente genial, ya que los túneles pueden contar con un número configurable de repetidores y solamente se encargan de una única tarea que es enviar o recibir datos. Este modelo no solamente dificulta los ataques de análisis de trafico, sino también los ataques de correlación, ya que los túneles de entrada y salida no guardan ningún tipo de relación entre ellos, son completamente independientes y solamente la instancia que ha construido sus túneles sabe cuales son las máquinas que se utilizan para enviar y recibir datos. Por otro lado, a diferencia TOR, todas la comunicación va cifrada en todos los puntos, desde el principio hasta el final, utilizando un proceso de cifrado que en el mundo de I2P se conoce como cifrado “Garlic”.

– TCP, UDP, ICMP, el protocolo que quieras. En I2P no nos limitamos a utilizar protocolo TCP, podemos utilizar cualquier protocolo de red sin temor a perder nuestro anonimato. Esta característica facilita enormemente las cosas a la hora exponer servicios, ya que no solamente no nos limitamos a protocolos conocidos que utilizan TCP, sino a cualquier protocolo de red como UDP. Esta es otra de las razones por las cuales en I2P es posible implementar servicios P2P y descargar torrents y en TOR no.

– Servicios ocultos. Por fin, mi página carga rápido! Los servicios ocultos en I2P no solamente son más eficientes y rápidos, son muchísimo más ricos en términos de funcionalidades, ya que la arquitectura de I2P permite crear sitios web que permitan la ejecución de aplicaciones web 2.0 con Javascript, HTML5, CSS3 y frameworks para mejorar la experiencia de usuario (vease Dojo, NodeJS, AngularJS, etc) de hecho, I2P cuenta con un sistema de plugins que permite desplegar aplicaciones aplicaciones de forma rápida e intuitiva. Tenemos ante nosotros una amplia gama de alternativas que no existen en TOR, eso sin contar con que dado que la red es completamente descentralizada no existen las demoras y molestos retrasos a la hora de acceder a los servicios ocultos en TOR. I2P es un serio candidato a aquellos que buscan privacidad y niveles fuertes de anonimato. Además, para aquellos como yo, que les gusta ver cómo funcionan este tipo de tecnologías, puede resultar tanto o más interesante que TOR, ya que su arquitectura es tan compleja como genial. Para no terminar este articulo sin un contenido practico que puedas probar en tu ordenador, me gustaría dejar una referencia a algunos artículos que he escrito sobre I2P en este sitio:

http://thehackerway.com/2011/11/28/preservando-el-anonimato-y-extendiendo-su-uso-conceptos-basicos-sobre-el-uso-de-i2p-parte-xxii/

http://thehackerway.com/2011/11/30/preservando-el-anonimato-y-extendiendo-su-uso-conceptos-basicos-sobre-el-uso-de-i2p-parte-xxiii/

http://thehackerway.com/2011/12/02/preservando-el-anonimato-y-extendiendo-su-uso-administracion-de-i2p-aplicaciones-y-servicios-incluidos-parte-xxiv/

http://thehackerway.com/2011/12/05/preservando-el-anonimato-y-extendiendo-su-uso-administracion-de-i2p-aplicaciones-y-servicios-incluidos-parte-xxv/

http://thehackerway.com/2011/12/07/preservando-el-anonimato-y-extendiendo-su-uso-servicios-anonimos-eepsites-y-ssh-en-i2p-parte-xxvi/

http://thehackerway.com/2011/12/09/preservando-el-anonimato-y-extendiendo-su-uso-servicios-anonimos-plugins-en-i2p-parte-xxvii/

http://thehackerway.com/2011/12/12/preservando-el-anonimato-y-extendiendo-su-uso-arquitectura-y-protocolos-utilizados-en-i2p-parte-xxviii/

http://thehackerway.com/2011/12/16/preservando-el-anonimato-y-extendiendo-su-uso-estructura-de-i2p-parte-xxx/

http://thehackerway.com/2011/12/21/preservando-el-anonimato-y-extendiendo-su-uso-hacking-i2p-desarrollo-de-aplicaciones-usando-streaming-library-parte-xxxii/

http://thehackerway.com/2012/01/18/preservando-el-anonimato-y-extendiendo-su-uso-hacking-i2p-desarrollo-de-aplicaciones-usando-bob-parte-xxxiii/

Si bien es cierto que son artículos que he escrito hace un poco más de 3 años, siguen teniendo vigencia y son bastante útiles para entender en detalle el funcionamiento de I2P. Finalmente, no creas nada de lo que he dicho, ve y compruébalo por ti mismo!. La invitación es clara, es el momento de comenzar a utilizar I2P y conocer de primera mano los beneficios que nos puede aportar.

Un saludo y Happy Hack! Adastra.

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

enero 22, 2015 Deja un comentario

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.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 1.619 seguidores

A %d blogueros les gusta esto: