Archivo
Seguridad en ElasticSearch: ES desde la perspectiva de un pentester – Parte V
Cuando ponemos un nodo en modo “cluster” es cuando realmente se empiezan a complicar las cosas desde el punto de vista de la seguridad. Algunas consideraciones que fácilmente se pueden detectar desde el punto de vista de un pentester son las siguientes:
Sin mecanismos de autenticación o autorización en el acceso a la API Rest.
Como se ha visto en los post anteriores de ésta serie (parte1, parte2, parte3, parte4), la API Rest de una instancia de ES es muy potente, de hecho es el corazón del motor. Desafortunadamente, por defecto no se implementa ningún mecanismo de seguridad para la autenticación de usuarios. Recordad que ES es una base de datos, con un modelo de funcionamiento diferente a las bases de datos relacionales pero su objetivo principal es el mismo: el almacenamiento de información. Si en una base de datos tradicional se permite que cualquier usuario sin autenticación previa, ejecute consultas SQL sobre las tablas y que tenga la posibilidad de lanzar procedimientos almacenados, estamos en una situación poco deseable en la que como mínimo, es posible que se produzcan fugas de información sensible y a mayores, en la explotación del sistema. Pues bien, por defecto esto es lo que tenemos con cualquier instancia de ES. Alguien podría decir: “pero no pasa nada, porque la API Rest de ES se vincula únicamente a la interfaz de red local, que no está expuesta a otros sistemas y por lo tanto únicamente un administrador podrá acceder a ella”. Sí y no. Si utilizamos ES en modo de desarrollo, es decir, con un único nodo local y sin activar el modo cluster esto es cierto, pero aún así, si el sistema ya ha sido comprometido y un atacante tiene la posibilidad de ejecutar comandos, se podría crear fácilmente un túnel SSH que exponga el puerto en el que se encuentra en ejecución la API Rest de ES y de esta forma, acceder a la información almacenada en el cluster. Incluso, sin llegar al supuesto de que el sistema haya sido comprometido, es posible que el administrador quiera acceder a la instancia remotamente y lanzar consultas, para ello también podría crear un túnel SSH abriendo la posibilidad de que él y cualquiera pueda entrar ya que por defecto, no hay mecanismos de autenticación y autorización.
| ssh -L 0.0.0.0:9999:127.0.0.1:9200 esuser@localhost |
Por ejemplo, si se ejecuta el comando anterior sobre el sistema en el que se encuentra en ejecución la instancia de ES, se abrirá el puerto “9999” en todas las interfaces de red disponibles y se podrá acceder a la API Rest de ES utilizando dicho puerto. Esta es solo una forma, existen otras más, por ejemplo utilizando redirecciones con socat. Este y muchos otros temas relacionados con la post-explotación de sistemas los enseño en los cursos que imparto en Securízame por si estás interesado.
Operaciones de administración de la instancia de ES sin protecciones de ningún tipo.
Ahora bien, en el caso de que efectivamente, lo anterior no sea posible porque el sistema está correctamente securizado y no hay agujeros de seguridad que le permitan a un atacante crear un túnel como el anterior, aún hay que considerar que si la instancia de ES se ha configurado en modo “cluster”, cualquiera se podrá conectar a ella, ya que como se ha visto en la parte anterior de esta serie, para que el modo cluster funcione correctamente la instancia tiene que permitir la conexión remota por parte de otros nodos. Esto significa que lo más probable es que otras instancias puedan consultar cualquier endpoint de la API Rest, incluyendo aquellos que permiten la administración completa del nodo, nuevamente sin ningún tipo de restricción.
Fugas de información sensible con instancias maliciosas en el cluster
Otra cuestión a tener en cuenta en el modo cluster, es que se puede consultar fácilmente si una instancia actúa como “master” y levantar otra instancia que funcione en modo “esclavo” para obtener las replicas de la información almacenada en el cluster. Esto está muy bien sino fuese porque nuevamente, no hay ningún mecanismo de autenticación y autorización por defecto en ES para este tipo de operaciones, es decir, que por defecto se “confía” en que la instancia que se quiere unir al cluster es legitima y no hay ningún mecanismo para indicar cuáles son aquellas instancias que realmente están autorizadas para unirse al cluster y cuáles no. Es posible que el lector recuerde o haya visto alguna vulnerabilidad de transferencia de zona en servidores DNS mal configurados, pues en este caso estamos ante una situación muy similar. Es posible levantar una instancia de ES y editar la configuración por defecto para que apunte al master y obtener la replica de los documentos almacenados en el cluster, es decir, la información propiamente dicha.
Denegación del servicio sobre nodos del cluster.
Existe otro problema inherente al funcionamiento de ES relacionado con el almacenamiento de la información. Como se ha mencionado anteriormente, la estructura de los documentos almacenados en ES parte de un índice, que funciona como un esquema en una base de datos relacional. Esta información se carga en memoria con el objetivo de que el acceso sea rápido, por lo tanto la máquina sobre la que se ejecutan dichas instancias tienen que ser lo suficientemente potente (tanto en términos de memoria como de procesamiento) para admitir la carga de estos documentos. Se tiene que tener un muy buen control sobre lo que se va a almacenar, es decir, permitir la inserción de documentos únicamente con la información estrictamente necesaria y evitar que sean estructuras JSON muy grandes. Si la API Rest de ES puede ser consultada por cualquiera o simplemente, no se tiene cuidado con las cuestiones indicadas antes, es posible que hayan problemas de almacenamiento en una o varias instancias del cluster, pudiendo incluso provocar condiciones de denegación de servicio. Por otro lado, tal como se ha explicado en uno de los posts anteriores de la serie, gracias a la API Rest de ES es posible abrir y cerrar índices, acción que se encarga de volcar los documentos del índice en cuestión a disco (operación de cierre) o de disco a memoria (operación de apertura). El problema de estas operaciones es que son costosas en términos de recursos como resulta evidente y si se ejecutan constantemente sin ningún control sobre índices con miles de documentos (ejecutando un script malicioso, por ejemplo) es bastante probable que se produzca una condición de denegación de servicio.
Tráfico sin cifrar.
En modo cluster los nodos se comunican e intercambian paquetes de datos sin ningún tipo de protección en la capa de transporte. Esto significa que evidentemente, es inseguro por defecto. Como seguramente ya sabéis, esto puede dar lugar a diferentes tipos de ataques que van desde la captura pasiva de paquetes hasta la manipulación y posterior reinyección de los mismos en ciertos escenarios. En este punto poco más merece la pena explicar, es evidente que se trata de un problema de seguridad que no es aceptable en un cluster encargado de almacenar información sensible.
¿Contramedidas?
Si el lector ha trabajado anteriormente con ES, seguramente una de las primeras cosas en las que pensará será en las características de seguridad disponibles en el módulo “X-Pack” (https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-security.html) y a continuación en la inversión que habría que realizar para adquirir y habilitar dicho módulo en la instancia de ES, ya que no es gratuito. Sin embargo, debido a la presión de la comunidad pidiendo implementar mecanismos de seguridad en la versión gratuita de ES, desde mayo del presente año todas las versiones de ES desde la 6.8 cuentan con características de seguridad incluidas en el producto y que se pueden activar si el administrador así lo desea. Dicho anuncio se ha hecho público hace unas pocas semanas a la fecha de escribir este post y se puede consultar aquí: https://www.elastic.co/es/blog/getting-started-with-elasticsearch-security
No obstante, como resulta evidente las instalaciones de ES existentes tienen que ser “reinstaladas” con las nuevas versiones disponibles en los repositorios de ES, lo cual no es precisamente una tarea fácil cuando la instancia o cluster tiene datos almacenados pero ya es algo.
Algunas de las características relativas a la seguridad en ES, que ahora se encuentran integradas por defecto y para las que no hace falta tirar de X-Pack son las siguientes.
- Control de accesos basado en roles.
- Comunicación segura entre nodos de la instancia.
- Autenticación de usuarios basada en directorio activo, LDAP, Kerberos, SAML o de forma local.
- Tráfico confiable “nodo a nodo”, habilitando filtrados basados en listas blancas.
- Logging en eventos relacionados con la seguridad de forma transparete.
Entre muchas otras cosas más. Se trata de características que evidentemente se deben utilizar en un entorno productivo para proteger la información de accesos no autorizados y “miradas indiscretas”.
Un Saludo y Happy Hack.
Adastra.
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
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
