Filtración de WebRTC

Una fuga de WebRTC es una vulnerabilidad en los navegadores que permite a un sitio web descubrir la dirección IP real de un usuario, eludiendo los servidores proxy o VPN al consultar directamente las interfaces de red a través de los mecanismos STUN/TURN de WebRTC. Esta exposición ocurre porque WebRTC, diseñado para la comunicación en tiempo real, a menudo utiliza conexiones UDP a servidores STUN (Session Traversal Utilities for NAT) y TURN (Traversal Using Relays around NAT) para establecer conexiones directas peer-to-peer, y estas solicitudes pueden no ser enrutadas a través del proxy configurado del navegador.

Entendiendo WebRTC y su Arquitectura

WebRTC (Web Real-Time Communication) es un proyecto de código abierto que permite la comunicación de voz, video y datos en tiempo real directamente entre navegadores y otras aplicaciones cliente. Permite la transferencia de datos peer-to-peer sin requerir servidores intermedios, reduciendo significativamente la latencia y la carga del servidor para aplicaciones como videoconferencias, intercambio de archivos y transmisión en vivo.

Los componentes clave del establecimiento de conexión de WebRTC incluyen:

• Servidor de Señalización: Se utiliza para intercambiar metadatos (por ejemplo, mensajes de control de sesión, configuración de red, capacidades de medios) entre pares antes de que se establezca una conexión directa. El proceso de señalización en sí no está estandarizado por WebRTC y puede usar varios protocolos (por ejemplo, WebSocket).
• ICE (Interactive Connectivity Establishment): Un marco que permite a los pares descubrir y establecer conexiones directas. ICE utiliza servidores STUN y TURN para encontrar la mejor ruta de comunicación posible.
• Servidor STUN: Ayuda a los pares a descubrir su dirección IP pública y el tipo de NAT detrás del cual se encuentran. Cuando un cliente detrás de un NAT envía una solicitud a un servidor STUN, el servidor responde con la dirección IP pública y el puerto del cliente tal como se ven desde Internet.
• Servidor TURN: Se utiliza cuando una conexión directa peer-to-peer no es posible (por ejemplo, debido a NATs o firewalls restrictivos). Un servidor TURN actúa como un relé, reenviando todo el tráfico entre pares.

El aspecto crítico para la fuga de IP es cómo ICE recopila "candidatos", es decir, posibles direcciones de red y puertos que se pueden usar para la comunicación. Estos candidatos incluyen:

• Candidatos de Host: Direcciones IP locales (por ejemplo, 192.168.1.100, 10.0.0.5) de la máquina del usuario.
• Candidatos Reflexivos del Servidor: La dirección IP pública y el mapeo de puertos asignados por el router NAT, descubiertos a través de un servidor STUN.
• Candidatos Reenviados: Direcciones IP y puertos en un servidor TURN, utilizados cuando la conexión directa no es posible.

El Mecanismo de Fuga de WebRTC

Cuando un navegador inicia una conexión WebRTC, utiliza las API de JavaScript para consultar al sistema operativo las interfaces de red locales y luego realiza solicitudes STUN para descubrir su dirección IP pública. Estas solicitudes STUN suelen basarse en UDP y a menudo son realizadas directamente por el navegador o la biblioteca WebRTC subyacente, eludiendo la configuración del proxy HTTP/SOCKS configurada para el tráfico web general.

El objeto RTCPeerConnection del navegador enumera directamente las direcciones IP locales y envía solicitudes de enlace STUN. Las respuestas de los servidores STUN incluyen la dirección IP pública del cliente. Esta información, incluyendo tanto los candidatos IP locales como los públicos, se pone a disposición del par remoto (o, críticamente, del sitio web que aloja la aplicación WebRTC) a través del proceso de intercambio de candidatos ICE.

Incluso si se utiliza un proxy o una VPN, el motor WebRTC del navegador aún podría realizar estas conexiones directas y sin proxy a los servidores STUN o consultar directamente las interfaces de red locales, revelando la dirección IP real del usuario.

Ejemplo: Divulgación de IP por JavaScript

Un sitio web malicioso o de diagnóstico puede usar unas pocas líneas de JavaScript para iniciar una conexión WebRTC y extraer estos candidatos ICE.

// Este es un ejemplo simplificado con fines ilustrativos.
// La explotación en el mundo real implica una recopilación de candidatos más compleja.

function getWebRTCIPs() {
    return new Promise((resolve, reject) => {
        const pc = new RTCPeerConnection({
            iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
        });
        const candidates = [];

        pc.onicecandidate = (event) => {
            if (event.candidate) {
                const candidate = event.candidate.candidate;
                // Ejemplo de cadena de candidato:
                // "candidate:4234997380 1 udp 2043278322 192.168.1.100 50000 typ host" (IP local)
                // "candidate:4234997380 1 udp 2043278322 203.0.113.45 50000 typ srflx" (IP pública vía STUN)

                const ipMatch = /(?:[0-9]{1,3}\.){3}[0-9]{1,3}/.exec(candidate);
                if (ipMatch && ipMatch[0] && candidates.indexOf(ipMatch[0]) === -1) {
                    candidates.push(ipMatch[0]);
                }
            } else {
                // Todos los candidatos ICE han sido recopilados
                if (candidates.length > 0) {
                    resolve(candidates);
                } else {
                    reject(new Error('No se encontraron candidatos IP de WebRTC.'));
                }
            }
        };

        pc.createDataChannel(''); // Se necesita un canal de datos para activar la recopilación de candidatos
        pc.createOffer()
            .then(offer => pc.setLocalDescription(offer))
            .catch(reject);
    });
}

// Uso:
// getWebRTCIPs().then(ips => console.log('IPs descubiertas:', ips)).catch(error => console.error(error));

Este código JavaScript inicia una RTCPeerConnection y escucha los eventos onicecandidate. Cada evento contiene una cadena de candidato que incluye una dirección IP (local, pública a través de STUN o reenviada a través de TURN). Un sitio web puede analizar estos candidatos para extraer las direcciones IP reales.

Identificando una Fuga de WebRTC

Para determinar si una configuración de proxy es vulnerable a las fugas de WebRTC, se pueden usar herramientas en línea:

1. Visite un servicio de prueba de IP: Navegue a sitios como ipleak.net o browserleaks.com/webrtc mientras está conectado a través del proxy.
2. Compare las IPs reportadas:
   • IP del Proxy: Esta es la dirección IP que el servicio proxy debería presentar a Internet.
   • IP de WebRTC: Esta sección listará las direcciones IP descubiertas a través de WebRTC.
   • Su IP Real: Esta es su dirección IP pública real, que idealmente debería estar oculta.

Si la sección "IP de WebRTC" muestra su dirección IP pública real, existe una fuga de WebRTC. Si muestra su IP de red local (por ejemplo, 192.168.x.x o 10.x.x.x), esto indica que el navegador está enumerando interfaces locales, lo que puede no exponer directamente su IP pública, pero aún revela la configuración de la red interna.

Estrategias de Mitigación

La mitigación de las fugas de WebRTC requiere acciones específicas, ya que las configuraciones de proxy estándar a menudo no son suficientes.

Configuración del Navegador y Extensiones

Los diferentes navegadores ofrecen distintos niveles de control sobre WebRTC:

• Mozilla Firefox:

  • Escriba about:config en la barra de direcciones.
  • Busque media.peerconnection.enabled y establezca su valor en false. Esto deshabilita WebRTC por completo, lo que puede romper algunas aplicaciones web legítimas.
  • Alternativamente, busque media.peerconnection.ice.no_host_candidates y establézcalo en true. Esto evita que el navegador exponga las direcciones IP locales.
  • Busque media.peerconnection.ice.default_obfuscate_host_addresses y establézcalo en true. Esto ofusca las direcciones IP locales reportadas por WebRTC.

• Google Chrome / Navegadores basados en Chromium:

  • Chrome no ofrece banderas de configuración directas en chrome://flags para deshabilitar WebRTC por completo sin afectar otras funcionalidades del navegador.
  • Extensiones: Instale una extensión del navegador diseñada para bloquear las fugas de WebRTC, como "WebRTC Network Limiter" o "uBlock Origin" con filtros específicos. Estas extensiones suelen modificar el comportamiento de la API de WebRTC del navegador para evitar la exposición directa de la IP.
  • La extensión "WebRTC Network Limiter" funciona configurando Chrome para que solo use "candidatos de host mDNS" o "candidatos ICE solo de proxy", limitando efectivamente los tipos de candidatos recopilados y compartidos.

• Opera:

  • La función VPN integrada de Opera a veces incluye protección contra fugas de WebRTC. Cuando está habilitada, enruta el tráfico de WebRTC a través de la VPN. Verifique la configuración en Configuración > Privacidad y seguridad > VPN.

Controles a Nivel del Sistema Operativo

Aunque menos precisos, los controles a nivel del sistema operativo pueden restringir el tráfico de WebRTC:

• Reglas de Firewall: Bloquee el tráfico UDP saliente en puertos STUN/TURN comunes (por ejemplo, 3478, 19302-19309). Esto puede evitar que las solicitudes STUN lleguen a servidores externos, pero también puede romper la funcionalidad legítima de WebRTC.
• Gestión de Interfaz de Red: En algunos escenarios, deshabilitar adaptadores de red específicos puede evitar que sus direcciones IP sean enumeradas, pero esto generalmente no es práctico para el uso diario.

Proxy vs. VPN para la Protección contra Fugas de WebRTC

La diferencia fundamental en cómo operan los proxies y las VPNs afecta su capacidad para prevenir las fugas de WebRTC.

Una VPN cifra y enruta todo el tráfico de red del dispositivo a través de un túnel seguro, incluido el tráfico UDP generado por las solicitudes STUN de WebRTC. Esto asegura que la única dirección IP expuesta a los servidores STUN externos sea la IP del servidor VPN, previniendo eficazmente una fuga de WebRTC. Los proxies a nivel de navegador, por el contrario, operan a un nivel superior y pueden enrutar solo el tráfico TCP, dejando que las conexiones UDP de WebRTC se establezcan directamente.

Para una protección robusta contra las fugas de WebRTC y una privacidad integral, una solución VPN de sistema completo es generalmente más efectiva que un proxy específico del navegador. Al usar un proxy, las configuraciones o extensiones específicas del navegador son obligatorias para evitar que WebRTC exponga la dirección IP real.