Pi Guardian: Un sistema de seguridad con Latch, Bots de Telegram y una Raspberry Pi con ojos #RaspberryPi #Latch

Como ya os han contado Chema Alonso y Pablo González - que presentó su Latch'sApp -, el Equinox es nuestro “Hack Day” personal. Un evento que nació en las entrañas de ElevenPaths y que se extiende ahora a todo el área de nuestro Chief Data Officer de Telefónica y que nos permite abandonar nuestro día a día durante 24 horas para desarrollar nuestras ideas más “locas”.

Figura 1: Pi Guardian. Sistema de seguridad con Latch, Bots de Telegram y una Raspberry Pi con ojos

Por supuesto no todo es programar durante esas 24 horas. Es una oportunidad estupenda para hacer piña y conocer más de cerca a compañeros con los que no trabajas normalmente, o para comer pizza, mucha pizza.

Figura 2: Pizza, mucha pizza en el Equinox de CDO de Marzo de 2017

En esta edición, la segunda en la que participo desde que llegué a ElevenPaths, decidí hacerlo en solitario. Se que es el trabajo en equipo es importante, pero tenía ganas de probarme a mí mismo y presentar un proyecto ante el tribunal para ir perdiendo el miedo escénico. Y de este proyecto os voy a hablar en el artículo de hoy. Se llamó:

Pi Guardian

La idea para mí era sencilla. Desde que los compañeros de Latch añadieron los Webhooks (necesitas estar conectado con una cuenta de desarrollador para ver la documentación de Latch), es posible convertir la app en un interruptor para casi cualquier cosa.

Figura 3: Documentación de los Webhooks de Latch (en sitio de developer)

Por otro lado, quería desenterrar mi vieja Raspberry PI y hacer algún hack en el que pudiera jugar con algo de electrónica, que aquí se lo pasan de maravilla con la VPN con Latch, OpenVPN y Virus Total, o en el caso del DirtyTooth Hack donde también la utilizaron para las PoC. Así, decidí construir mi Pi Guardian, un sistema de alarma anti-intrusos gestionado únicamente con la app de Latch.

Figura 4: Sensor de movimiento PIR

Para ello, me recorrí Madrid la tarde anterior al Equinox en busca de un sensor de movimiento PIR, que básicamente da una señal digital cada vez que detecta movimiento. Cuando en mi Raspberry PI detectara esta señal, preguntaría a la API de Latch: "¿Candado cerrado?" y Latch haría el resto por mí. Recibiría una notificación en la app indicando que alguien ha intentado acceder a mi cuenta. Aunque en este caso, significaba que Pi Guardian ha detectado un intruso.

Figura 5: Alerta de que alguien ha sido detectado por Pi Guardian

Además, con la app de Latch para Apple Watch también recibía la notificación en mi muñeca, por lo que en apenas una hora había construido un sistema de alarma totalmente funcional con un sencillo bloque IF en mi lenguaje favorito.

Figura 6: Alerta de sensor de movimiento en Apple Watch

Como aún tenía tiempo, se me ocurrió que podía darle ojos a mi Pi Guardian. Sería tan sencillo como añadir una Webcam al sistema que disparase una foto cuando detectase algún movimiento el sensor y tenerlo coordinado con Latch. Así que al lío.

Poniéndole ojos a Pi Guardian

Pedí una Webcam USB prestada a mis compañeros del departamento de IT e instalé en mi Raspberry Pi el software Open Source Motion. Esto me permitía tomar fotografías y grabar tomas de video cada vez que el sensor detectara movimiento. El bloque IF tenía ahora un par de líneas más.

Figura 7: Raspberry Pi con sensor de movimiento y Webcam USB

Ahora ya tenía un sistema que grababa vídeos y tiraba fotos cuando detectaba movimiento, pero como aún no habían terminado las 24 horas, podía meterle más funcionalidades. Así que pensé en qué más añadirle.

Un bot de Telegram para gestionar a Pi Guardian

La siguiente funcionalidad que quería añadir era algo más ambiciosa. Pensé que sería útil permitir que la alarma fuera gestionada por varios usuarios, pensando en un entorno familiar. Para ello, y por simplicidad, implementé un Bot de Telegram que podría añadir a un chat de grupo y que procesaba los comandos "on" y "off" para activar/desactivar la alarma en paralelo al candado de Latch.

Figura 8: Control de las funciones de Pi Guardian con un bot de Telegram

También implementé el comando “pic”, con el que tomaba una foto con la webcam y la enviaba al chat. Así, tenía una app multiplataforma desde la que también podría gestionar mi Pi Guardian.

¿Integrándolo con AURA?

Por último, ya que aun me quedaban unas horas y que la edición de este año animaba a desarrollar proyectos relacionados con Aura, se me ocurrió implementar un “Aura, protect my home” que seguro daría muchos puntos a la demo, al estilo del "Aura, show my Latch" de mi compañero Javier Espinosa.


Figura 9: Aura controlando Latch

La idea consistía en enviar un mensaje de voz al chat de Telegram, procesarlo desde el Bot y lanzar el comando correspondiente. Sin embargo, aprovecharé este post para hacer una pequeña confesión. Se me acababa el tiempo y el procesamiento de audio no era algo trivial, pero ese “Aura, protect my home” sonaba todo el rato en mi cabeza. Entonces recordé cuando Chema Alonso nos hablaba del Golden Path de Steve Jobs en la presentación del primer iPhone y decidí implementar el siguiente pseudocódigo:

IF recibo audio AND alarma ON?
alarma OFF!
ELSE IF recibo audio AND alarma OFF?
alarma ON!

Así que básicamente implementé la funcionalidad de activar/desactivar la alarma mediante mensajes de voz, aunque daría igual el contenido de ese mensaje.

Pi Guardian en acción

Lo siguiente ya fue la demo. Acepté el reto de hacerla en Inglés para que los compañeros de UK pudieran seguirla. Quedó muy divertida gracias a la ayuda de mi compañero Antonio, que se quedó en la oficina para hacer saltar la alarma y saludar a la cámara. Aquí os dejo una vídeo del funcionamiento de Pi Guardian.

Figura 10: Demo de Pi Guardian

El proyecto no resultó vencedor en ninguna categoría. Tenía poco que hacer contra el Virtual Rubik de Dani, Jorge y Pedro, y mi “Aura” no podía hacer frente al proyecto de “Laura” de Javi y Carlos. y qué decir del Birrinder, ese red social para tomar birras basada en la 4º Plataforma que te avais de los Spoiler Alerts cuando alguien iba por delante de ti en una serie que estabas viendo. Insuperables.

Figura 11: Log de accesos en Latch para Pi Guardian

Eso sí, me llevé una alarma antirrobo para casa que funciona y que además me permite ver qué hace mi perro cuando estoy fuera y que, como se ve en la imagen superior, puede monitorizar constantemente para saber la historia de todos los eventos usando el log de Latch.

Autor: Julio García Pérez, Sofware Engineer @ElevenPaths

Plugin de Latch’sApp para DataExfiltration Toolkit (DET)

Hace un par de días hablábamos de cómo hacer exfiltración de datos a través de Latch con Latch'sApp. Sí, un uso un tanto diferente, pero que era válido para intercambiar información oculta en las posiciones de los cerrojos de Latch, incluso, ¿por qué no? Hacer un cliente de mensajería diferente. Quizá la velocidad no sería la más puntera, a la altura del coche de Fernando Alonso en este comienzo de temporada, pero la exfiltración se podría realizar.

Figura 1: Plugin de Latch'sApp para Data Exfiltration Toolkit (DET)

Durante el desarrollo de la IV Edición del Equinox, Álvaro Nuñez-Romero (@toolsprods) y yo, tuvimos tiempo para pensar en el uso de DET, Data Exfiltration Toolkit, y pensamos en migrar nuestro código escrito en Python a un plugin para esta herramienta. De esta forma, cualquier usuario podría tener nuestro hack en su DET.


Figura 2: Exfiltrando datos con Latch'sApp
Lo primero que trabajamos es ver como se extendían los plugins de DET. Sabíamos que DET tiene una serie de plugins para utilizar canales encubierto para exfiltrar datos, como, por ejemplo, el plugin de Twitter o el de Gmail. Por otro lado, utiliza otros plugins para exfiltrar datos a través de la esteganografía en protocolos de red, como, por ejemplo, HTTP, TCP o DNS. Como veis, y ya vimos en su día, interesante conjunto de herramientas para utilizar en los ejercicios de exfiltración de datos en un proyecto de hacking ético.

Hands On Lab: Mirando cómo funcionan los plugins de DET

DET se encarga de ejecutar todo lo necesario para que el plugin reciba y muestre los datos. Hay que recordar que DET tiene una arquitectura cliente-servidor en la que un extremo envía unos datos hacia el otro extremo. Mirando el funcionamiento nos damos cuenta que necesitaremos crear un fichero con unas funciones concretas, que será el plugin, y modificar el fichero JSON con nombre config, para que éste tenga en cuenta nuestro plugin con los valores que nosotros queramos.

Figura 3: Código para enviar los datos byte a byte

El plugin tiene una función denominada send, a la cual DET le pasa el parámetro Data. Este parámetro son los datos a exfiltrar, byte to byte. Por otro lado, tiene una función denominada listen. Esta función será utilizada por la parte receptora, la que se supone que está fuera de la empresa. Se ejecutará una función u otra en función de los parámetros con los que se invoque DET.  En esta otra imagen, se puede observar parte del código de la función listen.

