A equipe de pesquisa da Oligo Security recentemente revelou a vulnerabilidade conhecida como “0.0.0.0 Day”. Essa vulnerabilidade permite que sites maliciosos contornem a segurança do navegador e interajam com serviços que estão sendo executados na rede local de uma organização. Isso pode levar a acessos não autorizados e execução remota de código em serviços locais por atacantes fora da rede.
A vulnerabilidade
A questão decorre da implementação inconsistente de mecanismos de segurança em diferentes navegadores, juntamente com a falta de padronização na indústria de navegadores. Como resultado, o endereço IP aparentemente inofensivo, 0.0.0.0, pode se tornar uma ferramenta poderosa para os atacantes explorarem serviços locais, incluindo aqueles usados para desenvolvimento, sistemas operacionais e até redes internas.
O Impacto
O impacto do 0.0.0.0 Day é amplo, afetando indivíduos e organizações. A descoberta de campanhas de exploração ativas, como a ShadowRay, ressalta ainda mais a urgência de lidar com essa vulnerabilidade.
O que divulgou a empresa de segurança?
A equipe de pesquisa da Oligo recentemente descobriu uma vulnerabilidade crítica que afeta todos os principais navegadores da web, permitindo que os invasores violem redes locais. Essa descoberta, que apelidamos de “0.0.0.0 Day”, expõe uma falha fundamental na forma como os navegadores lidam com solicitações de rede, potencialmente concedendo a atores mal-intencionados acesso a serviços sensíveis que estão sendo executados em dispositivos locais.
A vulnerabilidade 0.0.0.0 day em detalhes
Pesquisadores da Oligo Security divulgaram uma vulnerabilidade lógica para todos os principais navegadores (Chromium, Firefox, Safari) que permite que sites externos se comuniquem com (e potencialmente explorem) software que está sendo executado localmente em MacOS e Linux. O Windows não é afetado por esse problema.
Os pesquisadores da Oligo descobriram que sites públicos (como domínios terminados em .com) são capazes de se comunicar com serviços que estão sendo executados na rede local (localhost) e potencialmente executar código arbitrário no host do visitante usando o endereço 0.0.0.0 em vez de localhost/127.0.0.1.
Correção em andamento: Navegadores em breve bloquearão 0.0.0.0
Após a divulgação responsável, as solicitações HTTP para 0.0.0.0 agora estão sendo adicionadas aos padrões de segurança usando um Pedido de Comentário (RFC), e alguns navegadores em breve bloquearão completamente o acesso a 0.0.0.0. O 0.0.0.0 não será mais permitido como um IP de destino na especificação Fetch, que define como os navegadores devem se comportar ao fazer solicitações HTTP.
O que disse o Google Chrome, Apple e Mozilla?
No início de abril de 2024, a Oligo divulgou essas descobertas de vulnerabilidade para as equipes de segurança responsáveis por cada um dos principais navegadores. As equipes de navegador de cada empresa reconheceram a falha de segurança e trabalharão na mudança do padrão relacionado, e também implementarão mitigações no nível do navegador. Eventualmente, todos os navegadores bloquearão 0.0.0.0, mas, ao mesmo tempo, o mercado exige um padrão comum a ser seguido. Devido à natureza da vulnerabilidade e à complexidade do patch em todos os navegadores, ela permanece explorável, permitindo que sites externos se comuniquem com serviços no Localhost.
A falta de um padrão finalizado levou a diferentes implementações em diferentes navegadores. Isso significa que cada navegador hoje lida com solicitações HTTP para a rede interna ou local de maneira diferente.
Google Chrome (e navegadores baseados em Chromium como Edge):
PNA (Private Network Access) é uma iniciativa liderada pelo Google, e continua a evoluir e melhorar. No entanto, a vulnerabilidade 0.0.0.0 contornou o mecanismo PNA no Chromium, que bloqueia sites de acessar 127.0.0.1, localhost e outros IPs privados via Javascript quando carregados a partir de sites públicos.
Após nosso relatório, o Chrome está bloqueando o acesso a 0.0.0.0 (Finch Rollout) a partir do Chromium 128. O Google irá implementar gradualmente essa mudança ao longo dos próximos lançamentos, completando-a pelo Chrome 133, momento em que o endereço IP será completamente bloqueado para todos os usuários do Chrome e Chromium.
Vale a pena notar que a porcentagem de sites que se comunicam com 0.0.0.0 está aumentando, com base em contadores no Chromium. Essas páginas podem ser maliciosas, e atualmente a porcentagem está em 0.015% de todos os sites. Com 200 milhões de sites no mundo a partir de agosto de 2024, até ~100K sites públicos podem estar se comunicando com 0.0.0.0. A figura abaixo ilustra esse aumento.
Apple Safari:
Os navegadores baseados na Apple, incluindo o Safari, são baseados em um software de código aberto chamado “WebKit”. Após nosso relatório, a Apple fez mudanças que quebram o WebKit que bloqueiam o acesso a 0.0.0.0. Como parte dessa mudança, eles adicionaram uma verificação ao endereço IP do host de destino. Se for tudo zeros, a solicitação é bloqueada. As mudanças específicas podem ser encontradas aqui.
Mozilla Firefox:
Até agora, não há uma correção imediata no Firefox. Embora uma correção esteja em andamento, o Firefox nunca restringiu o Acesso à Rede Privada, então tecnicamente sempre foi permitido. Nessa perspectiva, é “nada para corrigir” já que o PNA não é implementado em primeiro lugar. Após nosso relatório, a Mozilla alterou a especificação Fetch (RFC) para bloquear 0.0.0.0. O Firefox priorizou a implementação do Acesso à Rede Privada, mas ainda não foi implementado. Em um ponto indeterminado no futuro, 0.0.0.0 será bloqueado pelo Firefox e não dependerá da implementação do PNA.
0.0.0.0 Day no Chrome, Chromium, Safari, Firefox e Edge – Detalhes técnicos
Navegadores – todos nós temos um favorito, e todos nós os usamos diariamente. Mesmo aplicativos que não são navegadores costumam carregar recursos de domínios externos, como ao usar o Google Analytics e SDKs semelhantes do lado do cliente ou incorporar scripts, ou vídeos.
Os navegadores sempre foram um alvo de segurança, levando os desenvolvedores de navegadores a introduzir conceitos de segurança inovadores como sandboxing e cookies HTTPS-ONLY, ou implementar padrões como CORS (Cross Origin Resource Sharing) em torno de solicitações entre sites para proteger servidores e usuários finais. Todos esses mantêm sites maliciosos usando ataques de falsificação de solicitação entre sites (CSRF) longe dos dados privados dos usuários, redes internas e aplicativos locais.
Por design, os navegadores podem enviar uma solicitação para quase qualquer servidor HTTP usando Javascript. Ao lidar com uma resposta entre sites, os mecanismos de segurança do navegador decidem qual ação tomar:
Válido: Propaga os dados da resposta para o contexto Javascript (sucesso) Inválido: Retorna uma resposta mascarada ou levanta um erro especial (CORS, SOP, …). Mas às vezes, a resposta não importa. Com a vulnerabilidade do 0.0.0.0 Day, uma única solicitação pode ser suficiente para causar danos. Antes de entrarmos nos detalhes, há um pouco de contexto para entender.
Um IP incomum: O que é 0.0.0.0, afinal?
Vamos voltar ao início do problema: 0.0.0.0 tem “múltiplos usos”. Você já deve estar pensando em alguns deles: “todos os IPs neste host”, “todas as interfaces de rede neste host” ou simplesmente “localhost”. O RFC 1122 se refere a 0.0.0.0 usando a notação {0,0}:
Ele proíbe 0.0.0.0 como um endereço de destino em IPv4 e só permite como um endereço de origem em circunstâncias específicas, como quando usado em um pacote DHCPDISCOVER durante o aperto de mão DHCP, quando um IP é alocado pela primeira vez. O 0.0.0.0 às vezes é usado em arquivos /etc/hosts para bloquear certos domínios (servindo como um bloqueador de anúncios) ou, quando usado em políticas de rede, os blocos CIDR 0.0.0.0/32 – todos os IPs são permitidos.
Por que este site está me escaneando?
A “impressão digital” digital dos usuários de um site é uma técnica conhecida que tem muitos propósitos. O uso mais comum legítimo é identificar usuários que retornam, mas a técnica também pode ser usada por atores de ameaças para coletar inteligência para campanhas de phishing. Quando validado cruzado com dados adicionais sobre o usuário, os sites podem dizer muito sobre quem está visitando atualmente – mesmo que você nunca tenha feito login.
Em maio de 2020, uma manchete interessante apareceu no Hacker News:
Neste caso, o Ebay aparentemente tentou escanear a porta do visitante assim que o site foi carregado. Usando essa técnica, o site usou Javascript para escanear as portas no localhost (127.0.0.1), resultando em uma impressão digital interessante e única.
O código Javascript usado pelo Ebay poderia distinguir entre respostas válidas (algo está sendo executado naquela porta) e erros HTTP (nada está ouvindo naquela porta).
Os navegadores não deveriam ter a capacidade de enviar essas solicitações em primeiro lugar. Por quê? Porque uma única solicitação HTTP poderia atacar um roteador doméstico – e se é tudo o que é necessário, cada usuário precisa ser capaz de prevenir que essa solicitação aconteça.
Felizmente, o Chrome introduziu o PNA (Private Network Access):
Este novo padrão estende o CORS restringindo a capacidade dos sites de enviar solicitações a servidores em redes privadas. O PNA propõe distinguir entre redes públicas, privadas e locais. As páginas carregadas em um contexto menos seguro não poderão se comunicar com contextos mais seguros. Por exemplo, o attacker.com não será capaz de contatar 127.0.0.1 ou 192.168.1.1 porque esses endereços IP são considerados mais privados.
Colocando 0.0.0.0 à prova: PNA Bypass
De acordo com a especificação PNA atual, os seguintes segmentos de IP são considerados privados ou locais:
Durante a pesquisa, notamos que “0.0.0.0” não estava nesta lista. Acreditávamos que como parte do PNA, os sites não poderiam despachar solicitações para 0.0.0.0. De acordo com a especificação, ele não deveria ser usado como alvo.
Para descobrir, foi executado um servidor HTTP dummy no localhost (127.0.0.1).
Notícias Relacionadas
Dr.Web
Dr.Web desconectou todos os servidores após um ataque cibernético
A empresa antivírus russa Doctor Web (Dr.Web) anunciou que desconectou todos os servidores após um ataque cibernético no sábado, 14 de setembro, como medida protetiva. Ataque cibernético sofrido pela Dr.Web A empresa revelou que detectou “sinais de interferência não autorizada” em sua infraestrutura de TI. Então, resolveu desconectar os seus servidores. A empresa destaca ainda […]
Violação de dados Temu
Temu nega violação de dados mesmo hacker alegando roubo
Mesmo depois de um hacker afirmar que roubou 87 milhões de registros de informações de clientes, a Temu nega ter sido hackeada ou sofrido uma violação de dados. Violação de dados Temu O agente da ameaça colocou os supostos dados à venda ontem no fórum de hackers BreachForums, junto com uma pequena amostra para servir […]
Em seguida, os especialistas tentaram acessá-lo por meio de um domínio externo do Javascript, usando 0.0.0.0.
Ele … simplesmente funcionou. A solicitação chegou ao servidor.
O que aconteceu aqui?
- Sob domínio público (.com), o navegador enviou a solicitação para 0.0.0.0.
- O servidor dummy está ouvindo em 127.0.0.1 (apenas na interface de loopback, não em todas as interfaces de rede).
- O servidor no localhost recebe a solicitação, a processa e envia a resposta.
- O navegador bloqueia o conteúdo da resposta de se propagar para o Javascript devido ao CORS.
Isso significa que sites públicos podem acessar qualquer porta aberta em seu host, sem a capacidade de ver a resposta.
Entendemos que isso era uma maneira de contornar a implementação atual do PNA e uma falha inerente nos navegadores. A equipe da Oligo reportou o que foi encontrado a todos os navegadores, seguindo a divulgação responsável, mas foi preciaso um exemplo de uma ameaça real e um vetor de ataque real para provar.
Encontrando aplicações locais vulneráveis
Primeiro, os especialsitas da Oligo precisaram encontrar uma aplicação que estava em potencial problema. Muitas aplicações são propensas a serem impactadas pela vulnerabilidade do 0.0.0.0 Day.
Quando os serviços usam o localhost, eles assumem um ambiente restrito. Essa suposição, que pode (como no caso desta vulnerabilidade) ser falha, resulta em implementações de servidor inseguras. Por exemplo, muitas aplicações pulam desafios de token CSRF e comprometem a autorização ou autenticação porque se supõe que estão sendo executadas em um ambiente de rede estritamente controlado.
Em alguns casos, nenhuma autorização ou autenticação pode ser necessária, ou pode não haver verificação de tokens CSRF. Quando o aplicativo vê indicações de que está sendo executado em um ambiente seguro, ou uma rede confiável e isolada, ele permite rotas HTTP POST que não têm autorização ou tokens CSRF, e acesso de gravação a recursos e configurações – permitindo a execução de código. Mesmo uma única solicitação HTTP pode ser suficiente para permitir o acesso às suas portas.
Para encontrar um aplicativo local que seria vulnerável a partir do navegador, primeiro foi preciso um servidor HTTP que rodasse em uma porta local (interface de rede localhost).
Para explorar totalmente essa vulnerabilidade, obtendo a execução remota de código, foi necessário que o serviço tivesse uma rota HTTP que pudesse escrever, ajustar ou modificar arquivos e configurações.
Não demorou muito para termos nosso primeiro aplicativo vulnerável: Ray.
POC: ShadowRay a partir do navegador
ShadowRay, uma recente campanha de ataque direcionada a cargas de trabalho de IA, foi descoberta pela Oligo no ambiente selvagem. Os pesquisadores agora provaram que é possível executar este ataque a partir do navegador, usando 0.0.0.0 como vetor de ataque.
ShadowRay permitiu a execução arbitrária de código quando inadvertidamente exposto à internet, e passou despercebido por quase um ano. Como grandes fãs do Ray, muitas vezes o usamos localmente para desenvolvimento. Com isso em mente, nos perguntamos: “Um site público poderia explorar um cluster Ray rodando no localhost?”
Explicação: Primeiro, no terminal à direita, foi executado um cluster Ray local no localhost. Em seguida, no terminal à esquerda, iniciaram um socket que está ouvindo novas conexões, para abrir um shell reverso. Então, a vítima clica no link no e-mail, que executa o exploit. O exploit abre um shell reverso para o invasor na máquina do visitante.
Aqui está o código de exemplo que foi usado para o exploit:
Chromium
Safari
Firefox
Mais uma vez… funcionou.
Foi muito fácil. Percebeu-se instantaneamente que executar o ShadowRay a partir do navegador é apenas um de um número inegavelmente enorme de ataques de Execução Remota de Código (RCE) habilitados por essa abordagem – então decidiram procurar mais.
Selenium Grid
Campanhas de ataque recentes, como a SeleniumGreed, mostraram atores de ameaças aproveitando servidores públicos Selenium Grid para obter acesso inicial a organizações, usando vulnerabilidades conhecidas de Execução Remota de Código. Em instâncias locais do Selenium Grid, descobrimos que o RCE é possível ao despachar uma solicitação POST para http://0.0.0.0:4444/ com uma carga útil criada.
Outro vetor de ataque interessante: usar o cluster local Selenium Grid para navegar em sites usando configurações de navegador inseguras, para obter acesso a domínios internos e registros DNS privados atrás de uma VPN.
Pytorch Torchserve (ShellTorch)
Em julho de 2023, a Equipe de Pesquisa da Oligo divulgou várias novas vulnerabilidades críticas para os mantenedores do Pytorch Amazon e Meta, incluindo o CVE-2023-43654 (CVSS 9.8). Essas vulnerabilidades, coletivamente chamadas de ShellTorch, levam à Execução Remota de Código (RCE) no PyTorch TorchServe – permitindo finalmente que os invasores obtenham acesso completo e não autorizado ao servidor.
Praticantes de IA que usam o TorchServe em uma rede interna (localmente ou usando encaminhamento de porta), essas vulnerabilidades podem ser aproveitadas através de 0.0.0.0 também, levando à comprometimento do cluster local TorchServe que está atrás de firewalls e WAF.
Identificando usuários retornantes com base em portas abertas
Outro vetor de ataque interessante é a capacidade de reconhecer usuários anônimos – especialmente usuários que não têm cookies e nunca fizeram login – ao escanear suas portas. Os resultados da varredura de porta local podem ser validados cruzados com mais dados, como User-Agent, endereço IP e outros identificadores (como https://amiunique.org/ enfatiza). As seguintes portas são usadas por diferentes personas dentro da organização.
- TeamViewer (porta 5938)
- Selenium Grid (porta 4444)
- Ray (porta 8265)
Conclusão
PNA é fantástico – um esforço verdadeiramente incrível liderado pelo Google e pela comunidade. Mas até que o PNA seja totalmente implementado, sites públicos podem despachar solicitações HTTP usando Javascript para alcançar com sucesso serviços na rede local. Para que isso mude, precisamos que o PNA seja padronizado, e precisamos que os navegadores implementem o PNA de acordo com esse padrão.
CORS também é ótimo, e já torna a internet muito mais segura. CORS impede que as respostas cheguem ao invasor, então os invasores não podem ler dados ao fazer solicitações inválidas. Ao enviar uma solicitação, se os cabeçalhos CORS não estiverem presentes na resposta, o código Javascript do invasor não será capaz de ler o conteúdo da resposta.
Em nossa demonstração, a Oligo prova que ao usar 0.0.0.0 juntamente com o modo “no-cors”, os invasores podem usar domínios públicos para atacar serviços rodando no localhost e até mesmo obter execução arbitrária de código (RCE), tudo usando uma única solicitação HTTP.
Graças aos relatórios da Oligo, os navegadores priorizaram essas correções e fizeram mudanças bloqueando 0.0.0.0 como IP de destino.
Como posso proteger aplicações locais do 0.0.0.0 day?
Obviamente, esperar por uma correção do navegador não é o ideal – então há algumas coisas que os desenvolvedores podem fazer para proteger aplicações locais.
Aqui estão as dicas fornecidas pelos especialistas da Oligo:
- Implemente cabeçalhos PNA Verifique o cabeçalho HOST da solicitação para proteger contra ataques de rebind DNS para localhost ou 127.0.0.1.
- Não confie na rede localhost porque ela é “local” – adicione uma camada mínima de autorização, mesmo quando estiver rodando no localhost.
- Os desenvolvedores do Jupyter Notebook fizeram um ótimo trabalho nisso, adicionando um token por padrão.
- Use HTTPS quando possível.
- Implemente tokens CSRF em suas aplicações, mesmo que sejam locais.
- Lembre-se de que os navegadores atuam como gateways, e eles têm capacidades de roteamento para espaços de endereço IP internos em muitos navegadores.
