Passo a passo da exploração de RCE por desserialização do Fastjson CVE-2017-18349, abrangendo identificação da superfície de ataque, impressão digital, injeção JNDI e obtenção de shell reverso em um ambiente de laboratório Docker.
Vamos começar com o que está sendo executado no ambiente. Listo todos os contêineres ativos:
docker ps
A vítima expõe apenas uma única porta: 8090
Atualmente, ainda não estou totalmente claro sobre o alvo. A partir dos resultados do docker ps, o sistema publica apenas um serviço notável externamente na porta 8090, que está mapeado para o serviço interno do contêiner. Esta é a principal superfície de ataque a ser analisada.
⇒ Eu faço um Curl diretamente para obter mais informações
curl -i 192.168.3.137:8090/
Análise da resposta:
Content-Type: application/json;charset=UTF-8.{"age": 25, "name": "Bob"}.⇒ Pensamento: Ao acessar a porta 8090, o servidor retorna dados JSON. Isso indica que o endpoint não serve apenas uma página web estática, mas possui um backend processando requisições e serializando dados em JSON para retornar ao cliente. A partir dos resultados do docker ps, o comando em execução dentro do contêiner mostra sinais de ser uma aplicação Java, então a próxima direção de inspeção é identificar (fingerprint) parsers JSON comuns em Java.
Em Java, bibliotecas JSON populares como Jackson, Gson e Fastjson se comportam de maneira diferente ao encontrar entradas incomuns. Portanto, podemos utilizar a técnica de Identificação (Fingerprinting) baseada em Erro. O erro retornado às vezes revela diretamente a biblioteca ou o mecanismo de processamento interno. Entre elas, o Fastjson é um alvo que precisa de verificação precoce porque versões antigas tinham múltiplas vulnerabilidades críticas relacionadas à Desserialização AutoType.
Aqui, não afirmo imediatamente que o backend usa Fastjson. Escolho apenas o Fastjson como a primeira direção de verificação porque ele tem uma impressão digital clara através da chave @type, e se for de fato uma versão antiga do Fastjson, a capacidade de exploração pode ir muito além de um erro de análise padrão, potencialmente levando até a RCE.
O Fastjson tem uma característica muito útil para identificação: ele reconhece a chave especial @type. Se o backend usar Fastjson e o corpo da requisição enviado para o fluxo de desserialização suportar AutoType, o parser pode tentar interpretar o valor de @type como um nome de classe Java.
Portanto, envio um payload contendo @type apontando para uma classe inexistente. O objetivo desta etapa não é explorar imediatamente, mas observar se o backend reage ao @type.
curl -i -X POST -H "Content-Type: application/json" \
-d '{"@type":"com.non.existent.Class"}' \
http://192.168.3.137:8090/
Se o backend usasse um parser JSON padrão e não se importasse com @type, este campo poderia ser ignorado ou tratado como uma chave normal no JSON. No entanto, aqui o backend reage com comportamento relacionado a tipo (type not match - tipo não corresponde), significando que a requisição entrou no fluxo de processamento de mapeamento classe/tipo.
A mensagem "type not match" é uma assinatura característica frequentemente encontrada quando o Fastjson processa @type mas a classe especificada não corresponde ao tipo de dado esperado pelo endpoint, ou a classe não existe/não é permitida ser desserializada.
⇒ Pensamento: O backend realmente analisa o corpo JSON da requisição POST, o campo @type não é ignorado, o parser possui um mecanismo de processamento de metadados de tipo, e o erro retornado corresponde ao comportamento do Alibaba Fastjson. Portanto, podemos concluir com alta confiança que o backend está usando Alibaba Fastjson.**
Após a etapa de identificação, não posso concluir imediatamente que o sistema é explorável. O backend usando Fastjson apenas prova que a requisição JSON entra no fluxo de processamento de @type.
Para executar um exploit de RCE, o seguinte deve ser verificado:
⇒ Pensamento: O erro type not match mostra que o backend reage ao @type, mas o payload atual usa apenas uma classe falsa para acionar um erro. Para a exploração real, precisamos substituir essa classe falsa por uma classe real presente no Java/JDK que seja capaz de criar comportamentos de saída como JNDI lookup.
Para determinar a versão, verifico diretamente dentro do contêiner/aplicação.
Após identificar que a aplicação está empacotada como o arquivo /usr/src/fastjsondemo.jar, prossigo com uma análise aprofundada desta estrutura de pacote para procurar a biblioteca de processamento JSON. Verificando a estrutura do diretório BOOT-INF/lib/ revela o arquivo fastjson-1.2.24.jar (Figura X).
O uso exato da versão 1.2.24 — a primeira e mais famosa versão afetada pela vulnerabilidade de desserialização sem nenhum mecanismo de defesa autoType — nos permite confirmar que o sistema é vulnerável ao CVE-2017-18349.
Encontrar fastjson-1.2.24.jar confirma que a aplicação usa uma versão muito antiga do Fastjson, pertencente ao grupo afetado pela falha de Desserialização AutoType. Nesta versão, o mecanismo de controle sobre o AutoType não foi endurecido como nas versões posteriores, portanto, em relação às condições da biblioteca, o sistema é suscetível à exploração através de classes gadget como JdbcRowSetImpl.
No entanto, a exploração real ainda depende de como o endpoint invoca o Fastjson. Se a aplicação analisar JSON em uma classe fixa, definir o payload @type no objeto raiz pode levar ao erro "type not match". Portanto, após identificar a versão, devemos continuar analisando a JVM, a classe gadget e o comportamento de callback LDAP para confirmar se a cadeia de exploração realmente atinge o JNDI lookup.
1. Analisando Barreiras da JVM
Além da versão do Fastjson, a versão do Java também é um fator decisivo. Verifico a JVM dentro do contêiner:
java -version
Esta é uma informação crítica porque as cadeias de exploração do Fastjson normalmente dependem de Injeção JNDI. Versões mais recentes do Java bloquearam o carregamento de classes de codebases externos via LDAP/RMI por padrão. No entanto, Java 8u102 é uma versão antiga que ainda não possui esses mecanismos de bloqueio.
Portanto, se o atacante puder acionar um JNDI lookup, a JVM da vítima tem a capacidade de baixar a classe de um servidor HTTP externo e carregá-la no runtime.
Após identificar o Fastjson antigo e a JVM, o próximo passo é encontrar uma classe presente no JDK que possa produzir comportamento perigoso quando desserializada.