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.
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.
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.
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.
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.
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