martes, abril 02, 2019

Sorry HAL: La IA supera en lectura de labios a los humanos

En la charla que dimos hace unos meses en la Fundación Telefónica sobre Ciencia Ficción e Inteligencia Artificial, realizamos una aproximación de los posibles futuros escenarios relacionados con la IA que aparecen en algunas famosas películas de Ciencia Ficción. Una de ellas era por supuesto “2001: Una Odisea en el Espacio” y en este clásico del cine en concreto hay una escena donde HAL 9000 es capaz de leer los labios de los astronautas Bowman y Poole, y así descubrir el plan que estaban trazando contra él.

Figura 1: Sorry HAL. La IA supera en lectura de labios a los humanos

Más allá de la capacidad de HAL 9000 de leer los labios, algo sobre lo cual ya se está trabajando y cada vez se está perfeccionando más con técnicas de Machine Learning y Visión Artificial, lo que realmente nos interesa de esta escena es su base, es decir, la comunicación sin utilizar el sonido como fuente principal.


Figura 2: Conferencia de Ciencia Ficción e Inteligencia Artificial

El objetivo principal sería conseguir llegar a hacer que una máquina sea capaz de interpretar las acciones o comandos que realiza un ser humano, sin que estos se propaguen en forma de sonido a través del aire.

De este modo dicha máquina podría recibir los comandos sin tener ningún tipo de interferencia exterior, es decir, que la ausencia de aire o un sonido ambiental extremo no sean obstáculo para que estos comandos se reciban perfectamente y nuestro asistente digital sea capaz de ejecutarlos.

Figura 3: Escena donde HAL 9000 lee los labios de la tripulación ubicada
en la exposición de la Fundación Telefónica “Odiseas de la Inteligencia”.

El verano pasado se publicó este paper, en el cual se estudia posibles soluciones “no-acústicas” para el reconocimiento de voz o ASR (Automatic Speech Recognition). Dicho de otro modo, buscar alternativas para enviar los comandos utilizando la boca, pero sin emitir ningún tipo de sonidos. En esta investigación se describe una técnica utilizando señales sEMG (Surface Electromyographic) para detectar los movimientos de los músculos de cara y el cuello. Esta técnica de reconocimiento de voz “silencioso” se conoce como SSR o Silent Speech Recognition.

Figura 4: Paper sobre Silent Speech Recognition

En el paper se describen diferentes técnicas donde se utilizan sensores ubicados, como hemos mencionado antes, en la cara y cuello del sujeto. Utilizando un modelo entrenado contra diferentes palabras, con sEMG es posible asignar un patrón de alta fiabilidad el cual es capaz de reconocer palabras y frases sin necesidad de propagarlos a través del sonido.

Figura 5: Ejemplo de sensores sEMG.

El MIT también se ha interesado en integrar alguna técnica que sea capaz de enviar estos comandos “silenciosos”. En concreto, han desarrollado un dispositivo llamado AlterEgo, el cual permite realizar una conversación totalmente silenciosa con un ordenador sin utilizar la voz, es decir, articulando internamente las palabras. Discreción absoluta.

Figura 6: Project AlterEGO en MitMediaLab

AlterEgo es capaz de detectar cualquier tipo de movimiento de la boca, aunque esta se mantenga cerrada (algo parecido a lo que ocurre cuando leemos en voz baja). Si dos personas tienen el dispositivo conectado, sería posible también hablar entre ellas con total y absoluta privacidad.

Figura 7: AlterEgo, dispositivo desarrollado por el MIT.

Pero también es curiosa la forma de cómo AlterEgo recibe la información, es decir, si alguien nos habla (ya sea el mismo asistente digital u otra persona) ¿escucharemos la conversación como siempre? ¿a través de nuestro sistema auditivo? La respuesta es sí, pero no exactamente.

Esta vez el “sonido” de entrada se recibe directamente a través de la mandíbula. Esta técnica no es nueva pero sí se está perfeccionando poco a poco, de hecho, ya podemos ver incluso auriculares a la venta que utilizan esta novedosa forma de transmitir y recibir el sonido.

Figura 8: Auriculares de "Bone Conduction"

Esta técnica de recepción de audio funciona a través de la conducción de dicha señal utilizando la vibración de los huesos de la mandíbula. Dicha vibración es detectada por nuestro oído interno, y de esa forma, es posible “escuchar” el mensaje sin necesidad de llevar ningún dispositivo de recepción de sonido (como unos auriculares, por ejemplo). Desde luego no es la mejor forma para escuchar música debido a la baja calidad de la recepción, pero sí son perfectos para poder escuchar conversaciones en cualquier tipo de ambientes.