Figura 4: Función listen para recibir los datos

PoC: Jugando con ambos extremos a Latchear y exfiltrar datos

Una vez escrito el plugin debemos actualizar el fichero de configuración de DET para que detecte nuestro plugin. En un alarde de imaginación se llama latch y así lo incluimos en el fichero de configuración.

Figura 5: Plugin latch incluido en la configuración de DET

Ahora, cuando preparemos el extremo A para exfiltrar los datos a través de las posiciones de los cerrojos de Latch tendremos que ejecutar la instrucción:

Python det.py –p latch –f [fichero a exfiltrar] –c [fichero de configuración config.json]

En ese momento, DET ejecutará la función send implementada en el plugin de latch para DET y se comenzará el envío de los datos. Como se puede ver, DET simplifica muchos el juego.

Por otro lado, en el extremo B se configurará DET para ejecutar el plugin de latch y ponerse a la escucha y recibir los datos. Para ello, se ejecutará la instrucción:

Python det.py –p latch –l –c [fichero de configuración config.json]

En el siguiente video se puede ver un ejemplo de uso y de exfiltración de datos con este método.

Figura 6: Demo de exfiltración de datos con DET usando latch

Como se puede ver, fue divertido participar en el Equinox y nos dio tiempo a sacar bastante juego a los cerrojos e, incluso, integrarlo en una herramienta de exfiltración de datos que podéis utilizar en un proyecto de hacking ético.
 
Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths

Latch en el mundo IoT integrado con Mosquito MQTT Broker #Mosquito #Latch #IoT @elevenpaths

A lo largo de la corta vida de Latch hemos visto muchas integraciones de nuestra tecnología con el mundo IoT, desde las integraciones con la hucha o la máquina de caramelos que hicimos internamente, hasta cosas como la integración en el chip ESP para hacer MicroLatch o el Latch My Car. Son muchas las ideas que han ido apareciendo a lo largo de este tiempo para controlar con Latch tu mundo físico.

Figura 1: Latch en el mundo IoT integrado con Mosquito MQTT Broker

En el pasado Latch Plugin Contest, le dimos el mejor premio - de 5.000 USD - a un proyecto de integración de nuestra tecnología al mundo IoT de la mano del proyecto Mosquito. Este nombre tan peculiar para una tecnología es el que recibe un proyecto Open Source que implementa una especificación MQTT Broker para controlar los dispositivos IoT tanto en el hogar, como en sistemas industriales o SCADA.

Figura 2: Proyecto Eclipse Mosquito

El protocolo MQTT fue diseñado originalmente en IBM, pero se convirtió en un estándar y ahora hay implementaciones Open Source como este Mosquito, hecha en Python, que puedes descargarte y utilizar en tus proyectos.

Figura 3: Faqs MQTT

El objetivo de un sistema MQTT Broker es de hacer de intermediario en esquemas de publicador/suscriptor para el mundo IoT, permitiendo que se descubran nuevos dispositivos, y que se puedan añadir nuevas peticiones de servicios. Esta tecnología permite que sea fácil ampliar, cambiar y reducir los sistemas IoT en una casa, una empresa o una fábrica. 

Figura 4: Esquema de funcionamiento de MQTT

Con la integración de Latch, lo que se permite es añadir un Segundo Factor de Autorización al MQTT Broker para no solo controlar la seguridad del acceso al panel de configuración, sino para añadir controles a las peticiones de servicio que se pueden encaminar a un determinado dispositivo.

Figura 5: Esquema de funcionamiento de control de MQTT con Latch

El manual y la documentación completa del proyecto de Latch para Mosquito MQTT Broker os lo he subido a a Slideshare, y ahí podéis ver desde su instalación, hasta la configuración completa de un entorno.

Figura 6: Manual de integración de Latch en Mosquito MQTT Broker

Además, para que podáis entender mejor el concepto de funcionamiento, este vídeo con una casita en maqueta de lo que sería el mundo IoT en el hogar explica paso a paso el funcionamiento y la utilidad de tener Latch integrado.

Figura 7: Demo de Latch integrado en Mosquito MQTT Broker

Puedes descargar Latch para Mosquito MQTT Broker en el GitHub de su creador, para que lo podáis probar en vuestras propias instalaciones de MQTT.

Figura 8: Latch para Mosquito MQTT Broker

Cada día que vemos la cantidad de cosas que se integran constantemente con Latch, nos sentimos más contentos del uso que se le da a nuestro Segundo Factor de Autorización, ya que las ideas que van apareciendo son cada vez más curiosas. Me encanta.

Saludos Malignos!

Latch’sApp: Un hack para exfiltrar datos con Latch @elevenpaths #latch #hacking #dataexfiltration

