Ataques de temporização baseados em WebSockets: como sistemas antifraude escaneiam suas portas locais

Você gostaria de experimentar o Octo Browser com desconto?
Use o código promocional OCTOSCRAPER para obter 30% de desconto em qualquer assinatura. Esta oferta é válida apenas para novos usuários.

Como o WebSocket se torna um scanner local

Primeiro, um pouco de contexto. O WebSocket é um protocolo de comunicação baseado em TCP projetado para a troca de mensagens em tempo real entre um cliente e um servidor.

Originalmente, ele foi criado para viabilizar coisas como jogos de navegador com latência mínima ou indicadores de digitação em tempo real em aplicativos de chat. Mas os desenvolvedores de sistemas antifraude rapidamente perceberam que, se um navegador pode abrir um socket para um servidor remoto, na maioria dos casos nada o impede de tentar se conectar também aos endereços locais do usuário.

Funciona da seguinte forma: assim que a WebPage de destino é carregada — ou quando você faz login —, um script antifraude oculto começa a tentar estabelecer conexões de forma assíncrona. Ele não varre todas as portas possíveis. Em vez disso, investiga o endereço 127.0.0.1 usando uma lista predefinida de portas, como a 9222 para CDP ou portas comumente usadas por clientes locais de VPN e servidores de banco de dados. Na maioria das vezes, essa abordagem funciona.

Por que os navegadores permitem isso

Os navegadores e sistemas operacionais modernos possuem duas características arquitetônicas que tornam isso possível.

1. Ignorando as restrições rígidas de CORS. Se um script antifraude tentasse escanear portas usando uma requisição HTTP comum (via fetch() ou XMLHttpRequest), o navegador bloquearia o acesso à resposta devido às suas medidas de segurança, política de mesma origem, restrições de CORS e regras de conteúdo misto. Os WebSockets funcionam de forma diferente. O protocolo não usa o modelo tradicional de CORS para restringir o acesso às respostas. Em vez disso, envia um cabeçalho Origin, que o servidor pode optar por validar. O simples fato de determinar se uma conexão foi bem-sucedida ou falhou já fornece informações valiosas para análise.

2. O ponto cego do firewall. A interface de loopback (127.0.0.1) desfruta de um nível de confiança excepcionalmente alto dentro do sistema operacional, já que o tráfego enviado do navegador para uma porta local nunca sai da sua interface de rede.

Como resultado, os firewalls integrados do Windows e do macOS normalmente não inspecionam nem filtram essas conexões internas, tratando-as como inerentemente seguras.

Isso dá aos sistemas antifraude um canal legítimo e essencialmente irrestrito para sondar seu ambiente local.

Mas como eles podem saber se uma porta está aberta se as políticas de segurança do navegador os impedem de ler as respostas diretas do sistema?

É aí que entram os ataques de tempo (timing attacks).

Como funciona um ataque de tempo

O sandbox do navegador impõe limitações estritas aos scripts. Devido à Política de Mesma Origem (SOP) e às restrições de CORS, um script não pode simplesmente ler uma resposta de um serviço local ou obter o código de erro exato retornado por uma conexão com falha. Felizmente para um ataque de tempo, ele não precisa disso.

O processo funciona assim:

1. O script inicia um temporizador interno (geralmente usando performance.now()).

2. Ele inicia uma conexão WebSocket:
   new WebSocket('ws://127.0.0.1:9222')

3. O script aguarda o disparo do evento onerror.

4. Assim que o erro ocorre, o temporizador para e o tempo decorrido é calculado.

A chave está em como a pilha de rede do sistema operacional lida com conexões TCP:

1. Se a porta estiver fechada. O sistema operacional rejeita imediatamente o pacote SYN de entrada enviando um pacote TCP RST em resposta. O navegador fecha o socket e aciona o manipulador onerror. Em uma máquina local, isso normalmente leva apenas de 1 a 5 milissegundos.

2. Se a porta estiver aberta. Primeiro, um handshake TCP de três vias completo é concluído. Em seguida, o navegador envia uma requisição HTTP Upgrade para estabelecer uma conexão WebSocket. Mesmo que o serviço escutando naquela porta não seja de fato um servidor WebSocket (por exemplo, um banco de dados ou um daemon SSH), a conexão não é encerrada imediatamente. Em vez disso, ela falha apenas após a incompatibilidade de protocolo ser detectada. O tempo adicional necessário para o handshake e a troca de dados aumenta o atraso para cerca de 10 a 50 milissegundos.

3. Se a porta for filtrada por um firewall. O firewall descarta silenciosamente o pacote SYN em vez de rejeitá-lo. O navegador não recebe resposta do sistema operacional e aguarda até que o tempo limite do sistema expire. Nesse caso, o atraso é medido em segundos em vez de milissegundos.

