RedWave Team : 12 noviembre 2025 14:49
Mucha gente cree que acceder solo a sitios HTTPS es suficiente para garantizar la seguridad al navegar en redes Wi-Fi no seguras. Alerta de spoiler: esta creencia es una falsa sensación de seguridad.
HTTPS (Protocolo de transferencia de hipertexto seguro) utiliza protocolos de cifrado como TLS para proteger la comunicación entre el navegador y el sitio web, garantizando la confidencialidad e integridad de los datos.
Si bien HTTPS ofrece una protección significativa sobre HTTP.
En este artículo de nuestra columna sobre WiFi , mostraremos cómo esta protección por sí sola no es suficiente, especialmente en entornos inseguros como las redes Wi-Fi abiertas.
A pesar del cifrado que proporciona el protocolo HTTPS, la red abierta y el fácil acceso a la información por parte de los atacantes nos exponen a:
Como se ha escrito en varios artículos, los hackers pueden explotar diversas técnicas para eludir o comprometer la protección HTTPS, entre ellas:
Comencemos diciendo que, según nuestras pruebas y análisis de alboratioro, uno de los ataques más insidiosos de los últimos años, el SSL Stripping , ha demostrado ser mucho menos efectivo.
Introducido en 2009 por Moxie Marlinspike , este ataque tenía como objetivo transformar una conexión HTTPS segura en una conexión HTTP simple, despojando al usuario de la protección criptográfica sin que se diera cuenta.
En la práctica, el atacante se insertó entre el navegador y el sitio web —un clásico ataque de intermediario— interceptando las comunicaciones y modificándolas sobre la marcha, con la capacidad de leer y manipular todo lo que pasaba a través de ellas.
Para contrarrestar este tipo de ataque, en 2012 se introdujo el mecanismo HTTP Strict Transport Security (HSTS). Mediante la cabecera Strict-Transport-Security, un servidor puede indicar al navegador que acceda al sitio exclusivamente a través de conexiones HTTPS durante un periodo de tiempo determinado. Esto impide que el navegador realice solicitudes HTTP inseguras al sitio, lo que reduce significativamente la superficie de ataque para la eliminación de SSL.
Imagina HSTS como una puerta electrónica: una barrera digital que solo se abre si cumples los requisitos necesarios; en este caso, una conexión HTTPS. Si intentas pasar con una conexión HTTP sin cifrar, la barrera permanece cerrada. Acceso denegado.
El sitio web comunica una regla específica al navegador mediante una simple cabecera HTTP:
«Para acceder aquí, solo se puede usar HTTPS, siempre. Cualquier otro método está bloqueado.»
Una vez recibido este comando, el navegador lo almacena y, a partir de ese momento, rechaza cualquier conexión no segura a ese sitio. Ni siquiera el usuario puede forzarlo: el acceso permanece cerrado para cualquiera que no cumpla con los requisitos de seguridad.
Una limitación del HSTS es que su eficacia depende de que el usuario haya visitado previamente el sitio mediante HTTPS. Para mitigar este problema, los principales navegadores mantienen una lista interna de sitios «autorizados» a los que siempre se debe acceder mediante HTTPS en la primera visita. Es como si esos sitios tuvieran una credencial electrónica preconfigurada: el acceso seguro está garantizado desde el principio.
Sin embargo, esta lista no puede incluir todos los sitios web existentes, lo que deja un margen de vulnerabilidad para los sitios no incluidos.
Por eso, en los sitios que no están incluidos en esa lista y no configuran HSTS correctamente, la barrera puede permanecer activa . En ese caso, un atacante aún podría intentar una degradación forzando una conexión HTTP mediante técnicas como la eliminación de SSL o la suplantación de DNS.
Además de lo anterior, las configuraciones incorrectas pueden exponer los sitios web a riesgos adicionales. Por ejemplo, si un sitio web no implementa HSTS correctamente o no está incluido en la lista de navegadores predeterminados, un atacante aún podría intentar un ataque de eliminación de SSL. Por lo tanto, es fundamental que los sitios web configuren HSTS correctamente y que los usuarios sean conscientes de los riesgos asociados con las conexiones inseguras.
HSTS es una herramienta potente, pero no mágica . Funciona muy bien, pero solo si se cumplen los siguientes criterios:
La adopción de HTTPS y HSTS ha reducido significativamente la efectividad de los ataques de eliminación de SSL. Sin embargo, la seguridad total depende de una configuración adecuada del servidor y de la concienciación de los usuarios. Es fundamental que los sitios web implementen HSTS correctamente y que los usuarios presten atención a la seguridad de sus conexiones.
La seguridad absoluta no existe ; ser conscientes de estas limitaciones y comprenderlas nos permite estar menos expuestos, sobre todo en redes abiertas como las públicas o no protegidas. Los atacantes han demostrado repetidamente su ingenio y su capacidad para encontrar siempre la manera de conseguir sus objetivos. En estos dos talleres, queremos destacar dos posibles escenarios que podríamos encontrar al conectarnos a una red abierta:
Nota: Todas las simulaciones se realizan en un entorno de laboratorio, sin involucrar redes ni usuarios reales.
Comencemos con una breve mención de la suplantación de ARP , que utilizaremos en ambos laboratorios y que se usa con frecuencia en redes no seguras.
La suplantación de ARP (o envenenamiento de ARP) es una técnica de ciberataque que explota las vulnerabilidades del Protocolo de Resolución de Direcciones (ARP) para asignar la dirección MAC del atacante a la dirección IP de otro dispositivo en la misma red local.
En pocas palabras, el atacante envía mensajes ARP falsificados a través de la red, convenciendo a otros dispositivos (por ejemplo, una computadora víctima y el enrutador) de que la dirección MAC del atacante coincide con la dirección IP de la víctima (o del enrutador).
En resumen, podemos ver en la tabla ARP del dispositivo de la víctima, antes del ataque ARP, la dirección MAC correcta asociada con la IP de la puerta de enlace.
En los sistemas Windows, “arp -a” permite ver la tabla arp actual creada a partir de comunicaciones anteriores con los hosts.
Una vez iniciado el ataque de suplantación de ARP, esta MAC asociada con la IP de la puerta de enlace fue reemplazada por la del atacante.
A partir de ahora, todo el tráfico que la víctima intente enviar a la puerta de enlace (192.168.0.1) para llegar a Internet llegará al atacante, quien luego lo reenviará al enrutador original y viceversa.
La víctima ya está siendo atacada y no es consciente del problema.
La suplantación de ARP es uno de los ataques utilizados para realizar un ataque de intermediario (MiTM).
Otra técnica podría ser utilizar la suplantación de DHCP, engañando a los clientes para que utilicen configuraciones DHCP diferentes a las esperadas, incluyendo una puerta de enlace diferente que el atacante puede controlar para interceptar y redirigir el tráfico.
En este laboratorio, analizamos paso a paso un ataque de intermediario (MITM) realizado en una red Wi-Fi desprotegida. El objetivo es simular un escenario real en el que un atacante puede interceptar y manipular el tráfico de la víctima, aprovechándose de la urgencia y la falta de atención del usuario. Todas las operaciones se realizan en un entorno de laboratorio, únicamente con fines formativos.
En este laboratorio, tanto la víctima como el atacante se encuentran en el mismo segmento de red desprotegido, donde no se han implementado técnicas de protección del lado de la red (discutiremos estas mitigaciones en artículos futuros).
Nuestra víctima es un usuario con sistema operativo Windows 11 actualizado con los últimos parches disponibles, que se conecta a una red Wi-Fi abierta. El uso de una red no segura se produce por diversas razones, como ya se analizó en el artículo « Redes Wi-Fi abiertas: un terreno fértil para el cibercrimen ».
Y es precisamente esa necesidad de mantenerse conectados a toda costa lo que se convierte en un arma muy poderosa para los atacantes.
El atacante opera desde una máquina Kali Linux , en la misma red que la víctima, y configura el sistema para interceptar y manipular el tráfico.
El primer paso consiste en habilitar el reenvío de paquetes en Kali, convirtiéndolo en un nodo que reenvía el tráfico entre la víctima y la puerta de enlace real.
sudo sysctl -w net.ipv4.ip_forward=1
Utilizamos iptables para reenviar todo el tráfico saliente en los puertos 80 (HTTP) y 443 (HTTPS) al puerto local 8080, donde un proxy estará escuchando.
sudo iptables -t nat -A PREROUTING -p tcp –dport 80 -j REDIRECT –to-port 8080
sudo iptables -t nat -A PREROUTING -p tcp –dport 443 -j REDIRECT –to-port 8080
Para interceptar las solicitudes de nombres de dominio y forzarlas a la IP del atacante, configuramos el secuestro de DNS con dnsmasq.
Editando o creando el archivo de configuración:
sudo nano /etc/dnsmasq.conf
Con el siguiente contenido:
interfaz=wlan0
no-dhcp-interface=wlan0
interfaces de enlace
privilegio falso
consultas de registro
log-facility=/var/log/dnsmasq.log
dirección=/#/192.168.1.251
Finalmente, iniciamos dnsmasq con:
sudo dnsmasq -C /etc/dnsmasq.conf
A partir de ahora, todas las solicitudes DNS recibidas por la interfaz wlan0 siempre devolverán la dirección IP del atacante ( 192.168.1.251 ), simulando un portal cautivo o un proxy MITM.
Para interceptar el tráfico, el atacante realiza un ataque de suplantación de ARP , haciendo creer a la víctima que su dirección MAC es la de la puerta de enlace.
sudo arpspoof -i wlan0 -t 192.168.1.113 192.168.1.1
Como se ha visto anteriormente, de esta forma, todo el tráfico destinado a la puerta de enlace se desviará a través de la máquina del atacante, que actúa como un intermediario transparente.
Ahora habilitemos mitmproxy , que actuará como un proxy transparente para interceptar e inspeccionar el tráfico HTTP y HTTPS.
sudo mitmproxy –modo transparente –mostrar host –puerto de escucha 8080
Nota: Para este laboratorio seleccionamos “mitmproxy” porque tiene un certificado descargable públicamente que no necesita ser de confianza y, por lo tanto, simplifica la instalación en el cliente de la víctima (http://mitm.it/).
Cuando la víctima se conecta a la red Wi-Fi abierta y sin protección, todo su tráfico termina en la máquina Kali Linux del atacante. Esto, como hemos visto en varios artículos, ya es un problema en sí mismo, pero si la víctima no toma ninguna medida adicional, al menos el tráfico HTTPS estaría a salvo.
Una vez que la víctima abre el navegador e intenta navegar, es redirigida automáticamente a un portal cautivo falso alojado por el atacante.
Como se muestra en la figura con el certificado aceptado y el tráfico que pasa por mitmproxy, el atacante podrá:
En conclusión, este taller representa una valiosa oportunidad para comprender las técnicas históricas de interceptación de redes, explorando su funcionamiento en un entorno controlado y seguro. Analizar estos escenarios implica no solo comprender cómo se produjeron los ataques, sino, sobre todo, comprender cómo prevenirlos y fortalecer la seguridad de nuestras infraestructuras digitales. Solo mediante el estudio práctico y la concienciación podremos construir sistemas más resilientes, capaces de resistir las amenazas pasadas y futuras.
Al igual que HTTP, el Protocolo de Transferencia de Archivos ( FTP ) es ahora obsoleto e inseguro, pero se sigue utilizando en muchas organizaciones para transferir archivos, incluidos datos confidenciales.
Al igual que HTTPS, el protocolo FTPS permite una conexión segura y cifrada entre el cliente y el servidor; esta extensión del protocolo FTP añade cifrado TLS o SSL (que no debe confundirse con SFTP ), de modo que nadie más que el servidor y el cliente pueda acceder al contenido de los datos.
FTP (Protocolo de Transferencia de Archivos) es un protocolo de red estándar que se utiliza para transferir archivos entre un cliente y un servidor a través de una red TCP/IP, como Internet. En la práctica, permite cargar y descargar archivos desde un ordenador remoto.
Esto todavía se utiliza ampliamente para el intercambio de datos.
Por lo tanto, queda claro que estos datos que viajan a través de la red o hacia Internet también deben estar protegidos mediante cifrado.
En este tipo de ataque obligaremos a la víctima a utilizar un protocolo débil, FTP downgrade.
Este ataque puede llevarse a cabo cuando la víctima utiliza un cliente FTP configurado para decidir automáticamente el protocolo más seguro entre los disponibles.
En este ejemplo utilizamos FILEZILLA, donde la configuración predeterminada es que el programa elija automáticamente la conexión segura si está presente.
En este caso, al conectarse normalmente, el cliente se conectará automáticamente a través de TLS, porque entenderá que el servidor FTP ha configurado el protocolo TLS.
En cambio, vemos que el uso de un ataque MiTM (Man In The Middle), en el que un atacante se posiciona en medio de la comunicación, permitirá que la víctima se vea obligada a utilizar el protocolo FTP en texto plano, recuperando así las credenciales de acceso.
Primero, habilite el reenvío de paquetes, lo que convierte al atacante en un enrutador IPv4, de modo que, como veremos más adelante, todo el tráfico entrante de la víctima se reenviará a la puerta de enlace real y viceversa:
echo 1 > /proc/sys/net/ipv4/ip_forward
Instalemos un servidor FTP local en el dispositivo de la víctima. En este ejemplo, también hemos instalado e iniciado FTP y lo hemos configurado para que solo acepte conexiones de texto sin cifrar (sin TLS).
sudo systemctl start pure-ftpd
Realizamos un ataque de suplantación de ARP (lo explicaremos mejor a continuación) mediante el marco MITMf; esto hará que la víctima cambie la dirección MAC asociada con la IP del enrutador, reemplazándola por la de la víctima.
MITMf (Man-In-The-Middle Framework) es una potente herramienta integral para realizar ataques de intermediario (Man-In-The-Middle) y manipular el tráfico de red. Su principal ventaja radica en superar las limitaciones de herramientas anteriores como Ettercap y Mallory, ofreciendo una arquitectura modular y altamente extensible.
MITMf representa una evolución significativa en el panorama de las herramientas MITM, al ofrecer una plataforma potente, flexible y actualizada para el análisis de la seguridad de la red y la simulación de escenarios de ataque.
Utilizaremos el parámetro -i para indicar la interfaz conectada a la red pública, –spoof y –arp para este ataque de envenenamiento arp y finalmente –target y –gateway, como puede imaginar, para las IP de la víctima y la puerta de enlace.
sudo ./mitmf.py -i wlan0 –spoof –arp –target 192.168.0.42 –gateway 192.168.0.1
Como se explicó anteriormente, gracias a la suplantación de ARP, todo el tráfico que la víctima intente enviar a la puerta de enlace para acceder a Internet y al FTP externo, llegará al atacante, quien luego lo reenviará al enrutador original y viceversa.
Todo esto sin que la víctima se dé cuenta de nada.
Ahora, para interceptar el tráfico FTP en tránsito, creamos una regla de preenrutamiento a través de iptables en el dispositivo del atacante, de modo que todo el tráfico enviado por la víctima al puerto 21 se redirija al servidor FTP local del atacante.
sudo iptables -t nat -A PREROUTING -p tcp –puerto-destino 21 -j REDIRECT –puerto-destino 21
Ahora bien, si la víctima se conecta a un servidor FTP a partir de este momento, la autenticación se realizará en el servidor del atacante sin TLS.
En este caso, esta última versión de FILEZILLA advertiría de un problema y de un probable ataque de degradación; otros programas podrían ni siquiera tener esta comprobación y proceder sin advertencia.
Esto se debe a que anteriormente nos conectamos a través de TLS, pero si hubiera sido la primera vez no se habría reportado el problema.
Si la víctima acepta este mensaje sin hacer demasiadas preguntas y procede con la autenticación, el ataque MITMF capturará las credenciales intercambiadas en texto plano, incluyendo la dirección IP del servidor FTP.
También veremos en los registros de FileZilla el mensaje de que estamos utilizando una conexión no segura.
Una consecuencia, además del robo de credenciales, es que si el atacante hubiera configurado un servidor FTP local que pudiera aceptar cualquier credencial transmitida por la víctima, también podría robar cualquier dato que la víctima intentara enviarle.
Obviamente, en este caso, también falta el preenrutamiento del puerto 20 y de algunos puertos pasivos.
Nota: FileZilla informa de la degradación solo si se ha producido previamente una conexión FTPS, pero no siempre bloquea el intento si la configuración está establecida en «conexión automática».
En este laboratorio, demostramos cómo, incluso con protocolos seguros como FTPS, la seguridad puede verse comprometida si no se adoptan configuraciones adecuadas e informadas. Mediante un ataque de intermediario (MITM) y técnicas de suplantación de ARP, fue posible forzar a un cliente FTP, configurado para seleccionar automáticamente el protocolo más seguro disponible, a recurrir a una conexión no cifrada (FTP), exponiendo así las credenciales y los datos transmitidos.
Este escenario también podría ocurrir con los protocolos POP, IMAP y SMTP si el cliente de correo configurara automáticamente el protocolo.
Por lo tanto, es importante prestar atención a las configuraciones del cliente para utilizar únicamente conexiones seguras.
Para reducir los riesgos asociados al uso de redes públicas o no confiables, existen diversas técnicas de mitigación que pueden aplicarse a nivel de infraestructura. Entre las más efectivas se encuentran:
En los próximos artículos, profundizaremos en cada una de estas soluciones, analizando escenarios del mundo real, configuraciones recomendadas y su impacto en la seguridad general de la red.
Como equipo de RedWave, queremos concienciar sobre el peligro de confiar ciegamente en protocolos cifrados o configuraciones predeterminadas, lo que puede generar una peligrosa falsa sensación de seguridad. Hemos visto cómo las conexiones seguras pueden verse comprometidas si las herramientas no están configuradas correctamente o si el usuario desconoce los riesgos.
Las comunicaciones seguras no se tratan solo de usar HTTPS o FTPS, sino de adoptar un enfoque proactivo que incluya configuraciones seguras, capacitación continua y buenas prácticas operativas.
En el próximo artículo, exploraremos el uso de una VPN como una capa adicional de protección en redes no confiables, y en artículos posteriores, analizaremos estrategias de mitigación concretas para reducir la exposición al riesgo incluso en redes problemáticas como el Wi-Fi abierto.
En esta apasionante historia, viajaremos a 1959 al Club de Ferrocarriles en Miniatura del MIT Tech y conoceremos a Steve Russell. Steve fue uno de los primeros hackers y escribió uno de los primeros ...
El significado de » hacker » tiene profundas raíces. Proviene del inglés «to hack», que significa picar, cortar, golpear o mutilar. Es una imagen poderosa: la de un campesino rompiendo terrones ...
Desde las vulnerabilidades de WEP hasta los avances de WPA3 , la seguridad de las redes Wi-Fi ha evolucionado enormemente. Hoy en día, las redes autoprotegidas representan la nueva frontera: sistemas...
Un hallazgo excepcional de los primeros tiempos de Unix podría llevar a los investigadores a los mismísimos orígenes del sistema operativo. En la Universidad de Utah se descubrió una cinta magnét...
Imagina una ciudad futurista dividida en dos: por un lado, relucientes torres de innovación; por el otro, el caos y las sombras de la pérdida de control. Esta no es una visión distópica, sino el p...
