Thread com soluções finais ou alternativas à falha de segurança do #Log4j 2. Vou atualizando se aparecer algo mais.
Versões impactadas: 2.0-beta9 à 2.14.1.
Antes de tudo, meu total apoio aos contribuidores da biblioteca que, via de regra, fazem isso de graça e no tempo livre.
Primeira e óbvia solução: atualize seus projetos para a versão 2.15.0 ou superior do Log4j 2.
Segundo, fique de olho em todos os projeto e ferramentas que você usa para poder atualizá-las assim que possível.
Para versões >= 2.10, é possível aplicar a system property log4j2.formatMsgNoLookups, ou variável de ambiente LOG4J_FORMAT_MSG_NO_LOOKUPS, ambas com valor true.
https://logging.apache.org/log4j/2.x/security.html
Para versões < 2.10, remova a classe JndiLookup de dentro do log4j. Da pra fazer assim:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
https://logging.apache.org/log4j/2.x/security.html
Se você tem um projeto Maven com um POM acima de outros, pode usar um plugin para forçar a versão do Log4j 2.
Se você tem um projeto Graddle também pode fazer algo parecido.
Se você usa WAF (Web Application Firewall) da Cloudflare, pode mitigar com 3 regras que foram criadas especificamente para essa falha.
https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-mitigation/
O WAS da AWS também já tem uma regra criada para mitigar o risco. A regra foi inserida em AWSManagedRulesKnownBadInputsRuleSet. Mas você tem que ativar e configurar.
https://aws.amazon.com/pt/security/security-bulletins/AWS-2021-005/
Em outros casos é possível criar regras para barrar requisições de entrada que contenham o padrão “${jndi“. O ataque principal tem sido em headers, mas nada impede que esteja em qualquer outro lugar da requisição.
O ataque faz com que seja feita uma chamada para um servidor malicioso. Se o time tem o costume de monitorar conexões relacionadas à JVM, considere verificar se existem conexões novas ou “estranhas” saindo da JVM.
Algumas pessoas apontando o Logout4Shell como uma vacina que usa a própria falha para aplicar uma correção. Eu não entrei em detalhes, então não sei até que ponto funciona.
https://github.com/Cybereason/Logout4Shell
Esse gist tem vários possíveis comandos para saber se tem alguém explorando a vulnerabilidade.
https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
O @volker_simonis iniciou um patch chamado Log4jHotPatch. Ele altera o comportamento de parte do código Java que era usado para abusar da falha. E faz isso em uma JVM em execução, sem precisar pará-la. 👀
Leia e avalie bem antes de usar. 😅
https://github.com/corretto/hotpatch-for-apache-log4j2
Ferramenta para pesquisar se artefatos compilados (zip, war, jar, ear, etc) contém uma versão vulnerável do log4j dentro deles, mesmo que estejam hierarquizados (jar dentro de jar dentro de jar).
https://github.com/mergebase/log4j-detector
Foi lançado o Log4j 2.16.0. Ele corrige mais uma vulnerabilidade, mas dessa vez de gravidade bem menor. O CVSS (nível de gravidade) é 3.7/10, sendo que a falha corrigida na 2.15 era 10/10.
Se você ainda tá no processo de atualização, avalie se compensa já ir para a 2.16.0.
log4j-scan: uma ferramenta para avaliar se aplicações em execução estão comprometidas pela falha, apontando diretamente para suas URLs. Parece uma boa para ser usada por times de segurança/infra/sre.
Originally tweeted by Rinaldo Pitzer Jr. (@rinaldodev) on 11 de December de 2021.