Os navegadores modernos reduzem intencionalmente a precisão do temporizador para aproximadamente 0,1–1 ms. No entanto, os ataques de tempo de rede não exigem precisão de nanossegundos.

A diferença entre um TCP RST imediato e uma tentativa de conexão atrasada é medida em dezenas de milissegundos, o que é mais do que suficiente para uma detecção confiável.

Sistemas antifraude avançados também levam em consideração fatores como a carga de CPU, a coleta de lixo do JavaScript e o comportamento do sistema operacional, portanto, não dependem de limites codificados fixos.

Em vez disso, o script primeiro executa uma calibração.

Antes de sondar as portas de real interesse, ele tenta se conectar a uma porta deliberadamente aleatória, de número alto e presumivelmente fechada, por exemplo:

ws://127.0.0.1:54321

Isso estabelece um tempo de resposta de referência para uma porta fechada na sua máquina específica naquele momento.

Só então o sistema antifraude compara o tempo de resposta das portas comumente associadas a ferramentas de multicontas com essa referência para identificar anomalias.

Por que os sistemas antifraude se importam com o seu localhost

O objetivo principal de um sistema antifraude é desanonimizar perfis de navegador e detectar multicontas.

A maioria das soluções de navegador antidetecção se concentra fortemente em camuflar impressões digitais de navegadores — Canvas, WebGL, fontes e sinais semelhantes — enquanto presta muito menos atenção à pilha de rede.

Portas locais abertas associadas a ferramentas de automação tornam-se indicadores altamente confiáveis de que uma identidade digital foi falsificada.

O que os algoritmos de pontuação procuram

Os dados de tempo coletados em frações de segundo são enviados ao servidor de pontuação do sistema antifraude.

Lá, o padrão de portas observado é analisado. Dependendo dos resultados, pontos de risco negativos podem ser adicionados à pontuação geral de risco do seu perfil.

Se a porta 9222 estiver aberta, é um forte indício de que o navegador está sendo controlado por meio do Chrome DevTools Protocol (CDP) por frameworks de automação como Puppeteer, Playwright ou Selenium.

Nesse ponto, a emulação de movimento do mouse ou simulação de entrada humana dificilmente ajudará. A sessão pode receber uma pontuação de risco muito alta, resultando desde um desafio por CAPTCHA até o banimento definitivo da conta, dependendo de quão agressivo for o sistema antifraude.

Da mesma forma, se portas como 22 (SSH), 3306 (MySQL) ou portas comumente usadas por aplicativos de proxy local estiverem abertas, é difícil se passar por um dispositivo de usuário comum.

O sistema antifraude provavelmente concluirá que está lidando com uma máquina virtual, com um servidor alugado ou com uma estação de trabalho profissional de multicontas, reduzindo significativamente a confiança atribuída à conta.

Cruzamento de dados e detecção de fazendas de contas

Essa é talvez a maior preocupação para quem gerencia várias contas.

Imagine que você esteja executando 50 perfis de navegador em uma única máquina.

Cada perfil possui:

• uma impressão digital de navegador única;

• um proxy dedicado;

• um endereço IP diferente.

Para os sites externos, eles parecem ser 50 pessoas diferentes. No entanto, o sistema operacional ou servidor subjacente ainda é o mesmo.

Isso significa que os mesmos serviços em segundo plano estão em execução, expondo o mesmo conjunto de portas abertas. Essa combinação única de portas abertas pode efetivamente se tornar uma superimpressão digital.

Um sistema antifraude pode reconhecer que cinquenta usuários supostamente não relacionados compartilham exatamente a mesma configuração de serviço local, altamente incomum. Ele pode então vinculá-los em uma única fazenda de contas e banir silenciosamente (shadow-ban) todo o grupo.

Em outras palavras, ao escanear o localhost, os sistemas antibot podem olhar por trás da sua impressão digital do navegador e revelar a infraestrutura real que alimenta sua estrutura de multicontas.

Como se proteger: isolamento e configuração do firewall

Ao lidar com sistemas antifraude sofisticados, sua estratégia de defesa deve ser baseada nos seguintes princípios:

1. Isole a pilha de rede. Use máquinas virtuais ou containers com ambientes de rede estritamente isolados. Se o navegador for executado em um ambiente totalmente isolado, os ataques de tempo retornarão os tempos de resposta padrão de portas fechadas, pois os serviços em execução na máquina hospedeira estarão fisicamente inacessíveis de dentro do ambiente virtual.

