Archivo

Posts Tagged ‘tor ControlPort’

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:

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

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

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

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

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

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

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

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

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

https://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.

Creando sitios ocultos en TOR de forma programática con TxTorCon

diciembre 4, 2014 1 comentario

Anteriormente he hablado sobre el uso de Stem para controlar instancias de TOR, una potente librería que no solamente se aprovecha del protocolo de control de TOR para la administración remota de una instancia en ejecución, sino que también cuenta con algunas utilidades para arrancar una nueva instancia con configuración personalizada, descargar y parsear los descriptores emitidos por las autoridades de directorio, entre muchas otras funcionalidades útiles. Es una librería que se explota bastante bien en Tortazo, una de las herramientas que he escrito para realizar pruebas de penetración contra repetidores de salida y servicios ocultos en la red de TOR.
Aunque Stem es una librería muy potente, existen otras alternativas que cuentan con las mismas capacidades y en esta ocasión, voy a hablar sobre TXTORCON.

¿Por qué TxTorCon? Porqué se trata de una implementación del protocolo de control de TOR basada en Twisted y a diferencia de Stem, TxTorCon es una implementación asíncrona. Una librería como TxTorCon permitirá crear programas reactivos que se encargarán de ejecutar acciones sobre una o varias instancias de TOR ante una lista de eventos predefinidos.

En esta entrada se verá cómo se puede utilizar TxTorCon para crear servicios ocultos en TOR de forma programática y aunque lo que se verá a continuación también se puede hacer con Stem, se trata de un ejercicio practico muy interesante que servirá para conocer los elementos básicos y la “metodología” que se debe seguir cuando se programa con esta librería.

Antes de continuar, se recomienda al lector tener claros los conceptos básicos sobre la configuración de una instancia de TOR y conocer bastante bien las propiedades admitidas en el fichero “torrc”, aunque crear un servicio oculto no es una tarea compleja ya que solamente es necesario definir la opción de configuración “HiddenService” en el fichero de configuración “torrc” tantas veces como servicios ocultos se desee crear, lo que si que puede ser complicado es mantener el servicio oculto correctamente securizado, pero eso es un tema del que se hablará en un próximo artículo.

En primer lugar, es importante conocer el uso de la clase “txtorcon.TorConfig” ya que en dicha clase es donde definen todos los elementos de configuración de una instancia de TOR y dicho elemento puede ser utilizado para levantar la instancia de forma programática utilizando TxTorCon.

import txtorcon
config = txtorcon.TorConfig()
config.SOCKSPort = 9051
config.ORPort = 4443
…..
config.save()

La clase “txtorcon.TorConfig” maneja un diccionario interno con las propiedades que se pueden definir en un fichero de configuración de TOR, con lo cual el programador debe definir cada propiedad como un atributo de instancia.

Ahora bien, para definir uno o varios servicios ocultos, es necesario crear un listado de instancias de la clase “txtorcon.HiddenService”. Dicho listado se almacenará en la variable “HiddenServices” de la instancia de “txtorcon.TorConfig” creada previamente.
La siguiente función servirá para definir los detalles de configuración básicos para iniciar una instancia de TOR con un servicio oculto.

import txtorcon
import functools
import tempfile
import os
from twisted.internet import reactor 

def createTemporal():
    tempDir = tempfile.mkdtemp(prefix='torhiddenservice')
    reactor.addSystemEventTrigger('before', 'shutdown',
functools.partial(txtorcon.util.delete_file_or_tree, tempDir))
    return tempDir 

def configuration(hiddenserviceDir, serviceInterface,
servicePort=8080, hiddenservicePort=80):
    if hiddenserviceDir is None:
        print "[+] HiddenServiceDir not specified... Generating
a temporal file."
        hiddenserviceDir = createTemporal()
    if os.path.exists(hiddenserviceDir) == False:
        print "[+] The HiddenServiceDir specified does not
exists... Generating a temporal file."
        hiddenserviceDir = createTemporal()
    config = txtorcon.TorConfig()
    config.SOCKSPort = 9051
    config.ORPort = 4443
    config.HiddenServices = [txtorcon.HiddenService(config,
hiddenserviceDir, ["%s %s:%s" %(str(hiddenservicePort),
serviceInterface, str(servicePort))] )]
    config.save()
    return config 

configuration('/home/adastra/Escritorio/django-hiddenservice',
'127.0.0.1')

La función “configuration” se encarga de recibir como argumento todos los elementos necesarios para establecer un servicio oculto en la configuración definida en el objeto “txtorcon.TorConfig” y posteriormente dicho objeto es retornado. Por otro lado, la función “createTemporal” es invocada internamente por la función “configuration” con el fin de devolver un directorio temporal para el servicio oculto en el caso de que el directorio indicado por parámetro sea invalido.

Ahora que la configuración se encuentra preparada, el siguiente paso consiste en utilizarla para iniciar la instancia de TOR en cuestión.

import txtorcon
import functools
import tempfile
import os
from twisted.internet import reactor 

