Archivo

Posts Tagged ‘elasticsearch cluster’

Seguridad en ElasticSearch: ES desde la perspectiva de un pentester – Parte V

octubre 14, 2019 1 comentario

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.

Seguridad en ElasticSearch: modo cluster – Parte IV

septiembre 16, 2019 1 comentario

En el post anterior ya se ha hablado sobre algunas características avanzadas para la búsqueda de contenidos en ES, ahora es el momento de hablar sobre la configuración necesaria en ES para que funcione en modo cluster. En primer lugar hay que mencionar que cuando se inicia una instancia de ES, lo primero que hace es intentar unirse a un cluster si se han indicado los detalles en dicho cluster en la configuración, en el caso de que no sea así, se entiende que el nodo funcionará en modo “standalone” y en tal caso, creará un cluster en donde es la propia instancia la que funciona como “master”.

Configuración modo “cluster” con múltiples nodos.

La configuración en modo cluster de ES con múltiples nodos es considerada como una configuración para un entorno de producción. Esto significa que en primer lugar, la instancia de ES ya no se ejecutará únicamente en la interfaz de loopback como se ha visto hasta ahora, sino que evidentemente, debe estar disponible y alcanzable por otros nodos/instancias que harán parte del cluster. La configuración de todas las instancias de ES giran en torno al fichero “elasticsearch.yml” para cuestiones concretas de la instancia y otros ficheros como el “jvm.option” y “log4j2.properties”  para asignar valores de configuración a la VM de Java, evidentemente se trata de una labor de vital importancia para el tuning de una máquina virtual y el correcto funcionamiento de la instancia, pero se sale un poco del scope de estos post. Todos estos ficheros, así como el keystore y certificado de la instancia se encuentran en el directorio “config”.

ES normalmente requiere muy poca configuración y prácticamente todos los cambios se pueden realizar en caliente gracias a la API disponible en el motor, excepto la configuración en modo cluster, de hecho, si se ha iniciado una instancia con sus valores por defecto se creará un directorio llamado “data” el cual contiene toda la información de los nodos vinculados al cluster. Si se inicia una instancia de ES con la configuración por defecto y luego, se plantea integrar dicha instancia en un cluster existente, es importante tener en cuenta que no solamente será necesario editar el fichero de configuración como se explicará a continuación, sino que además se debe eliminar el directorio “data” para que la instancia comprenda que ahora no es el “master” de un cluster local, sino que se unirá a un cluster existe. Esto último es importante, ya que en el caso de no hacerlo se producirán errores en el arranque aunque la configuración sea correcta.

Ahora bien, los valores de configuración mínimos que se deben indicar en el fichero de “elasticsearch.yml” son los siguientes:

cluster.name: Nombre que tiene el cluster al que la instancia se unirá.
node.name: Nombre del nodo.
cluster.initial_master_nodes: Se trata de las direcciones IP o nombres de dominio de uno o varios nodos “master” del cluster objetivo.
transport.host: Interfaz de red o dirección IP utilizada internamente por los nodos del cluster para la comunicación. Por ejemplo, esta dirección junto con el puerto indicado en “transport.tcp.port” son utilizados por otros nodos en el cluster para las replicas de shards.
transport.tcp.port: Puerto que se abrirá en la interfaz indicada en “transport.host”.
http.host: Interfaz de red sobre la que se servirá la API rest de la instancia (por defecto es localhost).
http.port: Puerto vinculado a la interfaz indicada con la propiedad “http.host” (por defecto es 9200).
network.host: Interfaz de red a la que se vinculará el servicio de conexión de la instancia. Es decir, la interfaz de red sobre la que otros nodos del cluster se conectarán con la instancia local.
node.master: Valor booleano que indica si la instancia es master o no del cluster.

Esto es lo mínimo que debe de existir en un fichero de configuración de ES para que funcione en modo cluster con otros nodos, sin embargo hay muchas más opciones de configuración que se pueden consultar en la documentación oficial. https://www.elastic.co/guide/en/elasticsearch/reference/current/important-settings.html

Una configuración valida podría ser la siguiente:

Nodo master:

cluster.name: cluster-adastra
node.name: adastra-1
transport.host: 0.0.0.0
http.host: 0.0.0.0
network.host: 0.0.0.0
transport.tcp.port: 9300
node.master: true

Nodo slave1:

cluster.name: cluster-adastra
node.name: slave1-node
discovery.seed_hosts: [“192.168.1.144”] #Dirección IP del master.
cluster.initial_master_nodes: [“adastra-1”]
transport.host: 0.0.0.0
http.host: 0.0.0.0
network.host: 0.0.0.0
transport.tcp.port: 9300
node.master: false

Nodo slave2:

cluster.name: cluster-adastra
node.name: slave2-node
discovery.seed_hosts: [“192.168.1.144”] #Dirección IP del master.
cluster.initial_master_nodes: [“adastra-1”]
transport.host: 0.0.0.0
http.host: 0.0.0.0
network.host: 0.0.0.0
transport.tcp.port: 9300
node.master: false

Esto se puede ejecutar desde un mismo ordenador con 3 instancias independientes de ES, con máquinas virtuales, contenedores de Docker o máquinas físicas. No obstante aquí no termina la configuración, cuando se utiliza la propiedad “network.host” con un valor distinto de la interfaz de loopback provoca que ES ejecute una serie de comprobaciones sobre el sistema llamadas “bootstrap checks” las cuales se encargan de verificar que el sistema cumple con las especificaciones mínimas para que el nodo funcione correctamente en un entorno productivo y de esta manera reducir los problemas que puedan tener los usuarios al interactuar con nodos configurados “de aquella manera”. La configuración del sistema que se debe de aplicar para cumplir con los requisitos se explica en la documentación oficial: https://www.elastic.co/guide/en/elasticsearch/reference/current/system-config.html

En este apartado la documentación está bien detallada y explica qué se debe hacer a nivel de sistema para que el nodo arranque correctamente y se una a un cluster existente o funcione como master.

Como se puede apreciar en la imagen anterior, cuando existe cualquier tipo de problema en la instancia relacionada con los “bootstrap checks” la instancia simplemente no arranca. Sin embargo es algo fácil de resolver si se siguen las indicaciones que arroja la instancia de ES.

En esta última imagen se puede ver cómo debe de ser una configuración “buena” para el nodo que actuará como master, como se puede ver se han pasado todas las comprobaciones iniciales y posteriormente, se ha elegido al nodo “adastra-1” como master ya que es la forma en la que se ha indicado en la configuración gracias a la propiedad “node.master: true”.

De momento, con lo que se ha visto en éste post en las partes 1 , 2 y 3 es suficiente para comenzar a abordar cuestiones relacionadas con el pestesting y securización sobre instancias de ES.

Un saludo y Happy Hack.
Adastra.

A %d blogueros les gusta esto: