Há algumas semanas, a notícia dos problemas de segurança do Log4j estava virando muitos usuários da rede de ponta-cabeça e é uma das falhas mais exploradas e que muitos especialistas rotularam como "as mais perigosas em muito tempo", Das vulnerabilidades que foram divulgadas na rede, falamos sobre algumas delas aqui no blog e desta vez encontramos notícias de outro.
E é isso há poucos dias foi divulgada a notícia de que outra vulnerabilidade foi identificada na biblioteca Log4j 2 (que já está listado em CVE-2021-45105) e que, ao contrário dos dois problemas anteriores, foi classificado como perigoso, mas não crítico.
O novo problema permite uma negação de serviço e se manifesta na forma de loops e terminações anormais ao processar certas linhas.
Vulnerabilidade afeta sistemas que usam pesquisa de contexto, como $ {ctx: var}, para determinar o formato de saída do log.
Os Log4j versões 2.0-alpha1 a 2.16.0 não tinham proteção contra recursão não controlada, Que permitiu que um invasor manipulasse o valor usado na substituição para causar um loop infinito que ficaria sem espaço na pilha e faria com que o processo travasse. Em particular, o problema ocorreu ao substituir valores como "$ {$ {:: - $ {:: - $$ {:: - j}}}}".
Além disso, Pode-se notar que pesquisadores de Blumira propuseram um ataque a aplicativos Java vulneráveis. que não aceitam solicitações de redes externas, por exemplo, sistemas de desenvolvedores ou usuários de aplicativos Java podem ser atacados desta forma.
A essência do método é que, se houver processos Java vulneráveis no sistema do usuário que aceita conexões de rede apenas do host local (localhost), ou processa solicitações RMI (Remote Method Invocation, port 1099), o ataque pode ser executado por código JavaScript executado quando o usuário abre uma página maliciosa no navegador. Para estabelecer uma conexão com a porta de rede de um aplicativo Java em tal ataque, a API WebSocket é usada, à qual, ao contrário das solicitações HTTP, nenhuma restrição de mesma origem é aplicada (WebSocket também pode ser usado para escanear portas de rede no local host para determinar os drivers de rede disponíveis).
Os resultados da avaliação da vulnerabilidade das bibliotecas associadas às dependências do Log4j publicadas pelo Google também são de interesse. De acordo com o Google, o problema afeta 8% de todos os pacotes no repositório Maven Central.
Em particular, 35863 pacotes Java relacionados ao Log4j com dependências diretas e indiretas foram expostos a vulnerabilidades. Por sua vez, Log4j é usado como dependência direta de primeiro nível apenas em 17% dos casos, e em 83% dos pacotes cobertos pela vulnerabilidade, o binding é feito por meio de pacotes intermediários que dependem do Log4j, ou seja, tell. dependências do segundo e nível mais alto (21% - o segundo nível, 12% - o terceiro, 14% - o quarto, 26% - o quinto, 6% - o sexto).
O índice de reparo da vulnerabilidade ainda deixa muito a desejar, uma semana depois de identificada a vulnerabilidade, dos 35863 pacotes identificados, o problema foi corrigido até o momento apenas em 4620, ou seja, para 13%.
Mudanças nos pacotes são necessárias para atualizar os requisitos de dependência e substituir as ligações da versão antiga por versões fixas do Log4j 2 (os pacotes Java praticam a ligação a uma versão específica e não a um intervalo aberto que permite a instalação da versão mais recente).
A eliminação da vulnerabilidade em aplicativos Java é dificultada pelo fato de que os programas geralmente incluem uma cópia das bibliotecas na entrega e não é suficiente atualizar a versão Log4j 2 nos pacotes do sistema.
Enquanto isso, a Agência dos Estados Unidos para Proteção de Infraestrutura e Cibersegurança emitiu uma diretiva de emergência exigindo que as agências federais identifiquem os sistemas de informação afetados pela vulnerabilidade Log4j e instalem atualizações que bloqueiam o problema. Antes de 23 de dezembro.
Por outro lado, foi dada uma orientação até 28 de dezembro, em que as organizações tinham a obrigação de relatar os trabalhos realizados. Para simplificar a identificação de sistemas problemáticos, foi elaborada uma lista de produtos em que foi confirmada a manifestação de uma vulnerabilidade (existem mais de 23 mil aplicações na lista).
Finalmente, Vale ressaltar que a vulnerabilidade foi corrigida no Log4j 2.17 que foi publicado há poucos dias e os usuários que têm as atualizações desabilitadas são recomendados a realizar a atualização correspondente, além do fato de que o perigo da vulnerabilidade é mitigado pelo fato de o problema se manifestar apenas em sistemas com Java 8.
fonte: https://logging.apache.org/