La pasada semana celebramos la IV Edición de nuestro Equinox, un evento interno en el que cualquier persona de CDO puede participar y llevar a cabo sus ideas más locas. En esta ocasión era mi segunda participación, ya que por varios motivos solo había podido participar en una de las tres ediciones anteriores.

Figura 1: "Latch'sApp" Un hack para exfiltrar datos con Latch

La primera idea que rondó deberá esperar para ver la luz, ya que no fue la elegida para participar en este hackathon, pero seguro que en el futuro se verá. La segunda idea fue la de crear un sistema de exfiltración de datos en el que ocultar información a través de los cerrojos de Latch.... y no sonaba nada mal. Este sistema permite crear un canal encubierto a través de las posiciones de los distintos cerrojos de una app de Latch.

Hands On con la exfiltración con Latch

Le comenté la idea a mi compañero Álvaro Nuñez-Romero (@toolsprods) y le gustó. Decidimos participar en las 24 horas de Equinox con esta idea y llevarla a cabo. La idea toca tres partes fundamentales para algunas pruebas de Data Exfiltration, que cada vez van cogiendo más auge en algunos proyectos de hacking ético.

Figura 2: Codificación de bytes con Latch

Este es un dato importante que fue proporcionado al jurado, ya que para comprobar si la inversión en controles internos que eviten o prevengan el filtrado de información de dentro de la organización al exterior es un hecho que cada vez se prueba más en una organización. El hack tocaba tres partes importantes:

• Data Exfiltration: La colocación de los cerrojos de Latch representa un 0 o un 1, es decir, si tuviéramos 8 cerrojos podríamos representar 1 byte. Si tuviéramos 16 cerrojos podríamos representar 2 bytes, etcétera.

• Canal encubierto: La posibilidad de crear un canal encubierto, como los vistos en la herramienta DET con el caso de Twitter, de Gmail, de Google Docs, son un claro ejemplo de cómo ocultar información a través de dichos canales.

• Esteganografía y/o cifrado: La esteganografía permite ocultar información en imágenes, protocolos, otros archivos, y en este caso pensamos que las posiciones de los cerrojos pueden ocultar información, ya sea de un mensaje concreto o, incluso, un archivo cifrado.

El algoritmo para la transmisión de información es sencillo:

1. Se puede enviar un mensaje o un fichero. Sea cual sea el dato a enviar se lee el primer byte. 

2. Se obtiene un binary string, el cuál es la representación en unos y ceros del byte leído. 

3. Se va leyendo cada posición del binary string. Si es 1 se coloca el cerrojo correspondiente a “off”. Si es 0 se coloca el cerrojo correspondiente a “on”. 

4. Hay un noveno cerrojo que marca si la operación es escritura o lectura. Es decir, cuando emitamos o subamos datos colocando los cerrojos en sus diferentes posiciones se marcará el noveno cerrojo a “off” para que el otro extremo sepa que tiene que leer la información. 

5. Cuando el extremo lee la información colocará el noveno cerrojo a “on”. De esta forma se establece una especie de turno entre ambos extremos. 

6. La información que lee el extremo son 8 cerrojos (o N en el caso de hacerlo escalable). Si el cerrojo está a “off” se añade en un binary string el valor 1, si el cerrojo está a “on” se añade un binary string el valor 0. 

7. Una vez se tenga el binary string completo se obtiene el byte y ese byte se ha filtrado.

En la siguiente imagen se puede ver cómo se produce el traspaso de un mensaje utilizando el algoritmo anterior desde una app que utilizamos como emisor y se dedica a configurar los pestillos en la forma adecuada, y una app receptora que se dedica a leer los valores de los pestillos.

Figura 3: Emisor a la izquierda, receptor a la derecha

En el caso de los ficheros el proceso es exactamente igual. Durante el propio Equinox pensamos que sería interesante cifrar los datos que se envían en local, utilizando para ello una clave que pudieran saber los dos extremos. En primer lugar, pensamos en el OTP que el propio Latch puede proporcionar a los usuarios, pero no conseguiríamos que ambos extremos se “enterasen” del mismo OTP, ya que cada vez que hacíamos una petición a una operación con OTP, éste cambia.

Cifrando los datos con AES

Decidimos utilizar un derivado del APP ID. De esta forma, el extremo A cifra en local todos los bytes que quiere transmitir, por lo que la posición de los cerrojos de un byte cifrado a uno no cifrado no es la misma. Con este método, si alguien tiene acceso a la posición de los cerrojos en un momento dado necesitaría, además, de la clave que descifra la información. El cifrado utilizado es un AES.

Figura 4: Envío de fichero cifrado usando AES y codificado en Base64

