viernes, 17 de marzo de 2017

NoSQL INSecurity: Preview and Basic Attacks

Cuando hablamos de bases de datos NoSQL, lo primero que pensamos es en rendimiento, flexibilidad y escalabilidad, las características propias y necesarias de las bases de datos utilizadas por los gigantes de Internet como Adobe, Amazon, Ebay, Twitter, Google, Netflix...

Pero analizando los features de bases de datos NoSQL como MongoDB, Cassandra, CouchDB, Hbase, Redis o Riak podemos darnos cuenta a primera vista que las medidas de seguridad que poseen son insuficientes o están pensadas para bases de datos utilizadas en ambientes "trusted", donde la posibilidad de ataques sea ínfima y existan otras medidas de protección por fuera del nivel de base de datos. 

A continuación los 4 tipos de datos que pueden almacenar las bases NoSQL por los cuales se las clasifica:

Ahora, ¿mo podemos detectar las debilidades de seguridad de una instalación de base de datos NoSQL para explotar tales fallos, o bien, remediarlos?

PUERTOS UTILIZADOS E INFORMACIÓN DE LA BASE DE DATOS

Empecemos por lo básico: ¿Cuáles son los puertos default que utilizan las bases de datos NoSQL más conocidas?:
  • MongoDB: 27017, 28017, 2780
  • Cassandra: 9160
  • CouchDB: 5984
  • Hbase: 9000
  • Redis: 6379
  • Riak: 8098
Buscando en Shodan van a encontrar varias ;)

Una vez identificada la base NoSQL objetivo de nuestra evaluación, Nmap tiene scripts para obtener información de la infraestructura y las propias bases de datos NoSQL como por ejemplo:

  • NSE mongodb-info y mongodb-databases para MongoDB
  • NSE cassandra-info para Cassandra
  • NSE couchdb-databases y couchdb-stats para CouchDB
  • NSE hbase-master-info para Hbase/Hadoop
  • NSE redis-info para Redis
  • NSE riak-http-info para Riak


AUTENTICACION

En cuanto a la autenticación, en la mayoría de estas bases de datos la autenticación y autorización de usuarios viene deshabilitada por default:

MongoDB: Por defecto en la instalación no se configura ningún método de autenticación, se debe crear usuarios y asignarle roles adecuados para poder habilitar la autenticación de usuarios 
https://docs.mongodb.com/manual/tutorial/enable-authentication/ 

En esta base de datos tenemos dos formas fáciles de chequear si la autenticación se encuentra habilitada, con "Mongo DB Login" de Metasploit o con el NSE mongodb-brute de NMAP:


Cassandra: La autenticación interna de usuarios de Cassandra no se encuentra habilitada por defecto: 
Para validar los mecanismos de autenticación de Cassandra podemos usar el NSE de nmap cassandra-brute:

Redis: Redis no soporta mecanismos de autenticación y autorización de usuarios, lo máximo que se puede hacer al respecto es proteger la instalación con una contraseña. 

Para validar el uso de contraseña o realizar bruteforce sobre la misma se puede utilizar el script de Nmap redis-brute:

Riak : Por defecto la seguridad se encuentra deshabilitada, hay que habilitarla específicamente para poder crear usuarios y autenticarlos. 
http://docs.basho.com/riak/kv/2.2.0/using/security/basics/

CouchDB: Por defecto viene en modo "admin party" que quiere decir que cualquiera puede conectarse con privilegios administrativos, sin utilizar un nombre de usuario ni contraseña de ningún tipo. Luego pueden crearse usuarios y restringir los privilegios administrativos 

Hbase: Con la configuración por defecto, cualquiera puede leer y escribir todas las tablas disponibles en el sistema, luego pueden configurarse mecanismos de autenticación y autorización:

ENCRIPCION EN LA TRANSMISIÓN Y ALMACENAMIENTO DE CONTRASEÑAS

MongoDB: La información de autenticación se encuentra almacenada en la colección system.users de la base de datos admin. Algunas instalaciones de MongoDB permiten acceder anónimamente a esta información y descargar todos los nombres de usuario y hash de las contraseñas ya sean MONGODB-CR (algoritmo de hash MD5 sin salt) o SCRAM-SHA-1 (algoritmo de hash SHA-1 y random salt por usuario) mediante la consulta "show users" en la base de datos admin. También hay scripts JS disponibles para obtener esta información como el siguiente de Average Security Guy: https://github.com/averagesecurityguy/scripts/blob/master/creds.js


