Injeção de template não autenticada no Atlassian Jira (CVE-2019-11581)

I) Construção

1. Versão do bug

4.4.x
5.x.x
6.x.x
7.0.x
7.1.x
7.2.x
7.3.x
7.4.x
7.5.x
7.6.x anterior a 7.6.14 (versão corrigida para 7.6.x)
7.7.x
7.8.x
7.9.x
7.10.x
7.11.x
7.12.x
7.13.x anterior a 7.13.5 (versão corrigida para 7.13.x)
8.0.x anterior a 8.0.3 (versão corrigida para 8.0.x)
8.1.x anterior a 8.1.2 (versão corrigida para 8.1.x)
8.2.x anterior a 8.2.3 (versão corrigida para 8.2.x)

2. Construir e depurar

• Modifique o valor set JVM_SUPPORT_RECOMMENDED_ARGS= no arquivo ./bin/setenv.bat (ou similar com o arquivo ./bin/setenv.sh do Linux) para executar a depuração remota

set JVM_SUPPORT_RECOMMENDED_ARGS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005

• No IDE (Intellij) crie uma Configuração de Depuração: Remote JVM Debug com os valores host e port como localhost:5005 e Command line arguments for remote JVM

-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005

• Execute o arquivo ./bin/config.bat (ou com o arquivo config.sh no Linux) e ajuste "Jira home" para o diretório do seu jira home

• Execute o arquivo ./bin/start-jira.bat (ou ./bin/start-jira.sh no Linux). Verifique se a versão do Java e as portas 8080 e 5005 estão livres, caso contrário não conseguirá executar!

• Selecione o modo privado

• Até esta etapa, lembre-se de usar um endereço de e-mail que possa receber e-mails :)

• Configure e teste a conexão completamente

• Em http://localhost:8080/secure/admin/EditApplicationProperties!default.jspa ative o recurso Contact Administrators Form

• Apenas anoto alguns lembretes ao construir, você pode consultar construindo jira a partir do código fonte

II) Análise

Após ler o Advisory sabemos que esse bug está no ContactAdministrators e no SendBulkMail (este eu pulo porque requer autenticação). Então comecei a testar o recurso ContactAdministrators e capturei a requisição

• Vejo que a requisição vai para /secure/ContactAdministrators.jspa, então verifico o arquivo ./atlassian-jira/WEB-INF/web.xml para ver para qual classe essa requisição será encaminhada
  
  

• Assim, a requisição será processada em JiraWebworkActionDispatcher, então coloco um breakpoint em init e server nesta classe e executo a depuração

• Dessa forma, o programa parou na função server, tracei um pouco e o programa entrou em ContactAdministrators.doExecute()

• Depois passou para send, onde o programa lista as contas de administrador ativas

• Em seguida, o programa passa para a função sendTo. Aqui vemos que o programa cria um MailQueueItem e o adiciona na mailQueue.

• O programa chama a função EmailBuilder.withSubject. Aqui, a string subject do e-mail (enviada pelo atacante) é convertida de String para TemplateSources e atribuída ao parâmetro subjectTemplate do EmailBuilder.

• Na função renderLater, o programa cria um EmailRenderer e o usa para criar um RenderingMailQueueItem

• A partir daqui, ao retornar para a função ContactAdministrators.sendTo. Após criar um MailQueueItem, o programa adiciona o item na mailQueue e retorna para a função doExecute para Redirecionar. Se seguir este fluxo de depuração, não é possível pular para a parte onde o programa renderiza o e-mail, portanto não consigo chegar à parte onde ocorre a injeção de template. Então, o que devo fazer para acompanhar o processamento do e-mail???

• Vejo que no EmailRenderer existe a função renderNow (o programa apenas chama renderLater). Suponho que quando o e-mail na fila é chamado para ser renderizado, ele também seguirá o mesmo fluxo que renderNow, então decidi traçar a partir da função renderNow

• A partir de renderNow, o programa chama EmailRenderer.render(). Coloco um breakpoint aqui e faço a requisição novamente para ver se o programa realmente chega até aqui

• Felizmente, o programa seguiu o caminho que supus. Em seguida, o programa chama renderEmailSubject

• Na sequência, o programa chama DefaultVelocityTemplatingEngine.render(this.subjectTemplate)

• Chega em DefaultVelocityTemplatingEngine.applying e DefaultVelocityTemplatingEngine.asPlainText

• Continua chamando asPlainText(Writer writer)

• Chega em toWriterImpl porque o writer que passei é um Fragment, então o programa entra no else

private void toWriterImpl(Writer writer, boolean attachCartridge) throws IOException {
            if (this.source instanceof File) {
                File template = (File)this.source;
                if (attachCartridge) {
                    this.context.attachEventCartridge(DefaultVelocityTemplatingEngine.this.createDefaultCartridge());
                }