Bug de segurança JsonWebToken abre servidores para RCE

Views: 208
0 0
Read Time:4 Minute, 11 Second

Uma vulnerabilidade de alta gravidade ( CVE-2022-23529 ) foi descoberta no popular projeto de criptografia de código aberto JsonWebToken (JWT), que pode ser usado por invasores para obter a execução remota de código (RCE) em um servidor de criptografia de destino.

O padrão aberto JWT define um método de transferência segura de informações codificando e assinando dados JSON. De acordo com os pesquisadores da Unidade 42 da Palo Alto Networks, uma exploração da vulnerabilidade resulta na verificação do servidor de uma solicitação de token da Web JSON criada com códigos maliciosos.

“A execução de código malicioso em um servidor pode levar a um grande dano e perda de confidencialidade, integridade e também pode causar uma negação de serviço”, alerta Artur Oleyarsh, pesquisador de segurança da Unidade 42. “Os sistemas relacionados e se comunicando com o servidor vulnerável também podem sofrer, portanto, o potencial de ataque e as consequências, uma vez que o sistema esteja vulnerável para uma execução remota de código, são significativos”.

O problema representa uma ameaça para todos que usam versões do JWT anteriores e incluindo a v8.5.1. A versão corrigida do pacote é v9.0.0, de acordo com uma postagem de 9 de janeiro da Unit 42.

Oleyarsh explica que geralmente as vulnerabilidades relacionadas aos tokens da Web JSON estão relacionadas a diferentes técnicas de falsificação de token que permitem que um agente mal-intencionado ignore os mecanismos de autenticação e autorização.

“Isso dá a eles [a] oportunidade de assumir contas, personificar usuários e elevar privilégios”, diz ele. No entanto, “esta última vulnerabilidade é única por vários motivos. Primeiro, aqui estamos falando sobre a execução de código em um host que verifica tokens da Web JSON”.

Sob o capô do CVE-2022-23529

Em vez de ignorar os mecanismos de autenticação ou autorização, o bug fornece uma maneira de um ciberatacante obter controle sobre um parâmetro de recuperação de chave da função “jwt.verify” (conhecida como secretOrPublicKey ).

Em uma exploração de prova de conceito, a Unidade 42 foi capaz de substituir o método “toString()” do objeto-chave.

“Em JavaScript, todo objeto que herda de Object.prototype, herda o método toString()”, diz Oleyarsh. “Assim, se houver uma chamada totalmente confiável para esse método e controlarmos o objeto-chave, podemos substituir seu toString () com conteúdo malicioso e executar código arbitrário”.

O uso de código aberto cresce, junto com o nível de ciberameaça

À medida que o uso de software de código aberto (OSS) continua a crescer, também aumenta o interesse do ciberatacante em usar componentes e pacotes de software como o JWT como um vetor de ataque.

“Estamos vendo os agentes de ameaças verificando ativamente vulnerabilidades conhecidas e explorando-as em minutos”, diz Oleyarsh . “Sem atenção e conscientização para a segurança do OSS, acho que veremos mais e mais ataques aproveitando os problemas de segurança do OSS”.

Ele diz que, como comunidade, os profissionais de segurança precisam contribuir e cooperar para tornar o software OSS mais seguro.

“Alguns dos desenvolvedores e mantenedores de OSS estão criando soluções com a segurança em mente, o que significa que eles estão constantemente corrigindo vulnerabilidades de segurança, verificando dependências vulneráveis ​​e mantendo alertas de segurança e publicando-os para que os usuários possam corrigir as versões não vulneráveis. , e alguns deles não são”, observa Oleyarsh.

Cada vez mais, ferramentas foram lançadas para ajudar o gerenciamento de defesa, identidade e acesso, e as equipes do centro de operações de segurança a descobrir componentes vulneráveis. O OSV-Scanner do Google , lançado em dezembro, por exemplo, gera uma lista de dependências em um projeto de desenvolvimento de software e verifica o banco de dados OSV em busca de vulnerabilidades conhecidas.

“Alguns estão fazendo um ótimo trabalho ao criar soluções maravilhosas e criativas para muitos problemas e disponibilizá-los para uso gratuito por qualquer pessoa”, diz Oleyarsh. “Se você está implementando OSS em sua organização, é uma boa prática usar scanners de pacotes OSS para verificar versões vulneráveis ​​de pacotes OSS que você está usando, bem como dependências vulneráveis.”

Enquanto isso, o Google também está colocando seu peso considerável em uma proposta de estrutura política liderada pelo governo dos EUA com o objetivo de reforçar a segurança do software de código aberto, instando o setor privado a apoiar a iniciativa.

De uma perspectiva manual, Oleyarsh acrescenta que as equipes devem examinar regularmente as páginas de avisos de segurança dos projetos OSS que usam para se manterem atualizados sobre os bugs e analisar a implementação de ferramentas de análise de composição de software (SCA) para ajudar a rastrear todos os pacotes e módulos de código aberto usados ​​por um projeto para informar esse processo.

Então, “quando você encontra um bug que tem implicações de segurança, é uma boa prática entrar em contato com os mantenedores por meio de um bate-papo privado e relatar o problema e até mesmo sugerir e discutir a solução”, diz ele.

FONTE: DARK READING

POSTS RELACIONADOS