Esta técnica la cual utiliza la vibración de los huesos también se ha aplicado a otro tipo de materiales, esta vez artificiales. Por ejemplo, este altavoz es capaz de transmitir el audio sobre cualquier superficie y la empresa Clarion ha llevado esta misma técnica al audio de los coches.

Clarion promete convertir tu coche en un altavoz en sí mismo. Es decir, el salpicadero se convierte esta vez en el altavoz y un dispositivo colocado en el espejo retrovisor interior apuntando al parabrisas, hace el efecto de sub-woofer.

Figura 9: Esquema interno de un altavoz que utiliza una superficie como medio de transmisión del sonido

Como hemos podido observar, la forma en la que nos comunicamos entre nosotros y las máquinas está cambiando día a día y puede que en unos años no se parezca en nada a la actual. Uno de los muchos puntos positivos de estas nuevas técnicas de comunicación es la implementación de soluciones para personas con algún tipo de deficiencia auditiva, ya que problemas como la eliminación del ruido ambiental o la interpretación de las palabras, se resuelven completamente.

También se abre una puerta a ayudar personas que tengan algún problema, por ejemplo, situado en las cuerdas vocales, ya que estos dispositivos al no utilizarlas, permiten una comunicación fluida basada en el movimiento de la boca y otros músculos de la cara o cuello.

Por otro lado, también se abre un nuevo capítulo en el mundo de la privacidad y la seguridad. Con estas nuevas técnicas se aumenta la seguridad a la hora de comunicarnos entre nosotros o entre máquinas (al menos desde el punto de vista de algún observador exterior), pero al mismo tiempo, la privacidad puede estar en riesgo, ya que todos estos dispositivos registran digitalmente todas nuestras interacciones, es decir, todas las conversaciones estarían registradas y almacenadas en alguna parte (problema parecido se aplica hoy día a los asistentes digitales y el almacenamiento de la información que reciben por parte de los usuarios).

Es increíble que incluso la escena de HAL 9000 y la lectura de labios, la cual siempre ha sido un símbolo del progreso de la tecnología, se está empezando a quedar anticuada.

Fran Ramírez, (@cyberhadesblog) es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" y del blog Cyberhades.

lunes, abril 01, 2019

2FWB: Second Factor Web Browsing [Parte 2 de 4] "Network Attacks"

Ya os he contado los trabajos que hemos venido haciendo con respecto a los Second Channels, ahora toca hablar de la parte de cómo protegerse contra los ataques en redes IPv4&IPv6. Ni que decir hay que en ElevenPaths, y en mi equipo de Ideas Locas de CDO trabajamos de continuo con todos ellos y hablamos largo y tendido. Desde ataques de Network Packet Manipulation, hasta ataques de phishing homográficos como los PunnyCodes, pasando por los procesos de Ethical Hacking con SSLStrip2 y Delorean o las investigaciones de HSTS, HPKP y Certificate Pinning.

Figura 11: 2FWB: Second Factor Web Browsing
[Parte 2 de 4] "Network Attacks"

Esto hace que la preocupación cuando Mi Hacker o Mi Survivor utilizan mi equipo en una red para conectarse a buscar algo en Internet sea máxima. Me preocupa y, además de fortificar el end-point, reviso periódicamente todo tipo de detalles para asegurarme que se están conectando al sitio correcto, que no hay ninguna inyección de scripts, que el DNS ha devuelto la dirección correcta, que el certificado digital es el que debe, etcétera. Verificaciones que seguramente también hacéis vosotros en vuestro día a día cuando navegáis por Internet.

Conexión Segura & SmartWiFi

Una de las primeras cosas que he hecho ha sido activar el servicio de Conexión Segura en casa. Este servicio permite que toda la navegación que se produce a través la conexión WiFi y la línea de fibra en los hogares con Movistar Fusión, sea analizado (sin romper HTTPs). Como cualquier servicio de seguridad no te da el 100% de garantías, pero sí que te permite añadir una capa de protección a la navegación y filtrar dominios maliciosos, o ataques comunes.

Figura 12: Gestión de Conexión Segura desde SmartWiFi

Este servicio, que se puede activar desde la app de SmartWiFi de forma gratuita para toda la navegación en la WiFi de Movistar, ha detectado ya que la mitad de los hogares, en los cientos de miles de navegaciones que están protegidas a día de hoy, hayan pasado por un contenido malicioso que ha sido bloqueado. Esto es un montón de peligros quitado. Un dominio que sirve un ransomware y es detectado, se bloquea para todos los clientes Movistar Fusión con Conexión Segura y evita que se expanda.

