Archive
Tahoe-LAFS. Creación y configuración de grids – Parte 2
En el primer articulo he hablado sobre el funcionamiento de Tahoe-LAFS y los motivos por los que resulta mucho más interesante utilizar un sistema descentralizado de este tipo en la nube, que uno de los servicios convencionales con los problemas que implica. Tahoe es un sistema de almacenamiento distribuido que se puede montar en un segmento de red local o incluso directamente en Internet siendo muy fácil de configurar y bastante estable. Tal como explicaba en el primer artículo, los clientes de un “grid” pueden subir ficheros y directorios de forma privada y segura, ya que los servidores de almacenamiento del sistema no tienen la capacidad de leer y/o escribir sobre dichos ficheros, solamente se limitan a almacenarlos y compartirlos en el caso de que se encuentren configurados para hacerlo. En Tahoe es posible crear varios tipos de nodos que tienen un funcionamiento muy concreto, es así como se pueden crear nodos cliente, servidor, introducers, servidores de estadísticas y generadores de claves. Desde luego, los nodos cliente, servidor y los introducers son los más interesantes desde el punto de vista funcional, ya que permiten crear un grid sobre el que se pueden subir documentos.
En el primer artículo se explicaba en qué consistía Tahoe, cómo instalarlo y crear un cliente básico, el cual se conectaba a un grid por medio de un introducer que se encuentra disponible en el proyecto para que los usuarios interesados puedan llevar a cabo pruebas contra un sistema en funcionamiento. Dicho introducer se encuentra disponible en internet a cualquiera que desee conectar sus nodos clientes de Tahoe con el sistema de pruebas del proyecto, las instrucciones para conectarse a dicho servicio se encuentra detalladas en el siguiente enlace: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid.
Para realizar pruebas está bastante bien, sin embargo es mucho más interesante crear un grid propio y configurarlo de tal forma que sea posible utilizar Tahoe de forma privada y confidencial con otros usuarios en Internet. Para conseguir esto, es necesario crear en primer lugar un “introducer”, el cual como ya se ha explicado antes, es el encargado de conectar al cliente con el sistema de grid, el cual se compone de 1 o muchos servidores de almacenamiento. A continuación se explica el procedimiento para crear un introducer ejecutando la utilidad “tahoe”.
En primer lugar, es necesario crear un directorio en el que se deberán crear los ficheros de configuración del introducer, una vez creado dicho directorio, es necesario ubicarse en él y ejecutar el siguiente comando.
| >tahoe create-introducer /adastraData/AdastraRealm/Hacking/networkHacking/AdastraIntroducerIntroducer created in ‘/adastraData/AdastraRealm/Hacking/networkHacking/AdastraIntroducer’ |
Después de crear el introducer, todos los ficheros y la configuración necesaria para que el nodo funcione correctamente, se habrá desplegado en el directorio especificado. En dicho directorio, se ha tenido que crear un subdirectorio llamado “private” el cual contendrá un fichero con nombre “introducer.furl” el cual contiene la dirección del introducer que debe ser utilizada por otros usuarios para que puedan conectarse al sistema de grid.
A continuación, se puede iniciar el nodo ejecutando el comando “tahoe” con el argumento “start”
| >tahoe start /adastraData/AdastraRealm/Hacking/networkHacking/AdastraIntroducerSTARTING ‘/adastraData/AdastraRealm/Hacking/networkHacking/AdastraIntroducer’
starting node in ‘/adastraData/AdastraRealm/Hacking/networkHacking/AdastraIntroducer’ |
Ahora que el introducer se encuentra iniciado, es el momento de probar si su funcionamiento es correcto, para ello se debe utilizar un nodo cliente de Tahoe y conectarlo con el introducer. Esto ya se ha visto en el artículo anterior, así que partiendo del cliente creado en dicho artículo, basta simplemente con editar el fichero de configuración del nodo (tahoe.cfg) y modificar la propiedad “introducer.furl” que se encuentra en la sección “[client]”. El valor que debe asumir dicha propiedad debe ser el mismo que se ha generado a la hora de crear el introducer y que se encuentra contenido en el fichero “<INTRODUCER_DIR>/private/introducer.furl”.
Una vez el cliente apunta al introducer, se procede a arrancar.
| >tahoe run ~/.tahoe/ STARTING ‘/home/adastra/.tahoe’
running node in ‘/home/adastra/.tahoe’ 2015-06-28 21:38:53+0200 [-] Log opened. 2015-06-28 21:38:53+0200 [-] twistd 13.2.0 (/usr/bin/python 2.7.6) starting up. 2015-06-28 21:38:53+0200 [-] reactor class: twisted.internet.epollreactor.EPollReactor. 2015-06-28 21:38:53+0200 [-] Listener starting on 37384 2015-06-28 21:38:53+0200 [-] NevowSite starting on 3456 2015-06-28 21:38:53+0200 [-] Starting factory <nevow.appserver.NevowSite instance at 0x7f81a2bf2440> 2015-06-28 21:38:53+0200 [-] My pid: 11224 2015-06-28 21:38:53+0200 [-] DatagramProtocol starting on 38362 2015-06-28 21:38:53+0200 [-] Starting protocol <twisted.internet.protocol.DatagramProtocol instance at 0x7f81a2c03a28> 2015-06-28 21:38:53+0200 [-] (UDP Port 38362 Closed) 2015-06-28 21:38:53+0200 [-] Stopping protocol <twisted.internet.protocol.DatagramProtocol instance at 0x7f81a2c03a28> |
Ahora que el cliente ha iniciado correctamente, se puede verificar si se encuentra conectado con el introducer creado previamente, para ello basta con ingresar a la consola web del nodo, la cual se encuentra levantada en el puerto 3456.
Cliente de Tahoe conectado a un Introducer.
Finalmente, se puede detener el introducer ejecutando el comando “tahoe” con el argumento “stop”
| >tahoe stop /adastraData/AdastraRealm/Hacking/networkHacking/AdastraIntroducerSTOPPING ‘/adastraData/AdastraRealm/Hacking/networkHacking/allmydata-tahoe-1.10.1/AdastraIntroducer’
process 11081 is dead |
Ahora bien, hasta este punto solamente se ha creado un introducer y se ha podido verificar que un cliente en Tahoe puede conectarse y subir/descargar documentos, sin embargo, tal como se podía apreciar en la imagen anterior, en el sistema de grid no existe ningún servidor de almacenamiento conectado, lo que significa que el sistema no funcionará correctamente cuando un cliente intente subir documentos.
Un sistema de grid no tiene ningún sentido si no existen uno o varios servidores de almacenamiento y para crear uno, nuevamente es necesario modificar el fichero de configuración de Tahoe e indicar que la instancia que utilice dicho fichero funcionará como un servidor de almacenamiento. Como se ha mencionado antes, los servidores de almacenamiento no tienen la capacidad de acceder a los ficheros que se suben a su espacio de almacenamiento, ya que se encuentran cifrados y solamente el cliente con la clave adecuada puede llegar a ellos. En este sentido, se trata de un “Data Store” cifrado, un concepto que es bastante utilizado en redes anónimas que siguen un modelo de compartición distribuido y privado, como es el caso de Freenet.
Para que una instancia de Tahoe pueda funcionar como un servidor de almacenamiento, se debe editar el fichero de configuración de dicha instancia (tahoe.cfg) y establecer las propiedades de dicho servidor en la sección “storage”, además, la propiedad “enabled” tiene que tener el valor “true” para que dicha instancia funcione como un servidor de almacenamiento.
| [storage]# Shall this node provide storage service?
enabled = true readonly = false reserved_space = 1G |
A continuación, dicha instancia de Tahoe debe vincularse con el introducer tal como se ha visto anteriormente, para ello se debe indicar el valor adecuado en la propiedad “introducer.furl”.
Finalmente, se ejecuta el servidor de almacenamiento como ocurre con cualquier instancia de Tahoe, utilizando el comando “run”
| >tahoe run /server/tahoe/STARTING ‘/server/tahoe’
running node in ‘/server/.tahoe’ 2015-07-12 19:52:55+0200 [-] Log opened. 2015-07-12 19:52:55+0200 [-] twistd 15.2.1 (/usr/bin/python 2.7.6) starting up. 2015-07-12 19:52:55+0200 [-] reactor class: twisted.internet.epollreactor.EPollReactor. 2015-07-12 19:52:55+0200 [-] Listener starting on 37384 2015-07-12 19:52:55+0200 [-] NevowSite starting on 3456 2015-07-12 19:52:55+0200 [-] Starting factory <nevow.appserver.NevowSite instance at 0x7f5e31f24cb0> 2015-07-12 19:52:55+0200 [-] My pid: 14783 2015-07-12 19:52:55+0200 [-] DatagramProtocol starting on 37926 2015-07-12 19:52:55+0200 [-] Starting protocol <twisted.internet.protocol.DatagramProtocol instance at 0x7f5e31ed04d0> 2015-07-12 19:52:55+0200 [-] (UDP Port 37926 Closed) 2015-07-12 19:52:55+0200 [-] Stopping protocol <twisted.internet.protocol.DatagramProtocol instance at 0x7f5e31ed04d0> |
Ahora el servidor de almacenamiento se debe encontrar vinculado con el introducer y con esto será suficiente para que los clientes puedan subir ficheros en la nube.
Registro del storage server
Como se puede apreciar, el sistema de grid ahora cuenta con un servidor de almacenamiento, sin embargo serán necesario más servidores para que se puedan subir documentos y ficheros sin dificultades, es decir, contar con una red real de servidores distribuidos para el almacenamiento de ficheros y documentos.
Saludos 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.
Intentando evadir mecanismos y restricciones de Seguridad – Creando una puerta trasera y accediendo a información de usuarios usando un DEB malicioso – Parte IV
En la entrada anterior se ha indicado como crear un instalador DEB malicioso utilizando msfpayload, lo que ha permitido obtener una consola en la máquina remota que se deseaba atacar.
Partiendo de la publicación anterior, se intentará crear un programa simple que acceda a la información de todos los usuarios del sistema y dicha información se intentará enviar a una máquina remota por medio de un socket. A continuación se indica paso a paso, el uso de algunas librerías propias en C/C++ (en concreto, contenidas en el paquete libc y build-essentials) y como se ha codificado está pequeña puerta trasera. El objetivo de lo que se indica a continuación, es solamente para fines ilustrativos, no se tienen en cuenta factores de seguridad vitales en la máquina atacada tales como firewalls, AV y/o IDS, de esta forma, un hacker con conocimientos medios en programación puede darse una idea de la cantidad de operaciones que puede llevar a cabo en una máquina objetivo con un vector de ataque como este.
Bind a puertos reservados utilizando usuarios sin privilegios de Root
Una de las tareas mas comunes de un administrador de sistemas consiste principalmente en la correcta configuración y arranque de diversos servicios tales como servidores web, servidores de correo, servidores DNS, etc. En todos los casos, alguien consciente de que la seguridad en los servicios expuestos al publico tendrá como referencia determinadas políticas de seguridad entre las cuales, sin lugar a dudas, se debe incluir la ejecución de dichos servicios con un usuario con privilegios limitados, es decir, el usuario ROOT no debería iniciar servicios como Apache o SendMail, ya que si existe algún problema con dichos servicios, como por ejemplo una vulnerabilidad que le permita al atacante acceder de forma remota (como por ejemplo el aprovechamiento de una vulnerabilidad de Buffer Overflow) este automáticamente tendrá privilegios de ROOT sobre el sistema, no hace falta indicar las nefastas consecuencias que conllevan incidencias como estas.
Recuperar Ficheros Borrados y Reparar sistemas de archivos
Para recuperar ficheros o reparar sistemas de archivos basados en Ext, es necesario utilizar la herramienta e2fsck, la cual espera como parámetro el dispositivo que se desea chequear, es necesario que este se encuentre desmontado:
e2fsck /path/filesystemExt
Recuperando ficheros borrados:
En primer lugar, un fichero es una relación de disco y enlace, de esta forma el sistema operativo puede acceder al fichero por medio del enlace que apunta a la ubicación física en el disco duro, (llamado inode) cuando se emplea el comando rm para eliminar un fichero, solamente se elimina el enlace al que apunta, sin embargo el fichero permanece en el disco duro por un periodo de tiempo, vamos a ver una practica habitual cuando un fichero es eliminado y un proceso hace uso de el (un proceso zoombie)
Servicios en TheHackerWay
Deep web: Privacidad y anonimato.
Hacking con Python
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
