A vulnerabilidade de zero dia do Log4Shell (CVE-2021-44228) na estrutura de log Java Log4j (versões 2.0 a 2.14.1) foi revelada em 9 de dezembro de 2021. A Apache Foundation atribuiu a pontuação máxima de CVSS de 10 ao Log4Shell, como milhões de servidores e, potencialmente, bilhões de dispositivos ficaram sob risco. Profissionais de segurança de todo o mundo começaram a corrigir a vulnerabilidade e escanear seus sistemas para descartar qualquer possível violação.

Como os ataques acontecem

• A vulnerabilidade é uma vulnerabilidade de validação de entrada, em que as pesquisas são processadas automaticamente, nesta instância, por meio do recurso JNDI.
  
• Um invasor hospeda uma classe Java vulnerável em um servidor remoto.  
  
• O invasor injeta uma mensagem de log vulnerável que carrega uma classe de seu servidor no aplicativo, que executa o código vulnerável no servidor de destino.
  
• Como a formatação é aninhada, a cascata de eventos pode ser serializada para expor rapidamente um grande volume de dados.
  
• Como o Log4j é usado em aplicativos cliente e servidor, ele os torna igualmente vulneráveis, pois qualquer entrada do usuário pode ser analisada pelo Log4j.

Embora a equipe do Apache tenha removido a vulnerabilidade e, para segurança adicional, também tenha desabilitado o recurso de pesquisa remota do Log4j v 2.16.0 em diante, a versão mais segura agora é o Log4j 2.17.1 e superior. Devido ao uso extensivo do Log4j como uma estrutura de registro preferencial (Java é executado em quase 3 bilhões de dispositivos), a vulnerabilidade do Log4Shell continua sendo relevante em 2022, à medida que as equipes de segurança de TI correm para evitar tentativas repetidas de ataque e, por outro lado, potencialmente espera-se que multas altas sejam cobradas por descumprimento. Isso precisa de uma abordagem holística para corrigir todos os componentes expostos à Internet, incluindo integrações de terceiros.

Como corrigi-lo

• Remendar primeiro. Em seguida, aplique firewalls, desative as pesquisas remotas. Todos os códigos voltados para a Internet com versões antigas do Log4j precisam de verificação e correção urgentes, incluindo uma correção abrangente em todas as instâncias nos servidores em nuvem.
  
• Considere o modelo Isolar, Minimizar, Monitorar e Defesa Ativa (IMMA).
  
• Os atacantes sempre deixam pegadas. Procure picos de CPU, alterações de configuração não autorizadas, logs e comandos inesperados ou comportamento não natural em conexões de rede, picos de volume ou interrupções suspeitas.

Sete lições

1. Adote uma cultura DevSecOps em que desenvolvedores, profissionais de segurança e equipes de operações desenvolvem uma forte colaboração e trabalham juntos para discutir, identificar, corrigir e evitar vulnerabilidades.
   
2. Escolha ferramentas de solução de problemas robustas e aprovadas e evite ferramentas gratuitas de fontes online não verificadas, pois elas podem piorar a situação e expor seus sistemas a outras explorações. Conheça sua superfície de ataque e execute a análise de código estático para detectar vulnerabilidades no nível do código-fonte.
   
3. Adote práticas seguras de desenvolvimento de software. Foco no desenvolvimento de código enxuto. Forneça recursos inesperados como recursos opcionais para reduzir ainda mais as brechas. Projete bibliotecas de software simples e componha outras bibliotecas sobre elas de maneira robusta, sem funcionalidades desnecessárias.
   
4. Implemente uma rotina de correção imediata, centralizada e automatizada de versões de software e um monitoramento completo de todos os componentes expostos para ficar à frente das vulnerabilidades.
   
5. Analise o uso do Log4j em todos os sistemas. Ubiquidade, longevidade, prevalência e uso não monitorado do Log4j em um número tão grande de instâncias tornaram isso um problema global. Analise todas as bibliotecas, de código aberto e fechadas, em busca de vulnerabilidades semelhantes e corrija-as proativamente antes que os invasores as encontrem.
   
6. Aplique um modelo Zero Trust em suas práticas de gerenciamento de dados, que é uma filosofia baseada no princípio de privilégio mínimo de “verificar primeiro, depois confiar”.
   
7. Use o código aberto com sabedoria. Como o Log4j é de código aberto, uma crítica é que seu código legado infundado é inseguro e usado por muitos desenvolvedores sem pensar. No entanto, o lado positivo do código aberto é que, por estar disponível gratuitamente, pode ser prontamente corrigido e compartilhado pela comunidade.

Também é prudente entender que a vulnerabilidade do Log4j é apenas uma entre muitas, e mais estão esperando para serem expostas. Especialistas alertam que, embora o pior pareça ter passado, é muito cedo para continuar como de costume. A solução geral está não apenas em corrigir o Log4j para as versões mais recentes, mas também em executar uma varredura completa de todos os sistemas de TI com servidores expostos e componentes de nuvem. Uma revisão completa das práticas de segurança para estabelecer um novo livro de códigos também é imperativa.

As soluções de monitoramento em nuvem, incluindo Site24x7 , entendem a gravidade da vulnerabilidade e verificam imediatamente seus sistemas para descartar explorações. Além disso, quando os aplicativos enfrentam a vulnerabilidade do Log4j, o APM Insight do Site24x7 possui um agente Java integrado que os detecta imediatamente e os exibe no console central do APM.

Você pode experimentar o Site24x7 dentro da sua empresa sem custo algum. Que tal realizar esse teste agora?

Conheça na prática como o Site24x7 pode ajudar você e o seu negócio. Nossos técnicos estão disponíveis para te apresentar a melhor solução de monitoramento em nuvem para sua infraestrutura, conte sempre com o apoio da equipe ACSoftware.

ACSoftware / Figo Software seu Distribuidor e Revenda ManageEngine no Brasil

Fone (11) 4063 1007 – Vendas (11) 4063 9639