Archivo
Seguridad en ElasticSearch: modo cluster – Parte IV
En el post anterior ya se ha hablado sobre algunas características avanzadas para la búsqueda de contenidos en ES, ahora es el momento de hablar sobre la configuración necesaria en ES para que funcione en modo cluster. En primer lugar hay que mencionar que cuando se inicia una instancia de ES, lo primero que hace es intentar unirse a un cluster si se han indicado los detalles en dicho cluster en la configuración, en el caso de que no sea así, se entiende que el nodo funcionará en modo “standalone” y en tal caso, creará un cluster en donde es la propia instancia la que funciona como “master”.
Configuración modo “cluster” con múltiples nodos.
La configuración en modo cluster de ES con múltiples nodos es considerada como una configuración para un entorno de producción. Esto significa que en primer lugar, la instancia de ES ya no se ejecutará únicamente en la interfaz de loopback como se ha visto hasta ahora, sino que evidentemente, debe estar disponible y alcanzable por otros nodos/instancias que harán parte del cluster. La configuración de todas las instancias de ES giran en torno al fichero “elasticsearch.yml” para cuestiones concretas de la instancia y otros ficheros como el “jvm.option” y “log4j2.properties” para asignar valores de configuración a la VM de Java, evidentemente se trata de una labor de vital importancia para el tuning de una máquina virtual y el correcto funcionamiento de la instancia, pero se sale un poco del scope de estos post. Todos estos ficheros, así como el keystore y certificado de la instancia se encuentran en el directorio “config”.
ES normalmente requiere muy poca configuración y prácticamente todos los cambios se pueden realizar en caliente gracias a la API disponible en el motor, excepto la configuración en modo cluster, de hecho, si se ha iniciado una instancia con sus valores por defecto se creará un directorio llamado “data” el cual contiene toda la información de los nodos vinculados al cluster. Si se inicia una instancia de ES con la configuración por defecto y luego, se plantea integrar dicha instancia en un cluster existente, es importante tener en cuenta que no solamente será necesario editar el fichero de configuración como se explicará a continuación, sino que además se debe eliminar el directorio “data” para que la instancia comprenda que ahora no es el “master” de un cluster local, sino que se unirá a un cluster existe. Esto último es importante, ya que en el caso de no hacerlo se producirán errores en el arranque aunque la configuración sea correcta.
Ahora bien, los valores de configuración mínimos que se deben indicar en el fichero de “elasticsearch.yml” son los siguientes:
cluster.name: Nombre que tiene el cluster al que la instancia se unirá.
node.name: Nombre del nodo.
cluster.initial_master_nodes: Se trata de las direcciones IP o nombres de dominio de uno o varios nodos “master” del cluster objetivo.
transport.host: Interfaz de red o dirección IP utilizada internamente por los nodos del cluster para la comunicación. Por ejemplo, esta dirección junto con el puerto indicado en “transport.tcp.port” son utilizados por otros nodos en el cluster para las replicas de shards.
transport.tcp.port: Puerto que se abrirá en la interfaz indicada en “transport.host”.
http.host: Interfaz de red sobre la que se servirá la API rest de la instancia (por defecto es localhost).
http.port: Puerto vinculado a la interfaz indicada con la propiedad “http.host” (por defecto es 9200).
network.host: Interfaz de red a la que se vinculará el servicio de conexión de la instancia. Es decir, la interfaz de red sobre la que otros nodos del cluster se conectarán con la instancia local.
node.master: Valor booleano que indica si la instancia es master o no del cluster.
Esto es lo mínimo que debe de existir en un fichero de configuración de ES para que funcione en modo cluster con otros nodos, sin embargo hay muchas más opciones de configuración que se pueden consultar en la documentación oficial. https://www.elastic.co/guide/en/elasticsearch/reference/current/important-settings.html
Una configuración valida podría ser la siguiente:
Nodo master:
| cluster.name: cluster-adastra node.name: adastra-1 transport.host: 0.0.0.0 http.host: 0.0.0.0 network.host: 0.0.0.0 transport.tcp.port: 9300 node.master: true |
Nodo slave1:
| cluster.name: cluster-adastra node.name: slave1-node discovery.seed_hosts: [“192.168.1.144”] #Dirección IP del master. cluster.initial_master_nodes: [“adastra-1”] transport.host: 0.0.0.0 http.host: 0.0.0.0 network.host: 0.0.0.0 transport.tcp.port: 9300 node.master: false |
Nodo slave2:
| cluster.name: cluster-adastra node.name: slave2-node discovery.seed_hosts: [“192.168.1.144”] #Dirección IP del master. cluster.initial_master_nodes: [“adastra-1”] transport.host: 0.0.0.0 http.host: 0.0.0.0 network.host: 0.0.0.0 transport.tcp.port: 9300 node.master: false |
Esto se puede ejecutar desde un mismo ordenador con 3 instancias independientes de ES, con máquinas virtuales, contenedores de Docker o máquinas físicas. No obstante aquí no termina la configuración, cuando se utiliza la propiedad “network.host” con un valor distinto de la interfaz de loopback provoca que ES ejecute una serie de comprobaciones sobre el sistema llamadas “bootstrap checks” las cuales se encargan de verificar que el sistema cumple con las especificaciones mínimas para que el nodo funcione correctamente en un entorno productivo y de esta manera reducir los problemas que puedan tener los usuarios al interactuar con nodos configurados “de aquella manera”. La configuración del sistema que se debe de aplicar para cumplir con los requisitos se explica en la documentación oficial: https://www.elastic.co/guide/en/elasticsearch/reference/current/system-config.html
En este apartado la documentación está bien detallada y explica qué se debe hacer a nivel de sistema para que el nodo arranque correctamente y se una a un cluster existente o funcione como master.
Como se puede apreciar en la imagen anterior, cuando existe cualquier tipo de problema en la instancia relacionada con los “bootstrap checks” la instancia simplemente no arranca. Sin embargo es algo fácil de resolver si se siguen las indicaciones que arroja la instancia de ES.
En esta última imagen se puede ver cómo debe de ser una configuración “buena” para el nodo que actuará como master, como se puede ver se han pasado todas las comprobaciones iniciales y posteriormente, se ha elegido al nodo “adastra-1” como master ya que es la forma en la que se ha indicado en la configuración gracias a la propiedad “node.master: true”.
De momento, con lo que se ha visto en éste post en las partes 1 , 2 y 3 es suficiente para comenzar a abordar cuestiones relacionadas con el pestesting y securización sobre instancias de ES.
Un saludo y Happy Hack.
Adastra.
Herramientas de pentesting interesantes: Jok3r – Parte 1
Desde hace bastante tiempo he querido escribir ésta serie de artículos pero por cuestiones de tiempo no había podido. Últimamente han ido apareciendo bastantes herramientas enfocadas al pentesting/hacking para diferentes contextos, algunas de ellas realmente interesantes y que merece la pena mencionar en este blog. Es importante automatizar todo el trabajo posible para soportar el procedimiento de descubrimiento, detección y posterior explotación de vulnerabilidades, incluyendo otras actividades que en ocasiones se deben realizar directa o indirectamente como ataques de Phishing, aplicación de técnicas OSINT, traceo y seguimiento de usuarios, análisis de tráfico, desarrollo de software, etc. No obstante, como siempre he dicho, ninguna herramienta o conjunto de ellas puede sustituir el trabajo y la metodología que aplica un pentester/hacker a la hora de lanzar un plan de ataque contra un objetivo, aunque las herramientas permiten recopilar información y en algunos casos, directamente explotar vulnerabilidades, lo más común es encontrarnos entornos en donde hay unas medidas de seguridad que ya tienen en cuenta las cosas más obvias, como actualizaciones y medidas de seguridad entre otras cosas. Dicho esto, no hay que olvidar nunca que como en prácticamente cualquier trabajo relacionado con tecnología, es necesario ser muy metódico, ordenado y limpio a la hora de realizar pruebas de penetración y esto es algo que no lo aprendes lanzando todo lo que viene en Kali Linux, lo aprendes con la experiencia y conociendo exactamente qué hacen por debajo las herramientas que utilizas en tu día a día para que no te conviertas en un “Nessus con patas” que solo lanza scripts y si no reportan nada es que todo está bien. Dicho esto, comenzaré a explicar algunas herramientas libres que me ido encontrando y que de alguna manera me han venido bien para trabajos que he realizado para algunos de mis clientes.
Jok3r: https://github.com/koutto/jok3r
Se trata de una herramienta particularmente interesante ya que no “reinventa la rueda” sino que en lugar de eso, reutiliza y combina un buen conjunto de herramientas de pentesting comunes para extraer la mayor cantidad de información de manera conjunta, sin tener que estar ejecutando cada una de forma independiente. Cuando se instala Jok3r el proceso puede tardar unos minutos ya que intenta instalar todas las dependencias y librerías necesarias por los proyectos que intenta combinar. También es posible instalar Jok3r desde su imagen oficial de Docker, una forma cómoda y rápida de tener la herramienta preparada para su uso.
Tal como se indica en el “README” del proyecto, cuenta con algunas características que la convierten en una herramienta muy interesante:
* Integración con más de 50 herramientas de pentesting comunes.
* Configuración sencilla, es posible eliminar o añadir herramientas con un simple fichero de configuración.
* Soporte a múltiples servicios de red basados en TCP y UDP, tales como HTTP, SSH, FTP, DNS, VNC, PostgreSQL, MySQL, etc.
* Se encarga de verificar el objetivo y seleccionar de forma automática las herramientas que puedan arrojar mejores resultados de acuerdo al contexto. Por ejemplo, en el caso de una aplicación web habilitará las herramientas relacionadas con pentesting en entornos web.
* Es capaz de detectar versiones y banners de productos específicos, para posteriormente compararlos con bases de datos CVE online, concretamente tirando de CVE Details y Vulners.
* Es capaz de realizar la explotación automática de algunas vulnerabilidades.
* Es capaz de realizar comprobaciones en CMS para detectar complementos o vulnerabilidades conocidas en Joomla, Drupal, WordPress, entre otros.
* Todos los resultados encontrados por la herramienta se van almacenando localmente en una base de datos y cuenta con algunas funcionalidades de reporting y gestión de resultados de forma independiente para cada auditoría realizada.
Bien, una vez visto el potencial de la herramienta lo siguiente es instalarla y usarla. Tal como se indica en las instrucciones de instalación del proyecto, la forma recomendada de hacerlo es utilizando la imagen Docker oficial, de esta forma no será necesario instalar dependencias directamente en el sistema host (son unas cuantas). No obstante, también se puede instalar directamente desde código fuente fácilmente, ya que cuenta con un script de instalación llamado “install_all.sh” que se encarga de dejarlo todo preparado para que sea posible utilizar la herramienta sin mayores dificultades. Basta simplemente con descargar la imagen y crear un nuevo contenedor, de la siguiente manera:
#sudo docker pull koutto/jok3r #sudo docker run -i -t --name jok3r-container -w /home/adastra/jok3r -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix --shm-size 2g --net=host koutto/jok3r |
Las opciones “-w”, “-e”, “-v” y “–shm-size” son utilizadas para evitar problemas de memoria en el contenedor, así como para utilizar herramientas con una GUI como por ejemplo un navegador web. Con “–net” en Docker se especifica el modo de red, en este caso es compartido con el fin de que tanto anfitrión como contenedor se puedan ver y sea posible crear conexiones reversas.
Luego, para poder detener y volver a levantar el contenedor, se puede utilizar el comando “sudo docker start -i jok3r-container”
Una vez levantado el contenedor, es necesario dirigirse a la ruta “~/jok3r” que es donde se encuentra el script “jok3r.py”. Para ver las herramientas que se encuentran instaladas se debe ejecutar el comando:
#python3 jok3r.py toolbox --show-all |
En el caso de la imagen Docker, se podrá ver que están todas las herramientas instaladas, luego para la gestión de las mismas, se pueden ejecutar los siguientes comandos:
Instalar todas las herramientas disponibles (algo que ya viene en la imagen de Docker). #python3 jok3r.py toolbox --install-all --fast Actualizar todas las herramientas sin realizar preguntas, todo sí y adelante. #python3 jok3r.py toolbox --update-all --fast Desinstalar todas las herramientas. #python3 jok3r.py toolbox --uninstall-all --fast Desinstalar una herramienta concreta. #python3 jok3r.py toolbox --uninstall-tool nombre_herramienta Desinstalar un servicio concreto y las herramientas asociadas. #python3 jok3r.py toolbox --uninstall nombre_servicio |
Además del comando “toolbox” existen otros que permiten realizar verificaciones, ataques y ver el estado de la base de datos local.
Comando de información para los perfiles, servicios y productos.
El comando “info” permite ver qué perfiles se encuentran habilitados en la herramienta, las pruebas de seguridad que se aplican sobre cada protocolo soportado e información de los productos de software que se encuentran registrados en la herramienta. Tal como se ha visto antes con el comando “toolbox” hay una serie de opciones que permiten interactuar con éste comando.
Como se puede apreciar, el comando “info” soporta algunas opciones simples que permiten ver qué cosas puede hacer jok3r contra un objetivo determinado y otros detalles informativos que pueden ser útiles. Se puede ejecutar la herramienta de la siguiente manera.
| #python3 jok3r.py info –services
Enseña una tabla con los servicios, puertos por defecto de cada servicio, herramientas asociadas y número de checks que realizará Jok3r sobre dicho servicio. #python3 jok3r.py info --checks <servicio> Enseña una tabla con el nombre de cada una de las comprobaciones disponibles para el servicio indicado, así como la categoría del chequeo y la herramienta empleada para ejecutarlo. #python3 jok3r.py info –products Enseña una lista de servicios disponibles y los diferentes tipos de productos que implementa dicho servicio, por ejemplo, para un servidor web, el producto puede ser Apache, Nginx, IIS, etc. #python3 jok3r.py info –attack-profiles Enseña una tabla con los perfiles de ataque disponibles, los cuales simplemente se encargan de agrupar varios checks y herramientas en un contexto concreto, por ejemplo para realizar comprobaciones sobre un CMS. |
Base de datos local en Jok3r.
Antes de realizar cualquier tipo de auditoría de seguridad, en Jok3r se almacena todo en diferentes espacios de trabajo, de tal manera que cada auditoría y sus resultados correspondientes, se encuentran almacenados de forma persistente en contextos separados, esto es similar a lo que hay en Metasploit Framework cuando se utiliza el comando “workspace” desde msfconsole. El comando “db” es el encargado de definir misiones, las cuales son simplemente el contexto de una auditoría y partiendo de dichas misiones ejecutar pruebas de seguridad contra los objetivos indicados, los resultados quedarán almacenados en dicha misión.
Para crear una misión basta con ejecutar el comando “mission” tal como se aprecia en la imagen anterior.
Tal como se puede apreciar, el comando “mission” sirve para gestionar las misiones en Jok3r y además, al crear una nueva misión automáticamente cambia el contexto y ubica al usuario en la misión que se acaba de crear. Para moverse entre las diferentes misiones previamente creadas, se ejecuta el comando “mission <nombre>” y la herramienta se encargará de cambiar el contexto y apuntar a la misión indicada.
De momento esto es suficiente para ver las funcionalidades básicas de la herramienta, en el siguiente post se profundizará en su uso a la hora de ejecutar pruebas para auditorías de seguridad.
Un saludo y Happy Hack
Adastra.
Monitorizar conexiones y desconexiones contra un servidor OpenVPN con Python.
Hola a todos. He vuelto. 🙂
Las próximas semanas tendré algo de tiempo libre y he decidido dedicarlo a este espacio, escribiré algunos artículos sobre seguridad que tengo pendientes desde hace mucho tiempo y que ahora, me dispongo a compartir con todos vosotros. Vamos a por uno sencillo primero!
Una de las características más interesantes que tiene OpenVPN es precisamente la posibilidad de ejecutar scripts ante determinados eventos, por ejemplo, es posible indicar en el fichero de configuración que se ejecute un programa determinado cuando un usuario se conecta o desconecta. Dicho programa puede ser un script escrito en Python, por ejemplo, que se encargará de recopilar la información de la conexión que ha establecido el cliente. Esto puede tener varios usos, entre los que se incluyen la monitorización de las conexiones de los usuarios, forzar a que los clientes se conecten únicamente desde ubicaciones concretas, limitar el número de conexiones con el mismo certificado o OVPN, etc. En resumen, permite un buen nivel de control sobre los usuarios y las conexiones realizadas contra el servidor. Ahora, esto cómo se hace?
Configuración de OpenVPN con “script-security”
La directiva de configuración “script-security” es precisamente la que permite la ejecución de scripts y otros programas externos desde el proceso en ejecución de OpenVPN. Sin embargo, está opción no está exenta de riesgos y problemas de seguridad potenciales, tal como se puede leer en la documentación oficial de OpenVPN:
“–script-security level [method]
- This directive offers policy-level control over OpenVPN’s usage of external programs and scripts. Lower level values are more restrictive, higher values are more permissive. Settings for level:0 — Strictly no calling of external programs.
1 — (Default) Only call built-in executables such as ifconfig, ip, route, or netsh.
2 — Allow calling of built-in executables and user-defined scripts.
3 —Allow passwords to be passed to scripts via environmental variables (potentially unsafe).The method parameter indicates how OpenVPN should call external commands and scripts. Settings for method:
execve — (default) Use execve() function on Unix family OSes and CreateProcess() on Windows.
system —Use system() function (deprecated and less safe since the external program command line is subject to shell expansion).
The –script-security option was introduced in OpenVPN 2.1_rc9. For configuration file compatibility with previous OpenVPN versions, use: –script-security 3 system”
Evidentemente, si se utiliza ésta opción en el fichero de configuración o como argumento a la hora de levantar el servicio hay que tener en cuenta, como mínimo lo siguiente:
1. Si se establece el método “2”, sería recomendable eliminar los permisos de lectura y escritura en los scripts que se ejecutarán por medio de OpenVPN, ya que si un atacante consigue acceso local y dichos scripts permiten su edición por parte de usuarios con permisos bajos, existe la posibilidad de que elevar privilegios en el sistema.
2. Evitar usar el método “3” ya que se pueden producir fugas de información sensible a la hora de establecer credenciales en variables de entorno.
Es una opción de configuración con la que hay que tener cuidado, sin embargo cuando se siguen los criterios anteriores es posible utilizarla sin riesgo. Esta opción únicamente le indica a OpenVPN que desde el proceso se podrán lanzar scripts o comandos externos, sin embargo con esto no es suficiente para indicar cuáles serán dichos scripts y cómo se deben ejecutar. Para ello existen otras opciones de configuración en las que se especifican precisamente estos detalles, tales como “up”, “client-connect” o “client-disconnect”. Dichas opciones se pueden incluir en el fichero de configuración utilizado para levantar el proceso de OpenVPN, por ejemplo:
script-security 2 client-connect "/usr/bin/python /home/adastra/connection.py" client-disconnect "/usr/bin/python /home/adastra/disconnection.py"
Tal como el nombre de la opción indica, estos scripts se van a ejecutar en el momento en el que un cliente se conecte o desconecte, lo que nos permite hacer cosas simples pero interesantes, como por ejemplo registrar en una base de datos los detalles relacionados con las conexiones de los usuarios (fecha, ubicación, duración de la conexión, etc.). Se trata de información que se almacena en el momento en el que el evento ocurre en forma de variables de entorno, por lo tanto, lo que se debe de hacer en estos scripts es simplemente leer el valor de dichas variables de entorno antes de que dejen de estar disponibles. El siguiente script en Python nos permite hacer precisamente esto, con muy pocas líneas y prácticamente ningún esfuerzo.
connection.py:
import posix,time;
with open('/tmp/conn.out','w') as fd:
fd.write(posix.environ['trusted_ip'])
fd.write(posix.environ['common_name'])
Con esto simplemente se escriben los valores de las variales “trusted_ip” y “common_name” en un fichero de texto en el directorio “/tmp”. Evidentemente existen otras variables de entorno que se pueden consultar, como por ejemplo la IP dentro de la VPN que se le ha asignado al cliente (ifconfig_pool_remote_ip).
No obstante, lo más normal es que esta información se almacene en una base de datos, para demostrar esto, el siguiente script se encargará del registro de las conexiones en una base de datos PostgreSQL, por lo tanto será necesario utilizar una librería como “psycopg2”.
import psycopg2
import posix
common_name = posix.environ['common_name']
trusted_ip = posix.environ['trusted_ip']
class Database():
def __init__(self, dbName="database_openvpn", dbUser="postgres", dbServer="127.0.0.1", dbPort=5432, dbPass="postgres"):
self.connection = psycopg2.connect("dbname='%s' user='%s' host='%s' port='%s' password='%s'" %(dbName, dbUser, dbServer, dbPort, dbPass))
self.cursor = self.connection.cursor()
def execute(self, createInstruction, params=None):
self.cursor.execute(createInstruction, params)
self.connection.commit()
id = self.cursor.fetchone()[0]
return id
def create(self, createInstruction, params=None):
self.cursor.execute(createInstruction, params)
self.connection.commit()
def select(self, selectInstruction, params=None):
self.cursor.execute(selectInstruction,params)
return self.cursor.fetchall()
def close(self):
self.cursor.close()
self.connection.close()
if __name__ == "__main__":
db = None
try:
db = Database()
db.create("CREATE TABLE IF NOT EXISTS user(id serial primary key, common_name varchar NOT NULL);")
db.create("CREATE TABLE IF NOT EXISTS addresses(id SERIAL PRIMARY KEY, address varchar(255) NOT NULL,user_id integer REFERENCES user(id));")
db.create("CREATE TABLE IF NOT EXISTS connections(id SERIAL PRIMARY KEY, date_connection TIMESTAMP NOT NULL, date_disconnection TIMESTAMP, address_id integer REFERENCES addresses(id));")
from datetime import datetime
fechaActual = datetime.now()
timeStampActual = psycopg2.Timestamp(fechaActual.year, fechaActual.month, fechaActual.day, fechaActual.hour, fechaActual.minute, fechaActual.second)
with open('/tmp/trazas-connect','w') as fd:
fd.write("Conexion de cliente %s desde %s \n" %(common_name, trusted_ip))
users = db.select("select id from user where common_name = %s", (common_name,))
userid = 0
if len(users) < 0:
fd.write("\nUsuario registrado previamente en la base de datos")
userid = users[0][0]
fd.write("\nIdentificador de usuario: %s " %(str(userid)))
else:
fd.write("\nUsuario NO registrado previamente en la base de datos")
userid = db.execute("insert into user(common_name) values(%s) RETURNING id", (common_name,))
fd.write("\nUsuario insertado en BD con identificador: %s" %(str(userid)))
addressid = db.execute("insert into addresses(address, user_id) values(%s, %s) RETURNING id", (trusted_ip, userid,))
fd.write("\nDirección insertada en BD con identificador: %s" %(str(addressid)))
connid = db.execute("insert into connections(date_connection, address_id) values(%s, %s) RETURNING id", (timeStampActual, addressid,))
fd.write("\nConexion insertada en BD con identificador: %s" %(str(connid)))
fd.write("\nProceso de registro finalizado correctamente.")
fd.write("\n-----------------------------------------\n\n")
finally:
if db is not None:
db.close()
Este sería el script de registro, en donde se almacenan las conexiones de los usuarios y un par de detalles básicos. En este programa se verifica si el usuario se encuentra almacenado en base de datos y si está, no se procede a almacenar nada en la base de datos. El script en realidad es bastante simple, sin embargo tiene bastantes líneas de código, las cuales como se puede apreciar, en su mayoría sirven para depurar. El motivo de esto es que a día de hoy (o mejor, hasta donde llegan mis conocimientos en OpenVPN) no hay manera de depurar los programas externos que se lanzan desde el proceso de OpenVPN y si por lo que sea, dichos programas, como por ejemplo este script, lanza una excepción no controlada, el servidor rechazará la conexión con el cliente, este es otro de los motivos por los que hay que tener mucho cuidado a la hora de utilizar esta característica. Por ejemplo, suponiendo que la base de datos “database_openvpn” no se encuentre creada o que directamente el servicio de PostgreSQL se encuentre detenido, en tales casos el script lanzará una excepción y si no se controla adecuadamente, supondrá que ningún cliente se va a poder conectar a la VPN.
Ahora bien, si la opción “client-connect” permite indicar un script que se lanzará justo en el momento en el que un usuario se conecta, la opción “client-disconnect” hace lo mismo pero al reves, cuando el cliente envia la señal de cierre de conexión. Siguiendo la lógica del script anterior, el script de desconexión se encargará de realizar una operación DELETE/UPDATE sobre cada una de las tablas relacionadas. Este sería el contenido de dicho script:
import posix
import psycopg2
common_name = posix.environ['common_name']
trusted_ip = posix.environ['trusted_ip']
class Database():
def __init__(self, dbName="database_openvpn", dbUser="postgres", dbServer="127.0.0.1", dbPort=5432, dbPass="postgres"):
self.connection = psycopg2.connect("dbname='%s' user='%s' host='%s' port='%s' password='%s'" %(dbName, dbUser, dbServer, dbPort, dbPass))
self.cursor = self.connection.cursor()
def execute(self, createInstruction, params=None):
self.cursor.execute(createInstruction, params)
self.connection.commit()
def select(self, selectInstruction, params=None):
self.cursor.execute(selectInstruction,params)
return self.cursor.fetchall()
def close(self):
self.cursor.close()
self.connection.close()
if __name__ == "__main__":
db = None
try:
db = Database()
from datetime import datetime
fechaActual = datetime.now()
timeStampActual = psycopg2.Timestamp(fechaActual.year, fechaActual.month, fechaActual.day, fechaActual.hour, fechaActual.minute, fechaActual.second)
with open('/tmp/trazas-disconnect','w') as fd:
conn = db.select("select c.id from user u, addresses a, connections c where (u.id = a.user_id and c.address_id = a.id) and u.common_name = %s and a.address = %s and c.date_disconnection IS NULL", (common_name, trusted_ip,) )
connid = 0
fd.write("\nProceso de desconexion iniciado para el usuario %s " %(common_name))
if len(conn) > 0:
connid = conn[0][0]
fd.write("\nIdentificador de conexion a actualizar %s " %(str(connid)))
db.execute("UPDATE connections SET date_disconnection = %s where id = %s", (timeStampActual, connid,))
fd.write("\nProceso de desconexion del usuario %s finalizado correctamente" %(common_name))
fd.write("\n-----------------------------------------------\n\n")
except:
fd.write("\nSe ha producido una excepción\n")
finally:
if db is not None:
db.close()
Con esto ya se tendría un sistema para la gestión de conexiones en VPN, algo que serviría para monitorizar la actividad del servidor y las conexiones/desconexiones que realizan los usuarios.
Eres libre de utilizar estos scripts y modificarlos a tu gusto para realizar pruebas o incluso para implementarlos en tu propio servicio de OpenVPN
Un saludo y Happy Hack.
Adastra.
Ataques MITB persistentes “cross-browser” con Kangoo Framework – Parte 1.
Uno de los grandes inconvenientes de los ataques del tipo “client-side” es que dependen en gran medida de la interacción del cliente (navegador) y su configuración. Es posible crear un hook en un lenguaje como Javascript para ejecutar rutinas maliciosas en el lado del cliente y comprometer su sistema, es una técnica en la que se basan herramientas tan interesantes y potentes como BeEF, sin embargo, en el momento en el que el navegador o la pestaña donde se está ejecutando el hook se cierra, los recursos utilizados por el hook incluyendo las conexiones que pudiera tener abiertas con el atacante se pierden. Es algo difícil de manejar desde el lado del atacante y aunque el hook se encuentre muy bien desarrollado, es importante mantener viva la interacción del cliente con la página que contiene las rutinas maliciosas, algo que no siempre es posible por innumerables razones. Por este motivo, buscar una forma persistente, o al menos, que permita que las conexiones entre la víctima y el atacante sean lo más estables posibles, es uno de los principales objetivos en éste tipo de vectores de ataque. Una buena forma, consiste en “engañar” a la víctima y hacer que instale una extensión maliciosa en su navegador, la cual se va a encontrar en ejecución de forma constante, siempre y cuando dicha extensión se encuentre activa en el navegador, por supuesto. Evidentemente, para que la extensión en cuestión sea interesante para el mayor número de “víctimas” potenciales, debe ofrecer algo que el cliente quiera tener en su navegador, que le aporte algo significativo y útil para las actividades que desempeña, ya sea ocio, trabajo o cualquier otra cosa. Algunas ideas que se me ocurren, podrían ser:
– Extensión que permita programar alertas ante diferentes tipos de eventos sobre múltiples redes sociales.
– Extensión que permita gestionar varios perfiles de redes VPN y permita conectarse a una o varias de ellas.
– Extensión para detectar y bloquear páginas con scripts maliciosos (la vida está llena de ironías).
– Extensión que permita almacenar localmente las páginas visitadas dependiendo de las reglas indicadas por el usuario.
– Extensión para gestionar de forma ordenada, estructurada, categorizada y utilizando técnicas de machine learning, todo el p0rn que el usuario visualiza y descarga diariamente desde su navegador. Ojo, esto puede ser una idea de negocio y dado el volumen de datos manejar, es posible que sea necesaria una solución de big data. Millones de “víctimas” potenciales. (Es broma, o no…)
Cualquier idea que se os ocurra es aplicable, no obstante, al margen de la funcionalidad que deberá contemplar la extensión, es importante decidir cómo se debe desarrollar, sobre qué navegadores debe ser compatible, cuál será el medio de distribución y qué rutinas “maliciosas” debe ejecutar. En este post simplemente nos vamos a centrar en el primer punto y cómo, utilizando el Framework Kangoo, es posible desarrollar extensiones compatibles con los navegadores más utilizados actualmente, tales como Firefox, Chrome o IE.
¿Qué es Kangoo y cómo funciona?
Kangoo es un framework desarrollado en Python que permite crear extensiones rápida y facilmente, las cuales son compatibles en diferentes navegadores web. Dichas extensiones son desarrolladas utilizando la API disponible en Kangoo y que permite incluir rutinas en Javascript o incluso, cargar scripts de forma remota, algo que desde luego puede ser explotado por un atacante para incluir en la extensión un script con Javascript que permita llevar a cabo un ataque “client-site”, aunque evidentemente en tal caso es necesario tener en cuenta las restricciones de seguridad que impone el navegador web.
En este caso concreto y partiendo de los ejemplos suministrados en el proyecto, se va a crear una extensión sencilla que se desplegará en un navegador web Chrome, así que vamos a ello.
En primer lugar, es necesario instalar Kangoo, que como se ha dicho anteriormente es un proyecto basado en Python y para hacerlo, basta simplemente con seguir los siguientes pasos:
1. Descargar la última versión disponible del sitio web oficial de Kango: http://kangoextensions.com/kango.html
2. A continuación, se debe descomprimir el paquete descargado en cualquier directorio y comenzar a crear proyectos.
2.1 Desde hace algún tiempo el link de descarga no funciona correctamente, si os da un 404 al intentar descargar el ZIP del proyecto, recordar que podéis utilizar “la máquina del tiempo”: http://archive.org/web/ y navegar a un snapshot previo. Los de el 2017 no funcionan correctamente, así que ir a los últimos del 2016.
3. Dentro del directorio de Kangoo se encuentra el script “kango.py” el cual permite la creación y gestión de proyectos.
4. Crear el proyecto con el siguiente comando:
python kango.py create “THWExtension”
[ INFO] Contact extensions@kangoextensions.com to enable IE support
[ INFO] Running Kango v1.8.0
Input project name: THWExtension
[ INFO] Creating project…
[ INFO] Project created in directory /THW/THWBlog/kango-framework-latest/THWExtension
5. Ahora que el proyecto ya se encuentra creado es el momento de verificar los directorios y ficheros que ha creado y entender para qué sirven.
En primer lugar, en el directorio THWExtension/src se encuentra todo el código de la extensión y es en donde hay que empezar a meter cosas. Vamos a encontrarnos con los siguientes directorios dentro de “src”:
“chrome”, “common”, “firefox”, “ie”, “safari”.
Evidentemente cada uno corresponde a elementos muy concretos de cada uno de dichos navegadores web, sin embargo la forma en la que funciona Kangoo nos permite desarrollar componentes “cross browser” que pueden funcionar en los navegadores soportados por el framework.
En el directorio “src/common“existen dos ficheros llamados “main.js” y “extension_info.js“, siendo éste último el que permite establecer los detalles básicos de la extensión creada anteriormente, incluyendo cosas tan importantes como el listado de “content_scripts” y “background_scripts“, así como detalles visuales de la extensión como el icono.
En el fichero “main.js” de la configuración por defecto creada para el proyecto, se incluyen las instrucciones básicas que ejecutará la extensión cuando el navegador la cargue en el contexto correspondiente, con lo cual es el punto en donde se deben incluir las instrucciones “core” de la extensión y es probablemente que sea el mejor punto para comenzar a incluir instrucciones que puedan ser maliciosas, algo que se verá en la siguiente entrada.
Aunque la configuración por defecto solamente crea un “background script” definido en el fichero “main.js“, una de las cuestiones más importantes en Kangoo Framework, es que es posible crear “background scripts” para las operaciones core de la extensión y “content scripts” para acceder al contexto de las páginas web visitadas por el usuario, accediendo a todo el DOM de la página y a su información, algo que desde luego puede ser muy interesante de cara a la creación de una extensión que realice cualquier tipo de rutina maliciosa. Los “content scripts” no solamente permiten acceder la estructura DOM de las páginas, también permite alterar dicha estructura, de tal forma que es posible controlar el comportamiento visual de los componentes enseñados por cualquier sitio web, permitiendo por ejemplo, incrustar un “iframe” oculto que se encargue de descargar un script malicioso. ¿Veis por donde van los tiros? 😉
Primera extensión (muy, pero que muy básica) utilizando Kangoo.
Después de crear el proyecto, el siguiente paso consiste en comenzar a incluir instrucciones en los scripts que harán parte de la extensión. Para ello, es necesario conocer los elementos de la API de Kangoo, la cual se encuentra basada en Javascript nos permite tener un total control sobre las cosas que se pueden y no se pueden hacer en la extensión. En primer lugar, es necesario ajustar los contenidos del fichero “src/common/extension_info.js”, ya que dicho fichero es el que realmente nos permite configurar nuestra extensión. El siguiente contenido puede valer para lo que nos interesa en éste punto.
{
"content_scripts": [“content.js”],
"description": "THW Labs extension",
"creator": "Adastra",
"background_scripts": [
"main.js"
],
"homepage_url": "https://thehackerway.com/",
"version": "0.1",
"browser_button": {
"caption": "THW Extension",
"icon": "icons/thw.png",
"tooltipText": "Make THW Blog great again"
},
"name": "THWExtension"
}
Como se puede apreciar, la parte más importante del fichero se encuentra en la definición de los “content_scripts” y “backgroud_scripts”, además, también es importante apreciar que el atributo “icon” de la estructura “browser_button” apunta a un fichero que se debe encontrar en el directorio “src/common/icons”. Con está configuración básica nos podemos centrar en incluir las instrucciones de los background y content scripts.
Background script
Como se ha comentado anteriormente, en los scripts de background se incluyen todas aquellas instrucciones que permiten controlar la extensión y cualquier otro detalle que hace parte de las funcionalidades propias de la extensión. Aquí se puede utilizar Kangoo en su máxima expresión, ya que es posible hacer uso de la API completa, la cual se encuentra documentada en el siguiente enlace: http://kangoextensions.com/docs/index.html
Ahora bien, las instrucciones básicas que contendrá nuestro primer background script serán las siguientes:
function THWExtension() {
var self = this;
kango.ui.browserButton.addEventListener(kango.ui.browserButton.event.COMMAND,
function() {
self.loadPage();
});
}
THWExtension.prototype = {
loadPage: function() {
kango.browser.tabs.create({url:'https://thehackerway.com/'});
}
};
var extension = new THWExtension();
Como se puede ver, lo primero que se define es una función que contiene la lógica de la extensión, la cual, en éste caso, se encarga simplemente de invocar a la función “loadPage” únicamente en el caso de que se produzca un evento sobre el botón de la extensión, es decir, cuando un usuario pinche sobre él. En éste caso se utiliza el objeto “kango.ui.browserButton” para vincular el evento correspondiente a la interacción del usuario con el botón de la extensión. Luego, se declara el prototipo de la función principal y en él, se incluye la función que se invocará ante el evento descrito anteriormente. La función invocada (“loadPage”) se encarga simplemente de utilizar la API de Kangoo para crear una nueva pestaña en el navegador y abrir en ella la url indicada en el parámetro “url”. Se trata de una extensión sencilla y en la que se puede apreciar la filosofía que se debe aplicar cuando se crean background scripts con Kangoo.
Content script
Si bien es cierto que se trata de un tipo de script bastante interesante, no suele ser utilizado muy a menudo, excepto claro está, para realizar operaciones muy concretas. En este caso, se va a crear un content script que simplemente se encargará de incluir un “iframe” en el árbol DOM de cada una de las páginas visitadas por el usuario, ni más ni me nos que eso. Algo sencillo y sin aplicar ningún tipo de filtro, absolutamente todas las páginas visitadas por parte del usuario serán procesadas por el content script e insertará en ellas el mismo “iframe”, evidentemente para que esto funcione, es necesario que la extensión se encuentre cargada y activa en el navegador web. El contenido del fichero “src/common/content.js” puede ser como el que sigue:
// ==UserScript==
// @name THW Frame
// @include http://*
// @include https://*
// @require jquery-1.9.1.min.js
// ==/UserScript==
var frame = $(document.createElement('iframe')).attr({
src: 'https://thehackerway.com',
width: 0
}).appendTo(document.body);
El content script es sencillo, en primer lugar las primeras instrucciones indican que se deben procesar absolutamente todos los dominios visitados desde el navegador web, ya sea por HTTP o por HTTPS. En el caso de querer excluir algún dominio concreto, simplemente basta con utilizar la etiqueta @exclude e indicar el dominio o patrón/expresión regular. También, como se puede apreciar, la etiqueta @require indica que se debe incluir el fichero “jquery-1.9.1.min.js” en la ejecución del content script. Posteriormente, se utiliza jquery para acceder a la estructura DOM de cada uno de los sitios web visitados desde el navegador web y se crea un “iframe” cuyo “src” apunta a https://thehackerway.com y además, el width a “0” indica que el script no va a ser visible de cara al usuario. Dicho elemento se inserta directamente en el arbol DOM de la página web visitada gracias a la función “appendTo”.
Se trata de un script sencillo y que puede hacer bastante daño como resulta evidente. Ahora vamos a ver cómo se construye y despliega la extensión en el navegador web.
Construcción y despliegue.
Con todos los elementos preparados, es el momento de construir la extensión. Es algo muy sencillo, basta con ejecutar el siguiente comando desde el directorio raíz de Kangoo (donde se ha instalado).
python kango.py build THWExtension
[ INFO] Contact extensions@kangoextensions.com to enable IE support
[ INFO] Running Kango v1.8.0
[ INFO] Building chrome extension…
[ INFO] Building firefox extension…
[ INFO] Building safari extension…
Con esto se genera el directorio “THWExtension/output” el cual contiene la extensión empaquetada y lista para ser desplegada. Hay que tener en cuenta varias cosas:
1. Los errores de construcción que arroja Kangoo en ocasiones suelen ser poco descriptivos, es importante asegurarse de que el fichero “extension_info.json” es correcto y que cada uno de los ficheros se encuentra ubicado donde debe de estar.
2. En el caso de que la imagen para el botón de la extensión no se encuentre en el directorio “src/common/icons” Kangoo lanzará un error que indica que no se ha podido abrir un fichero o directorio, concretamente lanzará la siguiente excepción:
IOError: [Errno 2] No such file or directory: ‘/THW/THWBlog/kango-framework-latest/THWExtension/output/chrome.crx’
3. En el caso de que los content o background scripts requieran de elementos externos, como el caso de un script como “jquery”, es necesario ubicar dicho fichero en el directorio “src/common” al mismo nivel en el que se encuentran dichos scripts.
Finalmente, basta simplemente con desplegar la extensión directamente en cualquier navegador soportado, del mismo modo que se instala cualquier extensión y una vez realizado dicho proceso, se podrá ver el botón de la extensión en la barra de extensiones del navegador.
4. En el caso de instalar la extensión de una versión reciente de Firefox, es posible que no sea posible hacerlo debido a que por defecto, el navegador admite únicamente extensiones firmadas. Ver en detalle el siguiente artículo de Mozilla: https://support.mozilla.org/t5/Problems-with-add-ons-plugins-or/Add-on-signing-in-Firefox/ta-p/30262 la solución para realizar pruebas es simple, entrar en la página web de administración del navegador “about:config” y cambiar el valor de la propiedad “xpinstall.signatures.required” a false.
Ahora, con la extensión activa, es posible navegar por cualquier sitio en Internet y se podrá apreciar en el árbol DOM de cada página, que se incluye un elemento “frame” que si bien, no es visible de cara al usuario, si se ve puede ver en el código fuente de la página.
De momento sólo tenemos una extensión básica, pero aún falta la parte en la que se introducen instrucciones que pueden ser interesantes de cara a un atacante, esto se verá en el siguiente artículo en donde se indicarán las alternativas disponibles partiendo de lo que se ha explicado en éste post.
Un saludo y Happy Hack!
Adastra.
Junio, mes de cursos de Python en Securizame.
Llega junio con una propuesta formativa muy interesante por parte de Securizame, en donde tendré el placer y el honor de colaborar con la serie de cursos enfocados completamente a Python. Como podréis apreciar en la web de Securizame, se trata de una oferta formativa bastante completa en la que tendréis la posibilidad de conocer en profundidad las características más interesantes del lenguaje con el acompañamiento de profesionales de primer nivel, entre los que se encuentran Dani Garcia (Cr0hn), Maria José Montes, Julio Semper y un servidor. Podéis adquirir los módulos en formato individual o el curso completo, algo que recomiendo si de verdad queréis aprender a crear herramientas de todo tipo con Python. Algunos de los módulos son online, pero como podréis comprobar, algunos son presenciales incluyendo el que voy a impartir, aunque se está barajando la posibilidad de hacerlos también online para las personas que por cualquier motivo no podéis acercaros a las oficinas de Securizame en Madrid. Evidentemente, los cursos presenciales tienen la ventaja de que podéis hacer todas las preguntas que queráis y resolverlas “in-situ” y por si fuera poco, son cursos que se van a impartir los viernes en la tarde y los sábados, lo que facilita enormemente las cosas para aquellas personas que por trabajo u otras obligaciones no tienen la posibilidad de asistir entre semana. Las instalaciones se encuentran muy bien equipadas y con todo lo necesario para desarrollar cada uno de las clases que haremos los profesores, cuyos contenidos hemos diseñado con mucho cariño e ilusión, esperando que de verdad os sean útiles para vuestras vidas profesionales y/o académicas.
Creo que es una buena oportunidad para dominar el lenguaje y automatizar muchas de las labores que seguramente hacéis manualmente y que pueden suponer varias horas del día haciéndolas.
Finalmente, para animaros un poco y dependiendo del número de asistentes que decidáis apuntaros al curso completo, llevaré algunas copias de los dos libros de Python que he escrito para rifarlas entre vosotros, algo que os vendrá como anillo al dedo para apoyar vuestra formación en dicho lenguaje.
Espero veros por allí y si necesitáis más información al respecto, podéis rellenar el formulario que se encuentra disponible aquí o llamar directamente al teléfono que aparece en la página.
Un saludo y Happy Hack!
Adastra.
THW Academy: Plataforma de aprendizaje para hackers en castellano.
Las cosas han cambiado muchísimo con respecto a hace poco más de 15 años, por aquel entonces encontrar información sobre seguridad informática y hacking no estaba al alcance de todo el mundo, en las bibliotecas ya te podías olvidar de encontrar manuales sobre reversing en sistemas Linux, explotación de software o hacking en general. Por aquella época todo ello era como la magia o la alquimia, cosas maravillosas que pocos habían llegado a escuchar y muchos menos habían llegado a ver.
Ahora tenemos Internet, comunidades, blogs, foros, etc. Mucha información que se encuentra a nuestro alcance y llegamos a ella al instante, muchas nuevas tecnologías y una curva de aprendizaje que cada vez está más cuesta arriba. No obstante nos seguimos encontrando con que prácticamente toda la documentación de calidad y con buenos niveles de profundidad se encuentra en inglés.
Hay muchos sitios en castellano que no son buenos, son lo siguiente, pero a veces se suelen centrar una temática muy concreta o abarcan muchos temas sin llegar a un nivel de profundidad aceptable en ninguno.
Luego, hay muchos cursos/certificaciones en donde te piden que pagues miles de euros para aprender sobre web hacking, reversing, networking, programación o cualquier otra temática concreta, con unos precios que a mi juicio tienen una calidad/precio muy desproporcionada.
Los que me conocéis o seguís este blog, sabéis que me gusta investigar y compartir lo que aprendo, llevo muchos años con una “sed” de conocimiento que nunca he llegado a saciar y aunque han habido épocas en las que me he sentido muy cansado y desmotivado por situaciones concretas, nunca he claudicado y llevo media vida, casi 15 años, intentando aprender y mejorar mis habilidades a nivel personal y académico, lo hago porque como he dicho en otras ocasiones, para mi esto no es solamente un oficio, representa una filosofía de vida a la que me mantengo fiel y también por eso escribo en este espacio cada vez que puedo.
Todo esto me ha llevado a crear THW Academy (http://academy.thehackerway.com/), una plataforma de aprendizaje totalmente online en la que vas a poder aprender sobre seguridad informática y hacking desde una perspectiva completamente “hands on” o practica. No esperes las típicas clases tradicionales llenas de conceptos teóricos sin ningún tipo de demostración practica, o clases demasiado extensas y aburridas en las que desconectas a los 10 minutos. Todas las sesiones de cada uno de los cursos tienen una parte teórica que suele ser muy concisa y una parte practica en la que se puede ver “al vuelo” cómo se aplican los conceptos teóricos.
Este espacio lo he diseñado con tres niveles de cursos: “Básico”, “Intermedio” y “Avanzado”, cada uno adaptado a su correspondiente nivel. Las personas inscritas en la plataforma podrán acceder a todos los cursos de cada nivel sin ningún tipo de restricción. Se suben varias sesiones todas las semanas que se pueden consultar en el calendario oficial, además tendrás acceso a vídeos en HD, documentación y espacios privados especialmente diseñados para probar técnicas de hacking.
Puedes seguir todos los cursos a la vez o solamente aquellos que sean de tu interés. Es aconsejable ir siguiendo las sesiones de todos los cursos para sacar el máximo provecho de la plataforma, pero el estudiante es libre de seguir únicamente aquellos cursos que decida. En la medida en que los cursos van avanzando, los contenidos van siendo más prácticos y didácticos, el desarrollo de las sesiones semanales es constante y muy dinámico, cada mes vas a tener acceso a varios vídeos que podrás repasar las veces que quieras.
La plataforma se encuentra ubicada en: http://academy.thehackerway.com y como podrás ver en el catalogo de cursos, los que se encuentran disponibles actualmente son los siguientes:
“Básico”
THWB1: Introducción a la programación en Python.
THWB2: Introducción a la privacidad y el anonimato.
THWB3: Introducción a la programación en Ruby.
THWB4: Introducción al pentesting y al hacking.
“Intermedio”
THWI1: Pentesting en aplicaciones web.
THWI2: Administración y hardening de servidores web Apache.
THWI3: Desarrollo web seguro con Java.
“Avanzado”
THWA1: Hacking con Python.
THWA2: Uso y configuración avanzada de I2P y Freenet.
THWA3: Uso y configuración avanzada de TOR.
Son 10 cursos a los que vas a tener acceso por el mismo precio y además hay promociones que te podrían interesar. El calendario oficial incluye la planificación de las sesiones que se van a publicar durante los próximos meses con sus correspondientes contenidos, el cual puedes consultar en el siguiente enlace: http://academy.thehackerway.com/calendario-oficial además, puedes ver más detalles sobre THW Academy aquí: http://academy.thehackerway.com/cuentame-que-es-esto
En los próximos meses también tengo planificados cursos sobre Arquitectura de ordenadores, introducción a ensamblador, Fuzzing y explotación de software avanzado en sistemas Windows y Linux.
Esto es lo que tengo para toda la comunidad, quiero compartir lo que constantemente he ido aprendiendo en los años que llevo dedicado a esto y todo lo que me queda por aprender. Creo que está es una buena forma.
Como siempre, si quieres comentarme cualquier cosa o necesitas más información, me puedes escribir a adastra@thehackerway.com
Saludos y Happy Hack!
Adastra.
Pentesting automatizado con Beef. Consumiendo la API Rest de BeEF con Python – Parte 3
La API Rest de BeEF cuenta con todo lo necesario para controlar y automatizar las actividades que se pueden llevar a cabo desde el C&C de BeEF. El hecho de poder invocar a los endpoints definidos en dicha API permite crear rutinas de código que ayuden a ejecutar los procesos de recolección de información y explotación de una forma mucho más rápida y eficiente. Tal como se ha enseñado en las dos entradas anteriores sobre BeEF, utilizar esta API no es nada complicado y solamente es necesario ejecutar las peticiones HTTP con los parámetros correctos. Para hacerlo, se puede utilizar herramientas como wget, curl o incluso netcat/socat y si se quiere automatizar el uso de estas herramientas, una buena forma de hacerlo consiste en crear un script en bash que que las ejecute. Evidentemente también es posible utilizar cualquier lenguaje de programación y ejecutar las peticiones HTTP de forma automatizada utilizando las diferentes librerías que proporcionan todos los lenguajes de programación modernos. Dicho esto, a continuación se explicará cómo invocar a algunos de los endpoints de BeEF utilizando Python y en el próximo artículo, lo mismo pero utilizando Ruby.
Consumiendo la API de BeEF con Python
Python cuenta con un considerable número de librerías para realizar peticiones HTTP, lo que facilita muchísimo las cosas a la hora de crear clientes o incluso servicios utilizando Python y este protocolo. Una de las más conocidas y utilizadas es “requests” ya que con muy pocas líneas de código se puede crear un cliente HTTP completamente funcional y soportando todas las características del protocolo HTTP 1.1, algo que en otras librerías como urllib, urllib2 o httplib requiere más líneas de código y un poco más de esfuerzo. Con esto en mente se podría crear un script utilizando requests para consumir la API Rest de BeEF, pero para facilitar aun más las cosas, existe una librería pequeña y simple llamada BeEF-API que ya se encarga de interactuar con los endpoints de BeEF y solamente es necesario invocar a los métodos adecuados de dicha librería. Se encuentra disponible en el siguiente repositorio de GitHub: https://github.com/byt3bl33d3r/BeEF-API y como ocurre con prácticamente todas las librerías en Python, para instalarla solamente hace falta ejecutar el script “setup.py” con el parámetro “install”.
Esta librería se encarga de gestionar la autenticación con BeEF y almacenar internamente el token generado, el cual como se ha visto en el primer artículo, es requerido para invocar algunos de los endpoints de la API Rest.
>python
Python 2.7.6 (default, Jun 22 2015, 17:58:13)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from beefapi import BeefAPI
>>> beef = BeefAPI({})
>>> beef.login('beef', 'beef')
True
|
Como se puede apreciar, todo parte de la creación un objeto del tipo “BeefAPI”, cuyo constructor recibe como argumento un diccionario, el cual puede tener las claves “host” y “port” en el caso de que se quiera indicar una interfaz de red y puertos distintos a los valores por defecto (127.0.0.1:3000). Posteriormente se invoca al método “login” enviando como parámetros el usuario y la contraseña para autenticarse en el sistema.
Una vez el usuario se ha conseguido autenticar y se ha generado un token para la sesión actual, la librería dispone de una serie de métodos para invocar distintos endpoints, gestionando el token de autenticación de forma automática en cada una de dichas invocaciones. Algunos de los métodos disponibles en una instancia de la clase BeefAPI, permiten obtener los módulos disponibles en la instancia de Beef, buscar módulos que contengan una cadena determinada, listar todos los navegadores que han ejecutado el “hook” de Beef y que se encuentran “online”, así como aquellos que se encuentran “offline” y por supuesto, ejecutar módulos contra todos o solamente algunos de los navegadores enganchados. Esta librería utiliza internamente “requests” y los valores de retorno de cada petición siempre son diccionarios que representan las repuestas emitidas por cada uno de los endpoints invocados en formato JSON.
Listando todos los módulos disponibles en BeEF
Como mencionaba antes, también es posible buscar módulos que cumplan con un patrón de texto determinado, pudiendo filtrar de esta forma aquellos módulos que sean de interés para el usuario.
Filtrando módulos en BeEF
Del mismo modo que se pueden realizar búsquedas y listar los módulos disponibles en BeEF, también es posible hacer operaciones similares contra los navegadores que se encuentra online y offline.
Listando navegadores hookeados
Y por último, pero no menos importante, es posible ejecutar un módulo determinado contra uno o varios navegadores que se encuentran “hookeados” en BeEF. Para hacerlo, en primer lugar hay que obtener el objeto correspondiente al navegador contra el que se desea ejecutar el módulo y en segundo lugar, se debe especificar el identificador del módulo que se desea utilizar contra el navegador. Cada objeto del tipo “Session” (navegador hookeado) tiene un método llamado “run” el cual recibe como argumento un valor númerico que representará el identificador de un módulo. Dicho método se encargará de buscar el módulo identificado con el valor especificado y posteriormente, se encargará de lanzarlo contra el navegador hookeado, algo que como se puede ver más abajo, se consigue con pocas lineas de código.
>>> for hook in beef.hooked_browsers.online: ... commandId = hook.run(243)["command_id"] ... print beef.modules.findbyid(243).results(hook.session, commandId) |
En este caso, el módulo con el identificador “243” corresponde al módulo “Detect tor”, el cual como su nombre lo indica, intenta determinar si el navegador en cuestión está utilizando TOR para navegar. El método “run” es el encargado de ejecutar el módulo especificado y de retornar una estructura en formato “JSON” con un identificador del comando, el cual debe ser utilizado posteriormente para obtener los resultados que ha devuelto el módulo.
Como se ha podido ver, utilizar está librería no es complicado y es una buena forma automatizar las tareas que pueden llevarse a cabo desde la consola web de BeEF. En el próximo artículo hablaré sobre cómo hacer esto mismo con Ruby.
Saludos y Happy Hack!
Adastra.
Servicios en TheHackerWay
Descubre los productos y servicios enfocados a la seguridad informática que ofrecemos en TheHackerWay
Deep web: Privacidad y anonimato.
Compra el libro de "Deep Web: TOR, FreeNET & I2P - Privacidad y Anonimato"
Hacking con Python
Compra el libro de "Hacking con Python".
Python para Pentesters
Compra el libro de "Python para Pentesters".
Número de Visitas:
Sobre Adastra:
Soy un entusiasta de la tecnología y la seguridad informática, me siento atraído principalmente por la cultura y los fundamentos del Gray Hat Hacking.
Soy una persona afortunada de poder dedicar mi tiempo y energía en hacer lo que me apasiona, aprendiendo y compartiendo lo aprendido. Con bastante frecuencia iré publicando entradas relacionadas con estudios y técnicas que he ido asimilando a lo largo de mis investigaciones, todas enfocadas a las diferentes facetas de la informática con un énfasis especial en la seguridad.
Saludos y Happy Hack!
adastra
