This post is also available in: Português
Pesquisadores alertam que a vulnerabilidade severa em bibliotecas de registro Java permite a execução remota de código não autenticado e acesso a servidores.
No dia 09 deste mês, foi publicada uma vulnerabilidade de dia zero crítica no Apache Log4j, rastreada como CVE-2021-244228 e denominada de Log4shell. A vulnerabilidade foi considerada uma das piores da década.
Para quem não conhece, esta é uma ferramenta de logs usada em diversas aplicações Java, o que deixa muitas soluções vulneráveis.
Ela foi classificada como uma vulnerabilidade grave, que permite a execução remota de código não autenticado, pois o usuário que executa o aplicativo utiliza a biblioteca de registro Java.
Durante os dias 11 e 12, foram identificadas diversas evidencias de que a vulnerabilidade está sendo explorada em todo o mundo, e as consequências são as mais diversas, até mesmo a possibilidade de evolução para um sequestro/exfiltração de dados.
A CISA aconselha os usuários e administradores a aplicarem as medidas recomendadas imediatamente para resolver as vulnerabilidades críticas.
A vulnerabilidade afeta as versões 2.0 até a 2.14.1, e pelo fato de ser em uma biblioteca, pode ser explorada em diversas plataformas, incluindo Windows e Linux.
Os pesquisadores alertam que, apesar da vulnerabilidade ter sido descoberta pela primeira vez no Minecraft, os aplicativos em nuvem são vulneráveis. Como os serviços são utilizados em aplicativos corporativos, provavelmente muitos produtos também estão vulneráveis.
As organizações podem identificar se estão vulneráveis examinando os arquivos de log de quaisquer serviços usando as versões afetadas de Log4j. Caso tenham strings controladas pelo usuário, correm risco de serem afetadas.
Realize as atualizações necessárias
A Apache Foundation corrigiu o problema na versão 2.16.0 e a atualização é o caminho recomendado. Para isso, é fundamental contatar os fabricantes das aplicações/softwares utilizados para conduzir o processo, bem como manter os sistemas operacionais devidamente atualizados.
Diversos fabricantes de antivirus/antimalware também já lançaram recursos para a prevenção contra os ataques, é fundamental assegurar que os endpoints estejam devidamente atualizados para evitar quaisquer possibilidades dentro do ambiente.
Na impossibilidade de atualização do Apache Log4j, alguns workarounds devem ser realizados:
- Nas versões 2.10 à 2.14.1: o recurso vulnerável pode ser desativado definindo o parâmetro log4j2.formatMsgNoLookups para “true”. É necessário que o parâmetro esteja na inicialização de scripts do Java Virtual Machine: -Dlog4j2.formatMsgNoLookups=true. Outra possibilidade é usar através de variável de ambiente para forçar a mudança: LOG4J_FORMAT_MSG_NO_LOOKUPS=”true”
- Para ambientes Kubernetes, deve ser usado o “kubectl set env” para definir a variável de ambiente supracitada como “true”. Isso refletirá em todos os pods e containers automaticamente;
- Nas versões 2.0-beta9 até 2.10: remover a classe JndiLookup do classpath com o comando “zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”
Busque seus fornecedores e mantenha o ambiente longe desta vulnerabilidade que é crítica, pois permite a execução remota de código, sem autenticação, e é amplamente utilizada por aplicações Java.
This post is also available in: Português
