El de esta semana, es el que tienes aquí mismo para Crear Operaciones e Instancias de Latch, que te van a permitir dotar de granularidad a la capa de control de autorizaciones de tu empresa.
He actualizado este artículo con el tercer tutorial, que explica cómo sacar partido a los WebHooks del API de Latch para integrar fácilmente la capa de control de autorizaciones en tus aplicaciones y servicios digitales.
Hace unos años, con el equipo de Ideas Locas, creamos una solución para controlar la navegación de un ordenador personal mediante un canal paralelo. Tan sencillo como que una persona teclee una URL para navegar en su Google Chrome y antes de que esta se cargue, se intercepta por un plugin la dirección, se envía por BlueTooth a un terminal móvil pareado al navegador, y este verifica por la conexión móvil "Si ese sitio es seguro", o si el responsable del "Control Parental" lo autoriza.
Después llegó la pandemia, nos reestructuramos en la compañía, y pusimos este proyecto de innovación en el "Backlog", pero sin llegar a dejarlo aparcado. Y seguimos dándole la vuelta, hasta que al final lo hemos lanzado ya en Tu Latch "Navegación Segura", de momento solo para la versión Android de Tu Latch, y para navegadores Google Chrome.
Tu Latch Navegación Segura es un servicio al que hay que suscribirse de manera anual, y permite estar conectado a una red WiFi pública de un aeropuerto, de un café, de un hotel, o cualquier red, y tener al servicio Navegación Segura protegiendo tu navegación en todo momento.
Configuración de Tu Latch Navegación Segura
Para poder utilizar Navegación Segura hay que contratar el servicio desde la propia app de Tu Latch, siguiendo el proceso que se detalla en las capturas.
Para proteger la navegación de tu equipo, es necesario que el terminal móvil y el navegador estén conectados por BlueTooth, por eso hay que descargarse el Plugin de Navegación Segura de Tu Latch para Google Chrome, tal y como explica el proceso, y después parearemos los dos equipos: El smartphone, conectado a la red móvil, y el equipo a proteger, conectado a la WiFi o al red que le da servicio a Internet.
Una vez instalado el plugin en Google Chrome, se puede hacer la activación del servicio desde el propio navegador, tal y como podéis ver en estas imágenes.
El plugin se instalará en el navegador, y a partir de ese momento ya sólo se necesitará realizar el pareado del navegador por Bluetooth con la app de Tu Latch cuando se vaya a navegar desde cualquier red en la que se desee tener Navegación Segura.
El Plugin de Navegación Segura de Tu Latch para Google Chrome hay que instalarlo la primera vez en el equipo, para que esté disponible en todas las sesiones del navegador Google Chrome.Una vez hecho, ya sólo se hará la activación del servicio.
Ahora ya podemos parearlo con Tu Latch y tendremos el canal de seguridad por BlueTooth, conectado a Tu Latch en el smartphone, y éste conectado al servicio de Navegación Segura para proteger la navegación de Google Chrome en el ordenador.
Este proceso se puede hacer desde cualquier navegador que se paree al terminal de Tu Latch con el servicio de Navegación Segura contratado, así que lo único que deberías realizar es el mismo proceso que te he descrito.
Lo recomendable, como explicamos tanto en el plugin como en la app de Tu Latch, es que el terminal móvil y el equipo con el navegador a proteger, estén en diferentes redes, para mantener limpios los dos canales de verificación y que un enemigo en el medio no pueda bloquear la consulta al servicio de seguridad.
A partir de ese momento, cuando un dominio se detecte como peligroso, el plugin de Tu Latch en Google Chrome bloqueará el sitio por Phishing, Fake Broker, Ciberestafa, Distribución de Malware, etcétera, y podremos ver que este sitio ha sido bloqueado por Tu Latch.
Por el contrario, si el dominio no se ha detectado como malicioso, sabremos que ha sido verificado por el servicio de Tu Latch Navegación Segura, tal y como podemos ver en la imagen siguiente.
Con el servicio de Tu Latch Navegación Segura puedes tener una capa extra de seguridad para navegar por redes en cafeterías, hoteles, aeropuertos, etcétera, de manera muy sencilla, y comprobando en todo momento que los dominios a los que te estás conectando son los correctos y no han sido manipulados. Ya os iré contando muchas más características sobre las novedades de Tu Latch. Y en breve estará en iPhone también.
Hace ya varias semanas salieron publicadas la mayoría de las conferencias que se dieron este año en la RootedCON 2019. Por un error, o un descuido, la charla que yo impartí este año salió confundida, por lo que se quedó sin publicar. Así que, mientras que descubro si la tienen grabada o no os voy a dejar una grabación que hizo uno de los asistentes al evento.
Figura 1: Conferencia de Chema Alonso en RoortedCON 2019 sobre "Second Factor Web Browsing (2FWB)""
La charla, como ya os conté, versa sobre Second Factor Web Browsing, una idea que se me ocurrió durante el verano de 2018 para poder ayudar en la navegación a Mi Hacker y Mi Survivor. De todo eso, os hablé en el artículo de "Second Factor Web Browsing" que acompaña a la charla, donde tenéis no solo el detalle de todo el proceso, sino también las demos en vídeo, las explicaciones y las diapositivas de la charla.
Figura 2: Chema Alonso en RootedCON 2019
Como no he conseguido la grabación, os he traído una que hizo Yair Rodriguez que tiene bastante buena calidad, para que no se pierda como las lágrimas en la lluvia. No es muy larga, ya que me pidieron un poco de tiempo para presentar a una startup española y recorté alguna cosilla con el objeto de no romper la agenda.
Tras comprobar que el funcionamiento de la solución de 2FWB con aplicación móvil y servicio en cloud para las verificaciones de seguridad funcionaba perfectamente, se nos ocurrió darle una vuelta de tuerca. Al final, habíamos optado por utilizar una conexión BlueTooth en lugar de una conexión BlueTooth Low Energy, y eso nos abría muchas puertas.
Figura 29: 2FWB: Second Factor Web Browsing [Parte 4 de 4] "2FWB Modo Centinela"
En un principio, recordad que la idea de usar 2FWB era poder tener una solución móvil que yo, como responsable adulto de Mi Hacker y Mi Survivor, pudiera utilizar en cualquier conexión de red para comprobar que no se estaba produciendo ningún ataque a la red IPv4 o IPv6 por la que se conectan esos equipos desde su ubicación hasta el servidor web. Pero el caso de uso evolucionó.
2FWB Personal y 2FWB Empresarial
Tras comenzar como una solución de protección para menores, también nos pareció una solución perfecta para navegación personal. Imagina que estás de viaje en una ciudad que no es la tuya. Tienes que trabajar y consumir muchos datos desde tu habitación de hotel, así que pides la red WiFi. Eres un tipo preocupado por la seguridad, así que tienes fortificado tu end-point (el equipo desde el que te conectas) y además, tienes las soluciones de fortificación de la red WiFi que puedes ya que la red WiFi no es tuya.
De las opciones de fortificación de las redes WiFi hablamos el año pasado en la RootedCON 2018, con la charla de Wild Wild WiFi: Dancing with wolves, donde explicamos los trabajos de investigación que hemos hecho durante estos años para fortificar las conexiones a redes WiFi con soluciones como Mummy, SSID Pinning, PsicoWiFi o WEP/WPA/WPA2-TOTP/Biometría.
Aún así, sacar tu teléfono móvil, parearlo con el Agente 2FWB y navegar con la Extensión 2FWB permitiría detectar ataques de Man in The Middle en la red, e incluso más allá. Es decir, si hiciéramos una conexión VPN entre nuestro equipo y un servidor VPN y el ataque de red IPv4 & IPv6 estuviera más allá de nuestro servidor VPN, o hubiera un Proxy manipulando nuestras peticiones entre el servidor web al que deseamos conectarnos y nosotros mismos, también se detectaría.
Figura 30: 2FWB Mobile App para uso personal
Esto es algo importante a resaltar de la solución de 2FWB y es que no está diseñada para detectar los ataques en la red de conexión a Internet, sino a los ataques de red que se produzcan en cualquier tramo entre el cliente y el servidor web que no esté compartido con el Second Channel.
Dicho esto, y pensando que esta solución utilizaba BlueTooth, se nos ocurrió que las redes por defecto podrían tener "centinelas" de seguridad fijos que ayudaran a dar esta protección. Imagina que llegas a tu despacho, a un centro de co-working o a tu casa, y tienes un dispositivo inteligente que no se conecta a tu red WiFi ni a tu red Ethernet, sino que tiene una SIM que lo conecta a Internet por un Second Channel. Este dispositivo, permite conexiones BlueTooth para vigilar la navegación.
Figura 31: Esquema de 2FWB Modo Centinela
Para esta Prueba de Concepto utilizamos un esquema como el que se puede ver, usando una Raspberry Pi y cambiando la SIM por un WiFi Tethering para tener la conexión del Second Channel usando la red móvil del smartphone con el que pareamos la Raspberry Pi.
Así, las personas que trabajan en ese espacio físico, por seguridad, deciden utilizar el servicio Centinela 2FWB de la ubicación física y se conectan a él con su Agente 2FWB a través de la Extensión 2FWB, lo que les permite tener alertas de seguridad y detección de ataques de red en todo el tramo de conexión que haya entre su equipo personal y servidor al que se están conectando. De nuevo, más allá incluso de su servidor VPN.
Prevención y Detección de ataques de red (más allá de la VPN)
En el trabajo de Wild Wild WiFi nos centramos en la Prevención de los ataques, pero este trabajo de Second Factor Web Browsing se centra en la Detección de los ataques. Una fase distinta dentro los procesos de fortificación y seguridad de cualquier sistema informático o servicio en la empresa.
Como parte de nuestro trabajo de innovación en materia de ciberseguridad dentro de ElevenPaths, tras realizar la Prueba de Concepto, observamos que esta solución de 2FWB, tanto en Modo App Móvil, como en Modo Centinela, tenía una aproximación única, así que hicimos la presentación de las patentes pertinentes de la solución.
Aún estamos en una fase embrionaria de convertir esta solución en un producto o servicio estable, pero es lo que tiene la investigación, cada día se avanza un poco más aprovechando todo el trabajo que se ha hecho antes hasta que sin darte cuenta las características se van introduciendo ellas solas en todo lo que va saliendo.
Os dejo las diapositivas que utilicé en la charla de RootedCON 2019 subidas a SlideShare, y no quiero terminar este artículo sin explicar que estos trabajos son el esfuerzo conjunto de un grupo de personas. No basta con tener la idea, hay que construirla y ahí contar con mis compañeros del equipo del Laboratorio de Innovación de ElevenPaths y del equipo de Ideas Locas es genial.
Vista la arquitectura general del sistema de Second Factor Web Browsing en el apartado anterior, vamos a ver cómo funciona el sistema con varios ejemplos. Para ello, vamos a explicar primero cuál es el formato de información que intercambian el Agente 2FWB en el sistema operativo desde el que se navega y la App 2FWB instalada en el terminal móvil que habilitará el Second Channel. Esta información se intercambia utilizando el protocolo BlueTooth tal y como ya se ha explicado.
Figura 20: 2FWB. Second Factor Web Browsing [Parte 3 de 4] "2FWB Mobile App"
Para que se entienda, vamos a suponer que desde el navegador del equipo de una de mis hijas se comienza a navegar a un determinado dominio de Internet. La Extensión 2FWB para Google Chrome extrae cierta información relativa a la respuesta que se recibe desde el servidor y se la entrega al Agente 2FWB que se encuentra corriendo en el sistema operativo. Éste, añade información relativa al propio entorno de red que no puede ser extraída con una extensión del navegador, y por Bluetooth envía un fichero con todos los datos a la App 2FWB que se encuentra en el terminal móvil pareado.
Figura 21: Alerta de seguridad para que llame a papá
Después de realizar todas las comprobaciones, en nuestro caso mediante un servicio en cloud que hace todas las verificaciones, la App 2FWB enviará una respuesta al Agente 2FWB que llegará hasta la Extensión 2FWB instalada en el navegador, dejando que prosiga la sesión de navegación, o bloqueando la pestaña con una aviso que diga: "¡Avisa a Papá". Recordad que se trata de un servicio que intenta ayudar a sentirse más seguros a los más jóvenes, y es como si su "papaete" estuviera navegando junto a ellos.
Peticiones y respuestas
El formato de intercambio es bastante sencillo. Desde el Agente 2FWB se envía a la App 2FWB este fichero con los datos más relevantes. El nombre del dominio, un id de la petición y la pestaña en la que está visualizando dicho contenido. Después se introducen los datos del certificado digital recibidos en la petición HTTPs que se utilizarán para verificar con el original del sitio.
Figura 22: Formato de envío de datos que va desde el Agente 2FWB a la App 2FWB
Además, se entregan las cabeceras HTTP que han venido en la respuesta entregada por el servidor web ante la petición del navegador, junto con la lista de scripts. Además incorpora información tomada del sistema por el propio Agente 2FWB como el TimeStamp o las respuestas DNS obtenidas.
En la lógica del Servicio 2FWB, que en nuestra arquitectura está en una plataforma Cloud pero que también podría recaer directamente en la App 2FWB, evalúa los diferentes controles para verificar los diferentes posibles ataques.
Evalúa la hora del sistema, el valor SHA256 del certificado que se recibe por el Agente 2FWB en la máquina con la que se debería obtener (revisando los posibles certificados digitales y las políticas HSTS para ver si existe algún Certificate Pinning marcado por el servicio).
Evalúa la dirección IPv4/IPv6 a la que se ha conectado, la lista de cabeceras HTTP recibidas, la lista de scripts, y hace una verificación extra del nombre de dominio contra servicios de inteligencia varios - como NotMining -para saber la calidad de ese dominio.
Figura 23: Respuesta a recibida a la petición de 2FWB con id:123
Y con todas las comprobaciones hechas, al Agente 2FWB le llega la respuesta vía App 2FWB con un formato similar a este. Donde si alguna de las validaciones anteriores falla (campo con valor a "False" ), se considerará que la conexión es peligrosa y el campo "Operation" devuelto en la respuesta, tomará el valor "Deny" . En caso contrario, el valor será "Allow" .
Probando ataques con Bettercap
Para probar el funcionamiento completo del sistema hemos preparado varios ataques utilizando caplets de Bettercap para tener la visión de cuál es la experiencia. En estos cinco vídeos vamos a poder ver cómo se detectan los ataques que hemos incluido en esta prueba de concepto. Desde una máquina con Kali Linux vamos a lanzar todos los ataques, y veremos la experiencia en la App 2FWB y en la navegación del navegador de Internet protegido por 2FWB.
Figura 24: Detección de ataque de ARP Spoofing con 2FWB
Figura 25: Detección de ataque de DNS Spoofing
Figura 26: Detección de ataque de Certificado Falso
Figura 27: Detección de ataque a HSTS
Figura 28: Detección de ataque de Cryptojacking
Control Parental con 2FWB
Una vez que tenemos la App 2FWB en el terminal del papá, donde se pueden ver las alertas que se generan en tiempo real con los posibles ataques, parecía bastante fácil implementar un sistema de Control Parental en tiempo real, para que el adulto que se encarga de vigilar la seguridad de la navegación de los menores pudiera bloquear o permitir determinados dominios.
Figura 28: Control Parental con 2FWB
En este caso, como se puede ver, hemos puesto la alerta de otro color - azul - para que no se asuste nadie cuando aparezca y se tenga claro que ha sido el adulto el que ha puesto este control momentáneamente, tal y como se puede ver en el vídeo de la Figura 28.
Como se puede ver, la posibilidad de tener un 2FWB permite tomar muchas decisiones en función de lo que se está recibiendo por el navegador de Internet conectado a la red WiFi o Ethernet, y de lo que se recibe por el Second Channel que utilizar el servicio de 2FWB. Pero aún podíamos darle una vuelta de tuerca más, que os contaré en la última parte de esta serie.
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.
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.
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.
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 -.
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 bypassHSTS, 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.
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.
Tengo la suerte de ser un "papaete" que tiene dos niñas que me vuelven loco. Son totalmente distintas, la mayor es "Mi Hacker" y la pequeña "Mi Survivor". Cada una es como es ella. No es fácil encontrar puntos en común en su forma de ver la vida, pero si hay algo que tienen las dos es que les encanta la tecnología.
Figura 1: 2FWB: Second Factor Web Browsing [Parte 1 de 4] "Second Channels"
Supongo que su "papaete" habrá tenido algo que culpa, y es que desde muy pequeñas las he expuesto a la tecnología, para que la vivan conmigo. Han estado en robótica y en tecnología desde que eran muy pequeñas. Scratch, Arduino, Lego Mindstorms, o lo que sea. Yo las apunto a cursos, seminarios, les compro libros de programación o simplemente les cuento cosas. Pero no solo eso, también las incito a hacer cosas conmigo en mi trabajo. Y les encanta.
Niñas y Tecnología
No intento que esta forma mía de vivir con mis salvajes deba ser la que se aplique con los niños y niñas. Esta es la forma en la que yo vivo la tecnología con Mi Hacker y Mi Survivor. Con Mi Hacker, en el año 2017, cuando aún no estaba lanzada AURA en ninguno de los países subimos juntos en el "Encuentro de Telefónica". Un acto privado con unas 1.000 personas donde ella hizo una demo completa guiada conmigo de cómo iba a funcionar AURA en la app móvil de Movistar+ en España.
Y con Mi Survivor, pues ya sabéis que rodé un pequeño anuncio el verano pasado con Movistar Home, dando rienda a su afición al Atlético de Madrid y jugando un rato con ella. Nos lo pasamos genial ese día, y se pasó dos días antes aprendiéndose las frases y repitiéndolas durante horas y horas a todo el que se acercaba.
Figura 3: Movistar Home y SuperCopa de Europa 2018
Y como os podéis imaginar, he estimulado mucho su interés por la tecnología, así que las preguntas que todo padre sufre, yo las tengo que debatir durante días y semanas con ellas. Preguntas que seguro que os suenan a la mayoría.
Papaete, ¿me dejas el móvil?
Papaete, quiero un iPhone.
Papaete, ¿puedo tener Musicali? Los grabo en privado. No, en borradores. Porfi, porfi.
Papaete, ¿por qué tu tienes Instagram y yo no puedo?
Papaete, no quiero Youtube Kids, quiero Youtube normal.
Papaete, ¿qué es esto de TikTok? ¿Y Crush?
Papaete, ¿puedo buscar en Internet una cosa del colegio?
Papaete, puedo bajar un jueguecito en el ordenador. Es gratis.
Papaete, ¿has visto a Momo? En el cole lo han visto todas las niñas…
Y claro, el verano pasado me tenían la cabeza llena de sus peticiones, así que decidí que tenía que hacer algo. Como todo buen investigador de seguridad me he pegado mucho con los ataques de red, y cuando estamos de viaje y hay que usar un ordenador, las redes WiFi me dan mucho miedo. Es lo que tiene haber estado criando y construyendo a nuestra querida Evil FOCA, o de jugar con los servidores Proxy. Ya sean por IPv4 o por IPv6, en cualquier red a la que te conectes puede aparecer un atacante.
Y como me tenía muy preocupado, empecé a pensar cómo podía vigilar sus conexiones mirando por encima del hombro todo lo que hacían pero sin estar. Y así fue como se me ocurrió esta idea del Second Factor Web Browsing (2FWB) que os voy a contar en esta serie, pero dejadme que lo haga uniendo los puntos de atrás adelante después de haberos explicado el punto de partida. La gracia es poder unir los puntos de cosas que vas dejando en el pasado para poder crear cosas nuevas en el futuro. Como lo que os cuento hoy.
Second Channels que no Side Channel
Recuerdo cuando llegó la primera vez que se me ocurrió empezar a utilizar un Second Channel en un producto. Era el año 2013 y acabamos de terminar nuestra primera patente de un producto que se llamaba en CodeName Path2. Era nuestra primera patente y estábamos construyendo el producto y todos los detalles del servicio que iba a proveer.
Ese Path2 se convirtió a la postre en Latch, y la pregunta que teníamos que resolver era... ¿cómo abrimos y cerramos el pestillo si estamos en una situación en la que no hay Internet? Las soluciones a estos problemas se suelen resolver con algoritmos TOTP generados en el end-point o generados en el bank-end y enviados por SMS, pero yo quería hacer algo distinto. Quería utilizar el canal SMS como si fuera un canal de comunicaciones y permitir que la app siguiere funcionando normalmente enviando "tramas" SMS.
En aquel entonces, haciendo lo que tiene que hacer un equipo de producto, decidimos quitar esa característica del roadmap principal y aceptar que no la teníamos para enfocar los recursos en partes del producto y servicio que consideramos más prioritarias en aquel en entonces.
Pero ni mucho menos se me olvidó.
Tiempo después empezamos a trabajar en la idea de ver cómo podrían funcionar las apps maliciosas en los Identity Providers de Internet para robar los Tokens OAuth y hacer ataques como el de RansomCloud lo que nos llevó a que hiciéramos nuestro querido y famoso SAPPO del que hablamos en la RootedCON 2016 y con el que nuestro amigo Kevin Mitnick asusta a los ejecutivos de todo el mundo en sus charlas.
Y fue con esa idea de hacer cosas con los Tokens OAuth la que volvió a tocar en mi cabeza la idea de los Second Channels. Lo que sucedió es que preparando la presentación del MWC de Febrero de 2017 fui a ver UNICEF en New York tras pasar a dar una pequeña charla en la Universidad de Columbia.
Allí nos estuvieron contando cómo el canal SMS era aún una poderosa herramienta para ellos porque en muchos de los países en los que trabajaban, o en muchas situaciones de emergencia, era el único canal de comunicaciones que existía. Inundaciones, corrimientos de tierra, situaciones de emergencia humanitaria por hambre o enfermedad, etcétera.
Hicimos un juego de prueba con el ahorcado para explicar cómo podía utilizarse, pero durante la última Vuelta Ciclista a España, tras hacer una etapa con el Movistar Team, me di cuenta de que podíamos hacer un sistema de mensajería en grupo basado en Internet+Stack SMS que diera más velocidad y cobertura a las comunicaciones durante carrera por las zonas más inhóspitas de los países, y nació el juguete que enseñamos en Diciembre de 2018.
Figura 9: Movistar Team Chat Room con Stack SMS
Pero aún lo podíamos utilizar para muchas más cosas. El poder contar siempre con un Second Channel tan cómodo, accesible y común como el SMS nos abría muchas posibilidades, y cuando en este Mobile World Congress 2019 nos pidieron alguna charla de seguridad, mis compañeros del equipo de Ideas Locas crearon el IoT AntiDDOS SMS Shield, es decir, una solución de control remoto de dispositivos IoT que estuvieran siendo inhabilitados por un ataque de denegación de servicios.
Figura 10: IoT AntiDDOS SMS(GSM) Shield
Como podéis ver, la idea de utilizar Second Channels ha sido una constante durante los últimos años en nuestro equipo, así que no es raro que apareciera la idea de Second Factor Web Browsing (2FWB) que os voy a contar a continuación. Pero como ha quedado muy largo, dejadme que esto sea en la siguiente parte del artículo.
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso 3DAIS
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
