Explorações PoC aumentam os riscos em torno da nova vulnerabilidade crítica do Jenkins

Explorações PoC aumentam os riscos em torno da nova vulnerabilidade crítica do Jenkins

As explorações de PoC aumentam os riscos em torno da nova inteligência de dados crítica do Jenkins Vuln PlatoBlockchain. Pesquisa vertical. Ai.

Cerca de 45,000 servidores Jenkins expostos à Internet permanecem sem correção contra uma vulnerabilidade crítica de leitura de arquivos arbitrária recentemente divulgada, para a qual o código de prova de exploração está agora disponível publicamente.

CVE-2024-23897 afeta a interface de linha de comando (CLI) integrada do Jenkins e pode levar à execução remota de código nos sistemas afetados. A equipe de infraestrutura do Jenkins divulgou a vulnerabilidade e lançou uma versão atualizada do software em 24 de janeiro.

Explorações de prova de conceito

Desde então, exploração de prova de conceito (PoC) o código da falha ficou disponível e há alguns relatos de invasores tentando ativamente explorar isto. Em 29 de janeiro a organização sem fins lucrativos ShadowServer que monitora a Internet em busca de atividades maliciosas relatou observar cerca de 45,000 Instâncias de Jenkins expostas à Internet que são vulneráveis ​​ao CVE-2024-23897. Quase 12,000 das instâncias vulneráveis ​​estão localizadas nos EUA; A China tem quase o mesmo número de sistemas vulneráveis, de acordo com dados do ShadowServer.

Muitas equipes de desenvolvimento de software empresarial usam Jenkins para construir, testar e implantar aplicativos. Jenkins permite que as organizações automatizem tarefas repetitivas durante o desenvolvimento de software – como testes, verificações de qualidade de código, verificação de segurança e implantação – durante o processo de desenvolvimento de software. Jenkins também é frequentemente usado em ambientes de integração contínua e implantação contínua.

Os desenvolvedores usam a CLI do Jenkins para acessar e gerenciar o Jenkins a partir de um script ou ambiente shell. CVE-2024-23897 está presente em um recurso de analisador de comando CLI que é habilitado por padrão nas versões 2.441 e anteriores do Jenkins e no Jenkins LTS 2.426.2 e anteriores.

“Isso permite que os invasores leiam arquivos arbitrários no sistema de arquivos do controlador Jenkins usando a codificação de caracteres padrão do processo do controlador Jenkins”, disse a equipe Jenkins no 24 de janeiro consultivo. A falha permite que um invasor com permissão Geral/Leitura – algo que a maioria dos usuários do Jenkins exigiria – leia arquivos inteiros. Um invasor sem essa permissão ainda seria capaz de ler as primeiras linhas dos arquivos, disse a equipe Jenkins no comunicado.

Vários vetores para RCE

A vulnerabilidade também coloca em risco arquivos binários contendo chaves criptográficas usadas para vários recursos do Jenkins, como armazenamento de credenciais, assinatura de artefatos, criptografia e descriptografia e comunicações seguras. Em situações em que um invasor possa explorar a vulnerabilidade para obter chaves criptográficas de arquivos binários, vários ataques são possíveis, alertou o comunicado do Jenkins. Isso inclui ataques de execução remota de código (RCE) quando a função URL raiz do recurso está habilitada; RCE através do cookie “Lembrar-me”; RCE através de ataques de script entre sites; e ataques remotos de código que ignoram as proteções contra falsificação de solicitações entre sites, disse o comunicado.

Quando os invasores podem acessar chaves criptográficas em arquivos binários via CVE-2024-23897, eles também podem descriptografar segredos armazenados no Jenkins, excluir dados ou baixar um heap dump Java, disse a equipe do Jenkins.

Pesquisadores da SonarSource que descobriram a vulnerabilidade e relataram à equipe Jenkins descreveu a vulnerabilidade como permitir que até mesmo usuários não autenticados tenham pelo menos permissão de leitura no Jenkins sob certas condições. Isso pode incluir a habilitação da autorização no modo herdado, ou se o servidor estiver configurado para permitir acesso de leitura anônimo, ou quando o recurso de inscrição estiver habilitado.

Yaniv Nizry, pesquisador de segurança do Sonar que descobriu a vulnerabilidade, confirma que outros pesquisadores conseguiram reproduzir a falha e têm um PoC funcional.

“Como é possível explorar a vulnerabilidade não autenticada, até certo ponto, é muito fácil descobrir sistemas vulneráveis”, observa Nizry. “Com relação à exploração, se um invasor estiver interessado em elevar a leitura arbitrária do arquivo à execução do código, seria necessário um conhecimento mais profundo do Jenkins e da instância específica. A complexidade da escalada depende do contexto.”

As novas versões 2.442 do Jenkins e versão 2.426.3 do LTS resolvem a vulnerabilidade. As organizações que não podem atualizar imediatamente devem desabilitar o acesso CLI para evitar a exploração, disse o comunicado. “Fazer isso é altamente recomendado para administradores que não conseguem atualizar imediatamente para Jenkins 2.442, LTS 2.426.3. A aplicação desta solução alternativa não requer a reinicialização do Jenkins.”

Remendar agora

Sarah Jones, analista de pesquisa de inteligência sobre ameaças cibernéticas da Critical Start, diz que as organizações que usam Jenkins fariam bem em não ignorar a vulnerabilidade. “Os riscos incluem roubo de dados, comprometimento do sistema, pipelines interrompidos e potencial para lançamentos de software comprometidos”, diz Jones.

Um motivo de preocupação é o fato de que ferramentas DevOps, como Jenkins, muitas vezes podem conter dados críticos e confidenciais que os desenvolvedores podem trazer de ambientes de produção ao criar ou desenvolver novos aplicativos. Um exemplo disso ocorreu no ano passado, quando um pesquisador de segurança encontrou um documento contendo 1.5 milhão de pessoas na lista de exclusão aérea da TSA sentado desprotegido em um servidor Jenkins, pertencente à CommuteAir, com sede em Ohio.

“A correção imediata é crucial; atualizar para as versões 2.442 ou posterior do Jenkins (não-LTS) ou 2.427 ou posterior (LTS) aborda CVE-2024-23897”, diz Jones. Como prática geral, ela recomenda que as organizações de desenvolvimento implementem um modelo de privilégio mínimo para limitar o acesso, e também façam varredura de vulnerabilidades e monitoramento contínuo de atividades suspeitas. Jones acrescenta: “Além disso, promover a conscientização sobre segurança entre desenvolvedores e administradores fortalece a postura geral de segurança”.

Carimbo de hora:

Mais de Leitura escura