Falha em navegadores permitia acesso remoto a redes locais

Problema em Safari, Firefox e navegadores baseados no Chromium abria porta para invasões no macOS e Linux. Apple e Google prometeram corrigir a vulnerabilidade.

Por Giovanni Santa Rosa

08/08/2024 às 16:45

Malwares RAT enganam antivírus com arquivos poliglotas (imagem ilustrativa: Vitor Pádua/Tecnoblog) — Falha nos principais navegadores do mercado envolvia endereço IP 0.0.0.0 (Imagem: Vitor Pádua / Tecnoblog)

Pesquisadores de segurança encontraram uma falha nos Chromium (base de Chrome, Edge e outros), Firefox e Safari no macOS e no Linux. O problema está em como os navegadores lidam com pedidos de acesso ao IP 0.0.0.0.

A startup israelense Oligo, especializada em cibersegurança, descobriu esta vulnerabilidade. Avi Lumelsky, pesquisador da empresa, diz que códigos de desenvolvedor e mensagens internas são algumas informações vulneráveis a este tipo de ação.

Ilustração de segurança — Redes locais podem ser comprometidas pelo ataque (Imagem: Vitor Pádua / Tecnoblog)

Um site malicioso poderia usar 0 IP 0.0.0.0 para mostrar outros endereços na mesma rede. Assim, uma possibilidade é acessar o “localhost”, nome do servidor em uma rede local ou computador. Dessa forma, atacantes poderiam ter acesso a redes internas, obtendo dados que deveriam estar protegidos.

O problema recebeu o nome de 0.0.0.0 Day — um trocadilho com o IP envolvido e o termo “zero-day”. Falhas zero-day são aquelas que existem em softwares já disponíveis no mercado e foram descobertas por outras pessoas ou empresas, deixando a desenvolvedora com zero dia disponível para corrigir a vulnerabilidade.

Windows está protegido

Existem algumas limitações nesta tática. A principal delas é que apenas indivíduos ou empresas que hospedam servidores web podem ser afetados.

Apenas máquinas com macOS e Linux são suscetíveis a ataques ao 0.0.0.0. O Windows bloqueia o acesso a este endereço de IP no nível do sistema operacional, ficando a salvo de acessos não autorizados.

Chama a atenção que esta vulnerabilidade parece existir há muito tempo. Em 2006, um usuário reportou, em um fórum da Mozilla, que sites haviam atacado seu roteador, o que ele acreditava ser um bug.

“Passaram 18 anos, com centenas de comentários, mas o bug continua aberto até hoje”, escreve a Oligo em seu blog. “Durante estes 18 anos, o tópico foi fechado, reaberto, classificado como grave ou crítico e explorado em ataques.”

Apple e Google vão corrigir o problema

A Oligo enviou, em abril de 2024, as informações da vulnerabilidade para as equipes de segurança responsáveis pelos principais navegadores do mercado.

A Apple disse à revista Forbes que passará a bloquear todas as tentativas de sites para acessar o endereço 0.0.0.0 no macOS 15 Sequoia, começando na versão beta. O Google pretende fazer o mesmo com o Chromium, que serve de base para o próprio Chrome, o Microsoft Edge, o Brave e mais navegadores.

A Mozilla, por outro lado, não decidiu o que fazer. Para a fundação responsável pelo Firefox, bloquear o 0.0.0.0 pode causar problemas a servidores que usam este endereço como substituto do “localhost”. A desenvolvedora ainda não tomou nenhuma medida e está discutindo o que fazer.

A Oligo critica a postura da Mozilla. “Ao permitir o 0.0.0.0, você permite basicamente tudo”, diz Gal Elbaz, cofundador da empresa de cibersegurança.

Com informações: Oligo, PC Mag, Forbes

Comentários da Comunidade

4 comentários

Participe da discussão

Os mais notáveis

Comentários com a maior pontuação

Rodolfo Ribeiro Gutman 2 dias atrás

Se os israelenses chamaram atenção para essa falha agora pode apostar que já exploraram a exaustão.

Diego Silva 2 dias atrás

Pelo que eu entendi, envolveria XSS contra o que estivesse hospedado em 0.0.0.0 que no caso é um endereço especial que simboliza todas as interfaces IPv4 da stack atual de rede. Só aí já temos requisitos para que isso ocorra:

