0
0
Um bug crítico de execução remota de código (RCE) em uma estrutura de máquina virtual Java (JVM) de software livre ameaça os ambientes corporativos, oferecendo aos invasores uma maneira fácil de comprometer as equipes de desenvolvimento, obtendo acesso aos sistemas de produção.
Isso é de acordo com Joseph Beeton, pesquisador sênior de segurança de aplicativos da Contrast Security, que descobriu a vulnerabilidade no Quarkus, uma estrutura Java nativa do Kubernetes gerenciada pela Red Hat e otimizada para JVMs.
O bug é rastreado como CVE-2022-4116 e recebeu uma classificação de 9,8 no CVSS.
A estrutura relativamente nova do Quarkus é usada como uma plataforma para ambientes sem servidor, em nuvem e Kubernetes – o último dos quais é a plataforma de gerenciamento de contêiner de fato para ambientes nativos de nuvem e teve vários problemas de segurança próprios.
A falha do Quarkus está presente no Dev UI Config Editor do framework, tornando-o vulnerável a ataques drive-by localhost que podem levar ao RCE, Beeton escreveu em um post de blog publicado em 29 de novembro . Além disso, “explorar a vulnerabilidade não é difícil e pode ser feito por um agente mal-intencionado sem nenhum privilégio”, observou ele no post.
Beeton descobriu a vulnerabilidade algumas semanas atrás enquanto preparava uma palestra para a conferência DeepSec recentemente realizada , mas diz que esperou para divulgar suas descobertas até que a Red Hat publicasse detalhes da falha em seu portal de suporte ao cliente em 21 de novembro. Beeton também publicou uma prova de exploração de conceito para CVE-2022-4116 em seu post.
As versões corrigidas do Quarkus, disponíveis agora, são 2.14.2.Final e 2.13.5.Final (LTS); qualquer pessoa que use a estrutura é incentivada a atualizar imediatamente.
Falha de segurança ‘perigosa’
A vulnerabilidade afeta o pacote “quarkus_dev_ui”, de acordo com a Red Hat, o que significa que afeta os desenvolvedores que constroem serviços usando o Quarkus, não os serviços reais em execução na produção.
No entanto, ainda é perigoso por vários motivos – por um lado, porque é bastante fácil de explorar e por outro porque os desenvolvedores geralmente têm acesso direto ao ambiente de produção de uma empresa, disse Beeton ao Dark Reading.
“Os desenvolvedores geralmente têm acesso aos sistemas de produção e, mesmo que não tenham, podem fazer alterações no código”, diz ele. “A máquina de um desenvolvedor comprometido pode ser aproveitada para enviar alterações de código malicioso para produção.”
Por exemplo, se um desenvolvedor que executa o Quarkus localmente visita um site com JavaScript malicioso, esse JavaScript pode executar código silenciosamente na máquina do desenvolvedor, o que pode levar a todos os tipos de problemas em qualquer rede ou ativos conectados a ele.
Em ambientes corporativos baseados em nuvem, os desenvolvedores geralmente precisam codificar bases, chaves do Amazon Web Services, credenciais de servidor e outros ativos, disse Beeton em sua postagem.
“O acesso à máquina do desenvolvedor dá ao invasor uma grande margem de manobra para outros recursos na rede, bem como para modificar ou roubar totalmente a base de código”, escreveu ele.
O bug em um contexto de segurança em nuvem
A falha deve ser entendida no contexto de pegadas baseadas em nuvem que possuem vários serviços hospedados em execução em um ambiente maior, explicou Beeton. Um equívoco sobre esse tipo de arquitetura é que “os serviços vinculados apenas ao host local não são acessíveis do mundo externo”, observou ele em seu post.
“Devido a essa crença equivocada, os desenvolvedores, por conveniência, executarão os serviços que estão desenvolvendo que são configurados de maneira menos segura em comparação com a maneira como eles [normalmente] o fariam”, escreveu ele.
Não há problema com esse cenário no caso de acessar JavaScript normal em um navegador e carregado de um domínio não malicioso, disse ele. Nesse caso, o JavaScript não seria capaz de fazer solicitações para outros domínios, incluindo localhost, sem uma solicitação de comprovação usada para verificar as configurações de compartilhamento de recursos entre origens (CORS) do servidor. Esta é uma verificação padrão para ver se o servidor permite solicitações do domínio que está sendo acessado.
No entanto, no caso de um determinado tipo de solicitação que não requer uma solicitação de comprovação – chamada de Solicitações Simples – a falha entra em jogo, disse Beeton.
“Para uma solicitação simples, o navegador faz a solicitação, recebe a resposta, mas esses dados – incluindo o código de status HTTP – não são retornados ao JavaScript”, escreveu ele. “É possível, no entanto, inferir se a solicitação foi bem-sucedida com base no tempo que demorou para retornar. Dentro dessas restrições, é possível acessar localhost e, em determinadas circunstâncias, acionar a execução de código arbitrário.”
Várias maneiras pelas quais os desenvolvedores podem ser direcionados
Se for esse o caso, os agentes de ameaças podem comprometer sites que os desenvolvedores usam injetando JavaScript malicioso em anúncios veiculados nos sites. Para um ataque à falha do Quarkus ser bem-sucedido nesse cenário, alguém que esteja executando o Quarkus no modo de desenvolvedor teria que visitar um site contendo o JavaScript malicioso, disse Beeton.
Dessa forma, os invasores podem acessar o código do desenvolvedor por meio de solicitações HTTP não simuladas para os serviços vinculados ao localhost, explicou ele.
“Requer apenas que o Quarkus esteja sendo executado no modo de desenvolvedor no mesmo ponto em que a guia do navegador está aberta”, observou ele. “Nenhuma outra interação é necessária para que esta vulnerabilidade seja explorada.”
Os invasores também podem explorar a falha lançando um ataque de phishing que convence um desenvolvedor a abrir um navegador da Web em uma página comprometida. “Se eles estiverem executando o Quarkus no modo de desenvolvedor, comprometê-los significaria apenas fazer com que eles clicassem no link; a página contendo JavaScript malicioso seria carregada e eles seriam comprometidos”, explicou Beeton.
Outras maneiras pelas quais a falha pode ser explorada são por meio de configurações incorretas comuns na estrutura Spring, que fornece um modelo abrangente de programação e configuração para aplicativos empresariais modernos baseados em Java, disse ele. Como alternativa, um invasor pode explorar vulnerabilidades conhecidas para gerar um RCE na máquina do desenvolvedor ou em outros serviços em sua rede privada.
Impacto potencial e correção
Há duas boas notícias em torno do status da falha, reconheceu Beeton. Uma delas é que a equipe Quarkus da Red Hat, como mencionado anteriormente, já emitiu uma correção que requer que o Dev UI verifique os cabeçalhos de origem para “origin: localhost” — que é definido pelo próprio navegador e não modificável por JavaScript — e aceita apenas esses pedidos, disse ele.
O outro aspecto reconfortante é que o Quarkus é um framework jovem, tendo sido lançado em 2019, então provavelmente não será usado tão extensivamente quanto, digamos, o framework Spring Boot de código aberto , disse ele.
E embora o Quarkus esteja ganhando popularidade, principalmente para os entusiastas do Kubernetes , “dada sua facilidade de uso e demanda significativamente mais leve de recursos de hardware para executar e executar aplicativos”, ele ainda não é tão amplamente usado quanto o próprio Kubernetes , disse Beeton.
“Portanto, o número de desenvolvedores afetados por esse ataque de host local é provavelmente pequeno”, disse ele.
Esmagando o vetor de ataque
Mesmo com a falha do Quarkus corrigida, os desenvolvedores que usam estruturas de código aberto ainda devem ser cautelosos ao desenvolver serviços por meio do host local, pois provavelmente há mais vulnerabilidades equivalentes ao CVE-2022-4116 que ainda não foram encontradas, alertou Beeton.
Uma solução para todo o vetor de ataque está no horizonte com a nova especificação PNA ( Private Network Access ) do W3C, que eventualmente será integrada aos navegadores para eliminar completamente esse modo de exploração, disse ele.
Atualmente, no entanto, apenas a equipe que oferece suporte à estrutura do Chromium – a base para os navegadores Chrome e Edge – está trabalhando ativamente para implementar a nova especificação, disse Beeton. Na verdade, o lançamento planejado para meados de dezembro do Chrome 109 deve incluir suporte para PNA.
O Firefox, por sua vez, tem suporte PNA em sua lista de pendências , mas ainda não agendou uma data de lançamento, enquanto os planos para adicionar a especificação ao Safari ou Edge permanecem incertos, embora a atualização do Chromium possa ser um bom presságio para sua próxima adição no Edge, acrescentou.
FONTE: DARK READING