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.
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.
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.
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 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.
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:
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"
*****************************************************************************************
 |
| 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.
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"
*****************************************************************************************
No hay comentarios:
Publicar un comentario