Linode Security Digest 12-19 de dezembro de 2021

Nota: Este posto foi actualizado em 15 de Dezembro de 2021 e novamente em 20 de Dezembro de 2021.

Esta semana, falaremos sobre a vulnerabilidade de Log4j2 que tem muitas organizações a lutar para corrigir os seus sistemas, mas primeiro, abordaremos algumas preocupações dos nossos clientes relativamente à vulnerabilidade.

Resposta de Linode a Log4j2 

• Avaliámos minuciosamente o âmbito de risco e o impacto desta vulnerabilidade crítica de dia zero em toda a nossa infra-estrutura nas primeiras horas após o lançamento público na sexta-feira, 10 de Dezembro.
• Observámos tentativas falhadas de exploração com a ajuda da nossa arquitectura de defesa de controlo de segurança em profundidade.
• Não observámos quaisquer Indicadores de compromisso relacionados com esta vulnerabilidade no nosso ambiente e estamos continuamente a monitorizar a nossa infra-estrutura para IBCs conhecidas sobre esta vulnerabilidade e outras.

Log4j2 Critical Remote Code Execution Vulnerability (CVE-2021-44228)

O Log4j2 é o sucessor do utilitário de registo Log4j comummente utilizado em Apache . Este componente é escrito em Java e faz parte dos serviços de registo Apache . De acordo com a Oracle, a Java Naming and Directory Interface (JNDI) é uma interface de programação de aplicações (API) que fornece a funcionalidade de nomes e directórios a aplicações escritas em Java. 

Na semana passada, Apache publicou na 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 aos atacantes que podem controlar mensagens de registo ou parâmetros de mensagens de registo executar código arbitrário carregado a partir de servidores LDAP. Na prática, isto é explorável por atacantes externos. Esta vulnerabilidade foi avaliada com uma pontuação CVSS de 10 em 10, uma vez que permite a um atacante executar código arbitrário em cada sistema afectado. Esta questão é mitigada pela actualização 2.15, que desactivou o comportamento de pesquisa do JNDI com base em dois números Jira no início de Dezembro e no final de Novembro. Apache também lançou o 2.17 para abordar outras questões que foram posteriormente encontradas sobre o componente.

Efeitos da Vulnerabilidade

Log4j2 é uma estrutura popular de exploração madeireira Java utilizada por vários fornecedores em numerosos produtos. Esta vulnerabilidade pode ser facilmente explorada através da manipulação da cadeia de utilizadores-agentes dos cabeçalhos de pedidos HTTP e do envio do pedido para sistemas vulneráveis. Embora o User-Agent não seja o único cabeçalho que pode ser utilizado neste tipo de ataque, uma carga útil maliciosa fará com que o componente vulnerável Log4j2 faça disparar uma pesquisa JNDI no servidor malicioso. Quando o URI malicioso incorporado nos cabeçalhos HTTP contém o caminho para um ficheiro de classe Java malicioso, este ficheiro é injectado no processo do servidor e permite que o atacante aceda ao sistema afectado. Múltiplas cargas úteis e desvios estão actualmente a ser observados na natureza, o que torna mais difícil a protecção contra o mesmo utilizando mecanismos de defesa comuns.

Um Diagrama do Ataque

O diagrama seguinte da Equipa de Resposta Informática de Emergência do Governo Suíço pode ajudar a compreender como funciona o ataque e como o mitigar.

Produtos afectados

Muitos vendedores divulgaram declarações para ajudar a mitigar esta vulnerabilidade, e estas declarações poderiam ser um recurso útil para os nossos clientes afectados. Pode encontrar os links abaixo para ler mais sobre os produtos afectados pelos vendedores. Esta não é uma lista completa de todos os produtos afectados. Para uma lista completa dos vendedores afectados e dos seus produtos, pode ver a lista curada pela SwitHak em Github ou outra lista partilhada pela TechSolvency.

• Apache
• Atlassian
• Elástico
• Cisco
• CloudFlare
• Debian
• GitHub
• Site Minecraft
• Oracle
• RedHat
• Cebola de segurança

Métodos Oficiais de Mitigação

Na página de segurança de Log4j, Apache declara que existem múltiplos métodos para abordar esta vulnerabilidade, mas é de notar que estes métodos podem não funcionar da mesma forma em todos os produtos vulneráveis. Para mais informações, consulte a declaração de segurança do vendedor sobre a vulnerabilidade.

• Os utilizadores de Java 8 (ou posterior) devem actualizar para a versão 2.17.0 para lidar com esta vulnerabilidade juntamente com outras vulnerabilidades recentemente encontradas.
• Os utilizadores que necessitem de Java 7 devem actualizar 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 semelhante ao abaixo:

zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class

Temos orgulho em partilhar o conhecimento com a nossa comunidade para ajudá-los a mitigar as vulnerabilidades, sejam elas tão críticas como esta ou menos impactantes. Sinta-se à vontade para deixar um comentário abaixo para partilhar as suas ideias e sugestões.