Air Profiling: Cómo perfilar usuarios por su tráfico WiFi

Hoy mismo ha tenido lugar el webinar que hemos hecho en ElevenPaths dentro de nuestra serie de CodeTalks For Developers sobre Air Profiling, una Prueba de Concepto que explica cómo se pueden hacer perfiles de navegación de usuarios en una red WiFi, por medio del análisis del tráfico que generan sin cifrar, o por medio de los puntos de conexión.

Figura 1: Air Profiling: Cómo perfilar usuarios por su tráfico WiFi

La idea nació dentro de un proyecto de Equinox, utilizando las bases de datos de URLs de apps que tenemos en Tacyt, y en este caso, Guillermo Román Ferrero y Javier Gutierrez Navío, han hecho una implementación.

Como he dicho, el proyecto de Air Profiling permite, a través del tráfico recogido mediante sondas que monitorizan el tráfico WiFi, procesar dicha información y realizar un perfil de los distintos usuarios, enfocado a clientes de dispositivos móviles, del uso de los dispositivos según la información obtenida al analizar su tráfico web.

Figura 2: CodeTalk for Developers "Air Profiling"

Para este proyecto, se han usado tecnologías de análisis de datos de Amazon Web Services, TCPdump y Python. Se ha utilizado una base de datos en ElasticSearch que permite de forma sencilla la recopilación y cruce de los distintos datos, y pintar, gracias a Kibana, gráficos con los resultados de los mismos.

El resultado final es una aplicación web, ubicada en un servidor Django, que permite mostrar los resultados del análisis de datos, mostrando información sobre la navegación web, qué páginas visita dicho usuario, un estudio de los tipos de páginas frecuentadas, la ubicación de los servidores áccedidos, y un timeline que muestra cuando ha realizado peticiones el dispositivo analizado.

Saludos Malignos!

Big Data Security Tales: Django en HUE en modo DEBUG y con Directory Listing (Level 103)

Otra de las cosas que es fácil probar y localizar es esta mala configuración por defecto de Django en distribuciones de Apache Hadoop. En concreto, Django es un framework para desarrollo de aplicaciones web escrito en Python, y sobre él está construido HUE, el interfaz de administración web de análisis de datos del que hablamos ayer. Muchos amantes de Python lo utilizan de forma habitual para desarrollar sus aplicaciones, e incluso tienes un módulo de Latch para Django que hizo en forma de hack nuestro amigo Deese de RootedCON usando el SDK de Latch para Python.

Figura 1: Django en HUE en modo DEBUG y con Directory Listing (Level 103)

El caso es que, en algunas distribuciones de Apache Hadoop en las que se incluye HUE, la configuración de Django no está lista para producción y viene en modo DEBUG. Basta con ir a la ayuda de Django y ver que explica lo siguiente.

Figura 2: Ayuda sobre el modo DEBUG en Django

Queda claro que jamas se debería poner en producción una aplicación escrita en Django con el modo DEBUG activado, pero sin embargo HortonWorks la lleva así. Basta con pedir un fichero que no existe en el servicio HUE (sin haber hecho login si quiera) y acceder a la información en modo DEBUG.

Figura 3: Información de DEBUG en el error de Django

Como se puede ver, son URLs disponibles en el servidor de HUE que quedan expuestas. Podemos incluso pedir alguna de ellas para darnos cuenta de otro error en el empaquetado y publicación de HUE en esta distribución, ya que el servidor web viene con Directory Listing y podemos ver las carpetas y los ficheros de algunas de estas URLS.

Figura 4: Servidor web de HUE con Directory Listing

Y si navegamos, llegamos al "art" con el que ha sido tuneado esta versión concreta de HUE, que como veis son los logos de HortonWorks.

Figura 5: Logos de HortonWorks en el "tuning" de esta versión de HUE

Como se puede apreciar, esta es una versión de HortonWorks con Apache Hadoop y HUE, lo que debería hacerte pensar, si tienes una distribución de estas en tu empresa, deberías revisar cuanto antes las configuraciones de HUE y Django.

Figura 6: Big Probles with Big Data - Apache Hadoop Interfaces Security

