0 
0 
Fonte: WizPDF
As organizações que trabalham para reduzir a exposição a ataques direcionados à vulnerabilidade Log4j de execução remota de código (RCE) divulgada em 9 de dezembro têm algumas novas considerações a ter em mente.
Pesquisadores de segurança da Blumira descobriram que os atores de ameaças podem potencialmente desencadear a falha RCE em aplicativos Log4j internos e expostos localmente por meio de uma conexão JavaScript WebSocket — sugerindo que a superfície de ataque pode ser muito maior do que se pensava. Enquanto isso, a Apache Foundation lançou mais uma atualização para corrigir uma terceira vulnerabilidade na estrutura de registro nos últimos dias, o que significa que as organizações precisarão mais uma vez corrigir seu software para permanecer totalmente protegidas contra a ameaça.
De acordo com Blumira, os invasores podem explorar a falha do Log4j RCE atraindo usuários para qualquer servidor que execute JavaScript para iniciar uma conexão WebSocket. WebSocket é um protocolo de comunicação que muitos navegadores modernos usam para comunicação bidirecional entre o servidor e o cliente. O site faria chamadas para o sistema do usuário ou rede local usando o WebSocket. Se o host da vítima for vulnerável, ela será forçada a chamar outro site controlado por invasores sobre LDAP, RMI, DNS, HTTP ou outro protocolo e baixar JavaScript malicioso para explorar o Log4j RCE, diz Matthew Warner, CTO e cofundador da Blumira.
“Se a vítima tivesse uma versão vulnerável do Log4j e estivesse desconectando solicitações para caminhos solicitados e/ou a origem dessas solicitações, isso acionaria a pesquisa Log4j JNDI para o host malicioso”, diz Warner. “Nenhum esforço adicional seria necessário.”
Warner diz que a pesquisa de Blumira mostra que o impacto do Log4j não se limita a servidores vulneráveis.
“Qualquer pessoa com um serviço que utilize uma versão vulnerável do Log4j em sua máquina ou rede privada local pode navegar em um site e potencialmente desencadear a vulnerabilidade”, diz Warner. Expande significativamente a superfície de ataque e é outra arma que os operadores de phishing e golpes de publicidade maliciosa provavelmente explorarão, diz ele.
O novo vetor de ataque não deve complicar as coisas para organizações que já estão seguindo as etapas de correção recomendadas para o Log4j. “No entanto, destaca a importância de corrigir todo o desenvolvimento local e servidores internos”, diz Warner.
Três Vulnerabilidades — Até Agora
Log4j é uma ferramenta de registro quase onipresente em ambientes Java. Desde 9 de dezembro, três vulnerabilidades únicas foram divulgadas na estrutura de registro, cada uma de gravidade variável. A mais séria é a vulnerabilidade crítica do RCE (CVE-2021-44228) que a Apache Foundation divulgou em dezembro. 9.. A falha existe em um recurso de pesquisa Java Naming and Directory Interface (JNDI) que é habilitado por padrão nas versões Log4j 2.0-beta9 a Log4j 2.14.1.
Os atacantes podem explorar o recurso para obter controle remoto completo de sistemas vulneráveis, que podem incluir sistemas voltados para a Internet, sistemas internos, componentes de rede, máquinas virtuais, controle industrial e sistemas SCADA e ativos hospedados na nuvem.
A Apache Foundation lançou uma versão atualizada do framework de log (Log4j 2.15.0) para usuários do Java 8 em 10 de dezembro para abordar a vulnerabilidade em meio a relatos de invasores que buscam ativamente explorar a falha.
Em seguida, seguiu com uma segunda atualização em dezembro. 13 (Log4j 2.16.0 para Java 8 e Log4j 2.12.2 para Java 7) porque a correção original basicamente acabou abrindo sistemas para ataques de negação de serviço (DoS) (CVE 2021-45046) sob certas condições.
Em 18 de dezembro, a Apache Foundation emitiu outra atualização (Log4j 2.17.0 para Java 8) para abordar uma terceira vulnerabilidade recursiva infinita no Log4j (CVE-2021-45105) que descreveu como permitindo ataques DoS.
“A recursão infinita é se chamar de código de novo e de novo e de novo”, diz Saryu Nayyar, CEO da Gurucul. “Eventualmente, ele transbordará a memória alocada a ele e fornecerá a capacidade de injetar código malicioso fora do espaço de memória definido.”
Tanto o CVE 2021-45046 quanto o CVE-2021-45105 só podem ser explorados sob condições específicas não padrão e, portanto, são considerados menos graves do que o CVE-2021-44228, a falha que foi divulgada em 9 de dezembro, que afeta uma faixa muito ampla de organizações.
De acordo com pesquisadores de segurança do Google, o bug afeta mais de 35.000 pacotes Java — ou mais de 8% — de todos os pacotes no Maven Central, um dos maiores repositórios de pacotes Java. A difusão da falha e a relativa facilidade com que ela pode ser explorada atraíram atenção generalizada dentro da comunidade de atores ameaçadores.
Fornecedores de segurança relataram ter visto inúmeros atacantes motivados financeiramente, bem como grupos de ameaças apoiados pelo estado de países como Irã, China e Turquia, tentando ativamente explorar a falha.
A atividade levou a Agência de Segurança Cibernética e Infraestrutura dos EUA (CISA) a emitir uma diretiva de emergência na sexta-feira ordenando que todas as agências federais civis tomassem uma série de medidas para identificar, corrigir ou mitigar sistemas vulneráveis. As agências têm até 23 de dezembro para cumprir os requisitos da diretiva.
Os últimos desenvolvimentos vêm em meio a sinais de que as organizações estão fazendo pelo menos alguns progressos no enfrentamento da ameaça. Uma análise que o fornecedor de segurança na nuvem Wiz realizou mostra que 10 dias após a falha ter sido divulgada, as organizações, em média, corrigiram cerca de 45% de seus recursos vulneráveis na nuvem. No entanto, o fornecedor descobriu que 45% das máquinas vulneráveis permanecem desprotegidas contra a ameaça. Desses sistemas, 25% tinham privilégios administrativos e 7% estavam expostos à Internet.
Enquanto isso, um painel que a Sonatype lançou esta semana para rastrear downloads do Log4j mostrou que havia mais de 4,6 milhões de downloads da ferramenta de registro desde dezembro. 10. Quarenta por cento do que a empresa descreveu como os “downloads mais recentes” eram de versões vulneráveis do Log4j.
FONTE: DARK READING