Log4Shell: Uma nova correção, detalhes de ataques ativos e recomendações de mitigação de riscos

Views: 856
0 0
Read Time:5 Minute, 5 Second

Devido ao extraordinário uso generalizado da biblioteca Apache Log4j de código aberto, a saga da vulnerabilidade Log4Shell (CVE-2021-44228) está longe de terminar.

Como Dr. Johannes Ullrich, Reitor de Pesquisa do SANS Technology Institute, observou recentemente: “A Log4Shell continuará a nos assombrar nos próximos anos”.

O conselho dele? “Lidar com a Log4Shell será uma maratona. Trate-o como tal.” Então, vamos ver quais são as últimas notícias que podem afetar seus esforços de mitigação e remediação.

Novas versões do Log4j

A recente descoberta de uma segunda vulnerabilidade Log4j (CVE-2021-45046) mostrou que a correção para abordar o CVE-2021-44228 no Apache Log4j 2.15.0 estava incompleta em certas configurações não padrão.

Essa vulnerabilidade pode permitir que atacantes criem dados de entrada maliciosos usando um padrão de Pesquisa JNDI, resultando em um ataque de negação de serviço (DoS).

“Observe que mitigações anteriores envolvendo configuração, como definir a propriedade do sistema ‘log4j2.noFormatMsgLookup’ como ‘verdadeiro’ NÃO mitigam essa vulnerabilidade específica”, observou a equipe de segurança do Apache Log4j.

“O Log4j 2.16.0 corrige esse problema removendo o suporte para padrões de pesquisa de mensagens e desativando a funcionalidade JNDI por padrão. Esse problema pode ser mitigado em versões anteriores (<2.16.0) removendo a classe JndiLookup do classpath (exemplo: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).” A equipe aconselha os usuários a atualizar para a versão 2.12.2 (para Java 7) ou 2.16.0 (para Java 8 ou posterior), na qual o recurso Pesquisas de Mensagens foi removido e o acesso ao JNDI foi desativado por padrão, e explicou por que algumas das medidas de mitigação compartilhadas há alguns dias estão incompletas.

Exploração ativa

PoCs estão constantemente aparecendo no GitHub e sendo bifurcados. O GitHub está trabalhando constantemente na remoção deles, mas o proverbial gato agora está fora do saco, e não há como voltar atrás.

À medida que continuamos a monitorar ameaças aproveitando a vulnerabilidade CVE-2021-44228 Log4j 2, estamos vendo atividades que vão desde experimentação até exploração de vários grupos, incluindo atores do estado-nação e corretores de acesso vinculados ao ransomware: https://t.co/WWSxGvaiDy

— Microsoft Security Intelligence (@MsftSecIntel) 15 de dezembro de 2021

A tentativa de env roubada mais comum foi:
Credenciais da AWS
Credões Docker
Instalações do Hadoob

Cargas úteis de ransomware: 4%
Cargas úteis de criptominadores: 22%
Cargas úteis do ladrão de informações: 61%
Cargas úteis desconhecidas: 13%

Cargas úteis do gadget JDNI: 23%

Cabeçalhos Spray N Pray: 70%
Tentativa Única: 21%
Outros: 9%

— Greg Linares (@Laughing_Mantis) 15 de dezembro de 2021

Pesquisadores do Bitdefender e do F-Secure detalharam as várias cargas úteis maliciosas entregues após a exploração bem-sucedida do Log4Shell: mineiros de moedas, RATs, ransomware, etc.

Como observado por Sean Gallagher, Pesquisador Sênior de Ameaças da Sophos, “os adversários provavelmente estão tendo o máximo de acesso a tudo o que puderem obter agora com o objetivo de monetizar e/ou capitalizá-lo mais tarde”.

Mitigação Log4Shell

A superfície de ataque é extremamente ampla, e os pesquisadores da Check Point detectaram pelo menos 60 variações do código de exploração original usado contra máquinas vulneráveis.

Por meio de sua plataforma de segurança de dispositivos sem agentes, a Armis detectou tentativas de ataque Log4Shell em mais de um terço de seus clientes e continua vendo novos ataques todos os dias. A maioria deles é contra servidores físicos e virtuais e câmeras IP, mas também detectaram tentativas de ataque para fabricar dispositivos (Painéis e Controladores HMI) e sistemas de atendimento (Kronos).

Mitigação Log4Shell
Fonte: Armis

“A maneira como os produtos modernos são construídos está usando uma grande hierarquia de dependências, onde os desenvolvedores usam bibliotecas escritas por empresas e engenheiros terceirizados para acelerar o processo de lançamento de software. Log4J é uma biblioteca extremamente básica que permite a gravação de logs em aplicações Java. A maneira como o CVE-2021-44228 afeta vem em 3 camadas – produtos em nuvem que usam diretamente o Log4J, aplicativos da web que usam bibliotecas que usam o Log4J e software pronto para uso que é implantado internamente em servidores e endpoints de clientes”, diz Michael Assraf, CEO da Vicarius.

“Como a correção e implantação de aplicativos em nuvem podem ser rápidas, atualizar bibliotecas que usam Log4J pode quebrar a funcionalidade, a menos que seja feito com cautela. As correções mais problemáticas são o software implantado internamente, que terá que esperar por uma atualização do fornecedor ou um patch de segurança, nesse cenário, os clientes são aconselhados a esperar por mais orientações do fornecedor e, a partir de agora, estão impotentes para reagir. Exemplos incluem: Elasticsearch, Intellij IDE, Jira Confluence, Apache Tomcat, Minecraft, Apache Hadoop, Eclipse IDE e muito mais.”

Gallagher diz que a prioridade mais imediata para os defensores é reduzir a exposição corrigindo e mitigando todos os cantos de sua infraestrutura e investigando sistemas expostos e potencialmente comprometidos.

“Onde os sistemas foram identificados como vulneráveis, os defensores devem executar um processo de resposta a incidentes e monitorar sinais de trojans de acesso remoto, como retornos de chamada C2. Segredos armazenados em sistemas expostos também devem ser girados, especialmente se estiverem expostos em variáveis de ambiente. Por fim, considere fornecedores críticos de terceiros que também podem estar em risco”, aconselhou ele.

Mathew Eble, vice-presidente de serviços da Praetorian, também alertou que a questão será propensa a falsos negativos.

“Externamente, não há como percorrer todos os caminhos possíveis que a exploração pode tomar. Mesmo quando as ferramentas de digitalização externas ficam mais sofisticadas em como identificam o problema, defendemos fortemente não confiar nos resultados da digitalização como um forte indicador do seu risco”, observou ele.

Esta recomendação é baseada em quatro questões que a empresa confirmou ao trabalhar com clientes. Com base nisso, eles expandiram suas recomendações iniciais para defensores.

Profissionais de segurança que lidam com a situação em suas organizações também são aconselhados a conferir a lista crescente de soluções afetadas e não afetadas da CISA. Outras listas semelhantes estão disponíveis aqui aqui.

FONTE: HELPNET SECURITY

POSTS RELACIONADOS