lunes, julio 25, 2016

Big Data Security Tales: MongoDB & Cassandra (Level 101)

Llevo un tiempo estudiando y aprendiendo mucho sobre el mundo del Big Data. No es que el mundo del Big Data fuera un gran desconocido para mí, pero he querido focalizarme este tiempo en dedicar más esfuerzos en jugar un poco más a fondo con las tecnologías más populares y unirlo con mi pasión por la seguridad informática. Hay muchas caras, a diferentes niveles, en el prisma que se crea cuando se juntan las tecnologías de Big Data y las de Seguridad Informática.

Figura 1: Big Data Security Tales: MongoDB & Cassandra (Level 101)

Quizá la más evidente es la posibilidad de crear nuevas herramientas de seguridad que manejen grandes volúmenes de datos para tener plataformas que antes no se podían ni imaginar imaginar. Nuestros servicios Tacyt, Sinfonier, FaastSandas o CyberThreats son claros ejemplos de tecnologías de seguridad que antes no eran ni imaginables sin el incremento en el volumen de datos que es posible manejar a día de hoy con ellas. 


Figura 2: Tecnologías de Big Data y CiberSeguridad

Por supuesto, el gran manejo de datos que es posible realizar hoy en día permite a las empresas capturar detalles, insignificantes a priori, de sus usuarios que llevan a un conocimiento tal de los mismos que la privacidad queda en serio riesgo. Exponente de este tipo son las tecnologías de WebBrowsing Fingerprinting que son capaces de llegar al mínimo detalle de los usuarios para saber quién es quién sin necesidad de que se lo diga. De esto hice una charla hace ya unos años.


Figura 3: Big Data y Privacidad

Otra de las caras del prisma en el que convergen la seguridad y el mundo del Big Data son los servicios de pentesting y auditoría de los mismos. No son nuevos los problemas con estos entornos, como ya vimos en el caso de los servidores MongoDB que podemos localizar por Internet sin ningún control de seguridad, y con todos los datos expuestos con solo hacer un poco de hacking con buscadores. Además, tampoco son inmunes a las técnicas de inyección de comandos, como ya vimos en el artículo de técnicas de MongoDB Injection.
Pero esto se exacerba aún más cuando vemos la gran miriada de tecnologías que Big Data que aparecen y desaparecen rápidamente. Cómo una tecnología puede o no eclosionar en este mundo y desaparecer rápidamente. Es un entorno joven en el que las tecnologías más conocidas apenas tienen unos años de vida. La primera versión de MongoDB es del año 2009 y la primera de Apache Cassandra es del año 2010 - aunque el proyecto lo liberara Facebook en el año 2008 -.

Cassandras inseguros en Internet

De esas primeras versiones a meterse de lleno en el mundo de las empresas aún les faltaría un tiempo, así que podemos decir que son tecnologías que se han hecho populares en los últimos tres o cuatro años. Si miramos el ecosistema de aplicaciones creadas alrededor de ellas aún estamos hablando de proyectos mucho más jóvenes de dos, tres años de vida, por lo que aún están lejos de alcanzar la madurez a la que deberán llegar si sobreviven.

En muchos de estos entornos nos volvemos a encontrar los mismos errores de pasado una y otra vez, y debido a su juventud no es complicado ver que muchas de ellas adolecen de seguridad por defecto en sus plataformas. Al igual que sucedía con MongoDB, con las bases de datos Cassandra sucede un poco lo mismo. Cassandra es una base distribuida en la que los datos almacenados se copian en diferentes nodos con un factor de replicación y es fácil localizar muchos entornos en los que no hay ninguna autenticación por defecto. 

Figura 5: Casi 2.000 clusters de bases de datos Cassandra publicadas en Internet

Es tan sencillo como realizar una búsqueda en Shodan - o en Censys - por el puerto 9160 y localizar las bases de datos de Cassandra que no tienen ninguna autenticación Shodan ya lo pone fácil ya que basta con localizar aquellos en los que los KeySpaces están disponibles en los resultados. En la imagen se puede ver que hay casi 2.000 bases de datos alcanzables directamente por el puerto 9160 desde Internet.