Para poder visualizar el envío de información cifrada, los bytes se envían cifrados con AES y luego codificados en base64. En la imagen se puede ver un ejemplo de envío de archivo cifrado a través de las posiciones e interpretación de los cerrojos de Latch.

La PoC final con DET

Aparte de comer, disfrutar de actividades en el Equinox y pasar un rato estrujándonos el cerebro nos sobró tiempo para hacer un plugin de DET utilizando Latch, pero eso ya será contado en otra ocasión. Aquí os dejamos el vídeo funcionando el sistema de exfiltración de datos con Latch.

Figura 5: Exfiltrado de datos con Latch en vídeo

Enhorabuena a los premiados en el Equinox y a las grandes ideas y proyectos que allí se vieron. Ser jurado en este tipo de eventos no es fácil y mis compañeros hacen que no les sea fácil. Suerte al jurado y a los próximos participantes del Equinox de septiembre.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths

Big Data Security Tales: Riak NoSQL Database #BigData

Haciendo recorrido a motores y tecnologías de Big Data de amplio uso, como parte de nuestro trabajo de actualización y mejora de los plugins de Faast, llegamos a Riak. Éste es un motor NoSQL que goza de cierta popularidad por su capacidad de trabajar en clusters distribuidos y es común encontrarlo en auditorías de seguridad.

Figura 1: Big Data Security Tales "Riak NoSQL Database"

Encontrar estos motores haciendo hacking con buscadores no es especialmente complejo. En primer lugar porque en buscadores como Shodan ya cuenta con su catalogación de producto,  ya que es fácil localizarlo por los puertos 8087 para el protocolo de comunicación riak y el 8098 para el panel de acceso HTTP.

Figura 2: Riak NoSQL en Shodan

En la parte de acceso web, el servidor web utiliza el HTTP Header del servidor MochiWeb & WebMachine, por lo que es sencillo saber si hay muchas posibilidades o no de encontrarse con un servidor NoSQL de Riak.

Figura 3: Puerto 8098 con el servicio HTTP 

Si el servicio HTTP está levantado, lo más probable es que te encuentres con un listado de ficheros en el directorio raíz, donde entre otros estará el archivo de estadísticas, con información general de todos los servidores que forman parte del cluster de Riak.

Figura 4: Contenido del servicio HTTP por el puerto 8098

No muchos de esos archivos son accesibles, y algunos son end-points de peticiones de servicio al motor NoSQL de Riak, pero entre ellos es posible que localices algún panel de adminsitración abierto al público.

Figura 5: Archivo Stats

Son muchos los que tienen el software de Riak Control o Riak Explorer publicados en la carpeta /admin, así que lo único que hay que hacer para ver si están o no publicados al exterior - que no deberían estar sin control - es buscar en esa URL.

Figura 6: Rick Control publicado al exterior de un cluster NoSQL

Con Riak Control se puede ver qué nodos forman parte del cluster y, entre otras cosas de monitorización, parar uno de ellos o hacer cambios en la configuración de cada uno de ellos.

Figura 7: Herramienta para gestionar los nodos de un cluster

Todas las cosas que se pueden hacer con Riak Control las puedes ver en este pequeño vídeo de marketing que hizo la compañía.

Figura 8: Vídeo de explicación de Riak Control

En el caso de Riak Explorer, se pueden crear configuraciones para gestionar los datos almacenados en el cluster NoSQL. Ahí tendrás listados de índices y los cubos de datos que se pueden crear ahí.

Figura 9: Riak Explorer... por HTTP

También se puede acceder a información detallada de cómo está funcionando el sistema y configurar los gráficos de control y monitorización a gusto, para tener los dashboards que se deseen con información de todos los nodos.

Figura 10: Gráficos en Riak Explorer

Tener esta consola de administración de cara a Internet puede ser un peligro, ya que cualquiera puede configurarse los buckets que desee, lo que puede producir errores en el funcionamiento de aplicaciones conectadas al motor.

Figura 11: Publicar una herramienta que puede hacer acciones potencialmente peligrosas en el sistema sin control de acceso no parece lo más oportuno. Ponle un Latch!

Encontrar estas utilidades de adminsitración web publicadas a Internet debería generar una alerta de seguridad para comprobar si están protegidas de forma segura o no. Si tienes un motor Riak en algún revisa su configuración. Sí, yo tampoco he visto mucho HTTPs.

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

Citas para la última semana de Marzo @elevenpaths @luca_d3 @movistar_team #BitCoin

En esta última semana de Marzo de 2017 que se nos viene encima, tenemos alguna acción que puede ser interesante. No os traigo muchas referencias, pero sí que algunas curiosas, como el seminario de las ElevenPaths Talks especial que vamos a dedicarle al DirtyTooth Hack, y alguna cosa extra.

Figura 1: Citas para la última semana de Marzo de 2017