2. Configure seu firewall corretamente. O seu firewall não deve simplesmente bloquear as tentativas de conexão, ele deve rejeitá-las imediatamente. Especificamente, use REJECT, que retorna instantaneamente um pacote TCP RST, em vez de DROP, que descarta silenciosamente os pacotes e força o navegador a esperar por um tempo limite. Uma resposta REJECT imita o comportamento de uma porta naturalmente fechada e, portanto, não parece suspeita para algoritmos de detecção baseados em tempo.

3. Bloqueie totalmente o acesso ao localhost. A abordagem mais radical — mas também a mais eficaz — é impedir completamente que o navegador acesse o localhost. Isso neutraliza imediatamente os scripts antifraude que tentam sondar seu sistema.

No entanto, essa abordagem tem um ponto negativo: alguns aplicativos legítimos, como softwares para chaves de segurança de hardware ou ferramentas de assinatura digital, organizam a comunicação por meio de agentes locais. Perder o acesso a esses serviços pode se tornar, por si só, uma anomalia que contribui para uma pontuação de risco mais alta.

Portanto, existem duas abordagens práticas:

• Filtragem refinada. Permita o acesso apenas a serviços locais confiáveis no nível do firewall ou de extensão do navegador, enquanto rejeita imediatamente (usando REJECT) qualquer tentativa em segundo plano de estabelecer conexões WebSocket a portas locais desconhecidas.

• Use ferramentas especializadas. A outra opção é contar com um software que resolva esses problemas diretamente no núcleo do navegador, como os navegadores antidetecção.

Por exemplo, o Octo Browser inclui proteção integrada contra varredura de portas locais. O Octo intercepta quaisquer tentativas de scripts de acessar endereços na faixa do 127.0.0.0/8 ou localhost, incluindo aqueles que usam a API do WebSocket, tratando-as diretamente no nível da API do navegador.

Testando as medidas de proteção

Você pode ver facilmente como isso funciona com um teste simples.

Primeiro, inicie qualquer servidor local no seu dispositivo para que ele abra uma porta de escuta.

Uma porta aberta será parecida com isso.

Depois, abra qualquer site em seu navegador e tente acessar a porta aberta.

Em um navegador Chrome padrão, a resposta chega com um pequeno atraso. Esse atraso confirma que a porta está aberta.

Realize o mesmo teste no Octo Browser e você verá que a porta parecerá estar fechada.

O Octo Browser controla o acesso às suas portas locais para evitar o vazamento de dados.

O Private Network Access (PNA) resolve o problema?

O Private Network Access (PNA) é um recurso de segurança implementado nos navegadores modernos (principalmente no Chrome) que impede que sites públicos enviem requisições a dispositivos ou servidores na rede local do usuário.

Os navegadores modernos de fato tentam mitigar essa vulnerabilidade das seguintes formas:

• restringindo ou bloqueando completamente o acesso ao localhost a partir de contextos públicos não seguros;

• exigindo um Contexto Seguro (HTTPS) antes que tais conexões possam ser iniciadas;

• realizando requisições de pré-envio CORS (CORS preflight) antes de permitir o acesso aos recursos da rede local.

No entanto, os desenvolvedores de sistemas antifraude também se adaptaram a isso. Eles usam domínios públicos que resolvem para o 127.0.0.1 (por exemplo, yourapp.localhost.com) junto com certificados HTTPS válidos, permitindo que burlem algumas dessas restrições básicas.

Mais importante ainda, o PNA não pode proteger você contra ataques de tempo no nível do TCP. Mesmo que o PNA acabe bloqueando uma requisição pela falta dos cabeçalhos exigidos, o navegador precisa primeiro estabelecer uma conexão TCP antes de poder determinar se esses cabeçalhos são aceitáveis. Se a porta estiver fechada, o sistema operacional rejeita imediatamente a conexão com um pacote TCP RST. Se a porta estiver aberta, o handshake TCP é concluído com sucesso. O navegador então tenta trocar dados, depara-se com as restrições do PNA, encerra a conexão e só então reporta um erro.

Essas etapas extras levam dezenas de milissegundos, que é precisamente a diferença de tempo em que os algoritmos antifraude se baseiam. Em outras palavras, o PNA impede que sites leiam dados locais, mas não consegue ocultar o tempo necessário para estabelecer uma conexão.

Conclusão

Hoje, um anonimato eficaz exige uma abordagem abrangente. Você pode criar o que parece ser o perfil de navegador perfeito, mas uma única porta de depuração esquecida, como a 9222, ou uma porta de banco de dados exposta pode comprometer completamente a sua camuflagem, que de outra forma seria impecável. Proteja sua pilha de rede: isole os seus ambientes de trabalho, configure o seu firewall cuidadosamente ou use soluções que tratem desse tipo de vazamento no nível do núcleo do navegador.