Una vez que se localiza una base de datos que tiene abierto el sistema sin ninguna autenticación, es fácil ir al siguiente paso y buscar algún cliente para conectarse a ellas y analizarlas. No hay tantos por Internet, pero se pueden utilizar alguno como Helenos o Datastax OpsCenter.

Figura 6: Datastax OpsCenter abierto a Internet

La gracia es que estas tecnologías, como el caso de Datastax OpsCenter son también muy jóvenes y también adolecen de problemas de seguridad por defecto. De hecho puede realizarse una búsqueda en Google para localizar paneles de Datastax OpsCenter abiertos a Internet que ya contienen clusters de bases de datos Cassandra expuestas a todo el mundo.

Figura 7: Datastax OpsCenter indexados en Google

También se pueden localizar por medio de Shodan sacando la firma "Server:" del software utilizado, algo que ya sabemos que hay que quitar para evitar el dorking, y que en este caso es Twistedweb por el puerto 8888, y localizar algunos paneles más que tienen abierto el panel sin autenticación alguna.

Figura 8: Paneles OpsCenter publicados en Internet

Desde estos paneles se puede gestionar la lista de clusters que estén ya conectados, o conectar un nuevo cluster de Cassandra de los que Shodan informa que están abiertos al público. Es decir, localizando un panel de OpsCenter se puede usar dicho servidor para gestionar remotamente un cluster Cassandra ubicado en otro lugar de Internet.

Figura 9: Agregar un cluster Cassandra a OpsCenter para administrarlo remotamente

Este es solo un ejemplo de cómo errores del pasado se repiten una y otra vez, y en este nuevo entorno de tecnologías de Big Data es fácil localizar muchas nuevas herramientas que hay que fortificar con el mismo cariño que las más tradicionales. Como esto da mucho juego, en las siguientes partes - porque serán varios artículos sobre este tema - os iré contando cómo están otras herramientas utilizadas habitualmente en el mundo de las tecnologías Big Data.
- Big Data Security Tales: ¡Vigila que tu MongoDB no le de tus datos a cualquiera! (Level 100)
- Big Data Security Tales: Cómo funcionan las MongoDB Injection
- Big Data Security Tales: MongoDB y Cassandra (Level 101)

- Big Data Security Tales: Apache Hadoop expuesto por no configurar HUE (Level 102)
- Big Data Security Tales: Django en HUE en modo DEBUG y con Directory Listing (Level 103)
- Big Data Security Tales: Las Interfaces de acceso al HDFS
- Big Data Security Tales: Apache Amabari Default Admin
- Big Data Security Tales: WSO2 Carbon y la ayuda para el Login
- Big Data Security Tales: Los Known-Bugs en WSO2 Carbon Server
- Big Data Security Tales: Kibana & ElasticSearch objetivos del ransomware
- Big Data Security Tales: Apache CouchDB Relax... o no
- Big Data Security Tales: Riak NoSQL Database
Saludos Malignos!

1 comentario:

  1. No esta demas quisas a algunos lectores les sirva
    https://docs.mongodb.com/manual/administration/security-checklist/

    No se si este de mas comentar que no es que halla una vulnerabilidad o advisory de esto si no que es una mala o missed configuracion . los motores NOSQL casi todos manejan request post get put (http request) .. por tanto no fueron diseñados para trabajar fuera de una lan ...

    su seguridad se centra en que estos datos viajen por una red segura (Lan). no para que salgan a internet . para tomar un poco mas en serio esto deberias por lo menos tocar algunos puntos de como asegurar este tipo de motores . y centrar ese supuesto issue de seguridad como lo que es..

    btw asi se crearia un user en mongodb evitanto estos accesso (no autorizados ?) ahun asi podrias conectarte y ver el tamaño de las bases y colecciones dentro de mongo pero no prodrias hacer un query, esto de nuevo es debido a que no fueron diseñadas para salir a la jungla (internet) .

    db.createUser({user: "Superseguro",pwd:"e##"FFR%VRWAS!", roles:[{role: "userAdminAnyDatabase", db: "admin" }] });

    bytes!

    ResponderEliminar