El primer evento que os dejo es este martes, en Madrid, un Meetup de un tema que nos interesa mucho "Seguridad en las monedas virtuales". Lo organiza el grupo de Madrid BitCoin y es para usuario generalista, pero como la seguridad de BlockChain y BitCoin es algo que a muchos preocupa, os dejo la referencia del evento del día 28 de Marzo a las 18:00.

Figura 2: Meetup en Madrid sobre la seguridad en las monedas virtuales

Yo el día 29 de Marzo estaré en México D.F. dando una conferencia con la empresa KIO Networks donde hablaré de la gestión de la seguridad en las organizaciones. Será una charla para CEOs, CIOs y CSOs donde intentaré darles algunas ideas de las que suelo compartir con ellos para gestionar mejor la seguridad de la información, que no siempre es una tarea sencilla. Es un evento por invitación, así que no os puedo dejar una URL de registro y debéis poneros en contacto con la empresa.

El miércoles 29, desde LUCA Data-Driven Decisions vamos a impartir un seminario por la tarde, a través de Internet y gratuito, donde vamos a contar el trabajo que estuvimos haciendo con los datos del equipo ciclista Movistar Team y que yo presenté no hace mucho. Puedes registrarte en la siguiente URL: LUCA Talk 3 "Big Data y Ciclismo" 

Figura 3: LUCA Talk 3 - Big Data y Ciclismo

Si te gusta el ciclismo, no debes perderte este seminario, porque estará también el gran Mikel Zabala, que es el actual Director del Cycling Research Center del equipo Movistar Team. Aquí en este vídeo tienes unas pinceladas del trabajo que vas a poder ver en el seminario de LUCA.


Figura 4: Demo del trabajo de LUCA con Movistar Team

Desde ElevenPaths vamos a dar un seminario online gratuito dedicado a al DirtyTooth Hack, de una hora de duración a través de Internet. No estaba en la lista oficial de las ElevenPaths Talks, así que lo hemos organizado ad-hoc para esta semana que entra. Estarán Jorge Rivera  - el CSA manitas que hizo todo el hardware para sustituir el módulo BlueTooth del Marshall Killburn - y nuestro compañero Pablo González, que me ayudó a gestionar el proyecto de este hack para que saliera adelante. 

Figura 5: Seminario online gratuito de DirtyTooth Hack

Será el jueves 30 de Marzo por la tarde, y puedes registrarte gratuitamente en la siguiente dirección URL: ElevenPaths Talk Special Edición DirtyTooth Hack.

Y esto es todo lo que os dejo de referencia. No es mucho, pero más que suficiente para que saques un rato para estar con nosotros, que hay temas interesantes a los que puedes asistir.

Saludos Malignos!

Hay otro Internet en las Wireless Meshnets: De Hyperboria a Freifunk pasando por B.A.T.M.A.N. o MeshBerry

Muchas veces, cuando se habla de la Deep Web se tiende a pensar que esta es lo mismo que TOR, y ni mucho menos es así. La Deep Web es un concepto mucho más genérico que habla de aquellos contenidos que no se encuentran accesibles por los canales de flujo masivo de conexiones, como son los buscadores como Google, Bing, o los grandes centros de compartición de información, como son Facebook, Twitter, Youtube, etcétera.

Figura 1: Hay otro Internet en las Wireless Meshnets

El concepto de Deep Web viene de un artículo publicado en el año 2001 en el que se ahonda en la dificultad de localizar aquel contenido que está fuera de los sistemas masivos de indexación, catalogación y búsqueda. Desde páginas web que quedan en el índice secundario de Google, hasta contenido que se encuentra almacenado en redes que necesitan de software especial de conexión, o lugares en los que son necesarias credenciales de acceso.

Figura 2: Artículo del año 2001 que introduce el concepto de Deep Web

En esta catalogación, por supuesto, entra la red TOR, las redes FreeNet o I2P, pero también una gran cantidad de redes P2P - donde yo ideé mi Dust-RSS, redes serverlesss como ISIS & OSIRIS, o la cada vez más popular red CJDNS y su famosa Hyperboria.

Figura 3: Charla en RootedCON 2011 sobre DUST-RSS

A lo largo de este tiempo, las comunidades han seguido desarrollando ideas para crear redes propias, fuera de los canales tradicionales, con diferentes arquitecturas descentralizadas, tal y como funciona TOR o CJDNS. En el año 2014, en las famosas conferencias HOPE (Hackers On Planet Earth) de New York, se impartió una charla sobre cómo estas redes podían hacerse a nivel local con la proliferación y abaratamiento de conexiones Wireless.

Figura 4: Wireless Meshnets

