0 
0 A saga Apache Log4j continua, já que várias novas vulnerabilidades foram descobertas na biblioteca popular desde que o Log4Shell (CVE-2021-44228) foi corrigido lançando Log4j v2.15.0.
Há CVE-2021-45046, uma falha DoS/RCE que foi corrigida na v2.16.0, depois CVE-2021-45105, um orifício DoS conectado à v2.17.0. Ah, e há o CVE-2021-4104, uma vulnerabilidade RCE que afeta o Log4j v1.2, que não será corrigida porque a ramificação 1.x atingiu o fim da vida útil.
Mas essas novas revelações não devem fazer você entrar em pânico. Embora o Log4Shell seja explorável na configuração padrão da biblioteca, os outros não são, e a probabilidade de aqueles serem explorados é, de acordo com Satnam Narang, da Tenable, baixa.
Kevin Beaumont, analista de ameaças à segurança, concorda:
Verificação de hype Log4j – a vulnerabilidade Log4j mais recente, hoje CVE-2021-45105:
– só se aplica a configurações *não padrão*
– só permitiria que o processo Java terminasse, sem execução de código.Concentre-se em remediar o Log4Shell e não seja pego no trem de hype de vulnerabilidade.
— Kevin Beaumont (@GossiTheDog) 18 de dezembro de 2021
Haverá foco contínuo nos vulns log4j por algum tempo. É muito importante saber que nem toda nova vulnerabilidade é igual ou provavelmente será explorada.
— Kevin Beaumont (@GossiTheDog) 19 de dezembro de 2021
Portanto, se possível, as organizações devem atualizar todas as instâncias do Log4j para v2.17.0 (para Java 8) e v2.12.2 (para Java 7). Se isso não for possível, os mantenedores do projeto aconselham remover a classe JndiLookup do classpath.
A CISA emitiu na sexta-feira uma diretiva de emergência obrigando as agências federais do poder executivo civil a abordar as vulnerabilidades do Log4j até 28 de dezembro de 2021.
Produtos afetados
Como algumas empresas confirmam tardiamente que seus produtos não são afetados pelas falhas porque não usam a biblioteca Log4j, o Google escaneou o Maven Central, o repositório de pacotes Java mais significativo, e descobriu que mais de 35.000 artefatos Java disponíveis dependem do código log4j afetado.
“As dependências diretas representam cerca de 7.000 dos artefatos afetados, o que significa que qualquer uma de suas versões depende de uma versão afetada do log4j-core ou log4j-api, conforme descrito nos CVEs. A maioria dos artefatos afetados vem de dependências indiretas (isto é, as dependências das próprias dependências), o que significa que log4j não é explicitamente definido como uma dependência do artefato, mas é puxado como uma dependência transitiva”, explicaram James Wetter e Nicky Ringland, da Open Source Insights Team do Google.
“No momento em que escrevo, quase cinco mil dos artefatos afetados foram consertados. Isso representa uma resposta rápida e um esforço gigantesco tanto pelos mantenedores do log4j quanto pela comunidade mais ampla de consumidores de código aberto. Isso deixa mais de 30.000 artefatos afetados, muitos dos quais dependem de outro artefato para corrigir (a dependência transitiva) e provavelmente estão bloqueados.”
O Centro Nacional de Segurança Cibernética Holandês (NCSC-NL) e a CISA estão constantemente atualizando suas listas de produtos afetados.
Vetores de ataque Log4j
Vetores alternativos de ataque Log4Shell estão sendo descobertos. Este, documentado por pesquisadores Blumira, poderia acionar o RCE em aplicativos Log4j internos e expostos localmente não corrigidos.
De acordo com os pesquisadores da AdvIntel Vitali Kremez e Yelisey Boguslavskiy, a gangue de ransomware Conti começou a usar o bug Log4Shell para movimento lateral.
“A exploração atual levou a vários casos de uso através dos quais o grupo Conti testou as possibilidades de utilizar o exploit Log4J2. Mais importante ainda, a AdvIntel confirmou que os criminosos perseguiram visando o vulnerável específico Log4J2 VMware vCenter para movimento lateral diretamente da rede comprometida, resultando no acesso ao vCenter afetando as redes de vítimas dos EUA e da Europa das sessões pré-existentes de Cobalt Strike”, eles compartilharam.
Mitigação de riscos
O tempo é essencial.
“É apenas uma questão de tempo até que Conti e possivelmente outros grupos comecem a explorar o Log4j2 em sua capacidade total. Recomenda-se corrigir o sistema vulnerável imediatamente e ver o Log4j2 como um vetor de exploração em grupo ransomware”, observaram os pesquisadores da AdvIntel.
Os administradores de redes OT também devem trabalhar ativamente na busca e implementação de soluções para protegê-los contra a exploração.
O conselho para os membros do conselho que o Centro Nacional de Segurança Cibernética do Reino Unido publicou na sexta-feira é uma cartilha útil sobre o que as organizações devem fazer no momento.
FONTE: HELPNET SECURITY