Figura 13: Gestión de seguridad de red WiFi con SmartWiFi

Es una capa de protección transparente para los hogares, y que yo tengo puesto a todos los familiares y amigos. Con un clic estás más protegido por defecto aplicando la seguridad desde un sitio estratégico, la red por la que circula el tráfico.

Un "Second Channel" para verificar el tráfico

Dicho esto, aún me queda el riesgo de todos ataques de red que se produzcan en la red local, o aquellos ataques al end-point que vengan por canales cifrados, o que no sean detectados por la solución EDR (Endpoint Detection and Response). En todos esos caso, además de hacer una fortificación del puesto de trabajo - recomendable el libro de Sergio de los Santos (@ssantosv) "Máxima Seguridad en Windows 4ª Edición" - queda la revisión manual de los mensajes de alerta, de los detalles de las conexiones, etcétera.

Figura 14: Máxima seguridad en Windows [4ª Edición]

Es decir, navegar de forma conjunta con ellas para ver qué está pasando en el equipo con un ojo crítico con el que buscar hasta el más mínimo detalle que pueda ser el indicador de un ataque. Y eso no escala. Mi tiempo no es infinito, y no puedo hacer todas las comprobaciones manualmente siempre, así que había que automatizar este proceso.

Verificar todo significaba estar siempre sentado a su lado y ver todo lo que pasaba. Pero, ¿y si para revisar todo en vez de estar sentado en su mismo equipo usamos de manera continua dos canales? De esta forma podríamos automatizar en otro equipo las verificaciones de "papapete" para saber si estamos sufriendo un ataque de red.

Figura 15: Idea detrás de 2FWB: Second Factor Web Browsing

La primera idea que se me vino a la cabeza fue que estaría bien tener un equipo con dos tarjetas de red, y tener siempre una conexión a él para ir recibiendo en la pantalla lo que está viendo en su navegación. Algo así como los equipos de "manos remotas" que tenemos en muchos equipos importantes en la red de comunicaciones.

Pero la mayoría de los portátiles - como la Microsoft Surface que le tengo puesta a Mi Hacker - viene con la WiFi solo. Podría comprar una segunda tarjeta, pero debería montar en todo momento una red y conectarla a mi equipo también con dos tarjetas, y además mi equipo debería conectarse a otra red distinta. Esto podría ser fácil, porque yo me suelo conectar vía "hotspot" a mi teléfono móvil vía BlueTooth. No es casualidad que se me ocurriera la malvada idea del DirtyTooth que presentamos en RootedCON 2017, era un power-user de ello.


Figura 16: DirtyTooth en RootedCON 2017

Pero para montar esta verificación de la navegación en tiempo real era demasiado lío el tener que poner el equipo de Mi Hacker o de Mi Survivor conectado al mío por una segunda red creada entre ellos y luego conectar mi terminal vía BluetTooth para usar una conexión de red LTE - que vistos los ataques a redes móviles usar otra red no es del todo seguro - que permitiera tener una segunda visión de los servicios de Internet a los que se conectan y verificar que todo está ok.

¿Y si lo simplificamos?

Al final, si tenemos una conexión vía BlueTooth+2G/3G/4G a Internet tenemos siempre un Second Channel en todos los equipos, y la verdad es que yo siempre llevo mi smartphone y todos los equipos que usamos vienen con BlueTooth. Es fácil conectar el equipo que usan mis hijas con mi SmartPhone utilizando BlueTooth y ver dónde están navegando y qué están viendo, para poder comprobar que lo que están recibiendo es lo que deben recibir.

Esta comprobación podríamos hacerla desde el propio termina móvil donde haríamos las comprobaciones, o mucho mejor, haciéndolo desde un servicio en la nube que haría esas verificaciones para todas las instancias de esta app. Las dos arquitecturas tienen ventajas e inconvenientes. Tener toda la lógica en la cloud simplifica la construcción, pero da un elemento más en el sistema que podría ser atacado en un posible esquema de DDOS al servidor en cloud que recoge la inteligencia para detectar los ataques.

Figura 17: Arquitectura de 2FWB con protección de app en smartphone

Por otro lado, tener toda la lógica en el terminal móvil obliga a desplegar nuevas apps o nueva lógica al dispositivo cuando hay nuevas reglas de detección de ataques. Pero hace el atacante deba conseguir vulnerar la red del equipo desde el que se navega a Internet más la conexión a Internet del smartphone. Un doble ataque más difícil de realizar, sobre todo si no estás cerca geográficamente para atacar al dispositivo móvil - ver libro de Ataques a redes de comunicaciones móviles GSM/2G/3G/4G de nuestros amigos de Layak -.