En esa charla se habló del proyecto NYC Mesh, una red comunitaria en la ciudad de New York para conectarse sin necesidad de contar con una infraestructura concreta. Dicha red se crea con la unión de nuevos nodos a la misma que configuran protocolos especiales de encaminamiento que permiten la conexión entre ellos de manera dinámica. Para ello, utilizan una distribución con todo lo necesario para conectarse en una distribución de Raspberry Pi a la que llaman Meshberry.

Figura 5: Meshberry v0.2 en NYC Mesh

Uno de estos tipos de redes comunitarias, descentralizadas, y disponibles para cualquiera que quiera ser parte de ella, es Freifunk, muy popular en Alemania y que se basa en el protocolo de enrutamiento B.A.T.M.A.N. (Better Approach To Mobile Ad-hoc Networking), que resuelve el problema de envío de los paquetes en una red cambiante, descentralizada y móvil en la capa 2.

Figura 6: Vídeo que explica el concepto de las redes Freifunk

Llegué a esta red por casualidad, revisando unos mapas que mi amigo rootkit me había enviado, donde se puede ver de forma abierta todo lo que está pasando en cada una de estas redes Freifunk desplegadas por las diferentes regiones de Alemania.

Figura 7: Gráfico de una de las redes Freifunk en Alemania. Está bien nutrida

No es que me guste especialmente, pensando en la privacidad, que se puedan ver las conexiones con direcciones MAC de muchos de los equipos que están haciendo uso de ella desde una web, pero supongo que los que utilizan estas redes ya deben saber cambiar la dirección MAC, además de otras medidas de privacidad.

Figura 8: Región de Alemania cubierta de redes Freifunk

Lo bueno de utilizar una red como Freifunk, es que también te puedes conectar a Internet, lo que permite que, por ejemplo desde una conexión a la red Freifunk hagas uso de una conexión a la red TOR para contar con una capa extra de anonimato.

Al margen del uso que le quiera dar cada uno a este tipo de redes, desde el punto de vista técnico, es precioso ver cómo se siguen creando nuevas tecnologías día a día, y se consiguen proyectos de gran utilidad para muchas personas a base del esfuerzo y el conocimiento de unos pocos. Hay otro Internet fuera del mainstream.

Saludos Malignos!

Vídeos de las ElevenPaths Talks Temporada 3

Como ya hiciera con los vídeos de la Temporada 1 de las ElevenPaths Talks y con todas las sesiones que conformaron la Temporada 2, voy a utilizar este artículo para ir recopilando todas las grabaciones de las charlas que impartimos periódicamente desde ElevenPaths sobre tecnología en general y seguridad informática en particular. Tienes ya más de 50 charlas gratuitas disponibles.

Figura 1: Vídeos de las ElevenPaths Talks Temporada 3

Si quieres conocer la agenda de sesiones que tenemos por delante - que estamos en plena campaña - para apuntarte y asistir a ellas gratuitamente, puedes acceder a la web: ElevenPaths Talks. 

Figura 2: Lista de próximas sesiones de ElevenPaths Talks 3

Por ahora, los vídeos que tienes disponibles son los siguientes, e iré actualizando este artículo a medida que vayan publicándose las grabaciones cada dos semanas, así que pon este artículo en favoritos.

Figura 3: La Guerra contra el Ransomware

Figura 4: La red bajo ataque

Figura 5: Data Access Control y De Duplication en Cloud Computing

Por último, si quieres debatir sobre algo de lo que se haya hablado en las sesiones a posteriori, a priori o quieres proponer algún tema, puedes hacerlo a través de nuestra Comunidad online de ElevenPaths.

Saludos Malignos!

DirtyTooth Hack: Cómo reemplazar el módulo BlueTooth en un altavoz Marshall Killburn

Como ya se explicó en el ataque DirtyTooth Hack, si se quiere meter un módulo malicioso que cambie el comportamiento del BlueTooth Speaker para convertirlo en un Rogue DirtyTooth Speaker, como primer paso se requiere remplazar el módulo BlueTooth original por el nuevo módulo creado. En este artículo vamos a ver los detalles concretos del reemplazo en un BlueTooth Speaker modelo Marshall Killburn, que es el que utilizamos para la prueba de concepto.

Figura 1: Cómo reemplazar el módulo BlueTooth en un altavoz Marshall Killburn

Como ya explicó, para hacer el módulo BlueTooth malicioso se había construido un sistema que contenía, en un módulo Teensy v3.2, un módulo BlueTooth BC127 de BlueCreation , un módulo GSM/GPRS SIMCOM800C, un módulo BlueTooth HC-05 para tener una conexión serie sobre BlueTooth, además de la tarjeta SD para almacenamiento de los datos.

Figura 2: Esquema del hardware a introducir dentro del BlueTooth Speaker Marshall Killburn

Para introducir ese módulo malicioso de BlueTooth, primero hay que retirar el módulo original para poder reemplazarlo. En este altavoz en concreto el sistema BlueTooth se basa en un módulo BTM8630, con el chip CSR8630, pero acompañado de abundante electrónica adicional, destacando un doble amplificador operacional JRC NJM4560M.

Figura 3: Ubicación del módulo BlueTooth original en el altavoz Marshall Killburn

En la placa que monta el conjunto de pueden identificar las conexiones siguientes:

• R y L: parecen corresponderse con los canales de audio Right y Left. 

• LED: se corresponde con el Led Bluetooth del panel en lógica negativa. 

• 3.3v: tensión de alimentación estable a 3.3 voltios. 

• ON: corresponde con la selección de entrada de audio HIGH en INPUT. 

• 12v: tensión variable de 7 a 18v voltios de poca intensidad (nivel batería), 

• PAIR: presenta un pulso en HIGH de 550ms de duración al pulsar PAIR. 

• OFF: permite desconectar el sonido del amplificador en lógica negativa.

Figura 4: Módulo BlueTooth original en el altavoz Marshall Killburn

Tanto el chip original CSR8630 como el BC127 que lo reemplazará, presentan salidas de audio analógicas como corriente alterna de unos 600mVpp como máximo para cada uno de los canales, y ambos acompañados de su señal complementaria diferencial, para posibilitar la reducción de interferencias, tal y como se puede apreciar en la siguiente captura.

Figura 5: Salidas en el chip original CSR8630

Pero al parecer, la electrónica que acompaña al módulo original, especialmente el doble amplificador operacional, se utiliza para montar la señal de audio sobre un offset de corriente continua de 2.6v, lo que debe ser un requisito de diseño del amplificador Marshall.

Figura 6: Señal de audio con offset

La necesidad de satisfacer este requisito sin disponer del esquema original obliga a diseñar un circuito equivalente que presente un comportamiento similar. Para ello se utiliza un doble amplificador operacional Texas Instruments RC4060, de prestaciones similares al original, en configuración de restador de una tensión de referencia de 2.6v proveniente de un regulador lineal A78L02 a la señal complementaria diferencial, cuyo resultado es una señal de audio fiel a la orinal, incluso más nítida si cabe, sobre la portadora de continua esperada.

Figura 7: Señal de audio generada

Este circuito se realiza sobre una placa con un conector compatible con la original, donde se añaden los conectores necesarios para la alimentación a 5v del resto de módulos, un pequeño relé para la desconexión de la batería de litio que requiere el modem GSM.

Figura 8: Placa con conector que ajusta la señal a los requisitos del Marshall Killburn

Se incorpora también un transistor para invertir la lógica de la señal de desconexión del amplificador OFF, ya que aunque Blue Creation no lo documenta, su salida GPIO_03 cambia de estado según esté un audio en reproducción, utilizándose para desconectar el amplificador y evitar los molestos ruidos POTHS!!! entre cambios de audio, tal y como lo realiza el módulo original.

Figura 9: Diagrama con interconexiones finales al módulo adaptador

Una vez dispuestos todos los componentes, su interconexión se realiza tal y como se muestra en el diagrama de la Figura 9 superior. La tensión de alimentación de todos los módulos (INPUT +5vcc) se obtiene mediante la adición de una conexión al regulador lineal de 5 voltios presente en el circuito del amplificador. Aunque de formato SMD, puede llegar a entregar hasta 1.3 amperios, algo que parece más que suficiente para su cometido original y el escaso consumo de los módulos adicionales.

Figura 10: Conexión Final en el altavoz Marshall Killburn

El resultado final conectado al altavoz Marshall Killburn es el que se ve en la imagen superior, y el resultado final de la experiencia con el software es la que habéis visto en los vídeos del ataque DirtyTooth Hack.


Figura 11: Ataque de DirtyTooth Hack
Autor: Jorge Rivera, CSA de ElevenPaths

*********************************************************************************
- Dirtytooh hack site
- Libro de Hacking iOS: iPhone & iPad [2ª Edición]
- Conferencia DirtyTooth Hack en OpenExpo 2017
- DirtyTooth Hack: It´s only Rock'n Roll but I like it (I de V)
- DirtyTooth Hack: It´s only Rock'n Roll but I like it (II de V)
- DirtyTooth Hack: It´s only Rock'n Roll but I like it (III de V)
- DirtyTooth Hack: It´s only Rock'n Roll but I like it (IV de V)
- DirtyTooth Hack: It´s only Rock'n Roll but I like it (V de V)
- DirtyTooth Hack: Reemplazar el módulo Bluetooth en Marshall Killburn
- DirtyTooth Hack: Seminario en Vídeo
- DirtyTooth para Raspberry Pi
*********************************************************************************