def createTemporal():
    tempDir = tempfile.mkdtemp(prefix='torhiddenservice')
    reactor.addSystemEventTrigger('before', 'shutdown',
functools.partial(txtorcon.util.delete_file_or_tree, tempDir))
    return tempDir 

def configuration(hiddenserviceDir, serviceInterface,
servicePort=8080, hiddenservicePort=80):
    if hiddenserviceDir is None:
        print "[+] HiddenServiceDir not specified... Generating a temporal file."
        hiddenserviceDir = createTemporal()
    if os.path.exists(hiddenserviceDir) == False:
        print "[+] The HiddenServiceDir specified does not exists... Generating a temporal file."
        hiddenserviceDir = createTemporal()
    config = txtorcon.TorConfig()
    config.SOCKSPort = 9051
    config.ORPort = 4443
    config.HiddenServices = [txtorcon.HiddenService(config,hiddenserviceDir, ["%s %s:%s" %(str(hiddenservicePort),serviceInterface, str(servicePort))] )]
    config.save()
    return config 

def updates(prog, tag, summary):
    print "%d%%: %s" % (prog, summary) 

def setup_complete(config, proto):
    print "TOR Instance started!" 

def setup_failed(arg):
    print "SETUP FAILED", arg
    reactor.stop() 

def startTor(config):
    d = txtorcon.launch_tor(config, reactor,progress_updates=updates)
    d.addCallback(functools.partial(setup_complete, config))
    d.addErrback(setup_failed)
    reactor.run()
torrc = configuration('/home/adastra/Escritorio/hidden_service_django','127.0.0.1')
startTor(torrc)

En esta nueva versión del script se ha incorporado la función “startTor”, la cual se encarga de utilizar la configuración retornada por la función “configuration” para iniciar TOR. Como se puede apreciar, dicha función emplea la utilidad “txtorcon.launch_tor” enviando como argumentos, la configuración de TOR, el reactor de Twisted y una función de callback para procesar cada uno de los eventos producidos durante proceso de inicio. Finalmente, se adicionan dos funciones más en el caso de que el proceso de arranque haya ido bien o en el caso de fallo.

Después de ejecutar el script anterior, se podrá ver por consola algo muy similar a lo que se enseña en la siguiente imagen.

txtorcon1

El script puede parecer complejo pero tal como se ha explicado anteriormente, si se conoce el funcionamiento de Twisted y las funcionalidades básicas de TxTorCon, no resulta tan complicado de comprender.
Hasta este punto se asume que en la máquina local se encuentra un servicio levantado y esperando conexiones, más concretamente en el puerto “8080”. Evidentemente, dado el escenario anterior es necesario levantar un servidor web con Tomcat, una aplicación con Django o cualquier otro servicio en dicho puerto, pero dadas las características de Twisted, también es posible crear un servidor web simple directamente desde el script y de esta forma, se contará con una herramienta completamente funcional que puede levantar un servicio oculto sin depender de ningún programa externo (excepto el propio ejecutable de TOR).

import txtorcon
import functools
import tempfile
import os
from twisted.web import static, resource, server
from twisted.internet import reactor
from twisted.internet.endpoints import TCP4ServerEndpoint 

def createTemporal():
    tempDir = tempfile.mkdtemp(prefix='torhiddenservice')
    reactor.addSystemEventTrigger('before', 'shutdown',
functools.partial(txtorcon.util.delete_file_or_tree, tempDir))
    return tempDir 

def configuration(hiddenserviceDir, serviceInterface,
servicePort=8080, hiddenservicePort=80):
    if hiddenserviceDir is None:
        print "[+] HiddenServiceDir not specified... Generating a temporal file."
        hiddenserviceDir = createTemporal()
    if os.path.exists(hiddenserviceDir) == False:
        print "[+] The HiddenServiceDir specified does not exists... Generating a temporal file."
        hiddenserviceDir = createTemporal()
    config = txtorcon.TorConfig()
    config.SOCKSPort = 9051
    config.ORPort = 4443
    config.HiddenServices = [txtorcon.HiddenService(config,hiddenserviceDir, ["%s %s:%s" %(str(hiddenservicePort),serviceInterface, str(servicePort))] )]
    config.save()
    return config 

def updates(prog, tag, summary):
    print "%d%%: %s" % (prog, summary) 

def setup_complete(config, proto):
    print "TOR Instance started!" 

def setup_failed(arg):
    print "SETUP FAILED", arg
    reactor.stop() 

def startTor(config):
    #Starting a simple web site.
    root = static.File('/opt/WebSite')
    site = server.Site(root)
    hs_endpoint = TCP4ServerEndpoint(reactor, 8080,interface='127.0.0.1')
    hs_endpoint.listen(site)
    d = txtorcon.launch_tor(config, reactor,progress_updates=updates)
    d.addCallback(functools.partial(setup_complete, config))
    d.addErrback(setup_failed)
    reactor.run() 

torrc =configuration('/home/adastra/Escritorio/django-hiddenservice','127.0.0.1')
startTor(torrc)