Figura 18: Libro de hacking y seguridad en comunicaciones móviles
GSM/GPRS/UMTS/LTE (2G/3G/4G)

Con es doble canal usando una conexión a Internet de navegación vía red WiFi o Ethernet, y un segundo canal vía BlueTooth+3G/4G, podríamos realizar dos conexiones al mismo servidor desde dos puntos diferentes, usando dos redes distintas. Usar este doble canal tiene cierta similitud con el doble factor de autenticación en los sistemas de login, donde se busca que el atacante deba vulnerar dos elementos distintos para aumentar su dificultad. En este caso, el tráfico del primer canal debe generar respuestas similares y con propiedades similares al que se obtiene por el segundo canal y si no, generamos una alerta.

Esta idea, permite detectar ataques de red en el canal primario, como un DNS Spoofing, un ataque de Phishing, un dominio marcado en un servicio de seguridad como peligroso por usar ficheros JS de  cryptominnig, ataques de bypass HSTS, o de Certificado Falso. Solo necesitamos saber qué es lo que se está recibiendo como respuesta en el canal primario y hacer una comprobación en el canal secundario.

Arquitectura en el end-point

Para conseguir los datos de seguridad útiles para la detección de ataques, necesitamos en el equipo a proteger tener una extensión en el navegador que nos permita capturar las cabeceras HTTP y datos del DOM de la página HTML de la respuesta, más alguna información de red que recibimos del sistema, como direcciones IP resueltas por el DNS, datos del DNS que responde, tablas ARP, etcétera. Toda esta información se captura usando dos elementos.
- Extensión de navegador (en este caso Google Chrome): Este elemento extrae la información que necesitamos del D.O.M. (Document Object Model, y se lo envía al Agente. Además, recibe del Agente las ordenes de bloquear o no bloquear la sesión de navegación con un mensaje de alerta.
- Agente en el sistema (en este caso escrito en Node JS): Establece la conexión vía BlueTooth con el 2FWB y le envía la información recibida de la Extensión del navegador, además de información del sistema para que el 2FWB le diga el resultado de la evaluación. Después, recibe la información desde el 2FWB y manda las órdenes a la Extensión del Navegador para que bloquee o no la sesión.
Con esta arquitectura, tenemos la ocasión de que las verificaciones que haría yo mismo de forma manual para comprobar que está viendo lo que debe de ver en cada momento, de tal manera que si algo no cuadra, o se detecta un fallo en el certificado, el nombre del dominio, la dirección IP del servidor, los ficheros incrustados en el DOM del documento, etcétera, se bloquea la navegación con un aviso que llega a la pestaña del navegador en la que está visualizando el contenido.




A post shared by Chema Alonso (@chemaalonso) on

He de decir que hicimos pruebas con BluetTooth Low Energy y con un solo componente basado en la extensión de Google Chrome, pero la realidad es que teníamos dos problemas con esto:
1.- Volumen de datos: Con el protocolo BLE el volumen de datos que podíamos enviar era muy limitado y lo que necesitamos enviar y a la velocidad que lo necesitábamos nos limitaba mucho a la hora de hacer verificaciones de seguridad.
2.- Datos de red del sistema: Para poder detectar ciertos ataques como ARP Spoofing, ataques MITM en IPv6 con SLAAC, etcétera, necesitábamos información del sistema operativo así que necesitábamos un agente en el sistema.
Así que por eso se eligió usar un perfil BlueTooth desde el Agente y tener la extensión de Google Chrome para acceder a la información de la web que se estaba navegando y ver los datos en tiempo real del DOM. Tener las cabeceras HTTP, información del certificado, los archivos scripts inyectados, etcétera es algo que desde la extensión es posible realizar.

Saludos Malignos!

*****************************************************************************************
- 2FWB: Second Factor Web Browsing [Parte 1 de 4] "Second Channels"
- 2FWB: Second Factor Web Browsing [Parte 2 de 4] "Network Attacks"
- 2FWB: Second Factor Web Browsing [Parte 3 de 4] "2FWB Mobile App"
- 2FWB: Second Factor Web Browsing [Parte 4 de 4] "Modo Centinela"
*****************************************************************************************

Entrada destacada

Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment. Nuestro nuevo libro en 0xWord

Pocas veces me ha hecho tanta ilusión que saliera un nuevo libro en 0xWord como con este libro de " Hacking IA: Jailbreak, Prompt Inje...

Entradas populares