Nota: Este posto foi atualizado em 15 de dezembro de 2021 e novamente em 20 de dezembro de 2021.
Esta semana, falaremos sobre a vulnerabilidade do Log4j2 que tem muitas organizações que se esforçam para consertar seus sistemas, mas primeiro, abordaremos algumas preocupações de nossos clientes com relação à vulnerabilidade.
Resposta da Linode ao Log4j2
- Avaliamos cuidadosamente o escopo de risco e o impacto desta vulnerabilidade crítica de dia zero em toda nossa infra-estrutura nas primeiras horas após o lançamento público na sexta-feira, 10 de dezembro.
- Observamos tentativas fracassadas de exploração com a ajuda de nossa arquitetura de defesa de controle de segurança em profundidade.
- Não observamos nenhum indicador de compromisso relacionado a esta vulnerabilidade em nosso ambiente e estamos continuamente monitorando nossa infra-estrutura para as IoCs conhecidas sobre esta vulnerabilidade e outras.
Log4j2 Critical Remote Code Execution Vulnerability (CVE-2021-44228)
O Log4j2 é o sucessor do utilitário de registro em Apache Log4j, comumente usado. Esse componente é escrito em Java e faz parte dos serviços de registro em log do site Apache . De acordo com a Oracle, a Java Naming and Directory Interface (JNDI) é uma interface de programação de aplicativos (API) que fornece funcionalidade de nomeação e diretório para aplicativos escritos em Java.
Na semana passada, Apache publicou em sua página de vulnerabilidades de segurança Log4j que as versões log4j-core entre 2.0-beta9 e 2.14.1 contêm uma grave vulnerabilidade. Esta vulnerabilidade permite que atacantes que podem controlar mensagens de log ou parâmetros de mensagens de log possam executar código arbitrário carregado a partir de servidores LDAP. Na prática, isto é explorável por atacantes externos. Esta vulnerabilidade foi classificada com uma pontuação CVSS de 10 em 10, pois permite que um atacante execute um código arbitrário em cada sistema afetado. Esta questão é mitigada pela atualização 2.15, que desabilitou o comportamento de busca do JNDI com base em duas edições do Jira no início de dezembro e final de novembro. Apache também lançou o 2.17 para tratar de outras questões que foram encontradas posteriormente sobre o componente.
Efeitos da Vulnerabilidade
Log4j2 é uma estrutura popular de exploração madeireira Java utilizada por vários fornecedores através de numerosos produtos. Esta vulnerabilidade pode ser facilmente explorada manipulando a seqüência de cabeçalhos de solicitação HTTP do usuário-agente e enviando a solicitação para sistemas vulneráveis. Embora o User-Agent não seja o único cabeçalho que pode ser usado neste tipo de ataque, uma carga útil maliciosa fará com que o componente vulnerável Log4j2 acione uma busca JNDI no servidor malicioso. Quando o URI malicioso embutido nos cabeçalhos HTTP contém o caminho para um arquivo de classe Java malicioso, este arquivo é injetado no processo do servidor e permite que o atacante acesse o sistema afetado. Múltiplas cargas e desvios estão sendo observados atualmente na natureza, o que torna mais difícil a proteção contra ele usando mecanismos de defesa comuns.
Um Diagrama do Ataque
O seguinte diagrama da equipe de resposta a emergências informáticas do governo suíço pode ajudar a entender como funciona o ataque e como mitigá-lo.
Produtos afetados
Muitos fornecedores divulgaram declarações para ajudar na mitigação desta vulnerabilidade, e estas declarações poderiam ser um recurso útil para nossos clientes afetados. Você pode encontrar os links abaixo para ler mais sobre os produtos afetados pelos fornecedores. Esta não é uma lista completa de todos os produtos afetados. Para uma lista completa dos fornecedores afetados e seus produtos, você pode ver a lista curada pela SwitHak no Github ou outra lista compartilhada pela TechSolvency.
Métodos Oficiais de Mitigação
Na página de segurança do Log4j, Apache afirma que existem vários métodos para lidar com essa vulnerabilidade, mas deve-se observar que esses métodos podem não funcionar da mesma forma em todos os produtos vulneráveis. Favor consultar a declaração de segurança do fornecedor sobre a vulnerabilidade para mais informações.
- Os usuários do Java 8 (ou posterior) devem atualizar para a versão 2.17.0 para lidar com esta vulnerabilidade juntamente com outras vulnerabilidades recentemente encontradas.
- Os usuários que requerem Java 7 devem atualizar para a versão 2.12.2.
- Se estes dois passos não forem possíveis, a mitigação é remover a classe JndiLookup do classpath (mostrado como log4j-core-*.jar) usando um comando similar ao abaixo:
zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.classTemos orgulho de compartilhar o conhecimento com nossa comunidade para ajudá-los a mitigar as vulnerabilidades, sejam elas tão críticas quanto esta ou menos impactantes. Sinta-se à vontade para deixar um comentário abaixo para compartilhar suas idéias e sugestões.
Comentários