Por defecto MongoDB no utiliza encripción de las conexiones entre el cliente y el servidor de base de datos, por lo cual los usuarios y contraseñas pueden ser "sniffeados" e interceptados en la red con herramientas de sniffing como Wireshark. Soporta TLS/SSL para las conexiones de clientes a la base de datos pero esto tiene que ser específicamente habilitado y configurado.

Cassandra: Al habilitar la autenticación en Cassandra, por defecto se habilita el superuser "cassandra" con contraseña: cassandra. Todos los usernames y contraseñas (hasheadas con bcrypt) se almacenan en la tabla system_auth.credentials, una query como la siguiente traería la información de autenticación de los usuarios:

SELECT salted_hash,username FROM system_auth.credentials WHERE username=?

Por ejemplo el siguiente es el salted_hash del usuario cassandra con su default password cassandra:

También las credenciales pueden ser almacenadas en texto plano en archivos .dserc utilizados para la conexión automática de herramientas a la base de datos, asi que si tenemos acceso al file system podemos revisar estos archivos en busca de credenciales.

Por defecto Cassandra no utiliza encripción de las conexiones entre el cliente y el servidor de base de datos, por lo cual los usuarios y contraseñas pueden ser "sniffeados" e interceptados en la red con herramientas de sniffing. Soporta SSL para las conexiones de clientes a la base de datos pero esto tiene que ser específicamente habilitado y configurado.

Redis: Como explicamos en la sección anterior, Redis no posee mecanismos de autenticación de usuarios lo máximo que puede hacerse para proteger esta base de datos es asignarle una contraseña. Esta contraseña se almacena en texto plano en el archivo de configuración redis.conf del servidor en la sección "Security" parámetro requirepass.
En cuanto a la encripción de las conexiones, Redis no soporta ningún mecanismo de encripción, por lo cual la contraseña puede ser "sniffeada" e interceptada en la red con herramientas de sniffing.

CouchDB: En CouchDB los usuarios administradores y sus respectivas contraseñas (hasheadas con el algoritmo SHA-1 y salt) se almacenan en el archivo local.ini del servidor de base de datos. Pueden listarse por medio del browser con la siguiente consulta: http://<ip del equipo>:5984/_config/admins



Las contraseñas de los usuarios no administradores no se almacenan en el archivo de configuración local.ini sino en la base de datos de autenticación llamada: _users. Alli se registra cada usuario como un documento JSON. Para acceder al listado completo de usuarios y sus contraseñas (hasheadas con el algoritmo SHA-1 y salt) se debe realizar la siguiente consulta:  http://<ip del equipo>:5984/_users/_all_docs

Las contraseñas también pueden ser almacenadas en texto plano en los archivos de log si el CouchDB log level es "debug" asi que nunca está de mas revisar los logs en busca de credenciales.

En cuanto a la encripción de las conexiones, CouchDB no soporta ningún mecanismo de encripción, las mismas se realizan por medio de HTTP por lo cual los usuarios y contraseñas pueden ser "sniffeados" e interceptados en la red con herramientas de sniffing.

Riak: En Riak los usuarios y contraseñas (hasheadas con PBKDF2) son almacenados en una tabla en Riak TS. Para la interfaz administrativa Riak Control los nombres de usuario y contraseñas son almacenados en texto plano en el archivo advanced.config parámetro riak_control.auth.user.$username.password (el usuario por defecto es user y la contraseña por defecto es pass):

Por defecto Riak no utiliza encripción de las conexiones entre el cliente y el servidor de base de datos, por lo cual los usuarios y contraseñas pueden ser "sniffeados" e interceptados en la red con herramientas de sniffing. Soporta SSL para las conexiones de clientes a la base de datos pero esto tiene que ser específicamente habilitado y configurado.

Hbase: Al activar la autenticación en HBASE la misma se realiza por medio de Kerberos, que también puede ser utilizado para la encripción de las comunicaciones entre el servidor Hbase y los clientes.

ACCEDIENDO A LAS BASES DE DATOS

Una vez que obtuvimos credenciales de acceso en los pasos anteriores ya sea por medio de bruteforce, sniffing en la red o acceso a las contraseñas almacenadas (o verificamos que la base en cuestión no solicita autenticación) nos conectamos a las bases de datos de la siguiente manera:

MongoDB: La forma más fácil de conectarse es el Mongo CLI client, en Linux puede instalarse por medio de package mongodb-clients. Una vez que tenemos el cliente nos conectamos de la siguiente forma (la base de datos local tiene información del servidor y la base de datos admin es la que contiene las credenciales de los usuarios)
mongo [hostname]:[port]/[database_name]
También podemos escribir archivos javascript y hacer que se ejecuten directamente en el servidor MongoDB -muy útil y divertido por cierto XD-
mongo [hostname]:[port]/[database_name] [script_name]
Mas detalle de comandos soportados por el Mongo CLI en el siguiente enlace: 
https://docs.mongodb.com/manual/reference/mongo-shell/

Adicionalmente algunas versiones de MongoDB poseen una interfaz web para chequear el estado de la base de datos en el puerto 28017:

También existen clientes GUI para conectarse a MongoDB como por ejemplo Robomongo que además de tener una versión portable es multiplataforma. En la siguiente imagen nos conectamos con robomongo anónimamente a la base MongoDB y usamos la query "show users" para ver la información de los usuarios en la base admin: https://robomongo.org/download



Cassandra: La forma más fácil de conectarse a Cassandra es el cqlsh (un cliente en Python que viene por defecto con la instalación). También puede utilizarse herramientas de terceras partes como Helenos: https://sourceforge.net/projects/helenos-gui/



Redis: La forma más facil de interactuar con Redis es el Redis CLI client o redis-cli que puede instalarse en linux por medio del package redis-tools, se debe usar la primera forma de conectarse para Redis sin contraseña y la segunda en caso de tener una contraseña configurada:
redis-cli -h <hostname> -p <port>
redis-cli -h <host> -p <port> -a <password>

Por ejemplo se puede usar el comando info para obtener información del servidor, select (n) para seleccionar una base de datos, get (key) para obtener el valor de alguna string key en particular, a continuación una lista de todos los comandos que pueden usarse en Redis una vez conectado: http://redis.io/commands

CouchDB: En CouchDB es aún más fácil conectarse ya que no necesitamos ningún cliente en particular, se accede directamente por medio del browser en el puerto 5984 de la siguiente forma: http://<ip del equipo>:5984 
Una vez que CouchDB nos responde con el famoso "welcome" podemos entrar a /_utils/ para poder utilizar la herramienta administrativa "Futon" desde allí podemos listar, ver el contenido de las bases de datos, crear bases nuevas, eliminar las bases existentes, configurar la seguridad y muchas cosas más:




Riak: Riak posee una HTTP API que permite conectarse directamente desde el browser y realizar operaciones con Riak KV (la base de datos Riak Key Value) en el puerto 8098. Para verificar esto nos podemos conectar a http://<ip del equipo>:8098 y debería aparecer algo parecido a lo siguiente:
En el siguiente enlace la descripción y todas las operaciones que se pueden realizar por medio de la HTTP API de Riak: http://docs.basho.com/riak/kv/2.2.0/developing/api/http/
Todas las operaciones de GET, POST, PUT y DELETE también las podemos realizar con la herramienta curl que es la recomendada por Basho para Riak.

Adicionalmente hay que revisar si encuentra activa la utilidad administrativa para el management de clusters "Riak Control" a la cual se accede por medio del browser desde las siguientes direcciones: http://<ip del equipo>:8098/admin o https://<ip del equipo>:8096/admin
Si se encuentra activa y no solicita credenciales de autenticación (o pudimos obtener credenciales en los pasos anteriores) desde allí se puede administrar los clusters y los nodos de los clusters:





OTROS ATAQUES Y HERRAMIENTAS

En el próximo post veremos en detalle ataques mas sofisticados a bases de datos NoSQL y algunas herramientas para realizarlos como:

4 comentarios:

  1. Muy bu en post. Es muy poco habitual encontrar entornos NoSQL con mínimas medidas de seguridad.

    Saludos!

    ResponderEliminar
  2. Gracias Daniel me alegro que te haya gustado!

    ResponderEliminar
  3. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  4. Hola muy buenas tardes, te hago una pregunta donde conseguiste la información para la autenticación de cassandra. Gracias

    ResponderEliminar