Pentesting BeEF; & API Rest (automate tasks) (vol. III)


BeEf-3-Blog-002

BeEf-3-Blog-003
Captura 1: FinalArtículo” = Pentesting BeEF; & API Rest (automate tasks) (vol. II) 😉

BeEf-3-Blog-004

BeEf-3-Blog-005


BeEf-3-Blog-006

BeEf-3-Blog-007


./ 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 ido "mostrando" en las "dos" <"entradas anteriores"> del <blog> sobre <"BeEF">, "utilizar" esta <API> no es nada complicado y solamente es necesario "ejecutar" las <peticiones "HTTP"> con los "parámetros" correctos.

BeEf-3-Blog-008- Para hacerlo, se pueden "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 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 lo cuál, a "continuación" se "explicará" cómo <invocar> a algunos de los <"endpoints"> de <"BeEF"> utilizando <Python> :)

BeEf-3-Blog-009


BeEf-3-Blog-010

BeEf-3-Blog-011


=| <"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>. La tenéis "disponible" en el <siguiente repositorio> de <"GitHub"> ("clic" <"imagen inferior">);

BeEf-3-Blog-012|= Y, tal 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 habéis visto en el <primer artículo> ("vol. I"), es "requerido" para <invocar> algunos de los <"endpoints"> de la <"API Rest">;

BeEf-3-Blog-013!^ Como podéis "apreciar" (<"imagen superior">), todo parte de la "creación" de 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">;

BeEf-3-Blog-014- <"Imagen superior">; "Listando" todos los <módulos> "disponibles" en <"BeEF">.

BeEf-3-Blog-015


"/ Como "mencionábamos" 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";

BeEf-3-Blog-016- <"Imagen superior">; "filtrando" <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 encuentran <"online"> y <"offline">;

BeEf-3-Blog-017- <"Imagen superior">; "listando" 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 podéis <observar>" más "abajo" ("<imagen inferior">, se consigue con pocas "lineas de <código>";

BeEf-3-Blog-018- 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>.

BeEf-3-Blog-019

-) Como "habéis podido ver", "utilizar" está <librería> "no es complicado" y "es una buena forma de <automatizar> las <tareas>" que <pueden llevarse a cabo> desde la <consola "web"> de <"BeEF">.

BeEf-3-Blog-020

Salu2


TonyHAT - 391

Anuncios

Un comentario en “Pentesting BeEF; & API Rest (automate tasks) (vol. III)”

Responder

Por favor, inicia sesión con uno de estos métodos para publicar tu comentario:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s