CVE-2021-44228

Este é o Log4Shell, e ele merece cada fração de seu 10.0. A substituição por message lookup do Log4j2 resolve referências JNDI controladas pelo atacante, de modo que qualquer string que um atacante consiga registrar em log — um User-Agent, um campo de formulário, uma mensagem de chat — pode apontar o logger para um endpoint LDAP hostil e carregar código remoto. O atacante não precisa alcançar um endpoint especial; basta colocar texto em uma linha de log, que é quase toda a superfície de ataque de um aplicativo moderno. Não autenticado, remoto, disparado trivialmente.

O ritmo no mundo real aqui foi histórico: em questão de dias após a divulgação, isso passou de prova de conceito a exploração em massa indiscriminada por botnets, grupos de ransomware e atores estatais igualmente, porque o componente vulnerável está enterrado dentro de uma fração assombrosa do software Java e o gatilho é fácil demais de contrabandear. A dificuldade definidora nunca foi entender o bug — foi que o log4j-core se esconde no fundo de dependências transitivas, dentro de appliances e produtos de fornecedores onde os operadores nem sabiam que ele residia. Observe a delimitação: trata-se especificamente do log4j-core, não do log4net, log4cxx ou de outros projetos do Logging Services.

Este é o caso canônico do inventário profundo de dependências sobre a varredura de superfície, e é exatamente onde justificamos nosso valor. A jogada vencedora é responder, em tudo o que executamos e em tudo o que nossos fornecedores nos entregam, onde o log4j-core está embutido e em qual versão — incluindo as cópias transitivas e enterradas em appliances que nenhuma varredura simples de ativos revela. Até que uma instalação seja confirmada em uma versão corrigida (2.16.0 ou os backports 2.12.2/2.12.3/2.3.1, sendo a 2.15.0 apenas um passo parcial), tratamos os serviços Java acessíveis pela internet como alvos e combinamos a aplicação de patches com filtragem de egresso para LDAP hostil como patch virtual.