O sistema operacional deve ser Unix-based (Mac OS, Linux, FreeBSD e afins)
O sistema deve ter algum daemon na porta 80 ou na 443
O sistema deve ter um daemon que responda HTTP(s) nessa porta
O serviço HTTP(s) deve ter Access-Control-Allow-Origin permissivo
O serviço HTTP(s) deve ser uma API (seja REST ou SOAP, via XML)
O daemon precisa estar rodando não sob um usuário e grupo de serviço mas sim de root (por exemplo, lighttpd tem um usuário e grupo de mesmo nome, que isola o daemon do ambiente root)
O daemon precisa poder invocar comandos shell e/ou programas, ou então ter alguma conectividade com o DBus, ou ainda precisa poder executar tarefas que sejam destrutivas o suficiente para a rede local, como acessar e chamar zeroconf, Avahi, uPnP ou similares)
O usuário precisa acessar uma página que use JavaScript pra internamente requisitar (possivelmente via fetch API ou manipulação de iframe, embora nesse caso precisa também de um cabeçalho X-Frame-Options permissivo ou ausente, o que nesse último caso vai depender da política permissiva nas flags do chromium)
A API precisa ter falhas seríssimas como permitir chamadas sem autenticação, senha em branco, etc.
(Edit: esqueci de citar o mais óbvio: ) A depender da stack usada, o daemon precisa estar ouvindo em todas as interfaces IPv4 (não pode ser um IPv6 only, portanto, e nem pode ser um daemon no 127.0.0.1 ou em uma interface específica)

Só aí já dá pra ver que trata-se de uma situação extremamente específica. Não é qualquer um que vai estar rodando *nix com um daemon na porta 80/443, em root ou com potencial pra fazer coisas (como permitir, por exemplo, que um site exploite um Proxy local de uma API de smart ar condicionado e leve o usuário à hipotermia, ou desativar o controle de corrente de um no-break a ponto de causar um estouro da bateria interna e incendiar a casa, e ainda assim teriam mais poréns pra isso acontecer). Já começa que é um usuário *nix com um daemon rodando, ou seja, não trata-se de um leigo. Pode ser um técnico bem despreocupado com a segurança de seu sistema, mas aí não há sistema de segurança que seja suficiente pra proteger um usuário avançado despreocupado.

EDIT 2: Fiz um teste aqui, com um código bem simples instanciando um Express.js (e retornando um JSON qualquer) e tentando requisitar 0.0.0.0 a partir do DevTools em algum domínio de internet, e, como eu deixo bem claro no comentário a especificidade de variáveis nesse tipo de exploração, não foi nada fácil conseguir que a requisição sucedesse de primeira. Além do Access-Control-Allow-Origin que eu mencionei, descobri outra header que desconhecia, Access-Control-Allow-Private-Network que precisa estar como true. Como a maioria dos sites são em HTTPS, HTTP-only definitivamente não funciona, exigindo um certificado para a conexão ocorrer. Como estamos falando de uma rede local, o certificado usado jamais terá validade para 127.0.0.1 e muito menos para 0.0.0.0 pois não existe certificado localhost confiável por autoridade certificadora, a menos que o certificado seja autoassinado e também importado no Certstore, caso contrário, o erro de ERR_CERT_AUTHORITY_INVALID impedirá que o Fetch/XHR retorne alguma coisa, porque a conexão será barrada. Novamente, muito se para que ocorra esse “acesso remoto”.
Os navegadores atuais, sobretudo o Chromium, possuem inúmeras travas e muitas vezes nós, que mexemos com desenvolvimento, temos que inicializar o browser a partir de linha de comando com flags bem específicas para permitir o ambiente de desenvolvimento funcionar. E, nesse ambiente, obviamente o desenvolvedor não vai ficar acessando qualquer site, porque é um ambiente de desenvolvimento e não um ambiente doméstico.

123 2 dias atrás

penso igual

Felipe Silva 2 dias atrás

muito boa a analise.

Relacionados

Escrito por

Giovanni Santa Rosa

Repórter

Giovanni Santa Rosa é formado em jornalismo pela ECA-USP e cobre ciência e tecnologia desde 2012. Foi editor-assistente do Gizmodo Brasil e escreveu para o UOL Tilt e para o Jornal da USP. Cobriu o Snapdragon Tech Summit, em Maui (EUA), o Fórum Internacional de Software Livre, em Porto Alegre (RS), e a Campus Party, em São Paulo (SP). Atualmente, é autor no Tecnoblog.

Windows tem falha que permite remover as atualizações do sistema operacional Governo cobra que Apple e Google criem senha extra para celulares