Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Second Factor Web Browsing: Detección de amenazas a través del uso de un doble canal

4.865 Aufrufe

Veröffentlicht am

Se suele pensar, y afirmar, que una red local es segura por estar detrás de un elemento de red, como un router. Conocer que una red de área local ha sido comprometida es un proceso complejo para un usuario. Estudiar el canal comprometido es fundamental para conocer esta situación, aunque se debe tener en cuenta que si el canal está comprometido se debe utilizar un segundo canal no comprometido. La idea del paper es detallar la utilización de un segundo canal independiente del canal comprometido. El estudio y entendimiento de ataques de red es fundamental para conocer las amenazas.

Veröffentlicht in: Technologie
  • Login to see the comments

Second Factor Web Browsing: Detección de amenazas a través del uso de un doble canal

  1. 1. Resumen- Se suele pensar, y afirmar, que una red local es segura por estar detrás de un elemento de red, como un router. Conocer que una red de área local ha sido comprometida es un proceso complejo para un usuario. Estudiar el canal comprometido es fundamental para conocer esta situación, aunque se debe tener en cuenta que si el canal está comprometido se debe utilizar un segundo canal no comprometido. La idea del paper es detallar la utilización de un segundo canal independiente del canal comprometido. El estudio y entendimiento de ataques de red es fundamental para conocer las amenazas. Keywords – Segundo factor, Web browsing, segundo canal, WiFi, Internet, ARP Spoofing, DNS Spoofing, HSTS, Cryptojacking I. INTRODUCCIÓN La proliferación de las redes en entornos caseros y empresariales no ha hecho más que aumentar. En un entorno de red existen diferentes tipos de amenazas de ámbito local. Los ataques de red son cada vez más complejos y, por ello, se necesita un mayor conocimiento de las amenazas de este ámbito. Existe un gran ecosistema de ataques de red que pueden afectar a las máquinas en un ámbito local y/o externo: ARP Spoofing[1], DNS Spoofing[2], Cryptojacking[3], suplantación del certificado, SSL Strip 2[4] o ataques a las cabeceras HSTS[5], etcétera. La detección de este tipo de ataques sobre un canal comprometido puede no ser sencillo, ya que si éste está comprometido cada acción puede ser manipulada. Por ello, es de vital importancia la observación de la potencial amenaza en un canal alternativo, reduciendo drásticamente la posibilidad de tener el segundo canal comprometido. El ataque ARP Spoofing consiste en un ataque a nivel de enlace en el que se ‘envenena’ la caché ARP de una máquina para que su relación dirección IP – dirección MAC no sea cierta. El objetivo del atacante es lograr que cuando la máquina con la caché ‘envenenada’ quiera enviar el tráfico a una máquina adyacente en la red, su entrada en la caché ARP indica que debe enviarse a una dirección MAC que no corresponde con su receptor legítimo. De este modo, existe una máquina que pueda visualizar el tráfico, ya que éste le llega directamente de la víctima. El ataque DNS Spoofing es similar al anterior, salvo que el ‘envenenamiento’ se produce en la capa de aplicación, en el protocolo de resolución de nombres de dominio, DNS. El atacante llevará un ataque de red, el cual se puede realizar de diferentes formas, con el que la resolución de un dominio quedará asociada en la caché de la víctima a una dirección IP que no se corresponde originalmente con el dominio. De esta forma se puede manipular la navegación de un usuario y redirigirles a sitios de phishing o realizarle ataques de Evilgrade[6], entre otros. El cryptojacking consiste en el minado de criptomonedas desde el navegador de la víctima. Cuando una víctima accede a un sitio web y éste tiene algún componente Javascript que realiza este tipo de acciones sin consentimiento del usuario, se estaría ante un cryptojacking. La detección puede ser algo, relativamente, sencillo. La suplantación del certificado es un tipo de ataque que desemboca en un Man in the Middle. En otras palabras, cuando el atacante consiste comprometer la comunicación de una víctima para poder inyectar o insertar un certificado digital no legítimo en la comunicación, se puede obtener como resultado el compromiso de la comunicación, aunque ésta vaya cifrada. La técnica del SSL Strip[7] es una técnica que, inicialmente, fue creada por el investigador Moxie Marlinspike en el año 2009. Con la aparición de la protección HTTP Strict Transport Security o HSTS, ésta técnica dejó de ser funcional, siempre y cuando el HSTS esté habilitado en el servidor. La técnica SSL Strip 2 es una evolución de la técnica SSL Strip. SSL Strip 2 se aprovecha, cómo ocurre con SSL Strip, del intento de la primera conexión contra un dominio en el que no se hace uso del protocolo HTTPs explícitamente. Aprovechando que la primera conexión se realiza por HTTP, se puede ‘engañar’ al usuario para que piense que la comunicación circula por protocolo seguro. SSL Strip 2 tiene en cuenta varios detalles como la necesidad evitar que la cabecera STS o Strict- Transport-Security llegue a la víctima. Chema Alonso1 , Equipo CDO - Telefónica2 , Laboratorio de Innovación ElevenPaths3 ElevenPaths, Telefónica Digital España chema@11paths.com1 , pablo.gonzalez@11paths.com2 , labs@11paths.com3 Second Factor Web Browsing: Detección de amenazas a través del uso de un doble canal
  2. 2. II. ESTADO DEL ARTE La utilización de los segundos canales como vías para asegurar una autorización o una comunicación no es nuevo. El SMS es, en sí mismo, un canal de comunicación que envía texto o imágenes, en el caso de los MMS. La generación de utilizar el SMS como un mecanismo de comunicación más complejo y que proporcione una capa alternativa a la capa de transporte utilizada en Internet es algo viable. Esta idea se puede observar en la patente de Sybase Inc [8]. Tomar un paquete TCP y codificarlo para poder enviarlo en un SMS es una idea que permite enviar TCP, con lo que ello encapsule, sobre un mensaje SMS. Realmente, se necesitarían varios SMS, normalmente, para poder enviar un solo paquete TCP. Una implementación sobre la posibilidad de utilizar el SMS como un mecanismo de comunicación en capa de transporte similar al funcionamiento de TCP es SMS Stack [9]. SMS Stack es una librería Open Source que dispone de un SDK para diferentes lenguajes de programación. Figura 1: Trama de transporte de SMS Stack SMS Stack proporciona una capa de abstracción al desarrollador, tal y como se puede observar en la figura 1. El protocolo más cercano a la aplicación que envía y recibe se encapsularía en el apartado Data. Tecnologías como Latch[10] pueden encontrarse con la necesidad de realizar acciones, incluso cuando no hay Internet. Para resolver este problema se aplicaron soluciones de segundo canal independiente del primero. En este caso, la utilización del envío de SMS para abrir o cerrar un Latch es una posible solución. El canal SMS es, hoy en día, un elemento muy utilizado como canal alternativo para comprobar, verificar o autorizar acciones. El servicio SafePost[11] permite publicar en Twitter[12] o enviar emails a través de Gmail[13] u Outlook[14] a través del envío de SMS a un servidor, el cual se encarga de transforma el mensaje enviado por un canal a una acción a través del canal de Internet. Es un ejemplo de uso de segundo canal, el cual muestra las infinitas posibilidades del SMS hoy en día. Otro ejemplo de segundo canal, en este caso para mantener la conectividad o full communication, es la del chat de Movistar Team[15]. El chat envía los mensajes vía conexión a Internet, salvo cuando el dispositivo se queda sin datos. En ese caso, el envío de mensajes y comunicación se realiza a través del envío de SMS. En este caso, el segundo canal es un ejemplo de búsqueda de conectividad máxima y optimización de recursos. Otro caso en el que maximizar la conectividad se puede observar en el caso de uso sobre IoT o Internet of Things. La amenaza constante de la denegación de servicio a la que se enfrentan millones de dispositivos puede apoyarse en una solución basada en un segundo canal. La utilización de un segundo canal a través del SMS para poder conectar con dispositivos que han quedado aislados es una posibilidad real. Además, se suele utilizar para casos de elementos críticos de gestión, por ejemplo, ascensores, que deben proporcionar mecanismos secundarios para poder llegar a ellos, en caso de caer la conexión principal. Esto también ocurre con dispositivos de alamas comerciales. El concepto de segundo canal no está basado únicamente en el SMS. El medio por el que un usuario se conecta a Internet es fundamental para diferenciar canales. En un dispositivo móvil el mismo tráfico puede salir, generalmente, por dos interfaces de red diferentes. La red a la que se conecta la interfaz A puede estar comprometida, mientras que la red a la que se conecta la interfaz B puede no estarlo. III. PROPUESTA El riesgo de ataques de producidos o ejecutados en la red local o ataques al end-point que llegan a la máquina a través de canales cifrados o que no son detectados por una solución EDR o Endpoint Detection and Response. En estos casos, además de disponer de un entorno fortificado, se propone realizar una revisión de mensajes de alerta, detalles de conexiones, etcétera. La propuesta es navegar de forma conjunta por el segundo canal para ver qué ocurre en el equipo. Disponiendo de una conexión vía Bluetooth+2G / 3G o 4G a Internet se dispone de un segundo canal en todo momento y en todos los equipos. Es decir, el equipo del usuario está conectado a Internet por cable o WiFi, pero, además, tiene una conexión a través del Bluetooth del dispositivo con un elemento externo, que puede ser un dispositivo móvil, y hace una “copia” del tráfico. En otras palabras, el tráfico sale por el primer canal, el canal por defecto del equipo, y por el segundo canal. El segundo canal realizará las comprobaciones adecuadas para verificar
  3. 3. que el tráfico del usuario no está afectado por algún tipo de ataque de red o al endpoint. Las comprobaciones se pueden realizar en el propio dispositivo móvil. De esta forma se podría llevar la solución en todo momento con el equipo, ya que sería una solución móvil independientemente de la ubicación. La idea maneja la posibilidad de utilizar un servicio cloud para poder comprobar el tráfico que llega por el segundo canal. Ambas arquitecturas tienen ventajas e inconvenientes. Figura 2: Arquitectura propuesta simplificada Disponer de toda la lógica en el cloud simplifica la construcción, pero incrementa el número de elementos del sistema que podría ser atacado en un posible esquema de DDoS al servidor. Con este doble canal utilizando una conexión a Internet vía red WiFi o Ethernet, y un segundo canal vía Bluetooth más una conexión 3G/4G se podría realizar dos conexiones al mismo servidor desde puntos diferentes, es decir, utilizando dos redes distintas. La utilización de un doble canal tiene cierta similitud con el doble factor de autenticación en otros sistemas, dónde se busca que el atacante deba vulnerar dos elementos distintos. De esta forma se logra aumentar la dificultad de que ocurran las dos circunstancias, reduciendo la probabilidad de que se materialice la amenaza. Las respuestas que se obtiene a través del primer canal de comunicación deben ser similares o, prácticamente, idénticas a las del segundo canal. Si las propiedades no son similares, se deberá generar una alerta porque el usuario se encontrará ante la materialización de una amenaza. Con esta propuesta se permite detectar ataques de red en el canal primario, por ejemplo, un DNS Spoofing, un ataque de phishing, un dominio marcado en una lista negra como peligroso, ataques de bypass HSTS, etcétera. Para ello, solo se necesita conocer lo que se está recibiendo como respuesta en el canal primario y hacer una comprobación con lo recibido en el canal secundario. IV. ARQUITECTURA La arquitectura de esta solución de segundo factor para las respuestas obtenidas en el navegador no es compleja, pero dispone de varios elementos que serán expuestos a continuación. El equipo que se quiere fortificar con la solución de doble canal de verificación de respuestas debe disponer de una extensión en el navegador. Esta extensión se encarga de capturar las cabeceras HTTP y datos del DOM de la página que se ha obtenido de respuesta del servidor. La extensión se comunica con un agente que se instala en el equipo, el cual proporciona datos diferentes como, por ejemplo, tablas ARP, datos DNS, etcétera. En otras palabras, esta información se obtiene utilizando dos elementos: • Extensión de navegador. Para el caso de la prueba de concepto se ha utilizado Google Chrome. Este elemento permite extraer la información que se necesita del DOM o Document Object Model y es enviada al agente. Además, recibirá del agente las órdenes de bloquear o no bloquear la sesión de navegación con un mensaje de alerta. • Agente en el sistema. Este agente se ha escrito para la prueba de concepto en NodeJS. El agente es el encargado de establecer la conexión vía Bluetooth, es decir, con el segundo canal de comunicación. Envía información recibida de la extensión del navegador al servicio cloud o 2FWB. El servicio cloud evalúa la información y realiza las peticiones necesarias para la comprobación. Una vez se ha realizado el proceso se envía al agente la información adecuada para bloquear o no, en caso de haberse detectado un ataque de red. Con la arquitectura propuesta se automatiza las verificaciones ante ciertos ataques a los que la red del usuario puede estar expuesto. Se ha escogido una conexión Bluetooth sin Low Energy y utilizar un agente debido a varias circunstancias que se enuncian a continuación: • Volumen de datos. Con el protocolo BLE o Bluetooth Low Energy, el volumen de datos que se puede enviar está limitado para evitar un gran consumo de energía. En este caso, la arquitectura
  4. 4. de la prueba de concepto necesita velocidad para enviar las cabeceras HTTP y el DOM. • Datos de red del sistema. Para poder detectar ciertos ataques como ARP Spoofing o ataques MITM o Man in the Middle en IPv6 con SLAAC se necesita información del sistema operativo, así que se necesitaba un agente en el sistema. Figura 3: Arquitectura de la solución 2FWB I. FORMATO DE PETICIONES Y RESPUESTAS El formato de intercambio de información entre el agente y el dispositivo intermedio vía Bluetooth es muy sencillo. Se ha utilizado JSON como formato de intercambio, teniendo dos tipos de mensajes. Los mensajes de petición que informan de las peticiones y respuestas que se están realizando y obteniendo desde el navegador. Los mensajes de respuesta son los producidos por la aplicación que hay en el cloud y proporcionan al agente la información concreta sobre si existe alguna regla de detección que se haya disparado. Se tiene que diferenciar que un mensaje de petición y otro de respuesta no es lo mismo que las peticiones y respuestas que hace el navegador. Los datos referentes a la petición y respuesta obtenida por el navegador se envían en un mensaje de petición a la aplicación 2FWB en el cloud. Ésta evaluará lo que ocurre en esa comunicación y generará un mensaje de respuesta, con el formato que se visualizará más adelante. En la siguiente imagen se puede visualizar que hay varios campos en los mensajes de petición. Destacan varios como, por ejemplo, el nombre del dominio, el ID de la petición y la pestaña en la que se está visualizando el contenido en el navegador. Después se puede visualizar el contenido, desde el certificado hasta los headers HTTP. Figura 4: Formato del mensaje de petición a 2FWB El formato de respuesta se puede visualizar en la siguiente figura. Se puede ver un identificador que debe encajar con el de la petición, el identificador de la pestaña dónde se debe actuar en caso de existir alguna amenaza en dicha navegación, el resultado de la operación, es decir, si se debe bloquear o permitir la navegación y los datos de las reglas. En este último apartado se puede entender que la escalabilidsd de reglas de detección es realmente sencilla y posible. Figura 5: Formato del mensaje de respuesta de 2FWB
  5. 5. V. DETECCIÓN DE AMENAZAS Para las pruebas realizadas de detección de amenazas o de ataques en red y el endpoint se ha utilizado una máquina con distribución Kali Linux. Se ha utilizado la herramienta Bettercap para poder ejemplificar cada una de las amenazas expuestas en la introducción. Cuando hay una amenaza detectada por el agente, el mensaje de respuesta que le llega desde el 2FWB tiene alguna regla disparada a true, se mostrará una imagen que reescribe el DOM de la pestaña de navegación afectada. Si el ataque es de red entonces se abrirá una nueva pestaña y se mostrará el mensaje. Figura 6: Detección de ataque contra el usuario utilizando el 2FWB En el siguiente cuadro se muestra las detecciones actuales de este sistema. Los mensajes de alerta mostrados son idénticos al de la figura 6, salvo que cambia el mensaje. Si el usuario estuviera ante varios ataques, en conjunto, se mostraría la alerta identificando cada uno de los ataques. Nombre ataque ¿Detectado? ARP Spoofing Sí DNS Spoofing Sí Certificado falso (MITM) Sí Bypass HSTS (SSL Strip 2) Sí Ejecución de Cryptojacking Sí Tabla 1: Tabla resumen de ataques detectados en las pruebas con Bettercap VI. CONTROL PARENTAL Tras la arquitectura comentada se puede visualizar una opción más y es la posibilidad de utilizar la arquitectura como control parental. La posibilidad de visualizar los dominios que son visitados por el usuario y poder pasarlos por el agente y, de este modo, por una lista blanca o negra permite la creación de un control parental. La funcionalidad del control parental se lleva a cabo de una manera similar a la detección de la amenaza, aunque requiere de una interacción mínima por parte del usuario que supervisa la navegación. El usuario supervisor podría crear una lista blanca de sitios a las que se puede acceder o, por el contrario, ir creando una lista negra en función de la navegación. Sea como sea la política escogida se podrá bloquear la navegación del usuario. Figura 7: Denegación debida a la política del control parental En el instante que el agente envía las peticiones realizadas por el usuario en el navegador, la app cloud puede indicar a un usuario supervisor que acción realizar. Al igual que veíamos con el ejemplo de las amenazas, se puede proporcionar un valor control_parental : [true | false] para un dominio concreto. De este modo la entrada referente a ese dominio queda actualizada en la lista de control parental y el agente bloqueará el contenido de la web. El usuario visualizará un mensaje como el de la figura 7. VII.CONCLUSIONES La idea de utiliza una arquitectura 2FWB es poder disponer de una solución móvil, utilizable en un entorno estático como dinámico. La idea original era poder detectar amenazas a las que se enfrenta un usuario cuya red de datos se encuentra comprometida, tanto en IPv4 e IPv6. A esto, se le ha sumado la posibilidad de hacer un control parental sobre los dominios que el usuario visualiza. La solución es válida para el ámbito móvil, ya que estando de viaje o en cualquier sitio diferente de un hogar, gracias al uso del terminal móvil como punto intermedio que recibe vía Bluetooth los mensajes y los puede enviar vía 3G/4G a la app cloud, se puede utilizar en cualquier ubicación. Los resultados obtenidos han sido aceptables en lo que a navegación, velocidad y tasa de detección se refiere. Es una prueba de concepto funcional y que permitiría mejorar la seguridad de un entorno personal y empresarial.
  6. 6. VIII. REFERENCIAS [1] “Man in the Middle: ARP Spoofing”. https://www.flu- project.com/2011/01/man-in-middle_778.html [2] “DNS Spoofing”. https://www.welivesecurity.com/la- es/2012/06/18/dns-spoofing/ [3] “Cryptojacking. Coinhive y el mercado legal {e ilegal} de la minería de criptodivisas”. http://www.elladodelmal.com/2018/09/coinhive-y-el- mercado-legal-e-ilegal-de.html [4] “Ataques man in the middle a HSTS: SSLStrip 2 & Delorean”. http://www.elladodelmal.com/2016/03/ataques- man-in-middle-hsts-sslstrip-2.html [5] “Bypass HSTS”. http://www.pentester.es/2015/10/delorean.html [6] “Evilgrade”. https://github.com/infobyte/evilgrade [7] “SSL Strip”. https://www.flu-project.com/2011/04/ssl- strip_24.html [8] David L. Clegg. “TCP Over SMS”. https://patents.google.com/patent/US8099115B2/en https://patentimages.storage.googleapis.com/20/95/71/d273c5 b222b419/US8099115.pdf [9] Chema Alonso, Pablo González, Lucas Fernández y Francisco Ramírez “SMS Stack”. https://es.slideshare.net/elevenpaths/stack-sms y https://github.com/ElevenPaths/SDK-SMS-Stack [10] https://latch.elevenpaths.com [11] https://safepost.luca-d3.com [12] https://twitter.com [13] https://gmail.com [14] https://outlook.com [15] https://www.elladodelmal.com/2018/12/el-big-data-y-la- ia-al-servicio-de.html

×