Vazamento de WebRTC

Um vazamento de WebRTC é uma vulnerabilidade em navegadores que permite a um site descobrir o endereço IP real de um usuário, contornando servidores proxy ou VPNs ao consultar diretamente as interfaces de rede por meio dos mecanismos STUN/TURN do WebRTC. Essa exposição ocorre porque o WebRTC, projetado para comunicação em tempo real, muitas vezes usa conexões UDP com servidores STUN (Session Traversal Utilities for NAT) e TURN (Traversal Using Relays around NAT) para estabelecer conexões diretas ponto a ponto, e essas requisições podem não passar pelo proxy configurado no navegador.

Entendendo o WebRTC e sua arquitetura

WebRTC (Web Real-Time Communication) é um projeto de código aberto que permite comunicação de voz, vídeo e dados em tempo real diretamente entre navegadores e outras aplicações cliente. Ele possibilita a transferência de dados ponto a ponto sem exigir servidores intermediários, reduzindo significativamente a latência e a carga de servidor em aplicações como videoconferência, compartilhamento de arquivos e transmissão ao vivo.

Os componentes principais do estabelecimento de conexão do WebRTC incluem:

• Servidor de sinalização: usado para trocar metadados (por exemplo, mensagens de controle de sessão, configuração de rede, capacidades de mídia) entre os peers antes que uma conexão direta seja estabelecida. O processo de sinalização em si não é padronizado pelo WebRTC e pode usar vários protocolos (por exemplo, WebSocket).
• ICE (Interactive Connectivity Establishment): framework que permite aos peers descobrir e estabelecer conexões diretas. O ICE usa servidores STUN e TURN para encontrar o melhor caminho de comunicação possível.
• Servidor STUN: ajuda os peers a descobrir seu endereço IP público e o tipo de NAT atrás do qual estão. Quando um cliente atrás de um NAT envia uma requisição a um servidor STUN, o servidor responde com o endereço IP público e a porta do cliente, como vistos a partir da internet.
• Servidor TURN: usado quando uma conexão direta ponto a ponto não é possível (por exemplo, devido a NATs restritivos ou firewalls). Um servidor TURN atua como retransmissor, encaminhando todo o tráfego entre os peers.

O aspecto crítico para o vazamento de IP é como o ICE reúne "candidatos" – possíveis endereços de rede e portas que podem ser usados para comunicação. Esses candidatos incluem:

• Candidatos host: endereços IP locais (por exemplo, 192.168.1.100, 10.0.0.5) da máquina do usuário.
• Candidatos server reflexive: o endereço IP público e o mapeamento de porta alocados pelo roteador NAT, descobertos por meio de um servidor STUN.
• Candidatos relayed: endereços IP e portas em um servidor TURN, usados quando a conexão direta não é possível.

O mecanismo do vazamento de WebRTC

Quando um navegador inicia uma conexão WebRTC, ele usa APIs JavaScript para consultar ao sistema operacional as interfaces de rede locais e, em seguida, executa requisições STUN para descobrir seu endereço IP público. Essas requisições STUN normalmente são baseadas em UDP e frequentemente são feitas diretamente pelo navegador ou pela biblioteca WebRTC subjacente, contornando as configurações de proxy HTTP/SOCKS definidas para o tráfego web geral.

O objeto RTCPeerConnection do navegador enumera diretamente os endereços IP locais e envia requisições de binding STUN. As respostas dos servidores STUN incluem o endereço IP público do cliente. Essa informação, incluindo tanto os candidatos de IP local quanto os públicos, fica então disponível para o peer remoto (ou, o que é crítico, para o site que hospeda a aplicação WebRTC) por meio do processo de troca de candidatos ICE.

Mesmo que um proxy ou VPN esteja em uso, o motor WebRTC do navegador ainda pode conseguir fazer essas conexões diretas e sem proxy a servidores STUN, ou consultar diretamente as interfaces de rede locais, revelando o IP verdadeiro do usuário.

Exemplo: divulgação de IP via JavaScript

Um site malicioso ou de diagnóstico pode usar poucas linhas de JavaScript para iniciar uma conexão WebRTC e extrair esses candidatos ICE.

// Este é um exemplo simplificado, apenas para fins ilustrativos.
// A exploração no mundo real envolve uma coleta de candidatos mais complexa.

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;
                // Exemplo de string 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úblico via 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 os candidatos ICE foram coletados
                if (candidates.length > 0) {
                    resolve(candidates);
                } else {
                    reject(new Error('No WebRTC IP candidates found.'));
                }
            }
        };

        pc.createDataChannel(''); // É preciso um data channel para disparar a coleta de candidatos
        pc.createOffer()
            .then(offer => pc.setLocalDescription(offer))
            .catch(reject);
    });
}

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

Esse código JavaScript inicia uma RTCPeerConnection e escuta eventos onicecandidate. Cada evento contém uma string de candidato que inclui um endereço IP (local, público via STUN ou retransmitido via TURN). Um site pode analisar esses candidatos para extrair os endereços IP reais.

Identificando um vazamento de WebRTC

Para determinar se uma configuração de proxy está vulnerável a vazamentos de WebRTC, é possível usar ferramentas online:

1. Acesse um serviço de teste de IP: navegue até sites como ipleak.net ou browserleaks.com/webrtc enquanto estiver conectado pelo proxy.
2. Compare os IPs informados:
   • IP do proxy: é o endereço IP que o serviço de proxy deve apresentar à internet.
   • IP do WebRTC: esta seção lista os endereços IP descobertos via WebRTC.
   • Seu IP real: é o seu endereço IP público de verdade, que idealmente deveria estar oculto.

Se a seção "IP do WebRTC" exibir o seu endereço IP público real, há um vazamento de WebRTC. Se exibir o IP da sua rede local (por exemplo, 192.168.x.x ou 10.x.x.x), isso indica que o navegador está enumerando interfaces locais, o que pode não expor diretamente o seu IP público, mas ainda assim revela a configuração interna da rede.

Estratégias de mitigação

Mitigar vazamentos de WebRTC exige ações específicas, já que configurações padrão de proxy muitas vezes não bastam.

Configuração do navegador e extensões

Navegadores diferentes oferecem níveis distintos de controle sobre o WebRTC:

• Mozilla Firefox:

  • Digite about:config na barra de endereços.
  • Procure por media.peerconnection.enabled e defina o valor como false. Isso desativa o WebRTC por completo, o que pode quebrar algumas aplicações web legítimas.
  • Como alternativa, procure por media.peerconnection.ice.no_host_candidates e defina como true. Isso impede que o navegador exponha endereços IP locais.
  • Procure por media.peerconnection.ice.default_obfuscate_host_addresses e defina como true. Isso ofusca os endereços IP locais informados pelo WebRTC.

• Google Chrome / navegadores baseados em Chromium:

  • O Chrome não oferece flags de configuração diretas em chrome://flags para desativar completamente o WebRTC sem afetar outras funcionalidades do navegador.
  • Extensões: instale uma extensão de navegador feita para bloquear vazamentos de WebRTC, como a "WebRTC Network Limiter" ou o "uBlock Origin" com filtros específicos. Essas extensões geralmente modificam o comportamento da API WebRTC do navegador para impedir a exposição direta do IP.
  • A extensão "WebRTC Network Limiter" funciona configurando o Chrome para usar apenas "mDNS host candidates" ou "proxy-only ICE candidates", limitando efetivamente os tipos de candidatos coletados e compartilhados.

• Opera:

  • O recurso de VPN integrado do Opera às vezes inclui proteção contra vazamentos de WebRTC. Quando ativado, ele roteia o tráfego WebRTC pela VPN. Verifique as configurações em Settings > Privacy & security > VPN.

Controles no nível do sistema operacional

Embora menos precisos, controles no nível do SO podem restringir o tráfego WebRTC:

• Regras de firewall: bloqueie o tráfego UDP de saída em portas STUN/TURN comuns (por exemplo, 3478, 19302-19309). Isso pode impedir que requisições STUN cheguem a servidores externos, mas também pode quebrar funcionalidades WebRTC legítimas.
• Gerenciamento de interfaces de rede: em alguns cenários, desativar adaptadores de rede específicos pode impedir que seus endereços IP sejam enumerados, mas isso é geralmente impraticável no uso diário.

Proxy vs. VPN na proteção contra vazamentos de WebRTC

A diferença fundamental no modo de operação de proxies e VPNs afeta a capacidade de cada um de evitar vazamentos de WebRTC.

Uma VPN criptografa e roteia todo o tráfego de rede do dispositivo por um túnel seguro, incluindo o tráfego UDP gerado pelas requisições STUN do WebRTC. Isso garante que o único endereço IP exposto a servidores STUN externos seja o IP do servidor VPN, evitando efetivamente um vazamento de WebRTC. Proxies em nível de navegador, por outro lado, operam em um nível mais alto e podem rotear apenas o tráfego TCP, deixando as conexões UDP do WebRTC se estabelecerem diretamente.

Para uma proteção robusta contra vazamentos de WebRTC e privacidade abrangente, uma solução de VPN para todo o sistema costuma ser mais eficaz do que um proxy específico do navegador. Ao usar um proxy, configurações específicas do navegador ou extensões são obrigatórias para impedir que o WebRTC exponha o endereço IP real.