Os navegadores Web estão instalados em milhares de milhões de dispositivos em todo o mundo, o que os torna alvos privilegiados dos cibercriminosos. Uma vez que os principais navegadores Web têm enormes bases de utilizadores, uma única vulnerabilidade pode ter consequências de grande alcance. Manter os navegadores actualizados é fundamental para se manter protegido contra ameaças em evolução.
Para ilustrar a gravidade das vulnerabilidades nos navegadores Web, os nossos colegas efectuaram uma análise exaustiva da CVE-2024-6778, uma vulnerabilidade nos navegadores baseados no Chromium, que afecta particularmente o Chrome DevTools. Este blogue apresenta uma análise detalhada dos aspectos técnicos da vulnerabilidade, do potencial impacto e das estratégias de atenuação.
Antecedentes do CVE-2024-6778
A CVE-2024-6778 é uma vulnerabilidade de condição de corrida descoberta no Chrome DevTools. Permite que os atacantes injectem HTML ou JavaScript malicioso em páginas privilegiadas do navegador através de extensões maliciosas do navegador. De acordo com a NVD (National Vulnerability Database), esta vulnerabilidade foi classificada como de gravidade elevada, com uma pontuação CVSS de 8,8.
A classificação de gravidade elevada desta vulnerabilidade deve-se ao seu potencial para permitir a execução remota de código, o que pode resultar no comprometimento de sistemas, na perda de confidencialidade e na redução da disponibilidade.
Visão geral da segurança do Chromium
Para obter uma compreensão mais profunda das implicações do CVE-2024-6778, é importante conhecer os principais aspectos do modelo de segurança do Chromium. O Chromium é a base de código aberto para navegadores como o Google Chrome, Microsoft Edge, Opera e Brave. Utiliza um modelo de multiprocessos em que cada separador, também designado por renderizador, e vários componentes do navegador são executados em processos isolados para melhorar a estabilidade e a segurança, limitando o âmbito de potenciais compromissos.
Um elemento fundamental da segurança do Chromium é o seu mecanismo de sandboxing, que impede que os processos de renderização acedam diretamente aos recursos do sistema. Em vez disso, todas as interações são geridas através de canais IPC (Inter-Process Communication) para garantir que apenas são realizadas operações autorizadas.
Nem todos os componentes do Chromium estão sujeitos a uma caixa de areia completa. As páginas WebUI, como chrome://settings e chrome://downloads, são processadas dentro dos processos de renderização, mas operam com restrições parciais de sandbox. Este processo concede-lhes acesso a APIs do navegador que normalmente não são acessíveis através da Web.
Por exemplo, a página chrome://policy desempenha um papel vital em ambientes empresariais, uma vez que permite aos administradores e utilizadores configurar e aplicar políticas de segurança do browser. Estas políticas também são geridas através da Política de Grupo em sistemas Windows.
Como o chrome://policy pode interagir diretamente com o sistema operativo, é um alvo valioso para os atacantes. Com a vulnerabilidade CVE-2024-6778, que explora uma condição de corrida no Chrome DevTools, os atacantes podem injetar código malicioso nestas páginas, colocando sérios riscos de segurança.
Análise técnica do CVE-2024-6778
Descoberta
Esta vulnerabilidade foi descoberta numa funcionalidade de teste introduzida no Chrome Enterprise versão 117. Esta funcionalidade permite testar políticas através da página chrome://policy/test. Devido à limitada documentação oficial sobre esta funcionalidade, os nossos colegas efectuaram um exame minucioso do código-fonte do Chromium, complementado por informações do autor do CVE, para compreenderem totalmente a sua implementação e identificarem as vulnerabilidades de segurança associadas.
Componentes de gestão de políticas
A análise do código-fonte efectuada pelos bolseiros OPSWAT revelou que, em chrome://policy/testas políticas são geridas utilizando o Informação sobre a política e comunicada entre a WebUI e os processos do browser através da PolicyTestBrowserProxy classe. A Informação sobre a política é definida da seguinte forma:
Uma análise mais aprofundada da classe responsável pelo tratamento destas políticas permitiu identificar um método denominado applyTestPolicies. Este método utiliza uma API privada, setLocalTestPoliciespara aplicar dinamicamente uma lista de políticas.
Para saber como os pedidos de política são processados através desta API, os bolseiros analisam o ManipularSetLocalTestPolicies dentro do método PolicyUIHandler classe:
O ManipularSetLocalTestPolicies recupera os dados da política a partir dos argumentos fornecidos e obtém um ponteiro para o método LocalTestPolicyProvider através do conetor de política global do navegador. Em seguida, verifica a existência deste fornecedor antes de dar instruções ao perfil de utilizador atual para o utilizar.
Esta verificação foi considerada insuficiente, uma vez que apenas garante que fornecedor_de_teste_local não é nulo antes de aplicar as políticas. A criação e a inicialização de fornecedor_de_teste_local são controlados pelo Criar se for permitido método:
No âmbito do Criar se for permitido o valor de retorno depende inteiramente do resultado do método IsPolicyTestingEnabled função. Esta função determina se um LocalTestPolicyProvider é criada, com base numa combinação das preferências do utilizador e do canal de lançamento do browser:
Desde pref_serviço é consistentemente definido como nulo de cada vez que IsPolicyTestingEnabled() é chamada, a primeira condição é ignorada, deixando a decisão de ativação dependente apenas do canal de lançamento do browser.
Em compilações do Chromium sem marca, o canal de lançamento é predefinido para Canal::UNKNOWN. De acordo com a lógica da função, Canal::UNKNOWN é tratado da mesma forma que Canal::DEFAULTque ativa a funcionalidade de teste de políticas por defeito. A análise do fluxo de código revelou que a API privada setLocalTestPolicies pode ser invocado através da WebUI para aplicar políticas sem quaisquer restrições de acesso significativas.
Exploração
Ao identificar e tirar partido desta API privada, um atacante pode aplicar arbitrariamente políticas através da WebUI, permitindo a manipulação de definições como BrowserSwitcherEnabled, BrowserSwitcherUrlList, AlternativeBrowserPathe AlternativeBrowserParameters para executar comandos. Por exemplo, ao definir AlternativeBrowserPath para o powershell e AlternativeBrowserParameters para ["calc"]Se um URL específico for visitado, podem ser executados comandos shell arbitrários.
Aplicar uma política de utilizador maliciosa arbitrária através de API privada
Para demonstrar como as políticas podem ser aplicadas utilizando a interface privada setLocalTestPolicies API identificada na análise anterior, o seguinte código JavaScript é um script que define o AllowDinosaurEasterEgg e aplica-a efetivamente através do WebUI invocando setLocalTestPolicies:
A política pode ser aplicada com êxito para desativar o AllowDinosaurEasterEgg configuração.
Para um maior impacto, um atacante pode visar o BrowserSwitcher política:
Esta política permite que o navegador invoque um caminho alternativo do navegador se o URL corresponder a determinadas condições. Pode ser explorada configurando este caminho para apontar para um executável do sistema para executar comandos do sistema operativo. O seguinte código JavaScript demonstra esta abordagem:
Este script executa as seguintes tarefas:
- Ativa o
BrowserSwitcherfuncionalidade para example.com - Define o caminho alternativo do navegador para o powerShell
- Executa
calcularsempre que o URL especificado é acedido.
Simulação de extensão maliciosa do Chrome
A identificação da API privada que permite a aplicação de políticas introduz um vetor de ataque significativo para os adversários. Para explorar eficazmente esta vulnerabilidade, um atacante teria de desenvolver uma extensão maliciosa do Chrome que utilizasse a API Chrome DevTools para executar código JavaScript malicioso.
Para demonstrar o potencial impacto no mundo real, os nossos colegas simularam um cenário em que uma extensão maliciosa do Chrome é instalada num navegador vulnerável e utilizada para executar o ataque. As APIs chrome.devtools nas Extensões do Chrome permitem aos programadores alargar e interagir com a interface DevTools do Chrome.
No entanto, a execução da API do DevTools por meio de uma extensão apresenta alguns desafios que devem ser contornados. Primeiro, a API do DevTools só funciona quando o DevTools está aberto e inspecionando ativamente um site. Em segundo lugar, a API do DevTools não permite a execução de código na interface de utilizador da Web, WebUI. Essa limitação ajuda a manter a segurança e a integridade da WebUI durante os processos de desenvolvimento e inspeção
Sinais que indicam a execução de Javascript através da API de recarga
Uma análise mais aprofundada revelou que a função chrome.devtools.inspectedWindow.reload carece de verificação para confirmar se uma extensão tem permissão para executar scripts na página inspeccionada. O seu único nível de defesa é o servidor de extensão devtools, que bloqueia o acesso quando o URL da página inspeccionada é alterado.
As páginas about:blank herdam as permissões e a origem da página que as abriu. Isto significa que a capacidade de executar código em about:blank quando redireccionado a partir dos sinais da WebUI é uma potencial vulnerabilidade.
Execução de código na webUI através da API de recarga
A condição de corrida em chrome.devtools.inspectedWindow.reload() permite a execução de código nas páginas WebUI do Chrome (por exemplo, chrome://policy), que estão normalmente protegidas. A exploração tira partido da capacidade da API de recarregamento para injetar JavaScript durante as transições de página. Veja como funciona:
- Direcionar a webUI: Abrir uma página WebUI (por exemplo, chrome://policy) num separador e anexar DevTools.
- Injetar Script: Use a API reload() com um
Script injetadopara executar JavaScript arbitrário durante o recarregamento. - Explorar a condição de corrida: A condição de corrida ocorre quando o recarregamento é ativado antes da inicialização completa dos mecanismos de segurança da WebUI, permitindo a execução do script injetado.
No contexto da navegação da página about:blank para chrome://policy:
Como apenas o URL é verificado em vez da origem da página, existe um breve período após a navegação em que a origem reflecte a nova página enquanto o URL permanece inalterado.
Se chrome.devtools.inspectedWindow.reload for invocado durante esta janela, pode executar involuntariamente JavaScript na página de destino.
Melhorar a fiabilidade para condições de corrida
A exploração da condição de corrida é inerentemente pouco fiável devido à sua dependência do tempo. Além disso, recargas rápidas ou scripts malformados podem causar falhas na página. Uma nova abordagem para melhorar a confiabilidade envolve induzir intencionalmente uma falha de página, já que os comandos emitidos pelo DevTools são normalmente cancelados durante uma falha, mas Página.recarregar mapeado para chrome.devtools.inspectedWindow.reload() é colocado na lista de permissões e executado após o recarregamento da página.
Segue-se um modelo de fluxo de trabalho para bloquear uma página através do envio de comandos subsequentes:
Declaração do depurador no script de conteúdo pode provocar uma falha
A utilização do depurador duas vezes numa sucessão rápida interrompe o processo de navegação num script de conteúdo. Pode levar a uma falha ao colocar navigation_commit_state_ para um estado não previsto. Este problema surge quando RenderFrameImpl::SincronizarCompromissoSobreBlankForBug778318 é executado, alteração de _navigation_commit_state para um valor inesperado.
A primeira invocação faz uma pausa na execução, deixando navigation_commit_state_ num estado inconsistente, e o segundo faz uma pausa durante a CHECK_EQ falhando a validação do estado e causando uma falha.
Remediação
Negligenciar a atualização regular da versão do seu navegador pode deixar seu dispositivo exposto a sérias ameaças de segurança, especialmente aquelas ligadas a CVEs (Vulnerabilidades e Exposições Comuns). Para ajudar a mitigar esse risco, MetaDefender Endpoint™ oferece proteção robusta detectando a versão do seu navegador e verificando vulnerabilidades, incluindo CVEs conhecidos como CVE-2024-6778.
MetaDefender Endpoint assegura que a sua aplicação está actualizada e assinala quaisquer versões desactualizadas ou infectadas. Também lista as aplicações instaladas com vulnerabilidades conhecidas, categorizadas por gravidade CVE, e recomenda correcções para mitigar eficazmente as potenciais ameaças. Para ver uma demonstração ao vivo de como MetaDefender Endpoint pode ajudá-lo a mitigar esses riscos, entre em contacto com um dos nossos especialistas hoje mesmo.