De algunas de estas cosas habló el investigador Jakub Kaluzny en la reciente OWASP AppSecEU 16, así que no te pierdas la charla que está en el vídeo de la Figura 6. Aquí abajo tienes la lista de artículos de Big Data Security Tales para que no te vayas perdiendo ninguno.

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

Latch: Django, Demonios, Secretos y Despareado Seguro

Desde que di la charla en RootedCON sobre Hacking & Playing with Digital Latches han aparecido algunos hacks de usuarios que utilizan Latch de formas diversas y que junto con una recomendación de seguridad para implementar Latch os voy a contar hoy.

RootedCON y el plugin de Latch para Django

Uno de los hackers que organizan RootedCON, nuestro amigo Javi "Deese", me contó en la cena de ponentes que había estado trabajando en integrar Latch con Django. Como la idea me encantó, yo le pedí durante la charla que lo liberará y así lo ha hecho. Ahora está disponible su plugin de Latch para Django que puedes descargar desde el repositorio de GitHub que han habilitado: Django-Latch.

Figura 1: Plugin de Latch para Django

Ese mismo plugin es el que ellos utilizaron para integrar el servicio de Latch en las cuentas de acceso al portal creado por Django que utilizan en el propio sitio web de RootedCON, y ahora tú también puedes usarlo.

Figura 2: Latch integrado en RootedCON

Este se suma a la lista de plugins que ya tienes disponibles para usar en diferentes frameworks y que puedes utilizar desde ya con Latch.

Revelación de Secretos, daemons y 2-Keys Activations

Por otro lado, en HackPlayers publicaron un artículo titulado "Demonizando Latch para proteger archivos con dos llaves", en el que explican cómo implementar un esquema de 2-Keys Activation similar al que expliqué en la pasada charla de RootedCON.

Figura 3: Esquema de 2-Keys Activation con Latch

La idea de estos esquemas es que un determinado activo no se habilita hasta que no se han desbloqueado los dos latches que lo protegen, y ellos lo han integrado con un daemon que permite o no acceder a un determinado fichero.

Figura 4: Las dos cuentas que gestionan las dos llaves que dan acceso al activo

Este esquema lo teníamos nosotros en mente por ejemplo para una Web de Revelación de Secretos controlada remotamente que permitirá o no ver un determinado contenido cuando una o varias personas abran los latches que dan acceso al contenido.

Secure UnPair

Por último, quería explicaros cómo evitar un riesgo que tenemos identificado desde el principio. Supongamos que una víctima se conecta a su sitio web con una identidad que tiene protegida por Latch, peo la máquina está infectada por un bot.

El usuario abre el latch de la cuenta, introduce sus contraseñas y el bot roba el usuarios y la password al mismo tiempo que navega en la web y elimina el latch con un proceso de Despareado. A día de hoy lo que hacemos es avisar al usuario de que la lista de servicios ha cambiado y que una cuenta ha sido eliminada, para que sepa que algo ha pasado y pueda tomar medidas correctivas, como cambiar la password si aún está a tiempo o hablar con el sitio web del que le acaban de robar la identidad.

Figura 5: La lista de servicios protegidos por Latch ha cambiado

No obstante, en implementaciones personalizadas es posible crear un sistema de UnPair seguro, utilizando una operación controlada por Latch. La idea es que en el pestillo de la cuenta habrá una operación que controlará si se puede desparear o no la cuenta. Esto se crea en las operaciones de la cuenta y listo.

Figura 6: Añadiendo la operación de Desparear con opciones de OTP

De esta forma, el usuario tendrá una operación dentro del Latch de la cuenta que le permitirá bloquear el despareado automático e impedirá que un bot robe una identidad aunque sea con un man in the browser y la pueda utilizar. El sitio web lo único que necesita hacer es comprobar el estado de esa operación antes de lanzar un proceso de despareado.

Figura 7: El usuario controla si se puede o no desparear la cuenta

Eso sí, siempre podrá esperar a que el usuario maneje su cuenta para hacer las cosas malas cuando el usuario haya iniciado sesión. Eso sí, si hay operaciones que bloquean parte de la cuenta con Latch no podrá hacer nada que no esté abierto, mitigando el impacto del malware lo máximo posible.

Saludos Malignos!