2FWB: Second Factor Web Browsing [Parte 3 de 4] "2FWB Mobile App"

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.

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"
*****************************************************************************************