Evil Signature Injection: Borrado remoto de bases de datos, buzones de correos y ficheros de log con Evil Signatures y tu EDR

Después del incidente con Crowdstrike, uno de los EDR más famosos del mundo, los ojos de los investigadores de seguridad se han puesto en ellos. Tener en el sistema objetivo de un ataque un software que se ejecuta con tantos privilegios se ha convertido en oportunidad de usarlo como herramienta del atacante en lugar de temerlo como una herramienta defensiva.

Figura 1: Evil Signature Injection: Borrado remoto de bases de datos,

buzones de correos y ficheros de log con Evil Signatures y tu EDR

Ayer sábado, tranquilo por la tarde, comencé a repasar las charlas de BlackHat y DefCON, y me topé con el trabajo de EDR Reloaded: Erase Data Remotely de los investigadores Tomer Bar y Shmuel Cohen. Desde el principio me encantó la idea por lo simple y hacker que es, y sobre todo, porque es algo que hacíamos nosotros hace muchos años.

Back in 2012 with Eicar

En el año 2012, durante un tiempo, estuve jugando mucho con los Terminal Services y la Apps en Citrix. Escribí muchos posts sobre ellos, y acabé dando una charla junto al gran Juan Garrido en DefCON sobre Terminal Hackpplications llamada "Bosses love Excel, hackers Too", donde llevábamos, además de muchos de estos trucos que quedaron en el blog, una idea del gran Silverhack de meter la shell en EXCEL y desde una sesión de Terminal Services o Citrix controlar la máquina. 

Figura 2: Bosses love Excel, hackers too

Entre los trucos, estaba el de forzar que cantara el antivirus del servidor incluyendo la firma de EICAR para testar si estaba siendo investigada por un Antimalware (aún no se utilizaba el concepto de EDR), y cuál era en concreto. Lo dejé en el artículo: "Eicar para hacer jailbreak en Terminal Services o Citrix".

Figura 3: Symantec EndPoint Protection vigila este Citrix
y nos da el botón de ayuda para entrar en el sistema.

La gracia era qué, si saltaba la consola del antivirus, o una alerta, podríamos llamar a la ayuda, sacar un explorador de ficheros y abrir el sistema completo. Es decir, hacer Jailbreak a una sesión de Terminal Services o Citrix mediante un firma de una muestra de malware "ficticia", como era EICAR.

Erase Data Remotely with Evil Signatures

Ese concepto de "Firma Maliciosa" o "Evil Signature" es lo que han utilizado los investigadores para hacer que se borren ficheros, aprovechándose de Windows Defender en los sistemas Microsoft, y de otros EDR en sistemas GNU/Linux, generando una Evil Signature que ingresan en el sistema de diferentes maneras, ya sea incluyéndola en un fichero binario, en un doc, en una llamada HTTP, en una consulta SQL, o en un alta de un usuario de una plataforma SaaS.

Figura 4: Búsqueda de Evil Signatures para Windows Defender

La idea es tan sencilla como, buscar las firmas que usa Windows Defender, y probar para tener tener el mínimo de caracteres necesarios para que el EDR de Microsoft lo detecte como si fuera un malware de severidad HIGH, para lograr que la acción que se lance sea la más drástica, es decir, eliminar el fichero. 

Figura 5: Windows Defender tiene diferentes acciones por severidad

El resto es conseguir que el fichero ese sea el que quiere borrar el atacante. Así que, a partir de ese momento, es objetivo es ver cómo meter la firma más pequeña en el sitio adecuado para saber qué fichero quieres que borre el EDR que está protegiendo esta máquina.

Figura 6: Introduciendo la Evil Signature en un HTTP Post

En el ejemplo anterior, la Evil Signature se introduce simplemente en un parámetro por POST desde una llamada HTTP, para conseguir que Windows Defender elimine los logs del servidor de Web de la máquina.

Figura 7: Logs del servidor Web eliminados por Windows Defender

Lo mismo se puede hacer con una sesión Windows FTP, en este caso inyectando la Evil Signature como si fuera el nombre del usuario, pero al inscribirse este username en el fichero de log, salta el EDR y se carga el archivo completamente porque es severidad High.

Figura 8: La Evil Signature en el username de un Windows FTP

Esto, en determinados sistemas puede ser más crítico. En este caso, se carga el mailbox de un Mozilla  ThunderBird, que no le hará ninguna gracia al usuario que, sin hacer ninguna acción se acaba de quedar sin ninguno de sus correos almacenados.

Figura 9: Borrado del buzón de Mozilla ThunderBird

Y por supuesto, el propio log de la máquina Windows que viene de serie en todos los sistemas de Microsoft y que usan los SysAdmin para controlar lo que está pasando en su plataforma. De repente verán vacíos temporales.

Figura 10: Borrado de los logs de Windows

También, se puede lograr que Windows Defender elimine su propio log, lo que es una maravilla para borrar los rastros que un atacante deja en un sistema.

Figura 11: Eliminando los logs de Windows Defender

Además, se puede lograr que la víctima expanda el ataque, ya que si el fichero de log pasa al servidor de logs, se llevará la Evil Signature consigo, así que si tenemos un Splunk, éste acabará siendo afectado también.

Figura 12: Afectando la Evl Signature a Splunk

Pero lo peor de este ataque es que si lo consigues meter en el Datafile de una base de datos y que el EDR lo tome como un malware de severidad High, entonces podrías conseguir eliminar la base de datos de un objetivo, lo que no debe ser gracioso para nadie.

Figura 13: Borrando la base de datos de un MariaDB con Evil Signature

En este caso, los investigadores han sido capaces de que el EDR se cargue bases de datos de MariaDB ( MySQL), PostgreSQL, MomgoDB (adiós a tu BigData) y SQLLite, lo que podría dejar sin funcionar la gran mayoría de servicios y aplicaciones que corren sobre ellos.

Figura 14: Bases de datos afectadas por Evil Signature Injection

Y por supuesto, también se pueden hacer los ataques desde servidor a cliente. En este caso sería un Client-Side Attack que se puede hacer por culpa de visitar un servidor vulnerado, o por un ataque a través de él.

Figura 15: El Web Server envía la Evil Signature al cliente

Y el cliente ve cómo se le borran los ficheros del sistema a través del EDR que tenga configurado para "protegerlo" de los atacantes. Paradojas de la vida.

Figura 16: Windows Defender borra la historia de

Google Chrome y los Web Data

La gracia es que podría hacerse un CSRF, un XSS, un SSRF, o cualquier otro Client-Side Attack para que un atacante haga un Evil Signature Injection en tu equipo y tengas un problema de seguridad serio. Por suerte, los reportes han sido tomados en serio y - tras varias iteraciones - se han corregido, pero esta técnica hay que tenerla en cuenta porque cualquier software privilegiado que corra en tu máquina podría ser víctima de Evil Signature Injection y tener un problema serio en tu plataforma.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Unos consejos para fortificar MongoDB en el mundo NoSQL

Conocí el mundo de los NoSQL allá por el año 2013 cuando comenzamos con ElevenPaths a construir nuevas tecnologías. Teníamos muchos retos tecnológicos por completar ante nosotros. Fue una etapa en la que aprendimos mucho ante todos los cambios y avances en tecnología que aparecían ante nosotros. Hay algo que nos enseñaban cuando estudiábamos en la carrera y es que un Ingeniero debe buscar soluciones, es decir, analizar el problema, analizar una posible solución, diseñar, implementar, etcétera.

Figura 1: Unos consejos para fortificar MongoDB en el mundo NoSQL

A uno de esos problemas de aquella época le dimos solución basándonos en un tipo de bases de datos no relacionales llamas "Not Only SQL"  o NoSQL. Hoy me quiero centrar en una de esas NoSQL, en MongoDB. Es, por mérito propio uno de los motores de base de datos no relacional más utilizados hoy en día. En su día sacamos alguna noticia sobre MongoDB dónde su seguridad no quedaba bien parada, pero quizá no sea la seguridad que MongoDB puede aportar, si no la configuración que le apliquemos. Es decir, no es problema del producto y sí de la configuración que el administrador ejecute, con el caso de estos artículos del blog:

• Big Data Security Tales: MongoDB & Cassandra Level 101
• Vigila que tu MongoDB no le de los datos a cualquiera

El caso de MacKeeper fue recordado por los 13 millones de usuarios filtrados y los 21 GB de información sensible. Algunos echaron la culpa al producto, pero realmente y clarísimamente, fue una mala configuración. No es el único caso en el que este tipo de soluciones se han visto involucradas, por ejemplo, y más recientemente, tenemos el caso de las miles de apps de iOS que filtraron datos en Firebase, pero no solo en Firebase, en el listado aparece MongoDB también.

Figura 2: El caso de MacKeeper y los datos filtrados

En el artículo de hoy vamos a hablar de cómo fortificar MongoDB. La gente de MongoDB pone a disposición de sus usuarios / administradores una serie de “tips”. En muchos casos, hay cosas “obvias”, por ejemplo, que la conexión vaya cifrada entre la aplicación y la base de datos. De esto ya hemos hablado en el pasado con los ataques Network Packet Manipulation.

Figura 3: Libro de Cifrado de las comunicaciones digitales:
de la cifra clásica a RSA 2ª Edición de 0xWord

Sea como sea, siempre viene bien tener un listado de “tips” o una “checklist” dónde verificar algunas de las cosas que debemos configurar sí o sí en una base de datos, en este caso, no relacional como puede ser MongoDB.

Habilitar el control de acceso y configurar RBAC

Para que no ocurra como en los ejemplos anteriores de filtrado de información, es muy importante habilitar el control de acceso. Como hemos visto, si tu MongoDB da soporte a una aplicación web o un servicio expuesto en la red, es una de las primeras cosas que van a buscarse en un Hacking de Web Technologies. Los motores NoSQL con acceso anónimo son objetivo de pentesters y atacantes peor intencionados. Para ello, se puede utilizar un mecanismo de autenticación SCAM o x509 que trae el propio MongoDB. Además, se puede integrar con Kerberos o LDAP. 

Otra recomendación sería crear primero un administrador de usuarios y luego ir creando los usuarios necesarios. Es importante, crear un usuario por cada aplicación o persona que requiere acceder al sistema. Como define una de las mínimas de la seguridad informática, debemos seguir el principio del menor privilegio. Es decir, vamos a crear roles que definan derechos de acceso para un conjunto de usuarios.  

Figura 4: Hacking Web Technologies 2ª Edición

De esta forma, podemos crear usuarios y asignarlos solo a los grupos/roles que ellos necesiten para poder ejecutar sus tareas u operaciones. Cuando hablamos de usuarios, hay que tener en cuenta que muchas veces son las propias aplicaciones que requieren conectarse contra la base de datos.

Ya hemos comentado sobre RBAC de forma implícita, pero por si acaso, decir que RBAC es un control de acceso basado en roles (Role Based Access Control). Es decir, consiste en asignar derechos de acceso, como comenté antes, a los usuarios en función de los roles y las operaciones o tareas que tienen que realizar.  Para habilitar la autenticación, simplemente debemos cambiar la directiva “auth” o habilitar a true en el fichero de configuración /etc/mongodb.conf.

Figura 5: Configurando /etc/mongodb.conf

El resultado es que cuando queremos conectarnos con MongoDB a la base de datos que hayamos creado pues nos solicitarán credenciales. Puedes ver más sobre la creación de usuarios en la documentación oficial de MongoDB.

Figura 6: Conectándonos con nuestro usuario a MongoDB

Esto es algo muy básico, pero que como hemos visto pues no es algo que siempre se configure. Importante, antes de habilitar la autenticación hay que tener en cuenta el crear usuarios. Eso se hace con la función db.createUser y un documento JSON con el siguiente formato:

{

user: “pablo”,

pwd: “xxx”,

roles: [“dbOwner”] #si queremos que sea el propietario

}

MongoDB tiene lo que se llama “Collection-level access control” y permite hacer un permiso muy específico sobre las colecciones de datos. Es decir, puedes indicar qué tipo de acción puede hacer un rol sobre una colección de datos. Hay que recordar que una colección de datos está dentro de una base de datos. Sería como las tablas en el mundo SQL.

Cifrar comunicaciones con TLS/SSL y cifrar y proteger datos almacenados

El cifrado es clave tanto en lo que a la comunicación entre el cliente y el servidor como en el almacenamiento de los datos. Ya hemos comentado lo que son los ataques de Network Packet Manipulation. Además, Wireshark da soporte para mostrar los paquetes de MongoDB y diseccionarlo de forma sencilla. En otras palabras, si alguien se pone en medio de la comunicación entre la aplicación y el servidor de MongoDB toda la información que viaje entre ambos nodos quedará expuesta.

Figura 7: Paquetes MongoDB en WireShark

Explicar el proceso para proteger la comunicación entre cliente y servidor daría para uno o dos posts, por lo que os dejo el enlace a dicha información y se puede configurar de manera sencilla. Hay que tener en cuenta que habrá que configurar tanto servidor como cliente. 

Encypted at Rest: Almacenamiento seguro de la información  

Ahora, hablemos de la protección de la información en el interior de la base de datos. Cuando se crea un usuario, se nos indica en la documentación que la contraseña no se almacena en texto plano, como era de esperar. MongoDB dispone de una “feature” importante que es el motor de almacenamiento cifrado o “Encrypted Storage Engine”. Esta “feature” solo está disponible en MongoDB 3.2 en adelante y en la versión Enterprise. 

Figura 8: Encryption at Rest y MongoDB

Si el cifrado está activo, MongoDB Enterprise utiliza AES256-CBC a través del uso de OpenSSL. Se utiliza la misma clave para cifrar que para descifrar. MongoDB también soporta un cifrado en modo FIPS y AES con el modo Galois/Counter Mode.  Cuando se habilita este cifrado, el proceso incluye las siguientes acciones:

• Generación de una clave maestra y la generación de claves para cada base de datos. Es decir, que cada base de datos estará cifrada con una clave diferente. Esto es algo lógico.

• Cifrar los datos de cada base de datos con las claves generadas previamente para cada base de datos. También se cifrarán las claves de la base de datos con la clave maestra.

• El cifrado es llevado a cabo de forma transparente. Este cifrado se lleva a cabo en todo el almacenamiento, es decir, los archivos que contienen los datos están completamente cifrados. Lo interesante es que los datos descifrados solo existirán en la memoria y nunca en el disco, donde siempre estarán cifrados.

Nota: Ya hemos hablado en este blog sobre ataques a procesos en memoria con el objetivo de sacar información.

Registros y auditoría de las acciones

La trazabilidad es una de las subdimensiones de la seguridad. Es algo importante y el tener un registro de actividad también lo es. Habilitar la auditoría en un MongoDB es algo vital y que permite conocer que está ocurriendo en tu base de datos. Cuando se habilita la auditoría se escriben eventos en la consola del propio MongoDB, en el Syslog o en archivos.

Figura 9: Configuración de Filtros de Auditoría en MongoDB

Se registran operaciones de autenticación, de acceso, de autorización, etcétera. Se puede configurar filtros para restringir eventos capturados. Esto se puede hacer a través de la configuración de los filtros de auditoría. En la auditoría se registran:

• Autenticación y cómo se dijo anteriormente, también la autorización.

• Operaciones del cluster de MongoDB.

• Operaciones de lectura y escritura.

• Operaciones con el esquema o DDL.

• Mensajes personalizados de aplicaciones.

Asegurar el entorno de MongoDB

Este paso es muy importante. De nada valdrá tener las mejores recomendaciones y consejos en el ámbito del hardening a MongoDB, si luego tenemos las capas inferiores desprotegidas. Imagínate que permitimos que cualquier usuario pueda acceder a este equipo físicamente y no ponemos barreras, ¿Serviría tener cifrado los datos en disco? Si no tiene un login de usuario, si no tiene un firewall que rebaje la exposición, si no hay unas barreras físicas que evitan que cualquiera pueda acceder a ese equipo físicamente, etcétera.

Figura 10: Auditando MongoDB con Tenable Nessus

En este caso las recomendaciones van por la parte del firewall, pero no hay que quedarse solo con eso. Si vemos el modelo defensa en profundidad, la seguridad va en armonía con todas las capas. No vale fortificar mucho una capa, si luego por debajo, la base, no se sostiene.  Hay un artículo interesante de la gente de Tenable en la que hablan sobre la auditoría a MongoDB con Nessus.

Ejecuta MongoDB con opciones de seguridad habilitadas

Este apartado habla sobre la necesidad de ejecutar MongoDB con un usuario dedicado en el sistema. De forma que si es comprometida, no haya mucho que se pueda hacer hasta que haya una escalada de privilegio en el sistema. Además, hay una serie de opciones de seguridad que se pueden trabajar desde el principio y que ayudan a tener un entorno más seguro dentro de MongoDB. Seguramente, a estos consejos o recomendaciones se pueden añadir más y entrarían en opciones de seguridad habilitadas desde el principio.

• Deshabilitar la escritura side-server: MongoDB soporta la ejecución de código Javascript. Para llevar a cabo la mitigación de una posible vulnerabilidad a nivel de aplicación, es recomendable deshabilitar el código del lado del servidor. Esto se puede deshabilitar en el archivo de configuración con la directiva noscripting = false.

• Deshabilitar la interfaz de estado: ¿Qué es la interfaz de estado? Esto es un servidor HTTP que expone un sitio web el cual contiene estadísticas e información que pueden ser de interés para un administrador del sistema, pero también para un atacante. En el archivo de configuración se puede deshabilitar esta opción con la directiva nohttpinterface = true.

• Desactivar la interfaz REST: Es una interfaz administrativa que es interactiva, la cual se encuentra desactivada por defecto. Esta interfaz no tiene soporte para autenticación y se debe restringir el acceso a dicha interfaz, por ejemplo, por dirección IP o mediante interfaz de loopback. Para deshabilitar esta interfaz en el fichero de configuración debemos verificar rest = false.

• Limitar la exposición en la red: Limitar la exposición de direcciones IP de un servidor o de interfaces de red es importante. La opción bind_ip indica la interfaz de red por la que se escucharán peticiones en la base de datos. Esto ya depende de cada uno y sus necesidades. Se puede utilizar la directiva bind_ip para limitar la accesibilidad a la red de un programa MongoDB. También se puede jugar con un firewall y dejar pasar el tráfico que provenga de la dirección IP dónde se encuentra la aplicación. En el fichero de configuración se configura esta opción con la directiva bind_ip = [dirección IP de la interfaz que queremos].

Estos son algunos tips para mejorar la seguridad de una basa de datos MongoDB. Por supuesto, hay más cosas que se pueden hacer, pero con estas estamos mejorando bastante la seguridad de MongoDB. Es importante alinear los esfuerzos con el resto de capas, tal y como se indica en el modelo defensa en profundidad.

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Figura 11: Contactar con Pablo González

Dagda Docker Security Suite: Auditoría de seguridad en aplicaciones dockerizadas (2 de 2) #Docker

Tras hacer un recorrido sobre algunas de las soluciones que existen para analizar la seguridad de las aplicaciones "dockerizadas" teniendo diferentes puntos de vista en la primera parte de este artículo, es el momento de hablar del trabajo que he estado realizando durante este tiempo con Dagda.

Figura 11: Dagda Docker Security Suite Parte 2

La solución propuesta para dar solución para la auditoría de las aplicaciones que corren en entornos Docker ha sido Dagda, que se puede definir como una suite de seguridad Docker que permite tanto el análisis estático de vulnerabilidades de los componentes software presentes en imágenes Docker como el análisis de dependencias de distintos frameworks de aplicaciones. Además, permite detectar comportamientos anómalos en contenedores Docker en ejecución en base a reglas.

Figura 12: Dagda en GitHub

Una visión a muy alto nivel de la arquitectura de Dagda se muestra en la Figura 13 que se muestra a continuación. En dicha figura se muestra como Dagda se ejecuta en modo servidor standalone. Para su funcionamiento, Dagda se comunica con una base de datos MongoDB y con el socket de Docker.

Figura 13: Arquitectura a alto nivel de Dagda

En primer lugar, Dagda no se apoya en el proyecto cve-search para su base de conocimiento de vulnerabilidades, ya que cve-search necesita, además de MongoDB, un Redis para su funcionamiento.

VulnDB: Base de datos de vulnerabilidades en Dagda

La necesidad de otro componente más como es Redis, unido a la rigidez de su API de consulta, ha desembocado en lo que en la Figura 13 se denomina VulnDB, que no es más que una base de datos MongoDB. Esta base de datos está fuera del servidor Dagda, por lo que puede ser cualquier MongoDB proporcionado por el usuario.

En la base de datos VulnDB de Dagda, además de almacenar los expedientes CVE e información de Exploit-db, se ha añadido la base de datos completa de BugTraq de Symantec, la cual no ha sido utilizada nunca hasta la fecha por ninguna otra herramienta.

Figura 14: Base de datos de BugTraq en SecurityFocus

Además, en dicha base de datos se almacena también el histórico de los análisis estáticos realizados sobre las imágenes Docker y el resultado de la monitorización de los contenedores en ejecución. Esta funcionalidad de histórico también es única entre las herramientas y productos Open Source ya que éstos únicamente utilizan su base de datos para consultar las vulnerabilidades conocidas, quedando fuera de su objetivo, la gestión del histórico de los análisis realizados.

En comparación con el resto de herramientas de análisis de vulnerabilidades que no permiten el uso de la base de datos de vulnerabilidades que se descargan para cumplir su función, Dagda dispone de una API REST completa para su gestión, incluyendo entre dicha funcionalidad, el histórico de análisis y el acceso a la base de conocimiento de vulnerabilidades que ha poblado en MongoDB.

Análisis estático de vulnerabilidades en Dagda

En cuanto al análisis estático de vulnerabilidades de los componentes software presente en las imágenes docker, Dagda extrae el listado del software instalado en la imagen y busca las coincidencias con productos y versiones vulnerables contra VulnDB. Dagda soporta un gran número de distribuciones como: Red Hat/CentOS/Fedora, Debian/Ubuntu, OpenSUSE y Alpine, aunque es fácilmente ampliable.

Por otro lado, en cuanto al análisis de dependencias de distintos framworks de aplicaciones, Dagda se integra con el proyecto Docker dependency checker, el cual utiliza OWASP Dependency Check y Retire.js para analizar múltiples lenguajes como son: Java, Python, Node.js, JavaScript, Ruby & PHP.

Figura 15: Ejemplo de funcionamiento de Docker Dependency Checker

Dagda soporta también la detección de comportamientos anómalos en contenedores Docker en ejecución en base a reglas gracias a su integración con Sysdig/Falco, siendo dichas reglas, ampliables también según las necesidades del usuario en cada entorno de trabajo o producción.

Figura 16: Sysdig/Falco con soporte para containers docker

En la siguiente Figura 17 que se muestra a continuación, se puede ver un ejemplo de como se crea una regla de monitorización cuando un servidor ElasticSearch recibe tráfico entrante en un puerto distinto de los de servicio por defecto, que son 9200/9300.

Figura 17: Ejemplo de regla para detectar un uso de puerto indebido para acceder a ElasticSearch

La monitorización de los contenedores en ejecución se lleva a cabo desde que se arranca el servidor Dagda, pero será el usuario el que deberá explícitamente comenzar una monitorización de un contenedor concreto y pararla cuando desee para que quede registrado en el histórico de monitrorización del propio contenedor.

Figura 18: Ejecución de Dagda en modo CLI

Para finalizar, destacar que Dagda es un proyecto completamente Open Source y que tanto su código fuente, como la documentación de su uso, ya sea mediante el API REST o mediante su CLI, está completamente documentada en la Wiki del proyecto Dagda.

Ideas finales

Como conclusión, puedo remarcar que aunque exista un estado del arte muy amplio con respecto a herramientas focalizadas en algo muy concreto, como en este caso me ha sucedido con las herramientas de seguridad en Docker, siempre se puede encontrar un nuevo enfoque que ayude a resolver un problema dado en base a la recopilación de carencias que tengan las demás herramientas existentes.

Figura 19: Sección de Troubleshooting en la Wiki de Dagda

Espero que os haya gustado este trabajo y que os anime a iniciar vuestra propia investigación o aprendizaje en todo aquello que tengáis aún en la lista de tareas por hacer como me pasaba a mí con Docker y Python. Finalmente, recordaros también que podéis utilizar libremente el proyecto Dagda en vuestros entornos, añadirle nueva funcionalidad, reportar errores que detectéis o incluso, proponer nuevas ideas :-) En el siguiente vídeo tenéis un pequeño ejemplo de funcionamiento de Dagda.

Figura 20: Demostración de uso de Dagda

Autor: Elias Grande (@3grander) autor del Proyecto ODIN
Graduado en por el Master de Seguridad de la UEM

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, Faast, Sandas 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.

Figura 4: Bases de datos MongoDB accesibles sin autenticación

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!

Big Data Security Tales: ¡Vigila que tu MongoDB no le dé tus datos a cualquiera! (Level 100)

Ayer por la noche andaba revisando uno de mis temas favoritos, las cadenas de conexión a las bases de datos, cuando me topé con algo que al principio no pensé que fuera tan preocupante, pero que visto lo visto merece la pena que os deje por aquí una referencia a ello para que lo vigiléis. Se trata de la existencia de múltiples bases de datos MongoDB que exponen los datos que almacenan sin que sea necesario conocer ningún usuario ni contraseña del sistema.

Figura 1: ¡Vigila que tu MongoDB no le dé tus datos a cualquiera!

Me topé con ello buscando otras cosas por Shodan para hacer un poco de Hacking con Buscadores, pero al revisar los resultados que devolvió en la consulta que realicé, vi que este buscador tiene indexadas todas las bases de datos MongoDB que hay por Internet publicadas. Esto no debería ser especialmente reseñable ya que basta con revisar el puerto 27017 (Well-Known port para MongoDB) para todas las direcciones IPv4 e IPv6 que Shodan localice para saber si hay o no una base de datos MongoDb.

Figura 2: Información de las bases de datos en el servidor MongoDB mostrada por Shodan

Sin embargo, entre los resultados que muestra John Matherly de muchos de los MongoDB aparece el nombre de las bases de datos que están dentro e incluso el tamaño de las mismas. La única explicación plausible a esto es que 1) o la base de datos muestra esa información sin necesidad de conectarse o 2) la base de datos MongoDB permite conexiones anónimas.

Conexiones Anónimas a MongoDB

Las conexiones anónimas son algo muy común en otros servicios, como por ejemplo en los árboles LDAP a los que se puede acceder a mucha información - incluso vía conexiones PHP LDAP Admin -, o con el uso de conexiones con el protocolo SNMPv1 o SNMPv2 en servidores SNMP, así que quise probar si la información que se veía  era por el motivo 1 o por el motivo 2. Solo curiosidad.

Figura 3: Conexión anónima a un servidor MongoDB con Robomongo

Para ello me descargué una herramienta Open Source llamada RoboMongo - que además está solicitando apoyo para que el proyecto continúe vivo - que ofrece un sencillo GUI y realicé algunas conexiones a direcciones IP de las que muestra Shodan como servidores MongoDB. Para hacer la prueba, por supuesto, en la conexión al servidor no seleccioné la opción de autenticarme.

Figura 4: Datos de usuarios y contraseñas en una base de datos en MongoDB

Sorprendentemente, en muchas bases de datos se puede acceder a las instancias de las bases de datos, y con ello a toda la información que contienen. Datos que pueden ser de todo tipo. No es una ni dos las bases de datos MongoDB que permiten acceder de forma anónima sin conexión, sino que son muchas y ofreciendo muchos datos del propio servidor.

Figura 5: Datos del software del servidor sobre el que corre MongoDB

En el caso de los registros de log, se puede ver información de arranque del motor, con datos del tipo de servidor en que está corriendo, con versiones de sistema operativo, versiones de software de motores JavaScript o SSL que pueden exponer vulnerabilidades o con rutas locales que puedan utilizarse con un ataque combinado. 

Figura 6: Usuarios, contraseñas y datos personales como el teléfono

Pero es que en muchos casos están los datos de las aplicaciones, con datos de usuarios, contraseñas, datos personales, etcétera, lo que supone un gran riesgo para la seguridad de las empresas que no hayan fortificado sus bases de datos y permitan las conexiones anónimas al MongoDB.

Figura 7: Cómo funcionan las MongoDB Injection

Si tienes una instancia MongoDB, revisa la configuración de seguridad del motor y las bases de datos, y si tienes alguna aplicación web que tire sobre ellas, revisa este artículo que publicamos en el blog de Eleven Paths sobre las técnicas de MongoDB Injection.

- 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!