El programa anterior solamente añade los elementos necesarios para declarar un servidor web cuyo directorio raíz es “/opt/WebSite”. Dicho servidor web se levantará en el puerto 8080 en la interfaz de red local, tal como se ha definido en la configuración del servicio oculto. Con todo esto, después de que la instancia de TOR se levante y se creen los ficheros correspondientes al dominio “onion” y a las claves del servicio, cualquier cliente que intente ingresar por dicha la dirección onion del servicio oculto, podrá ver los contenidos del servidor web que se ha iniciado utilizando Twisted. La siguiente imagen enseña algo muy similar a lo que el usuario final verá en su navegador.

txtorcon2

Como se puede apreciar, al acceder a la dirección onion del servicio oculto, se pueden visualizar los contenidos del directorio “/opt/WebSite”, que es el directorio que se ha indicado como raíz del servidor web.

Aunque aquí se ha enseñado como crear un servicio web en la red de TOR, también es posible crear cualquier otro tipo de servicio siguiendo exactamente la misma dinámica que se ha explicado aquí, como por ejemplo por un servidor SSH/SFTP con Paramiko, un servidor FTP o incluso un servidor SMB. Tienes a tu disposición muchas alternativas a la hora de automatizar la creación de servicios ocultos en la web profunda de TOR.

Un Saludo y Happy Hack!

Hacking con Python Parte 25 – Atacando Repetidores de Salida de TOR

julio 22, 2014 1 comentario

Script que utiliza STEM, Python-Nmap y Shodan para atacar los repetidores que se encuentran registrados en los descriptores publicados por las autoridades de directorio.
Se trata de una versión inicial, que modificaré y extenderé en los proximos días.
Publicaré un post para explicar en que consistiran las caracteristicas que quiero implementar y como utilizarlo.

attackTor: https://github.com/Adastra-thw/pyHacks/blob/master/attackTOR.py

Repositorio GIT de la serie:
https://github.com/Adastra-thw/pyHacks.git


Make a Donation Button

Hacking con Python Parte 24 – Consulta de descriptores de TOR con Stem

julio 15, 2014 1 comentario

Conceptos basicos sobre los descriptores de TOR utilizando la API de STEM.

Repositorio GIT de la serie:
https://github.com/Adastra-thw/pyHacks.git


Make a Donation Button

Hacking con Python Parte 23 – Controlando instancias de TOR con Stem

julio 8, 2014 2 comentarios

Utilizando la API de Stem para acceder a repetidores locales de TOR.

Repositorio GIT para la serie:
https://github.com/Adastra-thw/pyHacks.git


Make a Donation Button

Preservando el Anonimato y Extendiendo su Uso – Funcionamiento de los Directorios Autoritativos y de Cache en TOR – Parte XXI

noviembre 25, 2011 2 comentarios

Como se ha mencionado anteriormente en estas entradas, el directorio de TOR almacena información sobre nodos disponibles en la red y cada nodo puede tener el suyo propio con el fin de descentralizar aun más este servicio, dado que cada nodo tiene una copia de esta información y la cachea de forma automática en su estructura interna. La razón por la cual se utilizan estos elementos en la red de TOR ha sido principalmente porque en las primeras versiones, cada cliente tenia conocimiento de los routers que componían los circuitos entre él y sus correspondientes destinos, disponía de un listado de routers que eran confiables (algo que no siempre podría ser cierto) y conocía las claves de cada uno, sin embargo, dada la naturaleza cambiante de la red, este listado se encontraba rápidamente desactualizado, conteniendo nodos que posiblemente ya no se encontraban disponibles o que sus correspondientes claves publicas habían cambiado (un poco menos frecuente, pero también podía ocurrir), lo que obligaba al cliente a realizar una nueva lista con bastante frecuencia. Para ello en TOR se han creado los directorios Autoritativos que contienen el estado actualizado de routers confiables y sus correspondientes estados. A continuación se indican los conceptos teóricos/funcionales y las opciones de configuración.

Leer más…

Preservando el Anonimato y Extendiendo su Uso – Opciones de configuración útiles en TOR – Parte XX

noviembre 23, 2011 Deja un comentario

Las opciones de configuración de un Relay son vitales para que su funcionamiento sea el esperado, ademas es importante tener claridad en los conceptos y la filosofía de cada una de estas opciones, en algunos casos su funcionamiento no es fácil de comprender y se necesitan conocimientos previos sobre protocolos de red y funcionamiento general del protocolo TCP. Sin embargo el hecho de tener un Relay bien configurado se traduce en mejor rendimiento, anonimato y seguridad ya que en cualquier software, los Bugs son temporales y en muchas ocasiones pasajeros, pero las malas configuraciones pueden ser permanentes si no se toman las medidas de detección y corrección oportunas. A continuación se enseña el significado de las opciones de configuración más interesantes en TOR cuando actúa como una instancia servidora para otros usuarios.

Leer más…

A %d blogueros les gusta esto: